#ConnectorClass

#Обзор

ConnectorClass — это ресурс уровня кластера, который определяет режимы доступа и спецификации поведения для конкретных типов инструментов.

Следующий пример определяет коннектор типа hello-git, который поддерживает базовую аутентификацию:

apiVersion: connectors.alauda.io/v1alpha1
kind: ConnectorClass
metadata:
  name: hello-git
spec:
  address:
    type: string  # Address in string format
  auth:
    types:
      - name: basicAuth
        secretType: kubernetes.io/basic-auth  # Using Basic Auth for authentication

В ConnectorClass режимы доступа и спецификации поведения для подключения инструментов к платформе определяются путем описания следующей информации:

• Формат адреса доступа к инструменту
• Поддерживаемые методы аутентификации
• Как проверять доступность инструмента
• Как проверять корректность аутентификации
• Как инструмент предоставляет API-возможности
• Какие возможности конфигурации предоставляет инструмент
• Метаданные для отображения в интерфейсе

В этом документе также приведены примеры, которые помогут читателям лучше понять, как настраивать ConnectorClass. Примеры

#Информация об адресе

Информация об адресе определяет формат доступа к инструменту. В настоящее время поддерживаются конфигурации адреса строкового типа. Эта информация об адресе ограничивает ограничения по типу поля, которым должен соответствовать текущий тип инструмента.

spec:
  address:
    type: string  # Currently supports only string type

На этом этапе это означает, что информация об адресе для подключения инструмента к платформе должна иметь тип string.

#Расширения адресов

spec.addressExtensions определяет дополнительные именованные адреса для текущего типа инструмента. Используется та же схема, что и у spec.params:

• spec.addressExtensions[].name — имя расширения. Должно быть уникальным в одном ConnectorClass.
• spec.addressExtensions[].type — тип значения. В настоящее время поддерживается только string.
• spec.addressExtensions[].default — значение по умолчанию (необязательно). Если не задано, это расширение обязательно в Connector.
• spec.addressExtensions[].description — описание (необязательно).

Этот механизм обычно используется, когда одному коннектору требуется несколько backend-адресов, например один адрес для Web-доступа и один API-адрес.

kind: ConnectorClass
metadata:
  name: github
spec:
  address:
    type: string
  addressExtensions:
    - name: api
      type: string
      description: GitHub API address, for example https://api.github.com
    - name: upload
      type: string
      default: https://uploads.github.com

При допуске коннектора применяется контракт класса, определенный здесь:

• Каждое расширение без default должно быть предоставлено Connector.
• Connector не может указывать имена расширений, не определенные в ConnectorClass.spec.addressExtensions.

О значениях на стороне коннектора и об использовании во время выполнения см. Расширения адресов Connector.

#Параметры

Параметры используются для определения дополнительных параметров при создании коннектора.

Вы можете определить обязательные параметры для создания коннектора с помощью поля connectorclass spec.params.

• spec.params[].name — имя параметра.
• spec.params[].type — тип параметра. В настоящее время поддерживается только тип string.
• spec.params[].default — значение параметра по умолчанию (необязательно). Если указано значение по умолчанию, пользователи могут не передавать этот параметр при создании коннектора.
• spec.params[].description — описание параметра (необязательно).

Например, следующая конфигурация позволяет пользователям указывать параметр sslVerify при создании коннектора типа git, со значением по умолчанию true.

kind: ConnectorClass
metadata:
  name: git
spec:
  params:
    - name: sslVerify
      type: string
      default: "true"

О конфигурации параметров при создании Connector см. документацию Connector.

В сочетании с возможностями connectors-csi-driver это обеспечивает более гибкую конфигурацию. Это особенно полезно, когда требуется предоставить параметризованные настройки. Например, при создании коннектора типа git пользователи могут передавать параметр sslVerify для управления проверкой SSL-сертификата. Подробнее см. документацию Конфигурация ConnectorClass.

#Информация об аутентификации

#Тип аутентификации

Тип аутентификации определяет вид учетных данных, используемых для аутентификации инструмента. Инструмент может поддерживать несколько типов аутентификации, позволяя пользователям выбирать один из них при работе с инструментом.

Пользователи могут однозначно именовать текущий тип аутентификации через:

• spec.auth.types[].name, который должен быть уникальным и не может повторяться.
• spec.auth.types[].secretType, который задает тип Secret, необходимый для аутентификации, и соответствует типу Secret Kubernetes.

