All Products
Search

This Product

    Container Service for Kubernetes:Considerations for configuring Service Load Balancing and CCM resource update policies

    Document Center

    Container Service for Kubernetes:Considerations for configuring Service Load Balancing and CCM resource update policies

    Last Updated:Mar 26, 2026

    When you set Type=LoadBalancer for a Service, the cloud controller manager (CCM) of Container Service for Kubernetes (ACK) automatically creates and manages Server Load Balancer (SLB) resources for that Service—including an SLB instance, listeners, and backend server groups. Both Classic Load Balancer (CLB) and Network Load Balancer (NLB) instances are supported.

    Before configuring a LoadBalancer-type Service, review the constraints, quota limits, and update policies described in this document to avoid service disruption or quota exhaustion in production.

    SLB instance reuse

    You can reuse an existing SLB instance instead of letting the CCM create one automatically. The following constraints apply:

    • Only reuse SLB instances created through the SLB console. Instances created automatically by the CCM cannot be reused.

    • For internal-facing access, the SLB instance must be in the same virtual private cloud (VPC) as the ACK cluster. Only NLB instances support cross-VPC reuse.

    • The network type of the SLB instance must match the Service's access type:

      • service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "internet" — the SLB instance must be Internet-facing.

      • service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet" — the SLB instance must be internal-facing.

    • Each listening port on an SLB instance can be used by only one Service at a time.

    • When reusing an SLB instance across clusters, ensure Services exposed by that instance have different names, unless they are deployed in different namespaces.

    Important

    You cannot change the SLB instance assigned to a LoadBalancer Service after creation. To switch to a different SLB instance, create another Service.

    CCM management behavior

    The CCM creates and manages SLB resources exclusively for Services with Type=LoadBalancer.

    Important

    If you change a Service from Type=LoadBalancer to any other type, the CCM deletes the SLB configurations for that Service, making it inaccessible through the SLB instance.

    The CCM uses a declarative API to continuously reconcile the SLB configuration against the Service specification. Because the CCM treats the Service spec as the source of truth and periodically overwrites SLB resources to match it, manual changes you make in the SLB console may be overwritten by the CCM—especially if service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners is set to true.

    Important

    Do not modify configurations of CCM-managed SLB instances in the SLB console. The CCM will overwrite those changes on the next reconciliation.

    Quotas

    VPC

    Each node in a cluster maps to one route entry in the VPC route table. The default limit is 200 entries per route table. If your cluster exceeds 200 nodes, log on to the Quota Center console and submit an application.

    For VPC limits and quotas, see Limits and quotas. To view your current VPC quota usage, go to the Quota Management page in the VPC console.

    SLB

    The following default SLB quotas apply per Alibaba Cloud account:

    Resource Default limit How to increase
    SLB instances per account 60 log on to the Quota Center console and submit an application
    Backend server groups per Elastic Compute Service (ECS) instance 50 log on to the Quota Center console and submit an application
    Backend servers per SLB instance 200 log on to the Quota Center console and submit an application
    Listeners per SLB instance 50 log on to the Quota Center console and submit an application

    Quota consumption and mitigation

    When using the Flannel network plugin with spec.externalTrafficPolicy: Cluster, the CCM registers every cluster node as a backend server for each LoadBalancer Service. This causes the backend server group quota to be consumed at a high rate across all your LoadBalancer Services. When the quota is exhausted, Service reconciliation fails.

    To reduce quota consumption, switch to spec.externalTrafficPolicy: Local. In Local mode, the CCM registers only the nodes that run backend pods for each Service, significantly reducing quota usage. Local mode also preserves source IP addresses in Layer 4 load balancing.

    To view your current SLB quota usage, go to the Quota Center page in the SLB console. For complete SLB limits, see Limits on CLB and Limits on NLB.

    Update policies for SLB resources

    The CCM follows different policies depending on whether you specify an existing SLB instance or let the CCM create one automatically.

    Resource Existing SLB instance (user-specified) CCM-created SLB instance
    SLB instance Specify with service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id. The CCM uses this instance and creates vServer groups for it. The instance is not deleted when the Service is deleted. The CCM creates, configures, and manages the instance automatically. The instance is deleted when the Service is deleted.
    Listeners Controlled by service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners: set to false to leave listeners unmanaged, or true to have the CCM manage and replace existing listeners. The CCM creates and manages listeners based on the Service configuration.
    Backend server groups See backend server group policies below. See backend server group policies below.

    Backend server group policies

    Backend server group behavior depends on the network plugin your cluster uses.

    Terway network plugin

    The CCM adds pod IP addresses directly as backend servers by default, bypassing the ECS node level.

    Flannel network plugin

    Behavior depends on spec.externalTrafficPolicy:

    • Cluster mode (externalTrafficPolicy: Cluster): The CCM adds all cluster nodes as backend servers by default. If node labels are specified in the Service configuration, only nodes with those labels are added.

      Important

      Cluster mode consumes the backend server group quota rapidly because every node is registered for every LoadBalancer Service. When the quota is exhausted, Service reconciliation fails. Switch to Local mode to avoid this.

    • Local mode (externalTrafficPolicy: Local): The CCM adds only the nodes running backend pods for the Service. This reduces quota consumption and preserves source IP addresses in Layer 4 load balancing.

    Node removal behavior (Flannel only)

    The CCM does not add master nodes to SLB instances used by the cluster.

    Running kubectl drain or kubectl cordon on a node does not automatically remove it from SLB backend server groups. To remove unschedulable nodes from the backend, set the annotation service.beta.kubernetes.io/alibaba-cloud-loadbalancer-remove-unscheduled-backend to on.