#Развертывание с высокой доступностью

Для производственных сред рекомендуется разворачивать систему Connectors в конфигурации с высокой доступностью (HA), чтобы обеспечить непрерывность обслуживания и отказоустойчивость.

#Обзор основных шагов

Настройка Connector с высокой доступностью включает три шага:

1. Установите replicas ≥ 2 — укажите spec.workloads[].replicas для каждого компонента Connectors. Минимально настройте ConnectorsCore (api, controller-manager, proxy) и любые используемые компоненты плагинов.
2. Положитесь на встроенную anti-affinity — система автоматически добавляет правила pod anti-affinity preferredDuringSchedulingIgnoredDuringExecution, чтобы реплики распределялись по узлам без дополнительной настройки.
3. При необходимости настройте affinity для многозональных кластеров — переопределите spec.workloads[].template.spec.affinity, чтобы обеспечить распределение по зонам с использованием requiredDuringSchedulingIgnoredDuringExecution, если это требуется.

Подробнее о каждом шаге рассказано ниже.

#Настройка Replicas

Вы можете увеличить количество реплик для каждой рабочей нагрузки, чтобы обеспечить высокую доступность. Это делается через поле workloads в спецификации компонента. Для производственных сред мы рекомендуем настраивать как минимум 2 реплики для каждой рабочей нагрузки, чтобы обеспечить непрерывность обслуживания при отказах узлов или при rolling update.

Ниже приведены конкретные примеры для каждого основного компонента connector:

#ConnectorsCore

ConnectorsCore включает три основные рабочие нагрузки: API server, controller manager и proxy. Для высокой доступности настройте все три с несколькими репликами:

apiVersion: operator.connectors.alauda.io/v1alpha1
kind: ConnectorsCore
metadata:
  name: connectors-core
  namespace: connectors-system
spec:
  workloads:
  - name: connectors-api
    replicas: 2
  - name: connectors-controller-manager
    replicas: 2
  - name: connectors-proxy
    replicas: 2

Спустя некоторое время у всех pod компонента connectors-core количество реплик равно 2, за исключением connectors-csi.

$ kubectl get pod -n connectors-system
NAME                                             READY   STATUS    RESTARTS   AGE
connectors-api-58fc8b45c4-9n8hc                  1/1     Running   0          67s
connectors-api-58fc8b45c4-12da7                  1/1     Running   0          67s
connectors-controller-manager-548659cdff-1d2dd   1/1     Running   0          35s
connectors-controller-manager-548659cdff-s7gnn   1/1     Running   0          35s
connectors-proxy-64bb994cd9-jbp2l                1/1     Running   0          61s
connectors-proxy-64bb994cd9-dfade                1/1     Running   0          61s

#ConnectorsGit

ConnectorsGit запускает один deployment плагина для интеграции с Git Server:

apiVersion: operator.connectors.alauda.io/v1alpha1
kind: ConnectorsGit
metadata:
  name: connectors-git
  namespace: connectors-system
spec:
  workloads:
  - name: connectors-git-plugin
    replicas: 2

Спустя некоторое время у всех pod компонента connectors-git количество реплик равно 2.

$ kubectl get pod -n connectors-system
NAME                                                    READY   STATUS    RESTARTS   AGE
connectors-git-plugin-84985b9d7d-vllp6                  1/1     Running   0          67s
connectors-git-plugin-84985b9d7d-vllp6                  1/1     Running   0          67s

#ConnectorsOCI

ConnectorsOCI запускает один deployment плагина, который отвечает за интеграцию с OCI registry:

apiVersion: operator.connectors.alauda.io/v1alpha1
kind: ConnectorsOCI
metadata:
  name: connectors-oci
  namespace: connectors-system
spec:
  workloads:
  - name: connectors-oci-plugin
    replicas: 2

Спустя некоторое время у всех pod компонента connectors-oci количество реплик равно 2.

$ kubectl get pod -n connectors-system
NAME                                                    READY   STATUS    RESTARTS   AGE
connectors-oci-plugin-84985b9d7d-vllp6                  1/1     Running   0          67s
connectors-oci-plugin-84985b9d7d-vllp6                  1/1     Running   0          67s

#ConnectorsHarbor

ConnectorsHarbor запускает один deployment плагина для функций, специфичных для Harbor:

apiVersion: operator.connectors.alauda.io/v1alpha1
kind: ConnectorsHarbor
metadata:
  name: connectors-harbor
  namespace: connectors-system
spec:
  workloads:
  - name: connectors-harbor-plugin
    replicas: 2

Спустя некоторое время у всех pod компонента connectors-harbor количество реплик равно 2.

$ kubectl get pod -n connectors-system
NAME                                                      READY   STATUS    RESTARTS   AGE
connectors-harbor-plugin-84985b9d7d-vllp6                  1/1     Running   0          67s
connectors-harbor-plugin-84985b9d7d-vllp6                  1/1     Running   0          67s

#Компоненты без Workloads

Остальные компоненты connector не имеют рабочих нагрузок типа Deployment и, следовательно, не требуют настройки реплик.

#Встроенная pod Anti-Affinity

Система включает встроенные правила pod anti-affinity, чтобы обеспечить распределение реплик по разным узлам. По умолчанию система использует preferredDuringSchedulingIgnoredDuringExecution с весом 100, что означает: scheduler будет по возможности размещать pod на разных узлах, но при отсутствии других вариантов все равно сможет запланировать их на одном узле.

Такая конфигурация по умолчанию обеспечивает:

• распределение pod по разным узлам, когда это возможно
• возможность планирования deployment даже при ограниченном числе узлов в кластере
• автоматический failover, когда узел становится недоступен

#Настройка правил Affinity

Если правила affinity по умолчанию не соответствуют вашим требованиям, вы можете переопределить их через конфигурацию workloads. Поле template.spec.affinity позволяет задать собственные правила affinity.

Для многозональных кластеров можно настроить zone-aware scheduling, чтобы распределять pod по availability zones. В следующем примере используется requiredDuringSchedulingIgnoredDuringExecution для принудительного распределения по зонам в сочетании с preferredDuringSchedulingIgnoredDuringExecution, чтобы внутри каждой зоны предпочитать распределение по узлам:

apiVersion: operator.connectors.alauda.io/v1alpha1
kind: ConnectorsCore
metadata:
  name: connectors-core
  namespace: connectors-system
spec:
  workloads:
  - name: connectors-api
    replicas: 3
    template:
      spec:
        affinity:
          podAntiAffinity:
            # Hard requirement: pods must be distributed across different zones
            requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchLabels:
                  control-plane: api
                  app.kubernetes.io/name: connectors
              topologyKey: topology.kubernetes.io/zone
            # Soft requirement: prefer distributing pods across different nodes within the same zone
            preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchLabels:
                    control-plane: api
                    app.kubernetes.io/name: connectors
                topologyKey: kubernetes.io/hostname

Такая конфигурация обеспечивает:

• строгое распределение pod по разным availability zones (жесткое требование)
• внутри одной зоны pod по возможности планируются на разных узлах (мягкое требование)
• устойчивость как к отказам уровня зоны, так и к отказам уровня узла