Kubernetes releases a new minor version every four months. As new Kubernetes versions are released, Container Service for Kubernetes updates its support for Kubernetes versions. For example, when a new version is released, ACK supports cluster creation of this version, provides maintenance support for this version, and discontinues outdated versions. This topic describes how ACK supports different Kubernetes versions, including the version list update cycle, the support policies, and the risks of using outdated Kubernetes versions.
Release history
The following table describes the Kubernetes versions that are supported by ACK managed clusters, ACK dedicated clusters, and ACK Serverless clusters.
Version | Status | Release date (ACK) | Discontinue date (ACK) |
Released | January 2025 | January 2026 Note
| |
Released | September 2024 | September 2025 Note Starting from v1.31, ACK has expanded its support for Kubernetes versions from only even-numbered minor releases, such as v1.28 and v1.30, to include all minor versions. Additionally, for Kubernetes minor versions 1.31 and later, the ACK support cycle has been adjusted to one year. | |
Released | June 2024 | June 2026 | |
Released | October 2023 | October 2025 | |
Released | April 2023 | April 2025 |
Version description
The Kubernetes versions supported by ACK follow the semantic versioning scheme in the x.y.z-aliyun.n format x.y.z is the open source Kubernetes version. x is the major version, y is the minor version, z is the patch version, and n is the ACK patch version.
Version lifecycle
After the Kubernetes community releases a new minor version, ACK performs a risk assessment and consistency test on the version. You can create clusters of the new version and update existing clusters to the new version within two weeks after the release.
After the Kubernetes community releases a new patch version for a minor version, ACK determines whether to release the patch version based on the risk level of the issue fixed by the patch version. If a new patch version that contains a high-severity vulnerability is released, ACK assesses and verifies the vulnerability within 24 hours after the release. After the new patch version is assessed and verified, ACK allows you to create clusters of the version and update clusters to the version.
Rules for supporting Kubernetes versions
Cluster creation
ACK allows you to create clusters of the latest three minor versions. Currently, the latest three minor versions are 1.31, 1.30, and 1.28 When ACK starts to support Kubernetes 1.31, Kubernetes 1.26 is discontinued and you can no longer create clusters of Kubernetes 1.26. In addition, you can no longer create clusters of the outdated patch versions of 1.26.
When a new patch version is released for a minor version, you can no longer create clusters of earlier patch versions of the minor version. For example, when 1.30.7 is released, you can no longer create clusters of 1.30.1.
Cluster update
ACK allows you to update ACK clusters from a minor version only to the following minor version. You cannot skip minor versions when you update ACK clusters or roll back your ACK clusters to an earlier version. For example, if your cluster runs Kubernetes 1.28 and you want to update the cluster to Kubernetes 1.31, you need to first update the cluster to Kubernetes 1.30 and then to Kubernetes 1.31.
ACK allows you to update an ACK cluster only to the latest patch version. You cannot update your cluster to outdated patch versions.
Technical support
ACK provides technical support for versions that are still available. Technical support provided by ACK includes consultation, online tutorials, and troubleshooting.
Risks in outdated Kubernetes versions
Security and stability risks exist in outdated Kubernetes versions. If your cluster runs an outdated Kubernetes version, you can no longer use the latest features, benefit from the latest bug fixes, enjoy improved technical support, or fix security vulnerabilities.
We recommend that you update your cluster to a secure and stable version.
Manual update: Manually update your cluster to the latest version. When you manually update your cluster, you can select the nodes that you want to update, specify the maximum number of nodes to update in each batch, configure the update interval, and configure the pause policy.
Auto update: Enable auto updates for your cluster. When you enable auto updates for your cluster, you can select an update frequency.
Forceful updates for outdated Kubernetes versions
Kubernetes does not disclose Common Vulnerabilities and Exposures (CVEs) or provide patches for CVEs in outdated Kubernetes versions. Therefore, security risks exist in outdated Kubernetes versions. The maintenance period of a Kubernetes version is one year after release. If a Kubernetes version was released more than one year ago, the version is outdated. ACK clusters are deployed on top of a managed architecture in Alibaba Cloud. If an ACK cluster runs an outdated Kubernetes version, the security risks in the version affect both the cluster and the cloud environment where the cluster is deployed. For availability and security purposes, after the Kubernetes version of a cluster becomes outdated, ACK forces the cluster to update to a secure and stable version supported by ACK.
However, ACK does not immediately force the update when the Kubernetes version of a cluster becomes outdated. We recommend that you manually update a cluster at the earliest opportunity when the Kubernetes version of the cluster becomes outdated. ACK will send notifications to you by text message, email, or internal message at least one month before the forceful update.
A forceful update includes the following operations:
Update the components that are incompatible with the destination Kubernetes version.
Update the control plane of the cluster.
Update node pools and nodes in the cluster.
In the following scenarios, forceful updates are not performed and you must manually update the cluster:
The cluster is an ACK dedicated cluster. In this case, we recommend that you migrate from the ACK dedicated cluster to an ACK Pro cluster. For more information, see Hot migration from ACK dedicated clusters to ACK Pro clusters.
The cluster runs Kubernetes 1.22 and uses Docker as the container runtime. For more information about how to migrate the container runtime from Docker to containerd, see Migrate the container runtime from Docker to containerd.
The NGINX Ingress controller version installed in the cluster is outdated and incompatible with the Kubernetes version of the cluster. For more information about the release notes for the NGINX Ingress controller, see Nginx Ingress Controller.
FAQ
Can I use a fixed Kubernetes version for my cluster?
No. Security risks in outdated Kubernetes versions affect both your cluster and the cloud environment where the cluster is deployed. For availability and security purposes, after the Kubernetes version of a cluster becomes outdated, ACK forces the cluster to update to a secure and stable version supported by ACK.
We recommend that you manually update your cluster to the latest Kubernetes version at the earliest opportunity. This way, you can use the latest features provided by ACK and enjoy optimized technical support. Before you update your cluster, refer to Release notes for Kubernetes versions supported by ACK to learn about the feature updates and usage notes of different Kubernetes versions. We recommend that you enable auto updates for your cluster to automatically update your cluster on a regular basis. For more information, see Automatically update a cluster.
How do I quickly update a cluster that runs an old Kubernetes version to the latest version?
You can use one of the following methods:
Method 1: Gradually update the cluster to the latest Kubernetes version. This method requires consecutive updates. Check whether the business in the cluster can stably run between updates. For more information, see Manually update a cluster.
Method 2: Create a cluster that runs the latest Kubernetes version and migrate workloads from the old cluster to the new cluster. After the migration is completed, delete the old cluster. For more information about how to create and configure a cluster, see Create an ACK managed cluster.
Can I skip minor versions when I update a cluster?
ACK allows you to update ACK clusters from a minor version only to the following minor version. You cannot skip minor versions when you update ACK clusters. Before you update the control plane, make sure that the Kubernetes version used by the control plane is the same as the Kubernetes version used by nodes in the cluster.
How do I change the container runtime from Docker to containerd when I update a cluster from Kubernetes 1.22 to 1.24?
Kubernetes 1.24 and later no longer use Docker as the built-in container runtime. When you update the Kubernetes version of a cluster to 1.24 or later, you must change the container runtime from Docker to containerd for the cluster.
Plan 1: Update by creating a new node pool and migrating workloads to the new node pool. Create a new node pool and select containerd as the container runtime when you create the node pool. Then, redeploy workloads, schedule the application pod to the new node pool, and delete the legacy node pool to migrate the workloads to the new node pool.
Plan 2: Update by replacing the system disk. This plan requires replacing the system disk of the nodes. Do not store important data in the system disk, or back up the data in the system disk before the update. The data disks are not affected by the update.
The following sections describe the scheme and configuration methods for this update plan.
For more information, see Change the container runtime from Docker to containerd.
How do I ensure stable cluster updates?
An ACK cluster consists of a control plane and node pools.
Control plane update: ACK performs a precheck before you update the control plane of a cluster to check whether deprecated APIs, incompatible components, incompatible feature configurations, or control plane issues exist in the cluster. The precheck results do not affect the workloads that run in the cluster. If issues are reported in the precheck results, you can fix the issues based on the suggestions provided in the console. For more information, see Manually update ACK clusters.
Node pool update: When you update a node pool, you need to update the kubelet and containerd. ACK performs a precheck before you update a node pool to check whether the node status, system resources, disk status, and network environment meet the requirements. The precheck results do not affect the workloads that run in the cluster. If issues are reported in the precheck results, you can fix the issues based on the suggestions provided in the console.
You can also configure an update policy for a node pool. When you configure the policy, you can select the nodes that you want to update, specify the maximum number of nodes to update in each batch, and configure the pause policy. If critical business data is stored on system disks, we recommend that you create snapshots for the system disks. For more information, see Snapshots. For more information, see Update a node pool.
What are the usage notes for cluster updates?
You cannot roll back your ACK clusters to an earlier version. We recommend that you perform a test update in the test environment. After you verify that the update works as expected, you can update clusters in the production environment. You can also update some nodes first to test the update. For more information, see Update some nodes first.
Different Kubernetes versions vary in terms of the supported component versions, supported features, and deprecated features. For more information, see Release notes for Kubernetes versions supported by ACK.
Follow the usage notes for control plane updates. For more information, see Usage notes for control plane updates.
Follow the usage notes for node pool updates. For more information, see Usage notes for node pool updates.
References
For more information about the operating systems and operating system image versions supported by ACK, see Release notes for OS images.
For more information about the CVEs related to ACK and how to fix the CVEs, see CVE vulnerability fixes.
For more information about the check items in the update precheck and the deprecated APIs that may lead to issues in the precheck results, see Cluster check items and suggestions on how to fix cluster issues.