Container Service for Kubernetes:Scale containers in seconds with ack-autoscaling-placeholder

Prerequisites

• Node autoscaling is enabled for the ACK cluster with an elastic node pool configured.

• A node label is set on the elastic node pool via Node Labels. This guide uses demo=yes.

How it works

All three steps work together through Kubernetes priority preemption:

1. The placeholder runs with a low PriorityClass (value -1), reserving node resources.

2. When an actual workload is deployed with a high PriorityClass (value 1000000), the scheduler evicts the placeholder and places it on the freed resources immediately.

3. The now-Pending placeholder triggers CA to provision a new node. Once the node is ready, the placeholder is rescheduled and the buffer is restored.

Deploy ack-autoscaling-placeholder

1. Log on to the Container Service Management Console. In the left-side navigation pane, choose Marketplace > Marketplace.

2. On the App Catalog tab, search for ack-autoscaling-placeholder and click ack-autoscaling-placeholder.

3. On the ack-autoscaling-placeholder page, click Deploy.

4. On the creation panel, click the Parameter tab, replace Parameters with the following YAML, and click OK.

   Set resources.requests to match allocatable resources on the target node, not total capacity. Nodes reserve capacity for kubelet, the operating system, and kube-proxy. Check with kubectl describe node <node-name> under Allocatable.

   nameOverride: ""
   fullnameOverride: ""
   
   priorityClassDefault:
     enabled: true
     name: default-priority-class   # Low-priority class for placeholder pods.
     value: -1                      # Must be above the CA expendable-pod cutoff and below real workload priority.
   
   deployments:
      - name: ack-place-holder
        replicaCount: 1
        containers:
          - name: placeholder
            image: registry-vpc.cn-shenzhen.aliyuncs.com/acs/pause:3.1
            pullPolicy: IfNotPresent
            resources:
              requests:
                cpu: 4             # Size these requests to match allocatable node resources,
                memory: 8Gi        # not raw node capacity (deduct kubelet, OS, and kube-proxy overhead).
        imagePullSecrets: {}
        annotations: {}
        nodeSelector:              # Must match the labels on the elastic node pool.
          demo: "yes"
        tolerations: []
        affinity: {}
        labels: {}

5. Choose Applications > Helm and verify the application status is Deployed.

Create a PriorityClass for the workload

1. Create priorityClass.yaml with the following content.

   apiVersion: scheduling.k8s.io/v1
   kind: PriorityClass
   metadata:
     name: high-priority
   value: 1000000       # Must be higher than the placeholder PriorityClass value (-1).
   globalDefault: false
   description: "High-priority class for production workloads."

2. Apply the PriorityClass.

   kubectl apply -f priorityClass.yaml

   Expected output:

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

Deploy the workload

1. Create workload.yaml with the following content.

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: placeholder-test
     labels:
       app: nginx
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         labels:
           app: nginx
       spec:
         nodeSelector:              # Must match the labels on the elastic node pool.
           demo: "yes"
         priorityClassName: high-priority   # References the PriorityClass created in Step 2.
         containers:
         - name: nginx
           image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
           ports:
           - containerPort: 80
           resources:
             requests:
               cpu: 3             # Must be less than or equal to the placeholder's cpu request (4)
               memory: 5Gi        # so the real workload fits within the reserved space.

2. Apply the Deployment.

   kubectl apply -f workload.yaml

   Expected output:

   deployment.apps/placeholder-test created

Verify the result

1. After deploying, the ack-place-holder pod status is Running.

   

2. The workload preempts the placeholder and starts on the same node. The placeholder moves to Pending.

   • The workload placeholder-test is Running on the node previously occupied by the placeholder.

   • The placeholder pod enters Pending state due to insufficient resources.

3. CA detects the Pending placeholder and provisions a new node. Once ready, the placeholder is rescheduled and the buffer is restored.

   

Next steps

For multi-zone over-provisioning, see Achieve Fast Elastic Scale-out in Multiple Zones Simultaneously.