Container Service for Kubernetes:Implement rapid elastic scaling across multiple zones

The problem

When a node pool is configured with vSwitches from multiple zones in a single scaling group, the Cluster Autoscaler cannot determine which specific zone needs new nodes. As a result, scaled-out instances may concentrate in one zone instead of being distributed evenly. This defeats the purpose of multi-zone deployment.

The solution

ACK addresses this problem with the ack-autoscaling-placeholder component, which uses resource redundancy to transform multi-zone elastic scaling into directed scaling of concurrent node pools. For more information, see Use ack-autoscaling-placeholder to scale pods within seconds. The mechanism works in three stages:

1. Create a node pool per zone with a zone label. Each node pool is assigned a label that identifies the zone it belongs to.

2. Deploy placeholder pods using nodeSelector. The ack-autoscaling-placeholder component schedules a placeholder pod to each zone based on the zone label. These placeholder pods use a PriorityClass with a lower weight than application pods.

3. Application pods preempt placeholder pods. When application pods are pending, they replace the lower-priority placeholder pods on existing nodes. The displaced placeholder pods then become pending themselves. Because the placeholder pods use nodeSelector-based scheduling (rather than antiAffinity), the Cluster Autoscaler can identify the exact zone each pending placeholder needs and triggers directed scale-out to the correct node pools concurrently.

Scaling flow

The following figure shows how simultaneous scaling across two zones works with this architecture.

1. The ack-autoscaling-placeholder component creates a placeholder pod in each zone. Placeholder pods have a lower scheduling priority than actual application pods.

2. When application pods enter the Pending state, they quickly preempt the placeholder pods and are deployed on existing nodes in each zone. The preempted placeholder pods then enter the Pending state.

3. Because the placeholder pods are scheduled using nodeSelector, the Cluster Autoscaler can scale out to the corresponding zones concurrently.

Deploy the component

1. In the left-side navigation pane of the ACK console, choose Marketplace > Marketplace.

2. Find and click ack-autoscaling-placeholder. On the ack-autoscaling-placeholder page, click Deploy.

3. Select a cluster from the Cluster drop-down list and a namespace from the Namespace drop-down list, and then click Next. Select a chart version from the Chart Version drop-down list, configure the parameters, and then click OK. After the component is deployed, choose Applications > Helm in the left-side navigation pane. You can confirm that the application is in the Deployed state.

Update the Helm release with placeholder Deployments

1. In the left-side navigation pane of the details page, choose Applications > Helm.

2. On the Helm page, click Update in the Actions column of ack-autoscaling-placeholder-default.

3. In the Update Release panel, update the YAML file based on the following example, and then click OK. Deploy a placeholder for each zone and define a placeholder Deployment for each zone. This example creates placeholder Deployments in Zones I, K, and H. Each entry in the deployments list follows the same structure. The first entry below is fully annotated; the subsequent entries differ only in the name and nodeSelector values. The following table summarizes the fields you must change for each zone: After the update succeeds, placeholder Deployments are created for each zone.

   Field	Zone I	Zone K	Zone H
   name	ack-place-holder-I	ack-place-holder-K	ack-place-holder-H
   nodeSelector	{"avaliable_zone":i}	{"avaliable_zone":k}	{"avaliable_zone":h}

      deployments:
      # --- Zone I placeholder ---
      - affinity: {}
        annotations: {}
        containers:
        - image: registry-vpc.cn-beijing.aliyuncs.com/acs/pause:3.1
          imagePullPolicy: IfNotPresent
          name: placeholder
          resources:
            requests:
              cpu: 3500m     # CPU request for each placeholder pod.
              memory: 6      # Memory request for each placeholder pod.
        imagePullSecrets: {}
        labels: {}
        name: ack-place-holder-I             # Deployment name. Use a unique suffix per zone.
        nodeSelector: {"avaliable_zone":i}   # Must match the node label key and value from Step 1.
        replicaCount: 10                     # Number of placeholder pods per zone.
        tolerations: []
   
      # --- Zone K placeholder (same structure, different zone) ---
      - affinity: {}
        annotations: {}
        containers:
        - image: registry-vpc.cn-beijing.aliyuncs.com/acs/pause:3.1
          imagePullPolicy: IfNotPresent
          name: placeholder
          resources:
            requests:
              cpu: 3500m
              memory: 6
        imagePullSecrets: {}
        labels: {}
        name: ack-place-holder-K
        nodeSelector: {"avaliable_zone":k}
        replicaCount: 10
        tolerations: []
   
      # --- Zone H placeholder (same structure, different zone) ---
      - affinity: {}
        annotations: {}
        containers:
        - image: registry-vpc.cn-beijing.aliyuncs.com/acs/pause:3.1
          imagePullPolicy: IfNotPresent
          name: placeholder
          resources:
            requests:
              cpu: 3500m
              memory: 6
        imagePullSecrets: {}
        labels: {}
        name: ack-place-holder-H
        nodeSelector: {"avaliable_zone":h}
        replicaCount: 10
        tolerations: []
   
      fullnameOverride: ""
      nameOverride: ""
      podSecurityContext: {}
      priorityClassDefault:
        enabled: true
        name: default-priority-class
        value: -1

   

Verification: Choose Applications > Helm and confirm that ack-autoscaling-placeholder-default shows the Deployed state with the updated configuration.

Option A: Named PriorityClass

1. Create a file named priorityClass.yaml and copy the following content to the file:

      apiVersion: scheduling.k8s.io/v1
      kind: PriorityClass
      metadata:
        name: high-priority
      value: 1000000              # The priority value. Must be higher than the default priority value (-1) of the placeholder pods created in Step 2.
      globalDefault: false
      description: "This priority class should be used for XYZ service pods only."

Option B: Global PriorityClass

If you do not need a separate PriorityClass for each pod, you can configure a global PriorityClass as the default. After this takes effect, pods without a specified PriorityClass automatically adopt this priority value, and preemption takes effect automatically.

   apiVersion: scheduling.k8s.io/v1
   kind: PriorityClass
   metadata:
     name: global-high-priority
   value: 1                              # The priority value. Must be higher than the default priority value (-1) of the placeholder pods created in Step 2.
   globalDefault: true
   description: "This priority class should be used for XYZ service pods only."

Apply the PriorityClass

1. Create the PriorityClass. Expected output:

      kubectl apply -f priorityClass.yaml

      priorityclass.scheduling.k8s.io/high-priority created

Verification: Run kubectl get priorityclass and confirm that high-priority (or global-high-priority) appears in the list with the correct priority value.