Пример:

spec:
  auth:
    types:
      - name: basicAuth  # Name of the authentication type
        secretType: kubernetes.io/basic-auth  # Corresponding Secret type
      - name: sshAuth
        secretType: kubernetes.io/ssh-auth

Во встроенных типах Secret K8S, за исключением Opaque, существуют ограничения по полям. При предоставлении Secret пользователь должен убедиться, что его поля соответствуют ограничениям типа.

При использовании типа Opaque необходимо объявить параметры аутентификации.

Как и в k8s, вы также можете использовать собственный Secret Type. В этом случае необходимо объявить параметры аутентификации.

#Параметры аутентификации

Параметры, необходимые для учетных данных во время аутентификации, определяются через spec.auth.types[].params.

Для стандартных типов Secret Kubernetes с четко определенными полями данных параметры можно не указывать. Например:

• kubernetes.io/basic-auth: аутентификация по имени пользователя и паролю
• kubernetes.io/ssh-auth: аутентификация по SSH-ключу

Для пользовательских типов аутентификации можно определить требуемые параметры аутентификации; в этом случае secretType помечается как Opaque или указывается пользовательское имя.

Например, для аутентификации GitLab Personal Access Token (PAT):

spec:
  auth:
    types:
      - name: privateToken
        secretType: Opaque
        params:
          - name: username
            type: string
          - name: private-token
            type: string
      - name: oauth2
        secretType: example.com/oauth2
        params:
          - name: clientID
            type: string
          - name: clientSecret
            type: string

Это определение требует, чтобы учетные данные, используемые в коннекторе инструмента, содержали поля, указанные в params.

#Необязательная аутентификация

Некоторые инструменты поддерживают доступ без аутентификации; это обозначается полем optional, указывающим, является ли аутентификация необязательной:

Например, следующее означает, что учетные данные для basicAuth необязательны, а учетные данные для sshAuth обязательны.

spec:
  auth:
    types:
      - name: basicAuth
        optional: true  # Marking authentication as optional
        secretType: kubernetes.io/basic-auth
      - name: sshAuth
        secretType: kubernetes.io/basic-auth

На этом этапе при подключении инструмента этого типа к платформе аутентификацию типа basicAuth можно не указывать.

#Проверка доступности

Проверки доступности используются для подтверждения того, что к инструменту можно получить нормальный доступ. Настройка способа выполнения этой проверки осуществляется через поле livenessProbe.

Проверка доступности может выполняться либо с помощью HTTP-запросов, либо через API ConnectorClass.

#Проверка с использованием HTTP-запросов

Вы можете настроить spec.livenessProbe.http для выполнения проверки доступности с помощью HTTP-запросов.

Пример

Следующий фрагмент показывает, что проверка выполняется с использованием HTTP-запросов.

spec:
  livenessProbe:
    http:
      path: /

Если инструмент возвращает статус 200, он считается доступным.

Подробнее см. Проверка с использованием HTTP-запросов в Authentication Probe. Конфигурация идентична, за исключением путей к полям.

#Проверка с использованием API ConnectorClass

Вы можете настроить spec.livenessProbe.api для выполнения проверки доступности с использованием API ConnectorClass.

Пример

Следующий фрагмент показывает, что проверка выполняется с использованием API ConnectorClass.

spec:
  livenessProbe:
    api:
      path: /

Подробнее см. Проверка с использованием API ConnectorClass в Authentication Probe. Конфигурация идентична, за исключением путей к полям.

#Проверка аутентификации

Проверка аутентификации используется для подтверждения корректности учетных данных аутентификации для инструментов этого типа. Если проверка аутентификации не требуется, поле authProbes можно не указывать.

• spec.authProbes[].authName указывает проверяемый тип аутентификации и должен совпадать с одним из имен, определенных в spec.auth.types[].name.

Проверка аутентификации может выполняться либо с помощью HTTP-запросов, либо через API ConnectorClass.

#Проверка с использованием HTTP-запросов

Вы можете настроить spec.authProbes[].probe.http для выполнения проверки аутентификации с помощью HTTP-запросов.

