Seamless Traffic Migration with Alibaba Cloud ACK’s Dual‑Node CLB Feature

Background

Containerized deployments reduce costs and boost development efficiency, but migrating traffic without interruption remains challenging. Alibaba Cloud ACK’s Cloud Controller Manager (CCM) now offers a feature that allows a single CLB backend to serve both in‑cluster Kubernetes nodes and external ECS instances, addressing smooth migration, canary releases, and multi‑cluster traffic scenarios.

Scenario 1 – Application Containerization Migration

Goal

Enable a CLB to forward traffic to both in‑cluster nodes and external ECS during migration.

Steps

Log into the CLB console, create a CLB, and note its ID (e.g., lb-xxxxx).

Create a Service of type LoadBalancer with the annotation

service.beta.kubernetes.io/alicloud-loadbalancer-force-override-listeners

set to false so CCM does not manage listener details.

CCM automatically creates the corresponding virtual server group.

In the CLB console, create a listener and associate it with the virtual server group.

Manually add the external ECS to the virtual server group and set its weight.

Service Manifest Example

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: "lb-xxxx"
    service.beta.kubernetes.io/alicloud-loadbalancer-force-override-listeners: "false"
  labels:
    app: nginx
  name: my-nginx-svc
  namespace: default
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  type: LoadBalancer
EOF

Expected Result

After applying the manifest, the CLB’s virtual server group lists both in‑cluster nodes and the external ECS. Scaling the in‑cluster application does not affect the external ECS.

Scenario 2 – Canary Release

Goal

Gradually shift traffic from existing ECS to the new Kubernetes cluster using weight‑based annotations.

Key Annotation

Set service.beta.kubernetes.io/alicloud-loadbalancer-weight on the Service to define the traffic proportion for the Kubernetes cluster.

Steps

Log into the CLB console, create the CLB, listener, and virtual server group; record IDs.

Manually add the external ECS to the virtual server group and assign its weight.

Create the Service with the weight annotation (e.g., "20" for 20% traffic to the cluster).

Service Manifest Example

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alicloud-loadbalancer-id: "lb-xxxxx"
    service.beta.kubernetes.io/alicloud-loadbalancer-vgroup-ids: "80:rsp-xxx"
    service.beta.kubernetes.io/alicloud-loadbalancer-weight: "20"
  name: nginx-svc
  namespace: default
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  sessionAffinity: None
  type: LoadBalancer

Expected Result

The CLB shows both the in‑cluster nodes and the external ECS, with traffic split according to the configured weight. Adjusting the weight enables a controlled, incremental migration.

Scenario 3 – Multi‑Cluster Active‑Active & Disaster Recovery

Goal

Allow a single CLB to distribute traffic across multiple Kubernetes clusters, each with its own weight, supporting high availability and disaster recovery.

Notes

Virtual server groups cannot be shared across CLBs.

Each virtual server group can be bound to only one port.

Both clusters must have a Cluster ID; Service names must differ if IDs are the same.

Steps

In the CLB console, create the CLB, listener, and virtual server group; record IDs.

Add external ECS (if any) to the virtual server group and set its weight.

In Cluster A, create Service‑A with weight 20%.

In Cluster B, create Service‑B with weight 80%.

Service‑A Manifest

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alicloud-loadbalancer-id: "lb-xxxxx"
    service.beta.kubernetes.io/alicloud-loadbalancer-vgroup-ids: "80:rsp-xxx"
    service.beta.kubernetes.io/alicloud-loadbalancer-weight: "20"
  name: service-A
  namespace: default
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  sessionAffinity: None
  type: LoadBalancer

Service‑B Manifest

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alicloud-loadbalancer-id: "lb-xxxxx"
    service.beta.kubernetes.io/alicloud-loadbalancer-vgroup-ids: "80:rsp-xxx"
    service.beta.kubernetes.io/alicloud-loadbalancer-weight: "80"
  name: service-B
  namespace: default
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  sessionAffinity: None
  type: LoadBalancer

Expected Result

After deployment, the CLB’s virtual server group lists nodes from both clusters, each receiving traffic according to its weight annotation. Scaling either cluster automatically updates the CLB backend.

Conclusion

By leveraging ACK’s new capability to mount both in‑cluster nodes and external ECS on a single CLB backend, enterprises can avoid traffic interruptions during migration, perform fine‑grained canary releases, and achieve multi‑cluster high availability for e‑commerce, gaming, and transportation workloads.