When you create an Container Service for Kubernetes (ACK) managed cluster, enable Auto Mode to launch a best-practice Kubernetes cluster with minimal planning. ACK then provisions and manages a System node pool to run system components and a Intelligent managed node pools to run your workloads, handling the entire node lifecycle so you can focus on your applications.
Before you enable Auto Mode, read Auto mode to understand its features and use cases.
Preparation
Planning and design
Before you create a cluster, plan and design the cluster configuration based on your business needs to ensure that the cluster runs stably, efficiently, and securely.
Region: The closer the selected region is to your users and deployed resources, the lower the network latency and the faster the access speed.
Zone: We recommend that you configure multiple zones to ensure high availability (HA) for the cluster.
Network address planning: Plan the VPC CIDR blocks (VPC's own CIDR block and vSwitch CIDR blocks) and Kubernetes CIDR blocks (pod address range and service address range) based on your business scenario and cluster size. This defines the IP address range for the entire cluster and the number of available IP addresses for pods and nodes.
Public network access: Determine whether cluster nodes need to access the public network. Public network access is required to pull public images.
Activation and authorization
Before you create a cluster, activate the service and authorize the account:
Activate ACK: For first-time use, log on to the ACK and complete the activation as prompted.
Role authorization: Go to RAM Quick Authorization and authorize the Alibaba Cloud account to create the default Container Service roles, so that ACK can properly invoke the related cloud service resources.
Activate cluster-related cloud products: Activate the cloud products on which ACK clusters depend, including VPC and SLB.
The creation process involves the purchase of pay-as-you-go resources (such as CLB). Make sure that your account balance is sufficient to avoid service outages caused by overdue payments.
Only Alibaba Cloud accounts can activate cloud products. To authorize RAM users to manage activated cloud products, see Grant cluster and cloud resource access with RAM.
Procedure
Log on to the ACK console. In the left navigation pane, click Clusters.
In the top-left corner of the page, select the resource group and region where your target resources reside.

On the Clusters page, click Create Kubernetes Cluster. On the ACK Managed Cluster page, enable Auto Mode.
After you enable Auto Mode, the page displays the three core capabilities of Auto Mode: Fully managed operations (fully managed cluster control plane, automatic version upgrades, maintenance-free nodes, and automatic self-healing), Automatic node scaling (on-demand elastic scaling, automatic instance type selection, and optimized resource costs), and Highly optimized node OS (container-optimized OS with fast startup, immutable file system, and secure-by-default best practices).
Follow the on-screen instructions to complete the cluster configuration. After you carefully review the cluster configuration and read the service agreement, click Create Kubernetes Cluster.
For detailed information about each configuration item, see Cluster configuration.
Auto Mode supports only ACK managed Pro cluster, and involves cluster management fees and related cloud product fees. View the cluster cost overview at the bottom of the creation page, or refer to the billing documentation of ACK and each product. See Billing overview and Cloud resource costs.
Click Console-to-Code in the top-right corner of the page to generate the corresponding Terraform or SDK example parameters for the current cluster configuration.
After the cluster is created, a system node pool and a Intelligent managed node pools are automatically created. The intelligent managed node pool dynamically scales on demand based on workload requirements. ACK takes over node lifecycle management, including operating system upgrades, software upgrades, and security vulnerability fixes.
After creation, ACK installs components based on your configuration. These components may consume computing resources in the cluster. The intelligent managed node pool automatically scales out the corresponding nodes.
What to do next
Appendix
Shared responsibility model
ACK Auto Mode provides automated, intelligent Kubernetes cluster operations and reduces the operational effort required. However, in some scenarios, you still need to fulfill certain obligations.
Alibaba Cloud responsibilities | Customer responsibilities | Shared responsibilities |
|
|
|
System node pool
ACK Auto Mode clusters rely on various system components to ensure normal cluster operation. Mixing system components with workloads may cause resource contention and mutual interference. The system node pool is a dedicated intelligent managed node pool in ACK Auto Mode clusters. It uses labels, taints, and scheduling policies to isolate system components on dedicated nodes, improving cluster reliability and security. The system node pool is enabled by default in new ACK Auto Mode clusters, with the default name |
How it works
The default name of the system node pool is ack-system. It uses the following combination of labels, taints, and scheduling policies to strictly isolate system components from workloads.
Mechanism | Configuration | Purpose |
Dedicated label |
| Identifies nodes as belonging to the system node pool, for use in scheduling policy matching. |
Taint |
| Prevents workload Pods without a corresponding toleration from being scheduled to the system node pool. |
Node Affinity |
| Forces system component Pods to be scheduled to nodes with the system node pool label. |
Toleration | By default, system components tolerate the | Ensures that system component Pods can be scheduled to the system node pool. |
The combination above achieves the following scheduling effects:
System components are scheduled to the system node pool: Node Affinity forces scheduling, and Toleration allows the Pods to pass the taint check.
Workload Pods are scheduled to regular node pools: Because workload Pods do not have a toleration for the
CriticalAddonsOnlytaint, they cannot be scheduled to the system node pool.
Main features and benefits
Strict isolation: System components are scheduled only to the system node pool, strictly isolated from workload node pools. This avoids resource contention and improves overall cluster stability and performance.
Managed by ACK: ACK handles the creation, upgrade, and scaling of the system node pool, without requiring manual intervention.
Quotas and limits
If you have a large cluster or your account contains many resources, you must be aware of the quotas and limits for using ACK clusters. For more information, see Quotas and limits.
Limits: These include ACK configuration limits (such as account balance) and single-cluster capacity limits (the maximum capacity of different Kubernetes resources within a single cluster).
Quota limits and quota increase requests: This includes quota limits for ACK clusters and the cloud products on which ACK depends, such as ECS and VPC. To request a quota increase, follow the instructions in the relevant documentation.
Cluster configuration
Create a cluster with the default configuration, or make flexible adjustments based on your business needs and the resources available under your account. In the Editable after creation column of the table,
indicates that the item cannot be modified after creation, and
indicates that the item can be modified. Pay special attention to items that cannot be modified.
Network configuration
Configuration item | Description | Editable after creation |
IPv6 Dual-stack | Supported only for Kubernetes 1.22 or later, only with Terway, and cannot be used together with eRDMA. The cluster supports both IPv4 and IPv6 protocols, but communication between worker nodes and the control plane still uses IPv4 addresses. Ensure the following:
| ✗ |
VPC | The VPC for the cluster. To ensure high availability, we recommend selecting two or more zones.
We recommend using standard private CIDR blocks for the cluster VPC (for example, 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16). If you have special requirements, apply at the Quota Center (Create a cluster using a public CIDR block VPC). Cloud resource and billing information: | ✗ |
Configure SNAT for VPC | Do not select this option when using a shared VPC. Select this option if nodes need public network access (to pull public images or access external services). ACK automatically configures a NAT Gateway and SNAT rules to enable public network access for cluster resources.
If you do not select this option, you can manually configure a NAT Gateway and SNAT rules after cluster creation. For details, see Public NAT Gateway. Cloud resource and billing information: | ✓ |
Access to API Server | ACK automatically creates a pay-as-you-go private CLB instance as the internal endpoint for the API Server. This CLB instance cannot be reused or deleted. If deleted, the API Server becomes inaccessible and cannot be restored. To use an existing CLB instance, submit a ticket. After selecting Use Existing Gateway for the VPC, you can set the SLB Source to Use Existing Gateway. You can optionally enable Expose API server with EIP.
To enable this later, see Enable public network access to API Server. Starting December 1, 2024, newly created CLB instances will no longer support Subscription billing, and will incur instance fees. For details, see [Product Announcement] Discontinuation of subscription billing for new cluster API Server CLB instances, Adjustment announcement for Classic Load Balancer CLB billing items. | ✗ |
Network Plug-in | The network plugin provides the foundation for pod-to-pod communication in the cluster. For a detailed comparison, see Compare Terway and Flannel container network plugins.
| ✗ |
Pod vSwitch | Required only when using the Terway plugin. The vSwitch used to assign IP addresses to pods. Each pod vSwitch corresponds to a worker node vSwitch, and both must be in the same zone. Important For the Pod virtual switch, use a subnet mask no larger than /19. The maximum allowed subnet mask is /25. If you use a larger subnet mask, the number of Pod IP addresses that can be allocated in the cluster is severely limited, which affects the cluster’s normal operation. | ✓ |
Container CIDR Block | Required only for Flannel. The IP address pool for assigning pod IPs. This CIDR block must not overlap with the VPC or any existing ACK cluster CIDR blocks in the VPC, and must not overlap with the Service CIDR. | ✗ |
Number of Pods per Node | Required only for Flannel. Defines the maximum number of pods allowed on a single node. | ✗ |
Service CIDR | Also known as Service CIDR, this is the IP address pool for assigning IPs to internal cluster services. This CIDR block must not overlap with the VPC or any existing cluster CIDR blocks in the VPC, and must not overlap with the Container CIDR Block. | ✗ |
Forwarding Mode | Select the kube-proxy proxy mode, which determines how cluster Services distribute requests to backend pods.
| ✗ |