• spec.authProbes[].probe.http.host указывает целевой host для проверки аутентификации. По умолчанию используется host из адреса коннектора.
• spec.authProbes[].probe.http.path указывает путь запроса для проверки аутентификации. Это абсолютный путь, который будет добавлен к URI host, полученному из spec.address коннектора, при выполнении проверки. Если spec.address содержит префикс пути, этот префикс будет игнорироваться при проверке аутентификации. Чтобы включить префикс пути, используйте Authentication Check Expressions для динамического получения этого значения.
• spec.authProbes[].probe.http.method указывает HTTP-метод для проверки аутентификации; поддерживаются GET и POST. По умолчанию используется GET.
• spec.authProbes[].probe.http.disableRedirect указывает, следует ли отключить HTTP-перенаправления во время проверки аутентификации. По умолчанию false (автоматическое перенаправление разрешено).
• spec.authProbes[].probe.http.httpHeaders указывает HTTP-заголовки, которые следует включить в запросы проверки аутентификации.
• spec.authProbes[].probe.http.scheme указывает URI scheme для проверки аутентификации. По умолчанию используется scheme из адреса коннектора.
• spec.authProbes[].probe.http.response.cel указывает ожидаемый ответ для проверки аутентификации.
  • Поведение по умолчанию: при успехе возвращается 200.
  • Пользовательская проверка: при настройке CEL-выражения аутентификация считается успешной, если выражение вычисляется в true.

CEL-выражение может использовать следующие переменные:

Пример

Следующая YAML-конфигурация демонстрирует, что во время проверки аутентификации система отправит к адресу коннектора запрос GET https://example.com/ HTTP/1.1 с заголовком Authorization: abc.

kind: ConnectorClass
metadata:
  name: example-class
spec:
  authProbes:
    - authName: basicAuth  # Corresponding authentication type
      probe:
        http:
          httpHeaders:
            Authorization: abc
          path: /
          method: GET # Defaults to GET, supports both POST and GET methods
          disableRedirect: false # Defaults to false, allowing automatic redirection
          response:
            cel: response.statusCode == 200  # Custom validation expression
---
kind: Connector
metadata:
  name: example
spec:
  connectorClassName: example-class
  address: https://example.com

#Проверка с использованием API ConnectorClass

Вы можете настроить spec.authProbes[].probe.api для выполнения проверки аутентификации с использованием API ConnectorClass. Сначала необходимо настроить spec.api в спецификации ConnectorClass. Ответ 200 указывает на успешную аутентификацию, а ответ 401 или 403 — на ошибку аутентификации. Подробнее об API ConnectorClass.

• spec.authProbes[].probe.api.path указывает путь endpoint API для проверки аутентификации. Это относительный путь, который будет добавлен к адресу API, полученному из конфигурации spec.api ConnectorClass. Если spec.api содержит префикс пути, этот префикс будет включен при выполнении проверки аутентификации.

Пример

Следующая YAML-конфигурация демонстрирует, что во время проверки аутентификации система отправит запрос GET https://example-api.default.svc.cluster.local/api/auth/check HTTP/1.1 к API ConnectorClass.

kind: ConnectorClass
metadata:
  name: example-class
spec:
  api:
    ref:
      kind: Service
      name: example-api
      namespace: default
    uri: /api
  authProbes:
    - authName: basicAuth
      probe:
        api:
          path: /auth/check # It is a relative path of the API address resolved from `spec.api` of connectorclass
---
kind: Connector
metadata:
  name: example
spec:
  connectorClassName: example-class
  address: https://example.com

#Пользовательские параметры проверки аутентификации

Некоторые сценарии проверки аутентификации могут требовать дополнительных параметров, например указания имени репозитория при проверке доступа к Git-репозиторию. Эти параметры можно определить с помощью spec.authProbes[].params.

kind: ConnectorClass
metadata:
  name: example-class
spec:
  authProbes:
    - authName: basicAuth  # Corresponding authentication type
      params:
        - name: repository
          type: string

#Выражения для проверки аутентификации

При настройке authProbes можно использовать выражения для динамического получения информации об учетных данных или метаданных Connector.

Например:

spec:
  authProbes:
    - authName: basicAuth  # Corresponding authentication type
      probe:
        http:
          httpHeaders:
            Authorization: {{ .Secret.StringData.token }}
          path: /
      params:
        - name: repository
          type: string

• Выражения можно использовать в полях probe.http.httpHeaders, probe.http.path и probe.api.path.
• Формат выражений соответствует синтаксису Go template.
• Поддерживаемые поля верхнего уровня включают:
  • .Connector: содержит информацию о самом ресурсе Connector
  • .Secret: содержит данные Secret, используемые для аутентификации Connector
