Container Service for Kubernetes:Create and manage node pools

Before creating a node pool, read Node pools to learn about the basics, use cases, related features, and billing.

Procedure

You can create, edit, delete, and view node pools on the node pool page of the target cluster.

1. Log on to the ACK console. In the left navigation pane, click Clusters.

2. On the Clusters page, click the name of your cluster. In the left navigation pane, click Nodes > Node Pools.

Create a node pool

You can configure a node pool on the console, including its basic, network, and storage configurations. Note that some settings, especially those related to node pool availability and network configuration, cannot be changed after the node pool is created. Creating a node pool does not affect the nodes and services in other node pools.

1. On the Node Pool page, click Create Node Pool. In the Create Node Pool dialog box, configure the settings.

   After creating a node pool, you can modify its configuration items on the Edit Node Pool page. The Modification Supported column indicates whether an item can be modified after creation. indicates an item cannot be modified, while indicates it can be.

   Basic configuration

   Parameter		Description	Modifiable
   Node Pool Name		Enter a custom node pool name.	✓
   Confidential computing		Note Only allowlisted users can configure confidential computing. To apply, submit a ticket. This parameter is available only when the container runtime is set to containerd. Specifies whether to enable confidential computing. Confidential computing is a cloud-native, one-stop container platform that provides hardware-based encryption for users with stringent security requirements. It ensures the security, integrity, and confidentiality of data in use (during computation) and simplifies the development, delivery, and management of trusted or confidential applications. For more information, see ACK-TEE Confidential Computing.	✗
   Container Runtime		For selection guidance, see Compare containerd, sandboxed container, and Docker runtimes. containerd (recommended): Community standard, supported for Kubernetes 1.20 and later. Sandboxed container: Provides a strongly isolated environment based on lightweight virtualization technology. For procedures and limitations, see Create and manage sandboxed container node pools. Docker (deprecated): Supported only for Kubernetes 1.22 and earlier. Creation is no longer supported.	✗
   Scaling Mode		Manual: ACK adjusts the node count in the node pool based on the configured Expected Number of Nodes, maintaining the node count at the Expected Number of Nodes. For details, see Manually scale node pools. Auto: When cluster capacity planning cannot meet application pod scheduling demands, ACK automatically scales node resources based on configured minimum and maximum instance counts. Clusters running Kubernetes 1.24 or later default to node instant scaling; clusters running earlier versions default to node autoscaling. For details, see Node scaling.	✓

   Managed configuration

   ACK offers three managed configurations with varying levels of automation for node pools.

   • Intelligent hosting: When intelligent hosting is enabled, ACK automatically scales the node pool based on workload demands. ACK also manages operational tasks, including operating system and software version upgrades, and fixing security vulnerabilities.

     Important

     For information about the capacity limits, operational boundaries, and storage specifications for intelligent hosting node pools, see Usage notes.

     This feature is available only in ACK Managed Cluster Pro clusters that run Kubernetes 1.30 or later.

   • Managed node pool: Select your desired automation capabilities and specify a cluster maintenance window.

     View related configurations

     Parameter	Description	Modifiable
     Auto Repair	ACK automatically monitors node status and performs self-healing tasks when nodes become abnormal. If you select Restart Faulty Node, node self-healing may involve draining nodes and replacing disks. For trigger conditions and related events, see Enable node self-healing.	✓
     Auto CVE Patching	Fix CVE vulnerabilities in node pool OS, supporting configurable vulnerability fix levels. Cloud resource and billing information: Security Center	✓

   • Disabled: Disables automation capabilities. You must manually manage the nodes and the node pool.

   To compare managed configuration capabilities and considerations, see Comparison of managed configuration capabilities and considerations.

   Network configuration

   Parameter		Description	Modifiable
   Network configuration	VPC	The cluster's VPC is selected by default and cannot be changed after the node pool is created. Cloud resources and billing: VPC	✗
   	vSwitch	During scaling, nodes scale in or out in the availability zones of the selected vSwitches based on the scaling policy. For high availability, select vSwitches in two or more different availability zones. To create a vSwitch, see Create and manage vSwitches. VPC	✓

   Instance and image configuration

   Parameter	Description	Modification supported
   Billing Method	The default billing method used when scaling out nodes in the node pool. Pay-As-You-Go: Can be enabled and released on demand. Subscription: Requires configuring Duration and Auto Renewal. Preemptible Instance: Currently, only spot instances with a protection period are supported. You must also configure the Instance Price Cap. The instance is created successfully when the real-time price of the specified instance type is below the maximum bid price. After the protection period (1 hour), the system checks the real-time price and inventory every 5 minutes. If the market price exceeds the bid price or inventory is insufficient, the spot instance is released. For usage recommendations, see Spot instance node pool best practices To maintain node pool consistency, you cannot change a Pay-As-You-Go or Subscription node pool to a Preemptible Instance node pool, or vice versa. Important Changing the billing method of a node pool affects only new nodes added during scale-outs. This change does not affect the billing method of existing nodes. To change the billing method for existing nodes, see Convert a pay-as-you-go instance to a subscription instance.	✓
   Instance configurations	When scaling out, nodes are allocated from the configured ECS instance families. To improve scale-out success rates, select multiple instance types across multiple zones to avoid unavailability or insufficient inventory. The specific instance type used for scaling is determined by the configured Scaling Policy. To ensure business stability and accurate resource scheduling, do not mix GPU and non-GPU instance types in the same node pool. Configure instance types for scaling in one of two ways: Specific types: Specify exact instance types based on vCPU, memory, family, architecture, and other dimensions. Generalized configuration: Select instance types to use or exclude based on attributes (vCPU, memory, etc.) to further improve scale-out success rates. For details, see Configure node pools using specified instance attributes. Refer to the console's elasticity strength recommendations for configuration, or view node pool elasticity strength after creation. For ACK-unsupported instance types and node configuration recommendations, see ECS instance type configuration recommendations. Cloud resource and billing information: ECS instance, GPU instance	✓
   Operating System	Marketplace Image is in phased release. The default operating system image used when scaling out nodes in the node pool. Public Image: Uses Alibaba Cloud Linux 3 container-optimized, ContainerOS, Alibaba Cloud Linux 3, Ubuntu, Windows, and other public OS images. For image details, cgroup versions, and usage limits, see Operating system. Custom Image: Uses a custom OS image. For details, see How to create a custom image from an existing ECS instance and use it to create nodes. To upgrade or change the operating system later, see Change operating system. Alibaba Cloud Linux 2 and CentOS 7 are no longer maintained. Use supported operating systems. We recommend Alibaba Cloud Linux 3 container-optimized or ContainerOS.	✓
   Security Hardening	When creating nodes, ACK applies the selected security baseline policy. Disable: No security hardening is applied to ECS instances. MLPS Security Hardening: Alibaba Cloud provides baseline check standards and scanning tools for Alibaba Cloud Linux MLPS 2.0 Level 3 images that comply with classified protection requirements. While ensuring native image compatibility and performance, these images are adapted for MLPS compliance to meet "GB/T22239-2019 Information Security Technology—Cybersecurity Classified Protection Basic Requirements." For details, see ACK MLPS hardening usage guide. In this mode, the root user cannot log on remotely via SSH. Connect to the instance via VNC in the ECS console and create a regular user that supports SSH logon. OS Security Hardening: Supported only for Alibaba Cloud Linux 2 or Alibaba Cloud Linux 3.	✗
   Logon Type	When selecting MLPS Security Hardening, only Password is supported. ContainerOS supports only Key Pair or Later. If using a key pair, you must start an administrative container after configuration to use it. For details, see Manage ContainerOS nodes. When creating nodes, ACK pre-configures the specified key pair or password on the instance. Set during creation: Key Pair: Alibaba Cloud SSH key pairs provide a secure and convenient logon authentication method comprising a public key and a private key. Supported only for Linux instances. Configure both the Username (root or ecs-user) and the required Key Pair. Password: Configure the Username (root or ecs-user) and password. Later: After instance creation, bind a key pair or reset the instance password yourself. For details, see Bind SSH key pairs and Reset instance logon password.	✓

   Storage

   Parameter	Description	Modifiable
   System Disk	Select a cloud disk type based on your business needs, including ESSD AutoPL, ESSD, ESSD Entry, and previous-generation disks (SSD and ultra disk). Configure capacity, IOPS, and other parameters. Available system disk types depend on the selected instance family. Disk types not displayed are unsupported. ESSD custom capabilities Supports custom performance levels. Larger disk capacity allows higher performance levels (PL2 for capacities over 460 GiB, PL3 for over 1260 GiB). For details, see ESSD. Only ESSD system disks support Encrypted. By default, Alibaba Cloud uses the service key (Default Service CMK) for encryption. You can also select a custom key (BYOK) pre-created in KMS. Supports selecting More Disk Categories to configure disk types different from the primary System Disk, improving scale-out success rates. When creating nodes, ACK selects the first matching disk type from the specified order. Cloud resource and billing information: ECS block storage	✓
   Data Disk	Select a cloud disk type based on your business needs, including ESSD AutoPL, ESSD, ESSD Entry, and previous-generation disks (SSD and ultra disk). Configure capacity, IOPS, and other parameters. Available data disk types depend on the selected instance family. Disk types not displayed are unsupported. ESSD AutoPL support Provisioned performance: Decouples disk capacity from performance, allowing flexible configuration of provisioned performance based on actual business needs without changing storage capacity. Performance burst: Temporarily boosts performance to handle peak read/write demands until business stabilizes. ESSD support Supports custom performance levels. Larger disk capacity allows higher performance levels (PL2 for capacities over 460 GiB, PL3 for over 1260 GiB). For details, see ESSD. When mounting data disks, all cloud disk types support Encrypted. By default, Alibaba Cloud uses the service key (Default Service CMK) for encryption. You can also select a custom key (BYOK) pre-created in KMS. During node creation, the last data disk is automatically formatted, and /var/lib/container is mounted to this disk. /var/lib/kubelet and /var/lib/containerd are mounted to /var/lib/container. To customize mount directories, adjust the data disk initialization configuration. You can select only one data disk as the container runtime directory. For details, see Can I customize directory mounting for data disks in ACK node pools? For scenarios requiring container image acceleration or rapid large model loading, use snapshots to create data disks, improving system response speed and processing capability. Select Add Data Disk Type to configure disk types different from the primary Data Disk, improving scale-out success rates. When creating nodes, ACK selects the first matching disk type from the specified order. An ECS instance can mount up to 64 data disks. The maximum number of disks supported varies by instance type. Query the disk quantity limit for an instance type using the DescribeInstanceTypes API (DiskQuantity). Cloud resource and billing information: ECS block storage	✓

   Instance count

   Parameter	Description	Modifiable
   Expected Number of Nodes	The total number of nodes the node pool should maintain. We recommend configuring at least two nodes to ensure normal operation of cluster components. Adjust the desired node count to scale the node pool in or out. For details, see Scale node pools. If you do not need to create nodes, enter 0 and adjust manually later or add existing nodes.	✓

   Advanced settings

   Expand Advanced Options (Optional) to configure settings such as scaling policies, resource groups, ECS tags, and taints.

   Advanced settings

   Parameter	Description	Modifiable
   Resource Group	Assigns the node pool to a selected resource group for easier permission management and cost allocation. A resource can belong to only one resource group.	✓
   Scaling Mode	Requires enabling Auto Scaling for the node pool and setting Scaling Mode to Auto. Standard: Scales by creating and releasing ECS instances. Swift: Scales by creating, stopping, and restarting ECS instances. When scaling is needed again, stopped instances are restarted directly, improving scaling speed. Stopped ECS instances do not incur compute resource fees, only storage fees (except for instance families with local storage capabilities, such as big data and local SSD types). For billing details and considerations about ECS instance stop modes, see Economical mode.	✗
   Scaling Policy	Configure how the node pool selects instances during scaling. Priority-based Policy: Scales based on the vSwitch priority configured in the cluster (vSwitch order from top to bottom indicates decreasing priority). If instances cannot be created in the higher-priority zone, the next priority vSwitch is used automatically. Cost Optimization: Scales from lowest to highest vCPU unit price. When the node pool uses Preemptible Instance, spot instances are prioritized. You can configure the Percentage of pay-as-you-go instances (%) to automatically supplement with pay-as-you-go instances when spot instances cannot be created due to inventory or other reasons. Distribution Balancing: Distributes ECS instances evenly across multiple zones, but only in multi-zone scenarios. If zone distribution becomes unbalanced due to inventory shortages, you can rebalance.	✓
   Use Pay-as-you-go Instances When Spot Instances Are Insufficient	Requires selecting spot instances as the billing method. When enabled, if sufficient spot instances cannot be created due to price or inventory reasons, ACK automatically attempts to create pay-as-you-go instances as a supplement. Cloud resource and billing information: ECS instance	✓
   Enable Supplemental Spot Instance	Requires selecting spot instances as the billing method. When enabled, upon receiving a system notification that a spot instance will be reclaimed (5 minutes before reclamation), ACK attempts to scale out new instances for compensation. Compensation successful: ACK drains the old node and removes it from the cluster. Compensation failed: ACK does not drain the old node, and the instance is reclaimed after 5 minutes. When inventory is restored or price conditions are met, ACK automatically purchases instances to maintain the desired node count. For details, see Spot instance node pool best practices. Active release of spot instances may cause business disruptions. To improve compensation success rates, we recommend also enabling Use Pay-as-you-go Instances When Spot Instances Are Insufficient. Cloud resource and billing information: ECS instance	✓
   ECS Tags	Add tags to ECS instances automatically created by ACK as cloud resource identifiers. Each ECS instance can have up to 20 tags. To increase this limit, apply on the Quota Platform. Because ACK and ESS occupy some tags, you can specify up to 17 custom tags per instance. Expand to view tag usage details ACK occupies two ECS tags by default. ack.aliyun.com:<Your cluster ID> ack.alibabacloud.com/nodepool-id:<Your node pool ID> ESS occupies one ECS tag by default: acs:autoscaling:scalingGroupId:<Your node pool scaling group ID>. After enabling node autoscaling, Auto Scaling occupies two ECS tags by default, so the node pool occupies two additional ECS tags: k8s.io/cluster-autoscaler:true and k8s.aliyun.com:true. After enabling node autoscaling, components use ECS tags to record node labels and taints for pre-checking scheduling behavior of scaled-out nodes. Each node label is converted to k8s.io/cluster-autoscaler/node-template/label/<Label key>:<Label value>. Each node taint is converted to k8s.io/cluster-autoscaler/node-template/taint/<Taint key>/<Taint value>:<Taint effect>.	✓
   Taints	Add key-value taints to nodes. A valid taint key includes an optional prefix and a name. If a prefix is specified, separate it from the name with a forward slash (/). Expand to view details Key: The name must be 1–63 characters long, start and end with a letter, digit, or character [a-z0-9A-Z], and can contain letters, digits, hyphens (-), underscores (_), and periods (.). If a prefix is specified, it must be a DNS subdomain, meaning a series of DNS labels separated by periods (.), up to 253 characters long, ending with a forward slash (/). Value: Can be empty, up to 63 characters long, must start and end with a letter, digit, or character [a-z0-9A-Z], and can contain letters, digits, hyphens (-), underscores (_), and periods (.). Effect: NoSchedule: Prevents new pods that do not tolerate this taint from being scheduled to the node, but does not affect pods already running. NoExecute: Prevents new pods that do not tolerate this taint from being scheduled to the node and evicts any running pods that do not tolerate this taint. PreferNoSchedule: ACK tries to avoid scheduling pods to nodes with taints they cannot tolerate, but does not enforce this strictly.	✓
   Node Labels	Add key-value labels to nodes. A valid key includes an optional prefix and a name. If a prefix is specified, separate it from the name with a forward slash (/). Expand to view details Key: The name must be 1–63 characters long, start and end with an alphanumeric character [a-z0-9A-Z], and can contain letters, digits, hyphens (-), underscores (_), and periods (.). If a prefix is specified, it must be a DNS subdomain, meaning a series of DNS labels separated by periods (.), up to 253 characters long, ending with a forward slash (/). The following prefixes are reserved by Kubernetes core components and cannot be specified kubernetes.io/ k8s.io/ Prefixes ending with kubernetes.io/ or k8s.io/. For example, test.kubernetes.io/. Exceptions: kubelet.kubernetes.io/ node.kubernetes.io Prefixes ending with kubelet.kubernetes.io/. Prefixes ending with node.kubernetes.io. Value: Can be empty, up to 63 characters long, must start and end with an alphanumeric character [a-z0-9A-Z], and can contain letters, digits, hyphens (-), underscores (_), and periods (.).	✓
   Set to Unschedulable	Newly added nodes are set as unschedulable by default when registered to the cluster. Manually adjust the node scheduling status in the node list. This setting applies only to clusters running Kubernetes versions earlier than 1.34. For details, see Kubernetes 1.34 version notes.	✓
   Container Image Acceleration	Supported only for containerd runtime version 1.6.34 or later. Newly added nodes automatically detect whether container images support on-demand loading. If supported, containers start faster by default using on-demand loading, reducing application startup time. For details, see Use on-demand loading to accelerate container startup.	✓
   [Deprecated] CPU policy	Specify the CPU management policy for kubelet nodes. None: Default policy. Static: Allows pods with certain resource characteristics on the node to have enhanced CPU affinity and exclusivity. We recommend using Custom node pool kubelet configuration.	✗
   Custom Node Name	Node names consist of a prefix, node IP address, and suffix. When enabled, node names, ECS instance names, and ECS instance hostnames change accordingly. Example: Node IP address is 192.XX.YY.55, prefix is aliyun.com, suffix is test. Linux node: Node name, ECS instance name, and ECS instance hostname are all aliyun.com192.XX.YY.55test. Windows node: Hostname is fixed as the IP address, with - replacing . in the IP address, and no prefix or suffix included. Thus, the ECS instance hostname is 192-XX-YY-55, while the node name and ECS instance name are aliyun.com192.XX.YY.55test. Important When the custom node name format depends on truncating part of the IP address, if the VPC CIDR block is large and the truncated IP length (lenOfIP) is insufficient, node name conflicts may occur, causing node scale-out failures in instant node elasticity scenarios. Based on your VPC CIDR block, set the IP truncation length as follows: For large CIDR blocks like 10.0.0.0/8 and 172.16.0.0/12, set lenOfIP to at least 9. For the 192.168.0.0/16 CIDR block, set lenOfIP to at least 6.	✗
   Worker RAM Role	Supported only for ACK managed clusters Specifiable only when creating a new node pool. Specify a Worker RAM role at the node pool level to reduce security risks from sharing a single Worker RAM role across all nodes. Default Role: Uses the default Worker RAM role created for the cluster. Custom: Uses the specified role as the Worker RAM role. If left empty, the default role is used. For details, see Use a custom Worker RAM role.	✗
   Instance Metadata Access Mode	Supported only for clusters running Kubernetes 1.28 or later. Configure the ECS instance metadata access mode. Inside the ECS instance, access the metadata service to obtain instance metadata, including instance ID, VPC information, NIC information, and other instance properties. For details, see Instance metadata. Normal Mode and Security Hardening Mode: Supports accessing the metadata service using both normal and reinforced modes. Security Hardening Mode: Supports accessing the metadata service using only reinforced mode. For details, see Use reinforced mode only to access ECS instance metadata.	✗
   Pre-defined Custom Data	Before nodes join the cluster, run the specified instance pre-user User-Data script. Example: If the pre-user data is touch /tmp/pre-script, the combined script execution order on the node is as follows. #!/bin/bash # Input instance pre-user data executes here touch /tmp/pre-script # ACK node initialization script executes here For the execution logic of this configuration during node initialization, see Node initialization process overview.	✓
   User Data	After nodes join the cluster, run the specified instance user User-Data script. Example: If the instance user data is touch /tmp/post-script, the combined script execution order on the node is as follows. #!/bin/bash # ACK node initialization script executes here # Input instance user data executes here touch /tmp/post-script For the execution logic of this configuration during node initialization, see Node initialization process overview. Successful cluster creation or node scale-out does not guarantee successful execution of the instance user script. Log on to the node and run grep cloud-init /var/log/messages to view execution logs.	✓
   CloudMonitor Agent	View and monitor node and application status in the CloudMonitor console. This setting applies only to new nodes added to the node pool, not existing nodes. To enable this for existing nodes, install it in the CloudMonitor console. Cloud resource and billing information: Cloud Monitor	✓
   Public IP	ACK assigns an IPv4 public IP address to nodes. This setting applies only to new nodes added to the node pool, not existing nodes. To grant public network access to existing nodes, configure and bind an EIP. For details, see Bind EIP to cloud resources. Cloud resource and billing information: ECS public network	✓
   Custom Security Group	Specify a basic or enterprise security group for the node pool. ACK does not add extra access rules to the security group. You must manage security group rules yourself to avoid access issues. For details, see Configure cluster security groups. Each ECS instance has a limit on the number of security groups it can join. Ensure sufficient security group quota.	✗
   RDS Whitelist	Add node IPs to the RDS instance whitelist.	✓
   Deployment Set	After creating a deployment set in the ECS console Create deployment set, specify it for the node pool so that scaled-out nodes are distributed across different physical servers, improving high availability. By default, a deployment set supports up to 20 * number of zones (determined by vSwitches), limiting the maximum node count in the node pool. Ensure sufficient quota in the deployment set. To enable this later, see Node pool deployment set best practices.	✓
   Resource Pool Policy	The resource pool strategy used when adding nodes (supported only when Instance Configuration Mode is set to Specify Instance Type). Resource pools include private pools generated after activating elastic provisioning or capacity reservations (immediate-effect capacity reservation or scheduled-effect capacity reservation) services, along with public pools, for node startup selection. Private Pool First: Prioritizes using the specified private pool. If no private pool is specified or the specified private pool lacks capacity, it automatically matches open-type private pools. If no eligible private pool exists, it uses the public pool to create instances. Private Pool Only: Requires specifying a private pool ID. If the specified private pool lacks capacity, node startup fails. Do Not Use: Does not use resource pool strategies.	✓
   [Deprecated] Private pool type	This configuration item is deprecated. Switch to using Resource Pool Policy to specify private pools. The private pool resources available for the selected zone and instance type. Types include the following: Open: Instances automatically match open-type private capacity pools. If no eligible private pool exists, public pool resources are used for startup. Do Not Use: Instances do not use any private pool capacity and start directly using public pool resources. Specified: Requires selecting a private pool ID to restrict instances to use only that private pool capacity for startup. If the private pool is unavailable, instance startup fails.	✓

