All Products
Search

This Product

    Container Service for Kubernetes:Node scaling overview

    Document Center

    Container Service for Kubernetes:Node scaling overview

    Last Updated:Sep 20, 2026

    Container Service for Kubernetes (ACK) Edge clusters can manage different node resources, both online and offline, including Elastic Compute Service (ECS) nodes across regions, data center nodes, nodes from other cloud service providers, and server nodes located in various settings such as factories, retail outlets, motor vehicles, and ships. In scenarios where offline node resources are inadequate, the auto scaling feature can seamlessly expand cloud nodes for ACK Edge clusters, enhancing scheduling capabilities. This dynamic scaling conserves resources, thereby significantly saving costs.

    Before you begin

    Read this topic to understand ACK node scaling solutions and choose the one that best fits your workload before enabling node scaling.

    Familiarize yourself with manual scaling, auto scaling, horizontal scaling, and vertical scaling in the Kubernetes official documentation.

    How it works

    Kubernetes node scaling differs from the traditional resource-utilization-threshold model. You may need to address this when migrating from data centers or other orchestration systems to Kubernetes.

    How are scaling thresholds determined?

    Hot nodes typically have higher resource utilization than other nodes.

    • If scaling is triggered by average utilization, hot node demand is masked by underutilized nodes, preventing timely scale-out.

    • If scaling is triggered by peak utilization, resource waste typically occurs across the cluster.

    How are loads reduced after nodes are added?

    In Kubernetes, pods are the smallest deployable units. Adding nodes does not redistribute existing pod loads — the pod count and resource limits remain unchanged, so new nodes receive no traffic from overloaded pods.

    How is node scaling triggered and performed?

    Utilization-based scaling may evict pods with high resource requests but low actual usage. If many such pods exist, schedulable resources are exhausted and some pods become unschedulable.

    How are scale-out activities triggered?

    The node scaling model monitors unschedulable pods. When pods fail to schedule due to insufficient resources, it simulates scheduling, selects a suitable auto scaling-enabled node pool, and adds nodes to the cluster.

    Note

    The simulation abstracts each auto scaling-enabled node pool as a virtual node with the CPU, memory, and GPU capacity of its configured instance types, plus the node pool's labels and taints. The scheduler adds this virtual node to the schedulable list, calculates the required node count, and provisions nodes accordingly.

    How are scale-in activities triggered?

    Scale-in applies only to nodes in auto scaling-enabled node pools; static nodes are unmanaged. When a node's utilization falls below the scale-in threshold, the model simulates pod eviction to verify the node can be drained. Non-DaemonSet pods in the kube-system namespace and PodDisruptionBudget-protected pods are skipped. After all eligible pods are evicted to other nodes, the node is removed.

    How can I improve the success rate of auto scaling?

    The success rate of auto scaling depends on the following factors:

    • Whether the scheduling conditions are met

      After creating an auto scaling-enabled node pool, confirm the pod scheduling policy for the node pool. If unsure, configure nodeSelector with the node pool label and run a scheduling simulation.

    • Whether resources are sufficient

      After the simulation, the system selects an auto scaling-enabled node pool and adds nodes. However, ECS instance type inventory in the node pool configuration affects the scale-out success rate. Specify multiple instance types across different zones to improve the success rate.

    How can I accelerate auto scaling?

    • Method 1: Use swift mode. After an auto scaling-enabled node pool completes one scale-out and one scale-in cycle, it enters swift mode. See Enable node autoscaling.

    • Method 2: Use a custom image based on Alibaba Cloud Linux 3 to improve IaaS resource delivery efficiency by 50%. See Optimize scaling with custom images.

    Node scaling solution

    The node scaling model scales resources at the resource layer. When the size of a cluster cannot meet pod scheduling requirements, this model automatically scales node resources to provide additional scheduling capacity. Node scaling is managed by the cluster-autoscaler component, which periodically polls and maintains the cluster state to identify conditions that meet scaling requirements, thereby automatically adjusting the number of cluster nodes.

    Scaling speed and efficiency

    • A scaling activity requires 60 seconds in standard mode and 50 seconds in swift mode.

    • When the duration of a scaling activity reaches 1 minute, auto scaling encounters a performance bottleneck. The efficiency of auto scaling will fluctuate based on the number of node pools and scaling scenarios. For example, if the number of node pools exceeds 100, the duration of a scaling activity is increased to 100 to 150 seconds.

    • Using a polling model, and constrained by the dependency on cluster state maintenance, the minimum latency is 5 seconds.

    Usage notes

    Quotas and limits

    • A VPC route table supports up to 200 custom route entries. To increase this limit, submit an application in the Quota Center console. For other resource quotas, see Underlying Cloud Product Quotas.

    • Configure the maximum number of nodes in an auto scaling-enabled node pool carefully. Ensure dependent resources and quotas are sufficient, such as VPC CIDR blocks and vSwitches, or scale-out activities may fail. For node pool limits, see Enable node autoscaling. For network planning, see ACK managed cluster network planning.

    • Node scaling does not support subscription nodes. Do not set the billing method to subscription when creating an auto scaling-enabled node pool. For existing node pools, ensure no subscription nodes are present before enabling auto scaling.

    • The node scaling feature is incompatible with SideCar Containers. Deploy Sidecar Container workloads to node pools with auto scaling disabled.

    Maintenance of dependent resources

    If elastic IP addresses (EIPs) are associated with ECS nodes added by node scaling, do not delete these nodes directly from the ECS console. The EIPs will not be automatically released.

    Further reading

    If you encounter issues when you use node scaling, refer to FAQs of node scaling for troubleshooting.