• Доступные методы внутри выражений описаны в библиотеке sprig:
  • Например: b64enc для кодирования строк в Base64, trimPrefix для удаления префиксов строк

Пример

Проверка Basic Authentication:

spec:
  authProbes:
    - authName: basicAuth
      params:
        - name: repository
          type: string
      probe:
        http:
          path: /{{- range .Connector.Spec.Auth.Params }}{{- if eq .Name "repository" }}{{ .Value.StringVal }}{{ end }}{{- end }}/info/refs?service=git-upload-pack
          httpHeaders:
          - name: Authorization
            value: >-
              {{- if .Secret }}Basic {{ printf "%s:%s" .Secret.StringData.username .Secret.StringData.password | b64enc }} {{- end }}

Коннектор выполнит проверку аутентификации на основе конфигурации, определенной в ConnectorClass.

Приведенный выше YAML демонстрирует проверку Basic Authentication:

• path: использует значение repository из auth.params коннектора, формируя путь /<repository>/info/refs?service=git-upload-pack
• Authorization: когда Connector настроен с Secret, поля username и password кодируются в Base64 и включаются в заголовок Basic authentication.

#Настройка логики аутентификации на основе Rego

Когда коннекторам инструментов требуется более сложная логика аутентификации, можно использовать настройку логики аутентификации на основе Rego.

Rego — это декларативный язык политик, который позволяет определять логику аутентификации. В ConnectorClass политики Rego задаются в поле auth.types[].generator.rego:

apiVersion: connectors.alauda.io/v1alpha1
kind: ConnectorClass
metadata:
  name: example
spec:
  address:
    name: address
    type: string
  auth:
    types:
    - name: rego-auth
      secretType: Opaque
      generator:
        rego: |
          package proxy
          auth = {
            "position": "header",
            "auth": {
              "Authorization": concat(" ", ["Bearer", input.data.token])
            }
          }

Политика Rego должна соответствовать следующим правилам:

• Определять правила в пакете proxy
• Формировать объект auth со следующей структурой:
  • position: место внедрения аутентификации, например "header", "query" или "body"
  • contentType: тип содержимого для внедрения в body (необязательно, используется вместе с position: "body")
  • auth: map пар ключ-значение для аутентификации

#Переменные, доступные в Rego

#Примеры политик Rego

#Basic Authentication

spec:
  auth:
    types:
    - name: basic-rego-auth
      secretType: Opaque
      generator:
        rego: |
          package proxy
          auth = {
            "position": "header",
            "auth": {
              "Authorization": concat(" ", ["Basic", base64.encode(concat(":", [input.data.username, input.data.password]))])
            }
          }

#Аутентификация по API Key

spec:
  auth:
    types:
    - name: apikey-rego-auth
      secretType: Opaque
      generator:
        rego: |
          package proxy
          auth = {
            "position": "query",
            "auth": {
              "api_key": input.data.apikey
            }
          }

#Аутентификация в JSON Body

spec:
  auth:
    types:
    - name: body-rego-auth
      secretType: Opaque
      generator:
        rego: |
          package proxy
          auth = {
            "position": "body",
            "contentType": "application/json",
            "auth": {
              "username": input.data.username,
              "password": input.data.password,
              "client_id": input.data.client_id
            }
          }

#Продвинутые приемы Rego

Вы можете использовать условную логику Rego для разных методов аутентификации:

#Условная аутентификация

spec:
  auth:
    types:
    - name: conditional-auth
      secretType: Opaque
      generator:
        rego: |
          package proxy

          # Default uses API key
          auth = {
            "position": "header",
            "auth": {
              "X-API-Key": input.data.apikey
            }
          }

          # Use OAuth token if available
          auth = {
            "position": "header",
            "auth": {
              "Authorization": concat(" ", ["Bearer", input.data.oauth_token])
            }
          } {
            input.data.oauth_token != ""
          }

#Аутентификация на основе времени

spec:
  auth:
    types:
    - name: time-based-auth
      secretType: Opaque
      generator:
        rego: |
          package proxy

          import time

          # Get current time
          current_time := time.now_ns() / 1000000000

          auth = {
            "position": "header",
            "auth": {
              "X-Timestamp": sprintf("%d", [current_time]),
              "X-Signature": hmac.sha256(input.data.api_secret, sprintf("%d", [current_time]))
            }
          }

