The Kubernetes community releases a new minor version approximately every four months. Container Service for Kubernetes (ACK) follows this upstream release cadence to provide new Kubernetes versions. This process includes creating, maintaining, and ending support for each version. This topic describes the ACK support mechanism for Kubernetes versions, including version releases, support status, lifecycle, and support policies.
Version Releases
The following Kubernetes versions are supported for ACK managed clusters.
Starting with Kubernetes version 1.31, ACK expands its supported Kubernetes versions from even-numbered minor versions only, such as 1.28 and 1.30, to all minor versions. For minor versions 1.31 and later, ACK provides one year of support per version.
Version | Status | ACK Release Date | ACK End-of-Support Date |
Released In grayscale | February 2026 | February 28, 2027 | |
Released | September 2025 | September 30, 2026 | |
Released | May 2025 | May 31, 2026 | |
Released | June 2024 | June 30, 2026 |
Version Number Format
ACK Kubernetes versions follow the format x.y.z-aliyun.n. In this format, x.y.z matches the upstream Kubernetes version, where x is the major version, y is the minor version, and z is the patch version. The value n is the Alibaba Cloud patch version.
Version Lifecycle
After the Kubernetes community releases a new minor version, ACK performs a risk assessment and compatibility testing. ACK usually enables cluster creation and upgrades for the new version within two weeks of the first patch release from the community.
After the Kubernetes community releases a new patch for a minor version, ACK evaluates the severity of the issues that are fixed by the patch. If the patch fixes an important security vulnerability, ACK typically completes validation within 24 hours and then enables cluster creation and upgrades.
Support Policy
Cluster creation
ACK supports cluster creation for the three most recent Kubernetes minor versions. For example, if the most recent minor versions are 1.35, 1.34, and 1.33, ACK stops supporting cluster creation for version 1.32 after enabling 1.35. Expired patch versions also become unavailable for new clusters.
When a new patch version is released for a minor version, older patch versions become unavailable for new clusters. For example, after 1.30.7 is released, you cannot create new clusters that use 1.30.1.
Cluster upgrade
Cluster upgrades must be performed sequentially. You cannot skip minor versions or downgrade a cluster. For example, to upgrade an ACK cluster from Kubernetes 1.33 to 1.35, you must first upgrade to 1.34 and then to 1.35.
For patch versions, you can upgrade only to the latest available patch version. You cannot upgrade to an expired patch version.
Technical support
ACK provides technical support for versions that are still under maintenance. This support includes answering questions, providing live guidance, troubleshooting, and resolving issues.
Risks of Using Expired Versions
Clusters that run expired versions are exposed to security and stability risks. After a cluster version expires, you can no longer access new features, receive bug fixes, or obtain timely technical support. In addition, critical security vulnerabilities may remain unpatched.
Upgrade your cluster to a secure and stable version.
Manually upgrade your cluster: You can upgrade your cluster sequentially to the latest version. You can also control the upgrade pace by specifying target nodes, setting the maximum number of nodes to upgrade per batch, configuring upgrade intervals, and pausing upgrades as needed.
Automatically upgrade your cluster: You can enable automatic cluster upgrades and choose a suitable frequency to keep your cluster updated on a regular schedule.
Forced Upgrades for Expired Versions
The Kubernetes community does not disclose CVEs or provide patches for end-of-support versions. Unpatched security vulnerabilities in expired versions may go undetected and unaddressed. Because ACK clusters use a managed architecture, these risks affect not only your cluster but also the overall security of Alibaba Cloud. To prevent long-term use of expired versions, ACK enforces upgrades to secure and stable versions.
ACK does not immediately force an upgrade when a cluster version expires. Manually upgrade your cluster to a secure and stable version as soon as possible. Before ACK enforces an upgrade, you are notified at least one month in advance by text message, email, or internal message.
A forced upgrade updates the following components:
Upgrade cluster components (only components that are incompatible with the newer cluster version).
Upgrade the cluster control plane.
Upgrade node pools and nodes.
Forced upgrades do not apply in the following cases. You must manually upgrade your cluster instead.
Your cluster is an ACK dedicated cluster. You must migrate to an ACK managed cluster Pro Edition. For more information, see Hot migrate an ACK dedicated cluster to an ACK managed cluster Pro Edition.
Your cluster runs Kubernetes 1.22 with Docker as the container runtime. You must migrate to containerd. For more information, see Migrate node container runtime from Docker to containerd.
Your cluster uses an outdated ACK Nginx Ingress component that is incompatible with newer ACK versions. For more information, see the change log for the Nginx Ingress Controller.
FAQ
Can I avoid upgrading my cluster and stay on one version forever?
No, you cannot keep a cluster on the same version indefinitely. Security risks from expired versions affect not only your cluster but also the overall security of Alibaba Cloud. Therefore, ACK does not allow clusters to run expired versions indefinitely and enforces upgrades to secure and stable versions.
We recommend that you promptly manually upgrade your cluster to access the latest features and better technical support. Before you upgrade, review the version release notes for information about feature changes and important considerations. We recommend that you enable automatic cluster upgrade to keep your cluster updated on a regular schedule.
My cluster runs a very old version. How can I upgrade quickly?
You have two options:
Option 1: Upgrade the cluster sequentially. After each upgrade, verify that your applications run as expected before you proceed to the next upgrade. For more information, see Manually upgrade your cluster.
Option 2: Create a new cluster that runs the latest version. Then, gradually migrate your applications to the new cluster and unpublish the old cluster. For more information about how to create and configure a cluster, see Create an ACK managed cluster.
Does ACK support skipping multiple versions during an upgrade?
No, it does not. ACK does not support skipping minor versions during an upgrade. You must upgrade your cluster sequentially. Also, before you upgrade the cluster control plane, make sure that the node versions match the control plane version.
When upgrading from Kubernetes 1.22 to 1.24, I need to switch from Docker to containerd. How do I do that?
Starting from Kubernetes 1.24, ACK no longer supports Docker as the container runtime. You must migrate the container runtime of your nodes from Docker to containerd.
You can switch the runtime in-place using the node pool upgrade feature, or create a new node pool that uses containerd and perform a rolling migration. For more information, see Migrate node container runtime from Docker to containerd.
How does ACK ensure upgrade stability?
An ACK cluster consists of a control plane and node pools.
Control plane upgrade: ACK runs pre-upgrade checks to check for deprecated APIs, component compatibility, configuration compatibility, and control plane components. These checks do not affect running workloads. If a check fails, you can view the remediation suggestions in the console. For more information, see Manually upgrade your cluster.
Node pool upgrade: A node pool upgrade involves upgrading components such as kubelet and containerd. ACK runs pre-upgrade checks on the node status, system resources, disk status, and network environment. These checks do not affect running workloads. If a check fails, you can view the remediation suggestions in the console.
You can also configure custom upgrade policies. For example, you can specify target nodes, set the maximum number of nodes to upgrade per batch, or pause upgrades. If the system disk of a node contains critical application data, create a snapshot before you upgrade the node pool. For more information, see Upgrade a node pool.
What should I watch for during cluster upgrades?
Upgrades cannot be rolled back. We recommend that you first upgrade your staging environment and validate the upgrade. After the validation is successful, upgrade your production environment. During the upgrade, you can upgrade specific nodes first for validation.
Each Kubernetes version supports different component versions and features, and may deprecate some features. For more information, see the version release notes for each version.
Follow the control plane upgrade considerations.
Follow the node pool upgrade considerations.
References
For more information about cluster upgrades, including the impact, procedure, considerations, and methods, see Upgrade a cluster.
For more information about the supported operating systems and image versions, see Operating system image release history.
For more information about CVE vulnerability fixes and related solutions, see CVE vulnerability fixes.
For more information about pre-upgrade check items and deprecated APIs, see Cluster check items and remediation.
ACK managed cluster Pro Edition provides enhanced reliability and security for large-scale enterprise production environments and offers a service-level agreement (SLA) with financial compensation. For more information about how to migrate, see Hot migrate an ACK managed cluster Basic Edition to an ACK managed cluster Pro Edition.