All Products
Search

This Product

    Container Service for Kubernetes:Deploy Services Across Clusters by Reusing Existing Load Balancers

    Document Center

    Container Service for Kubernetes:Deploy Services Across Clusters by Reusing Existing Load Balancers

    Last Updated:Mar 26, 2026

    The Cloud Controller Manager (CCM) lets you attach an existing Server Load Balancer (SLB) instance to Services in one or more ACK clusters, and to endpoints outside those clusters. With a single SLB instance acting as a unified ingress, you avoid provisioning a separate load balancer per cluster — useful when you need disaster recovery, high availability, or security isolation across clusters.

    Two scenarios are covered:

    • Scenario 1: Distribute traffic between a Service inside the cluster and an external endpoint (for example, an Elastic Compute Service (ECS) instance).

    • Scenario 2: Distribute traffic across Services in different ACK clusters.

    Prerequisites

    Before you begin, ensure that you have:

    Scenario 1: Distribute traffic to a cluster Service and an external endpoint

    Attach a Service inside the cluster and an external endpoint to the same SLB instance. The SLB instance routes traffic to both. When pods scale, they are automatically added to or removed from the vServer group without affecting the external endpoint.

    image

    Step 1: Get the SLB instance ID

    Log on to the CLB console or NLB console and note the ID of your existing SLB instance.

    Step 2: Create a Service using the existing SLB instance

    Use the ACK console

    In the ACK console, create a Service with the following settings:

    • Set Service Type to SLB.

    • Select Use Existing Resource, then choose the SLB instance from the drop-down list.

    • Select Overwrite Existing Listeners.

    Use kubectl

    Add the following annotations to your Service manifest:

    apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: <LB_ID>  # The ID of the existing SLB instance.
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners: "true"  # Set to true so CCM automatically creates listeners and vServer groups.
  labels:
    #...
  name: #...
spec:
  #...
    Important

    After the Service is created, CCM creates a vServer group and a listener that listens on the Service port for the SLB instance.

    Step 3: Add the external endpoint to the vServer group

    Log on to the CLB console or NLB console and add your external endpoint (for example, an ECS instance) to the vServer group that CCM created. For instructions, see Create and manage a CLB vServer group and Create and manage a vServer group.

    After you add the external endpoint, both the cluster pods and the external endpoint appear in the vServer group, and you can set their relative weights.

    Scenario 2: Distribute traffic across Services in different ACK clusters

    Attach Services from different ACK clusters to the same SLB instance. Each cluster's CCM keeps the vServer group in sync as pods scale, without affecting backend servers registered by other clusters.

    image

    Restrictions

    Review these constraints before you begin:

    • All Services sharing the SLB instance must use the same port.

    • Services deployed in the same namespace across clusters must have different names.

    • If you set traffic weights using the alibaba-cloud-loadbalancer-weight annotation, manage weights only through the annotation — do not modify weights in the SLB console, because console changes are not synced back to the Services.

    Step 1: Create a listener and vServer group manually

    Log on to the CLB console or NLB console and manually create a listener and vServer group for the SLB instance. For instructions, see CLB listeners, Create and manage a CLB vServer group, NLB listeners, and Create and manage a server group.

    Creating the listener and vServer group manually is required so that all clusters can share the same group — CCM in each cluster registers its own pods into this shared group.

    Step 2: Create the Services with shared vServer group annotations

    In each cluster, create a Service with the annotations below. All Services must reference the same SLB instance and vServer group.

    apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: "<YOUR_LB_ID>"            # The ID of the shared SLB instance.
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-vgroup-port: "<YOUR_VGROUP_ID>:<PORT>"  # The vServer group ID and the Service port, separated by a colon.
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight: "100"                # (Optional) Traffic weight for backend pods of this Service. Valid values: 1–1000. Default: 100.
  labels:
    #...
  name: #...
spec:
  #...

    Annotation reference

    Annotation Type Default Description
    alibaba-cloud-loadbalancer-id string — The ID of the existing SLB instance. CCM attaches the Service to this instance instead of creating a new one.
    alibaba-cloud-loadbalancer-vgroup-port string — Maps the Service port to a vServer group: <vgroup-id>:<port>. For multiple port-to-vServer group mappings, separate them with commas — for example, "<VGROUP_ID_1>:80, <VGROUP_ID_2>:443".
    alibaba-cloud-loadbalancer-weight integer 100 Traffic weight for all backend pods of this Service. Valid values: 1–1000. When set, CCM uses this value to register pod weights in the vServer group — manage weights only through this annotation, not in the SLB console.

    After you apply the Service manifests, the pods from each cluster appear in the shared vServer group in the SLB console. When an application scales, its pods are added to or removed from the group automatically, without affecting pods that belong to other Services.

    What's next

    References