Подробнее о языке Rego см. в:

• Rego Policy Language

#API ConnectorClass

API ConnectorClass позволяет разработчикам расширять API-возможности ConnectorClass через дополнительный HTTP API service. Это предоставляет RESTful API для ConnectorClass, позволяя клиентам легко получать доступ к ресурсам внутри инструментов при использовании Connector.

Если не требуется предоставлять собственные API-возможности для инструмента, spec.api можно оставить неопределенным.

#Настройка адреса API

API ConnectorClass настраивается в поле spec.api. Указать API service можно тремя способами:

1. Через ссылку на Kubernetes Service:

spec:
  api:
    ref:
      kind: Service
      name: git
      namespace: default

2. Через ссылку на Service с префиксом URI-пути:

Если у адреса API есть фиксированный префикс пути, его можно указать через spec.api.uri:

spec:
  api:
    ref:
      kind: Service
      name: git
      namespace: default
    uri: /api

3. Через абсолютный URI:

Также можно использовать spec.api.uri для указания абсолютного пути API:

spec:
  api:
    uri: https://git.example.com/api

#Разрешение адреса API

Независимо от использованного способа настройки, итоговый разрешенный адрес API будет сохранен в status.api.address.url. Например:

spec:
  api:
    ref:
      kind: Service
      name: git
      namespace: default
    uri: /prefix
status:
  api:
    address:
      url: https://git.default.svc/prefix

Дополнительная информация:

• Connector API
• ConnectorClass API Definition Specification

#Описание OpenAPI

Описание OpenAPI — это необязательная конфигурация, которая выполняет две основные задачи:

• Помечает, является ли API пользовательским API или использует Connector Proxy для доступа к оригинальному API инструмента
• Предоставляет определения API для поддержки ссылок на API в динамических формах клиента

Вы можете определить описание OpenAPI через spec.api.openapi. Структура соответствует спецификации OpenAPI 3.0. Например:

spec:
  api:
    openapi:
      openapi: "3.0.1"
      info:
        title: Git API
        version: "1.0.0"

В путях API можно определить расширение x-provider-type, чтобы указать, является ли API пользовательским или использует Proxy для доступа к оригинальному API инструмента. Допустимые значения: api или proxy.

Расширение x-provider-type определяется как: api.openapi.paths[<path>].<verb>[x-provider-type]

При использовании x-provider-type: proxy можно также определить x-openapi-address в той же операции, чтобы выбрать backend-адрес:

• пусто или не указано: fallback на Connector.spec.address
• имя расширения: разрешить из Connector.spec.addressExtensions[*].name
• прямой URL: использовать полный адрес http/https

Пример:

spec:
  api:
    openapi:
      openapi: "3.0.1"
      info:
        title: Gitlab API
        version: "1.0.0"
      paths:
        /git/api:
          get:
            summary: Get Git API
            x-provider-type: api  # Use custom API
        /api/v4/projects:
          get:
            summary: Get Gitlab Projects API
            x-provider-type: proxy  # Use Proxy to access the tool's original API
            x-openapi-address: api

Когда требуется ссылаться на API в динамических формах, в spec.api.openapi требуется дополнительная настройка. Подробнее см. Использование Connectors API в динамических формах.

#Возможности конфигурации

Возможности конфигурации определяют файлы конфигурации, которые ConnectorClass предоставляет клиентам. Эти файлы могут монтироваться в Pods с помощью Connectors-CSI Driver.

#Типы конфигураций

• Пользовательские конфигурации: определяются в spec.configurations
• Встроенные конфигурации: автоматически предоставляются Connectors-CSI Driver (см. Встроенные конфигурации)

#Пользовательские конфигурации

Конфигурации указываются через spec.configurations:

kind: ConnectorClass
metadata:
  name: git
spec:
  configurations:
  - name: gitconfig
    data:
      .gitconfig: |
        [http]
            extraHeader = Authorization: Basic {{ .context.token | b64enc }}
        [url "{{ .connector.status.proxyAddress }}"]
            insteadOf = {{ .connector.spec.address }}

Подробнее см. Рендеринг файлов конфигурации

Примечание: spec.configurations необязателен. Если он не определен, доступны только встроенные конфигурации.

#Информация о метаданных для отображения

