ConnectorClass
Содержание
Overview
ConnectorClass — это ресурс на уровне кластера, который определяет режимы доступа и спецификации поведения для конкретных типов инструментов. Он описывает:
- Формат адреса доступа к инструменту
- Поддерживаемые методы аутентификации
- Метод проверки доступности инструмента
- Метод проверки валидности аутентификации
- API-адрес инструмента
Например, следующее определение описывает коннектор типа Git, который поддерживает базовую аутентификацию:
Address Information
Информация об адресе определяет формат доступа к инструменту. В настоящее время поддерживаются конфигурации адреса типа string. Эта информация об адресе ограничивает тип поля, которому должен соответствовать текущий тип инструмента.
Это означает, что информация об адресе для подключения инструмента к платформе должна быть типа string.
Authentication Information
Authentication Type
Тип аутентификации определяет тип учетных данных, используемых для аутентификации инструмента. Инструмент может поддерживать несколько типов аутентификации, позволяя пользователям выбирать один из них при использовании инструмента.
Пользователи могут уникально именовать текущий тип аутентификации через
spec.auth.types[].name, который должен быть уникальным и не повторяться.spec.auth.types[].secretType, который указывает типSecret, необходимого для аутентификации, соответствующийkubernetes secret type.
Пример:
Authentication Parameters
Параметры, необходимые для учетных данных при аутентификации, определяются в spec.auth.types[].params.
Для стандартных типов Kubernetes secret с четко определёнными полями данных параметры можно опустить. Например:
kubernetes.io/basic-auth: аутентификация по имени пользователя и паролюkubernetes.io/ssh-auth: аутентификация по SSH-ключу
Для пользовательских типов аутентификации можно определить необходимые параметры аутентификации, при этом secretType указывается как kubernetes.io/opaque.
Например, для аутентификации GitLab с использованием Personal Access Token (PAT):
В этом случае потребуется, чтобы учетные данные, используемые в коннекторе инструмента, содержали информацию username и private-token.
Optional Authentication
Некоторые инструменты поддерживают доступ без аутентификации, что отмечается полем optional, указывающим, является ли аутентификация необязательной:
Например, следующий пример указывает, что учетные данные для basicAuth являются необязательными, а для sshAuth — обязательными.
В этом случае при подключении данного типа инструмента к платформе аутентификация типа basicAuth может быть пропущена.
Accessibility Check
Проверка доступности используется для подтверждения того, что к инструменту можно получить доступ нормально. Конфигурация способа проведения этой проверки задаётся через поле livenessProbe.
Например, следующий фрагмент указывает, что проверка выполняется с помощью HTTP-запросов.
Если инструмент возвращает статус 200, считается, что он доступен.
Authentication Checking
Проверка аутентификации используется для подтверждения того, как проверяется валидность аутентификационной информации для инструментов данного типа.
Например, следующий YAML указывает, что при проверке аутентификации инструмента будет выполнен http GET запрос с добавленным заголовком Authorization: abc.
authNameуказывает используемый тип аутентификации, должен совпадать сspec.auth.types[].name.- При проверке аутентификации будет напрямую использоваться информация об адресе коннектора инструмента.
spec.authProbes[].probe.http.methodзадаёт HTTP-метод для аутентификации, поддерживает GET и POST. По умолчанию GET.spec.authProbes[].probe.http.disableRedirectуказывает, отключать ли переадресацию при аутентификации. По умолчанию разрешена автоматическая переадресация.
Custom Authentication Check Parameters
Некоторые проверки аутентификации могут требовать дополнительных параметров, например, указания имени репозитория при проверке доступа к Git-репозиторию. Они могут быть заданы через spec.authProbes[].params.
Authentication Check Expressions
При настройке authProbes можно использовать выражения для динамического получения информации об учетных данных или информации о Connector.
Например,
- Выражения можно использовать в полях
httpHeadersиpath. - Формат выражений — go template
- Поддерживаемые верхнеуровневые поля:
.Connector: информация самого Connector.Secret: информация Secret, используемого для данных Connector.
- Методы, доступные в выражениях, можно посмотреть в документации sprig
- Например:
b64enc: Base64-кодирование строк,trimPrefixдля удаления префиксов строк
- Например:
Example
Проверка аутентификации Basic Auth
Коннектор будет выполнять проверку валидности на основе информации в ConnectorClass.
Приведённый выше yaml указывает проверку аутентификации для basic auth:
path: использует значениеrepository, заданное вauth.paramsвнутри информацииConnector, объединённое как/<repository>/info/refs?service=git-upload-packAuthorization: если в Connector настроен Secret, возвращаются поляusernameиpasswordиз Secret в base64.
ConnectorClass API {connectorclass_api}
ConnectorClass может предоставлять RESTful API для текущего ConnectorClass, что облегчает клиентам доступ к ресурсам внутри инструментов при использовании Connectors.
API ConnectorClass нужно настроить в поле spec.api, например:
Можно указать информацию о Service API через spec.api.ref. Если у API ConnectorClass есть фиксированный префикс адреса, его можно указать через spec.api.uri. Например:
Или можно указать абсолютный путь API через spec.api.uri. Например:
Вне зависимости от формы, итоговый разрешённый API-адрес будет храниться в status.api.address.url. Например:
Для указания API connector class через сервис
Для указания API connector class через URI
Для указания API connector class через сервис с использованием spec.api.uri для указания пути API
Для подробностей смотрите
Configurations
Вы можете указать конфигурационную информацию через spec.configurations. Например:
Обычно можно указать определённую конфигурационную информацию для типа инструмента, чтобы облегчить настройку при использовании. Например:
- Для инструментов типа
git— предоставить конфигурацию.gitconfig - Для инструментов типа
oci registry— предоставить конфигурациюconfig.json
Эти конфигурационные данные могут быть смонтированы в Pods в виде файлов через connectors-cs-driver.
Содержимое конфигурации поддерживает использование переменных, которые могут динамически рендериться при монтировании. Подробнее смотрите описание "Configuration file rendering" в connectors-cs-driver.
Example
Следующий ConnectorClass предоставляет файл с именем .gitconfig, используемый для игнорирования проверки SSL-сертификата при git clone.
Следующий ConnectorClass предоставляет файл с именем .gitconfig, который автоматически внедряет заголовки и заменяет URL Git при git clone.
More Information
Metadata
ConnectorClass — это стандартный ресурс Kubernetes, который можно помечать пользовательской информацией через labels и annotations.
Например:
Status Information
Информация о состоянии хранится в status.conditions. Типы включают:
APIReady: статус информации о возможности APIProxyReady: статус информации о возможности ProxyReady: указывает общий статус текущего ConnectorClass
Ready Condition
Ready Condition используется для указания текущего статуса ConnectorClass. Он агрегирует статусы других условий.
Если все остальные условия True, текущее условие True.
Если любое другое условие False, текущее условие False.
Если любое другое условие Unknown, текущее условие Unknown.
APIReady Condition
Указывает статус информации о сервисе API, настроенном для ConnectorClass. Сервис API задаётся через spec.api ConnectorClass.
Примечание:
- Проверка API лишь пытается запросить ссылку без проверки HTTP-статуса. Проверка здоровья сервиса API должна опираться на собственный механизм проверки здоровья API.
- Поскольку внешние сервисы могут изменяться в любой момент, статус API не может отражать актуальную информацию в реальном времени. Рекомендуется клиентам использовать эту информацию только как подсказку, не блокируя действия клиента.
ProxyReady Condition
Указывает статус информации о сервисе Proxy, настроенном для ConnectorClass. Сервис Proxy задаётся через spec.proxy ConnectorClass.
Compatibility
Обновления ConnectorClass могут повлиять на существующие Connectors. Если в ConnectorClass внесены несовместимые изменения, это может привести к тому, что ранее созданные Connectors станут недействительными. Ниже приведены некоторые изменения, которые могут привести к несовместимости:
-
Изменения в информации об аутентификации: если ConnectorClass изменяет поддерживаемые типы или методы аутентификации, это может привести к сбоям в работе Connectors, использующих старый метод аутентификации.
-
Изменения в конфигурационной информации: если изменяется конфигурация ConnectorClass, например, удаляется существующая конфигурация, это может привести к сбоям в работе Kubernetes workloads, зависящих от старой конфигурации.
Рекомендуется оценить область влияния перед обновлением ConnectorClass или при необходимости создать новый ConnectorClass.
More Examples
-
ConnectorClass, поддерживающий тип аутентификации
basic-auth -
ConnectorClass, одновременно поддерживающий типы аутентификации
basic-authиssh-auth, при этом дляbasic-authаутентификация необязательна. -
ConnectorClass для пользовательского типа аутентификации
-
ConnectorClass с настроенной
liveness probe -
ConnectorClass с настроенной
auth probe -
Полный пример конфигурации Git-коннектора: