The Kubernetes community releases a new minor version about every four months. Container Service for Kubernetes follows the upstream release schedule for its Kubernetes versions. This includes creating, maintaining, and discontinuing support for versions. This topic describes how ACK supports Kubernetes versions. It covers version releases, support status, the version lifecycle, and the version support policy.
Version releases
The following table provides details about the Kubernetes versions that ACK managed clusters support.
Version | Status | ACK release date | ACK end of life date |
Released | September 2025 | September 30, 2026 The support period is one year. | |
Released | May 2025 | May 31, 2026 The support period is one year. | |
Released | January 2025 | January 31, 2026 The support period is one year. | |
Released | September 2024 | September 30, 2025 Important Starting from version 1.31, ACK expands its support for Kubernetes versions from only even-numbered minor versions, such as 1.28 and 1.30, to all minor versions. The support period for version 1.31 and later minor versions is adjusted to one year. | |
Released | June 2024 | June 30, 2026 | |
Released | October 2023 | October 31, 2025 |
Version number format
The format of an ACK Kubernetes version is x.y.z-aliyun.n. In this format, x.y.z represents the community Kubernetes version, where x is the major version, y is the minor version, and z is the patch version. The n represents the Alibaba Cloud patch version (ACK patch version).
Version lifecycle
After the Kubernetes community releases a new minor version, ACK performs a risk assessment and a conformance test on the version. You can typically create clusters that use the new version or upgrade existing clusters to the new version within two weeks after the community releases a patch version.
After the Kubernetes community releases a new patch for a minor version, ACK determines whether to release an upgrade for the patch version based on the risk level of the fixed issues. For patch versions that fix important security vulnerabilities, ACK typically completes the assessment and verification within 24 hours. Then, you can create clusters that use the new version or upgrade existing clusters to the new version.
Version support policy
Cluster Creation
You can create clusters that run one of the three latest Kubernetes minor versions. For example, if the three latest minor versions are 1.33, 1.32, and 1.31, you can no longer create clusters of version 1.30 after ACK starts to support version 1.33. You also cannot create clusters that run expired patch versions.
After a new patch version is released for a minor version, you can no longer create clusters that run earlier patch versions. For example, after version 1.30.7 is released, you can no longer create clusters of version 1.30.1.
Cluster Upgrades
You can only upgrade a cluster one minor version at a time. You cannot skip minor versions or roll back to an earlier version. For example, if your ACK cluster runs Kubernetes 1.31 and you want to upgrade it to 1.33, you must perform two upgrades. First, upgrade the cluster to 1.32, and then upgrade it to 1.33.
For patch versions, you can only upgrade a cluster to the latest patch version. You cannot upgrade a cluster to an expired patch version.
Technical Support
ACK provides technical support for all supported versions. This support includes answering questions, providing online guidance, and troubleshooting.
Risks of expired versions
Clusters that run expired versions have security and stability risks. After a cluster version expires, you can no longer benefit from the features and bug fixes of new Kubernetes versions. You also cannot receive timely and effective technical support. This exposes your cluster to the risk of unpatched security vulnerabilities.
Upgrade your cluster to a secure and stable version.
Manually upgrade a cluster: Upgrade the cluster one minor version at a time to the latest version. You can control the upgrade pace by specifying the nodes to upgrade, setting the maximum number of nodes that can be upgraded in each batch, and configuring the upgrade interval and pause policy.
Automatically upgrade a cluster: Enable automatic cluster upgrades and select a reasonable upgrade frequency to ensure your cluster is upgraded periodically.
Forced upgrades for expired versions
The Kubernetes community does not disclose Common Vulnerabilities and Exposures (CVE) risks or provide patches for versions that are past their maintenance period, which is typically one year. Potential security risks in expired versions may not be discovered and fixed promptly. Because ACK clusters primarily use a managed architecture, these security risks affect not only your cluster but also the overall security of Alibaba Cloud. Therefore, ACK does not allow clusters to remain in an expired state for a long time. ACK will forcibly upgrade these clusters to a secure and stable version.
After a cluster version expires, ACK does not immediately perform a forced upgrade. You must manually upgrade the cluster to a secure and stable version. Before performing a forced upgrade, ACK sends you a notification at least one month in advance through text messages, emails, and internal messages.
When a cluster is forcibly upgraded, the following items are upgraded:
Upgrade the cluster components (only the components that have compatibility issues with a higher cluster version are upgraded).
The cluster control plane is upgraded.
Node pools and nodes are upgraded.
Forced upgrades are not performed in the following situations. You must perform a manual upgrade.
For an ACK dedicated cluster, we recommend that you migrate to an ACK Managed Cluster Pro. For more information, see Hot migrate an ACK dedicated cluster to an ACK Managed Cluster Pro.
The cluster runs version 1.22 and uses Docker as the container runtime. You must migrate to the containerd runtime. For more information, see Migrate from Docker to containerd as the container runtime for nodes.
The version of the ACK Nginx Ingress component is too old and has compatibility issues with later ACK versions. For component descriptions, see the component change log in Nginx Ingress Controller.
FAQ
Can I choose not to upgrade my cluster and stay on one version forever?
No, you cannot. Potential security risks in expired versions affect not only your cluster but also the overall security of Alibaba Cloud. ACK does not allow clusters to remain in an expired state for a long time. ACK will forcibly upgrade these clusters to a secure and stable version.
Upgrade your cluster version promptly (see Manually upgrade a cluster) to benefit from the latest features and better technical support provided by ACK. Before you upgrade, see the Release notes to learn about the feature changes and precautions for each version. We recommend that you enable the Automatic cluster upgrade feature to maintain periodic automatic upgrades for your cluster.
My cluster is running a very old version. How can I quickly upgrade it?
You can use one of the following solutions.
Solution 1: Upgrade the cluster one minor version at a time. After each upgrade, check whether your services in the cluster run as expected before you proceed with the next upgrade. For more information, see Manually upgrade a cluster.
Solution 2: Create a cluster of the latest version, gradually migrate your applications to the new cluster, and then unpublish the old cluster. For information about how to create and configure a cluster, see Create an ACK managed cluster.
Does ACK support skipping minor versions during an upgrade?
ACK does not support skipping minor versions during an upgrade. You must upgrade your cluster one minor version at a time. In addition, before you upgrade the control plane of a cluster, make sure that the nodes in the cluster run the same version as the control plane.
When I upgrade a cluster from version 1.22 to 1.24, I need to switch from Docker to containerd. How do I do this?
ACK no longer supports Docker as the built-in container runtime in version 1.24 and later. You must migrate the container runtime of your nodes from Docker to containerd.
You can switch the runtime in the original node pool by upgrading the node pool. You can also create a new node pool that uses containerd and perform a rolling migration. For more information, see Migrate from Docker to containerd as the container runtime for nodes.
How does ACK ensure the stability of cluster upgrades?
An ACK cluster consists of a control plane and node pools.
Control plane upgrade: ACK provides a pre-check feature that runs before an upgrade. This feature checks for deprecated APIs, component compatibility, feature configuration compatibility, and control plane components. The check results do not affect the services that run in the cluster. If the check fails, you can find recommended fixes in the console. For more information, see Manually upgrade a cluster.
Node pool upgrade: A node pool upgrade includes upgrading the kubelet and containerd. ACK provides a pre-check feature that runs before an upgrade. This feature checks the node status, system resources, disk status, and network environment. The check results do not affect the services that run in the cluster. If the check fails, you can find recommended fixes in the console.
You can also configure an upgrade policy. For example, you can control the upgrade pace by specifying the nodes to upgrade, setting the maximum number of nodes that can be upgraded in each batch, and configuring a pause policy. If the system disks of your nodes store important service data, you can also create snapshots for the nodes before you upgrade the node pool. For more information, see Update a node pool.
What do I need to know before I upgrade a cluster?
Cluster upgrades cannot be rolled back. First, upgrade a test environment. After the verification is successful, upgrade the production environment. During the upgrade, you can also prioritize the upgrade of specific nodes for verification.
The supported component versions, features, and deprecated features vary by Kubernetes version. For more information, see the release notes for different versions.
Follow the notes for control plane upgrades.
Follow the notes for node pool upgrades.
References
For information about cluster upgrades, including the impact, procedure, notes, and methods, see Upgrade a cluster.
For information about the operating system types and image versions that ACK supports, see Operating system image release notes.
For information about the CVE vulnerability fixes that ACK provides and the corresponding solutions, see CVE vulnerability fixes.
For information about the check items of the cluster upgrade pre-check and deprecated APIs, see Cluster check items and recommended fixes.
ACK managed clusters of the Pro edition provide enhanced reliability and security for large-scale enterprise production environments based on the Basic Edition. They also provide a compensable Service-level agreement (SLA). For information about how to migrate, see Hot migrate a basic ACK managed cluster to an ACK managed cluster of the Pro edition.