ConnectorClass — это стандартный ресурс k8s, которому можно присвоить пользовательскую информацию с помощью labels и annotations.

Например:

Например:

apiVersion: connectors.alauda.io/v1alpha1
kind: ConnectorClass
metadata:
  name: git
  labels:
    connectors.cpaas.io/git: "true"
  annotations:
    ui.cpaas.io/icon: "data:image/svg+xml;base64,PD94bWwgdmVyc2..."
    cpaas.io/display-name: Git
    cpaas.io/description: "Connect to any Git tool"
    connectors.cpaas.io/readme: "this is readme..."
    connectors.cpaas.io/docs-link: "/alauda-devops-connectors/concepts/connectorclass/git"

#Proxy ConnectorClass

Proxy ConnectorClass используется для настройки proxy-адреса для ConnectorClass.

Proxy ConnectorClass настраивается через spec.proxy. Например:

spec:
  proxy:
    ref:
      kind: Service
      name: proxy
      namespace: default
    # uri: https://proxy.example.com

Connector будет использовать proxy-адрес для проксирования запроса к ConnectorClass. Подробнее

#Использование Rego для извлечения token из запроса

При использовании встроенного reverse proxy можно настроить правила Rego через spec.proxy.authExtractor, чтобы извлекать token из запросов клиента и тем самым позволить встроенному reverse proxy проверять аутентификацию клиента с использованием извлеченного token.

Например:

spec:
  proxy:
    authExtractor:
      rego: |
        package proxy
        auth = {
          "token": input.request.headers["Private-Token"][0]
        }

Правила Rego должны соответствовать следующим требованиям:

• Правила должны быть определены в пакете proxy
• Используйте переменную auth для возврата token, где token имеет строковый тип, например: auth = { "token": "abcd1234" }
• Если token невозможно извлечь, возвращайте пустую строку, например: auth = { "token": "" }

В Rego доступны следующие переменные:

Примечания:

• Ключи заголовков в headers используют формат Canonical MIME Header Key (первая буква заглавная)
• При реализации правил Rego обеспечьте устойчивую логику. Например, возвращайте пустую строку, если input.request.headers имеет значение null или пусто.

Пример

spec:
  proxy:
    authExtractor:
      rego: |
        package proxy

        default auth = {
          "token": ""
        }

        auth = {
          "token": input.request.headers["Private-Token"][0]
        } if {
          input.request.headers != null
          input.request.headers["Private-Token"] != null
          count(input.request.headers["Private-Token"]) > 0
        }

В этом примере реализовано устойчивое извлечение token следующим образом:

• Определяется правило по умолчанию, возвращающее пустую строку token
• Перед обращением к заголовкам выполняется проверка, что они существуют и не равны null
• Проверяется, что конкретный ключ заголовка существует и содержит хотя бы одно значение

Подробнее о продвинутых правилах Rego см. в документации Rego Policy Language. Подробнее об использовании встроенного reverse proxy см. Connectors Proxy.

#Тип resolver

Proxy-адрес ConnectorClass будет разрешаться в соответствии с указанным типом resolver.

Тип resolver настраивается через аннотацию connectors.cpaas.io/proxy-resolver. Например:

apiVersion: connectors.alauda.io/v1alpha1
kind: ConnectorClass
metadata:
  name: oci
  annotations:
    connectors.cpaas.io/proxy-resolver: "path"

Это поле является соглашением между ConnectorClass-Proxy и Connector. Необязательное.

Поддерживаемые значения: host, path. Значение по умолчанию — host.

• формат host: http://{.ConnectorClass.Status.ProxyAddress.URL}
• формат path: http://{.ConnectorClass.Status.ProxyAddress.URL}/namespaces/{namespace}/connectors/{connector-name}

#Информация о статусе

После определения ресурса ConnectorClass информация о его статусе будет храниться в status.

Типы status.conditions включают:

• APIReady: информация о статусе возможности API
• ProxyReady: информация о статусе возможности Proxy
• Ready: обозначает общий статус текущего ConnectorClass

Состояние Ready

Ready Condition используется для обозначения состояния текущего ConnectorClass. Оно агрегирует состояние других условий.

• Когда другие Conditions равны True, текущее Condition равно True.
• Когда любое другое Condition равно False, текущее Condition равно False.
• Когда любое другое Condition равно Unknown, текущее Condition равно Unknown.

Состояние APIReady

