#High Availability Deployment

For production environments, it is recommended to deploy the Connectors system in a high availability (HA) configuration to ensure service continuity and fault tolerance.

The whole Connectors install is driven by a single ConnectorsConfig resource (see the Installation Guide). To run components in HA, edit that same ConnectorsConfig and set per-component workload settings under spec.components.<name>.spec.workloads.

#Key Steps Overview

Configuring HA on ConnectorsConfig involves three steps:

1. Set replicas ≥ 2 — Specify replicas for each managed component's workloads through spec.components.<name>.spec.workloads[]. At minimum, configure core (api, controller-manager, proxy) and any plugin components you use.
2. Rely on built-in anti-affinity — The operator automatically adds preferredDuringSchedulingIgnoredDuringExecution pod anti-affinity rules so replicas are spread across nodes with no extra configuration required.
3. Customize affinity for multi-zone clusters (optional) — Override spec.components.<name>.spec.workloads[].template.spec.affinity to enforce zone-level distribution using requiredDuringSchedulingIgnoredDuringExecution if needed.

More details on each step are provided below.

#Configuring Replicas

Increase the number of replicas for each component's workloads to achieve high availability. For production environments, we recommend configuring at least 2 replicas for each workload to ensure service continuity during node failures or rolling updates.

The components that ship Deployment workloads, and the workload names you address from ConnectorsConfig, are:

The other connector components do not have Deployment workloads and therefore do not require replica configuration. The connectors-csi DaemonSet that core also manages runs one pod per node and is not part of this list.

The following ConnectorsConfig sets HA replicas for every Deployment workload in one place:

apiVersion: operator.connectors.alauda.io/v1alpha1
kind: ConnectorsConfig
metadata:
  name: connectors-config
spec:
  components:
    core:
      spec:
        workloads:
          - name: connectors-api
            replicas: 2
          - name: connectors-controller-manager
            replicas: 2
          - name: connectors-proxy
            replicas: 2
    git:
      spec:
        workloads:
          - name: connectors-git-plugin
            replicas: 2
    oci:
      spec:
        workloads:
          - name: connectors-oci-plugin
            replicas: 2
    harbor:
      spec:
        workloads:
          - name: connectors-harbor-plugin
            replicas: 2

After a period of time, each configured workload scales to 2 replicas:

$ 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
connectors-git-plugin-84985b9d7d-vllp6           1/1     Running   0          61s
connectors-git-plugin-84985b9d7d-abcde           1/1     Running   0          61s
connectors-oci-plugin-84985b9d7d-7k2qm           1/1     Running   0          61s
connectors-oci-plugin-84985b9d7d-h9x4n           1/1     Running   0          61s
connectors-harbor-plugin-84985b9d7d-b3p8r        1/1     Running   0          61s
connectors-harbor-plugin-84985b9d7d-z6t2v        1/1     Running   0          61s

#Built-in Pod Anti-Affinity

The system includes built-in pod anti-affinity rules to ensure that replicas are distributed across different nodes. By default, the system uses preferredDuringSchedulingIgnoredDuringExecution with a weight of 100, which means the scheduler will try to place pods on different nodes when possible, but will still schedule them on the same node if no other options are available.

This default configuration ensures:

• Pods are spread across different nodes when possible
• Deployment remains schedulable even if the cluster has limited nodes
• Automatic failover capability when a node becomes unavailable

#Customizing Affinity Rules

If the default affinity rules do not meet your requirements, you can override them through the workloads configuration on ConnectorsConfig. The template.spec.affinity field allows you to specify custom affinity rules.

For multi-zone clusters, you can configure zone-aware scheduling to spread pods across availability zones. The following example uses requiredDuringSchedulingIgnoredDuringExecution to enforce zone-level distribution, combined with preferredDuringSchedulingIgnoredDuringExecution to prefer node-level distribution within each zone:

apiVersion: operator.connectors.alauda.io/v1alpha1
kind: ConnectorsConfig
metadata:
  name: connectors-config
spec:
  components:
    core:
      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

This configuration ensures:

• Pods are strictly distributed across different availability zones (hard requirement)
• Within the same zone, pods are preferably scheduled on different nodes (soft requirement)
• Provides resilience against both zone-level and node-level failures