#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.

#Key Steps Overview

Configuring a high-availability Connector involves three steps:

1. Set replicas ≥ 2 — Specify spec.workloads[].replicas on each Connectors Component. At minimum, configure ConnectorsCore (api, controller-manager, proxy) and any plugin components you use.
2. Rely on built-in anti-affinity — The system 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.workloads[].template.spec.affinity to enforce zone-level distribution using requiredDuringSchedulingIgnoredDuringExecution if needed.

More details on each step are provided below.

#Configuring Replicas

You can increase the number of replicas for each workload to achieve high availability. This is done through the workloads field in the component spec. For production environments, we recommend configuring at least 2 replicas for each workload to ensure service continuity during node failures or rolling updates.

Below are specific examples for each major connector component:

#ConnectorsCore

ConnectorsCore includes three main workloads: API server, controller manager, and proxy. For high availability, configure all three with multiple replicas:

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

After a period of time, all pods of the connectors-core component have a replica count of 2, except for 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 runs a single plugin deployment for Git Server integration:

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

After a period of time, all pods of the connectors-git component have a replica count of 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 runs a single plugin deployment that handles OCI registry integration:

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

After a period of time, all pods of the connectors-oci component have a replica count of 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

#ConnectorsMaven

ConnectorsMaven runs a single plugin deployment for Maven registry integration:

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

After a period of time, all pods of the connectors-maven component have a replica count of 2.

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

#ConnectorsHarbor

ConnectorsHarbor runs a single plugin deployment for Harbor-specific features:

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

After a period of time, all pods of the connectors-harbor component have a replica count of 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

#Components Without Workloads

The other connector components do not have Deployment workloads and therefore do not require replica configuration.

#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. 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: 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

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