Указывает информацию о статусе API service, настроенного для ConnectorClass. API service настраивается через spec.api ConnectorClass.

Примечание:

• Проверка API будет только пытаться выполнить запрос по ссылке и не будет принимать решения на основе HTTP return value. Проверка состояния API service должна опираться на собственный механизм health check этого API service.
• Поскольку API service может измениться в любой момент, информация о статусе API не может отражать данные в реальном времени. Рекомендуется использовать эту информацию как подсказку, а не полагаться на нее для блокировки поведения клиента.

Состояние ProxyReady

Указывает информацию о статусе Proxy service, настроенного для ConnectorClass. Proxy service настраивается через spec.proxy ConnectorClass.

#Совместимость

Обновления ConnectorClass могут влиять на существующие Connector. Если в ConnectorClass внесены несовместимые изменения, это может привести к тому, что ранее созданные Connector станут недействительными. Ниже приведены возможные изменения, которые могут вызвать несовместимость:

1. Изменения в информации об аутентификации: если ConnectorClass изменяет поддерживаемые типы или методы аутентификации, это может привести к сбоям у Connector, использующих старый метод аутентификации.

2. Изменения в информации о конфигурации: если информация о конфигурации ConnectorClass изменится, например будет удалена существующая конфигурация, это может привести к сбоям у Kubernetes workloads, зависящих от старой конфигурации.

Рекомендуется при обновлении ConnectorClass подтверждать область влияния, либо при необходимости создавать новый ConnectorClass.

#Больше примеров

• ConnectorClass, поддерживающий тип аутентификации basic-auth

  apiVersion: connectors.alauda.io/v1alpha1
  kind: ConnectorClass
  metadata:
    name: git
  spec:
    address:
      type: string
    auth:
      types:
        - name: basicAuth
          secretType: kubernetes.io/basic-auth
          optional: true

• ConnectorClass с пользовательским типом аутентификации

  apiVersion: connectors.alauda.io/v1alpha1
  kind: ConnectorClass
  metadata:
    name: sample
  spec:
    address:
      type: string
    auth:
      types:
        - name: patAuth
          optional: true
          secretType: Opaque
          params:
          - name: username
          - name: privateToken

• ConnectorClass, настроенный с liveness probe

  apiVersion: connectors.alauda.io/v1alpha1
  kind: ConnectorClass
  metadata:
    name: git
  spec:
    address:
      type: string
    auth:
      types:
        - name: basicAuth
          optional: true
          secretType: kubernetes.io/basic-auth
    livenessProbe:
      http:
        path: /

• ConnectorClass, настроенный с auth probe

  apiVersion: connectors.alauda.io/v1alpha1
  kind: ConnectorClass
  metadata:
    name: git
    labels:
      connectors.cpaas.io/git: "true"
  spec:
    address:
      type: string
    auth:
      types:
        - name: basicAuth
          secretType: kubernetes.io/basic-auth
          optional: true
    livenessProbe:
      http:
        path: /
    authProbes:
      - authName: basicAuth
        params:
          - name: repository
            type: string
        probe:
          http:
            path: /{{- range .Connector.Spec.Auth.Params }}{{- if eq .Name "repository" }}{{ .Value.StringVal }}{{ end }}{{- end }}/info/refs?service=git-upload-pack
            httpHeaders:
            - name: Authorization
              value: >-
                {{- if .Secret }}Basic {{ printf "%s:%s" .Secret.StringData.username .Secret.StringData.password | b64enc }} {{- end }}

• Полный пример конфигурации Git connector

  apiVersion: connectors.alauda.io/v1alpha1
  kind: ConnectorClass
  metadata:
    name: git
  spec:
    address:
      name: address
      type: string
    auth:
      types:
        - name: basicAuth
          secretType: kubernetes.io/basic-auth
          optional: true
    livenessProbe:
      http:
        path: /
    authProbes:
      - authName: basicAuth
        params:
          - name: repository
            type: string
        probe:
          http:
            path: /{{- range .Connector.Spec.Auth.Params }}{{- if eq .Name "repository" }}{{ .Value.StringVal }}{{ end }}{{- end }}/info/refs?service=git-upload-pack
            httpHeaders:
            - name: Authorization
              value: >-
                {{- if .Secret }}Basic {{ printf "%s:%s" .Secret.StringData.username .Secret.StringData.password | b64enc }} {{- end }}

#Подробнее

• Руководство пользователя Connector