2. Click Confirm Configuration.

   On the Confirm Configuration page, click Equivalent Code in the lower-left corner to generate sample Terraform or SDK parameters for the current node pool configuration.

   In the node pool list, a node pool's Status is Initializing during creation and changes to Active upon successful creation.

Edit a node pool

After a node pool is created, you can adjust its settings in the ACK console, such as vSwitches, billing method, instance types, system disks, and enabling or disabling auto scaling. For a list of editable settings, see the parameter descriptions in Create a node pool.

Editing a node pool does not affect its existing nodes or the workloads running on them. After the configuration is updated, new nodes added to the node pool use the new configuration by default.

1. On the node pools page, find the node pool to edit and click Edit in the Actions column.

2. On the Edit Node Pool page, modify the settings, and then follow the on-screen instructions to complete the configuration.

   While the node pool is being updated, its Status on the node pools page is Updating. When the update is complete, the Status changes to Active.

View a node pool

You can view the basic information and monitoring data for a node pool, as well as details about the nodes and a history of scaling activities in the pool.

Click the name of the target node pool to view the following information:

Delete a node pool

The release rules for nodes vary by billing method. Before you delete a node pool, check whether an expected number of nodes is set for the pool. This setting directly affects the node release behavior.

1. (Optional) Click the target node pool name. On the Basic Information tab, check if Desired number of nodes is configured. If this setting is not enabled, the Desired number of nodes field displays a hyphen (-).

2. In the Actions column of the target node pool, click >Delete. Read the confirmation message carefully, and then click OK.

   Important

   A node's system disk and data disks share its lifecycle. When a node is released, its cloud disks are also released, and all data on them is permanently lost. To keep your data safe, use a PersistentVolume (PV) to decouple the data lifecycle from the node lifecycle.

Related operations

After a node pool becomes active, you can perform the following operations in the node pool list.

Managed configuration capability comparison

FAQ

Related documentation

• You can remove a node when it is no longer needed. For more information, see Remove a node.

• ACK reserves a portion of node resources to ensure that kube components and system processes can run. For more information, see Node resource reservation policy.

• If your cluster has insufficient capacity to schedule application Pods, enable node scaling to automatically expand your node resources. For more information, see Node scaling.

• The maximum number of Pods per worker node depends on the network plugin and is usually fixed. To increase the number of available Pods, you can scale out the node pool, upgrade the instance type, or rebuild the cluster with a new Pod CIDR block. For more information, see Adjust the number of Pods per node.