All Products
Search

This Product

    Container Service for Kubernetes:Node scaling overview

    Document Center

    Container Service for Kubernetes:Node scaling overview

    Last Updated:Jun 17, 2026

    When your ACK cluster cannot schedule pending pods, use node scaling to automatically add or remove nodes. ACK provides node auto scaling and node instant scaling . Compared with node auto scaling, node instant scaling is faster and simpler.

    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 node scaling 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.

    The traditional scaling model adds nodes when CPU or memory utilization exceeds a threshold. However, this model has the following issues.

    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.

    ACK uses node scaling (resource layer) and workload scaling (scheduling layer) to address this. Node scaling triggers scaling based on pod resource utilization.

    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 is a node pool selected when multiple node pools with the auto scaling feature enabled exist?

    Multiple auto scaling-enabled node pools are treated as abstracted nodes. The autoscaler scores them using the standard scheduling policy, prioritizing affinity rules such as node affinity.

    If no match is found through affinity rules, node auto scaling falls back to the least-waste principle, selecting the node pool that leaves the fewest idle resources after scale-out.

    Note

    When both GPU-accelerated and CPU-accelerated auto scaling-enabled node pools meet scale-out conditions, the CPU-accelerated pool is prioritized.

    By default, node instant scaling evaluates instance availability and cost, prioritizing types with sufficient capacity and the lowest price.

    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.

    Scaling solutions: node auto scaling and node instant scaling

    Node scaling is a resource-level feature that automatically adjusts the number of nodes in your cluster. When existing capacity is insufficient for pod scheduling, the autoscaler provisions additional nodes.

    ACK provides two solutions for node scaling.

    Introduction

    Important

    Solution

    Component

    Description

    Solution 1: node auto scaling

    cluster-autoscaler

    Checks cluster status in a round-robin cycle and scales nodes when conditions are met.

    Solution 2: node instant scaling

    ACK GOATScaler

    An event-driven node autoscaler that ensures efficient resource delivery in large clusters and consecutive scale-out scenarios. A cluster is considered large if either a node pool with the auto scaling feature enabled contains more than 100 nodes, or more than 20 node pools in the cluster have the auto scaling feature enabled. Scaling speed: 45 seconds; success rate: 99%; resource fragment reduction: 30%. Supports custom scaling policies for extensibility.

    Solution comparison

    For node pools with auto scaling enabled (without swift mode), the node instant scaling feature is compatible with the existing node pool configuration and supports all pod types. The following table compares node instant scaling with node auto scaling.

    Benefit

    Node auto scaling

    Node instant scaling

    Scaling speeds and efficiency

    60 seconds in standard mode, 50 seconds in swift mode.

    With event-driven scaling and Alibaba Cloud ContainerOS, each scaling activity takes 35–55 seconds.

    Auto scaling hits a performance bottleneck at 1 minute. Efficiency fluctuates with node pool count and scaling scenarios — exceeding 100 node pools increases duration to 100–150 seconds.

    Scaling duration remains stable as node pool or pod count increases, making it suitable for fast-scaling scenarios.

    Round-robin mode with cluster status updates. Minimum latency: 5 seconds.

    Event-driven. Latency: 1–3 seconds.

    Resource scaling success rate

    Due to fluctuating cloud resource inventory and instance type variability, the success rate of node auto scaling is approximately 97%.

    An auto inventory selection policy filters thousands of Alibaba Cloud instance types by predefined conditions and priorities, automatically selecting optimal types or fallback alternatives when specified types are unavailable. This simplifies O&M and increases the success rate to 99%.

    Scale-out uses instance types from the node pool configuration. When multiple types are specified, the lowest-spec type is preferred.

    You can specify multiple instance types for scale-out activities.

    The autoscaler periodically retries when resource scaling fails.

    The autoscaler can generate alerts when the specified instance types are insufficient.

    Use and O&M

    Compared with node auto scaling, node instant scaling is easier to use in the following aspects:

    • Node pool configuration maintenance: Node instant scaling automatically selects instances across types and zones to host pending pods. With node auto scaling, you must manually maintain node pool configurations and update them whenever pod configurations change.

    • Node O&M: Scaling exceptions are surfaced through pod events, letting developers focus on pod lifecycle management.

    • Feature extension: Both solutions work with Descheduler to prepare elastic resources. Node instant scaling is intrusion-free and supports custom actions in resource provision policies and node lifecycle management for secondary development.

    Scheduling policy

    Beyond the scheduling features of node auto scaling, node instant scaling also supports:

    • Topology: Meets cross-zone high availability requirements.

    • Pod Disruption Budgets: Limits simultaneous voluntary pod evictions in multi-pod applications, ensuring stability during planned disruptions.

    Node instant scaling reduces the resource fragment rate by 30% using Bin Packing and PreBind (custom feature) policies.

    Limits of node instant scaling

    The following limits apply to node instant scaling. Review them before enabling node instant scaling.

    • Node instant scaling does not support the swift mode.

    • A node pool can contain up to 180 nodes per scale-out batch.

    • Scale-in cannot be disabled for a specific cluster.

      Note

      To disable scale-in for a specific node, see How to prevent a node from being scaled in by node instant scaling?

    • The node instant scaling solution does not check preemptible instance inventory. If the node pool's Billing Method is set to preemptible instances and Use Pay-as-you-go Instances When Spot Instances Are Insufficient is enabled, pay-as-you-go instances may be scaled out even if sufficient preemptible instances are available.

    Select a node scaling solution

    See Solution comparison and Limits of node instant scaling. Choose node auto scaling if your workload has lower demands for scaling speed and delivery certainty, and the limitations of node instant scaling are unacceptable.

    If your workload has any of the following requirements, node instant scaling is recommended:

    • Large clusters severely degrade node auto scaling efficiency. Choose node instant scaling, as cluster size has minimal impact on its scaling efficiency. A cluster is considered large if either a node pool with the auto scaling feature enabled contains more than 100 nodes, or more than 20 node pools in the cluster have the auto scaling feature enabled.

    • Faster scaling speed is required. Standard mode: node auto scaling takes 60 seconds; node instant scaling takes 45 seconds.

    • Consecutive scale-out batches are frequent. In consecutive scaling scenarios, node auto scaling performance degrades and fluctuates, while node instant scaling maintains a consistent ~45-second scaling time.

    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.

    References