The Kubernetes community releases a new minor version approximately every four months. Container Service for Kubernetes (ACK) aligns with this release cadence to manage the lifecycle of Kubernetes versions, including their creation, maintenance, and end-of-life (EOL). This document outlines the ACK support policy for Kubernetes versions, covering their releases, lifecycles, and support.
Release history
The following tables list the Kubernetes versions supported by ACK managed clusters.
Starting from v1.31, ACK supports all minor versions, expanding its previous policy of supporting only even-numbered minor versions (like 1.28 and 1.30). These versions are supported for one year.
Version | Status | ACK release date | ACK EOL date |
Planned | May 2026 | May 30, 2027 | |
Planned | February 2026 | February 28, 2027 | |
Planned | September 2025 | September 30, 2026 | |
Released | June 2024 | June 30, 2026 |
Version format
ACK uses the versioning scheme x.y.z-aliyun.n, where x.y.z is the community Kubernetes version (major.minor.patch) and n is the ACK patch version.
Version lifecycle
After the Kubernetes community releases a new minor version, ACK performs a risk assessment and runs consistency tests. Generally, you can create or upgrade clusters to the new version within two weeks of its first community patch release.
When the Kubernetes community releases a new patch version for a minor version, ACK evaluates the risk level of the fixed issues to determine whether to release an update. For patch versions that address high-severity security vulnerabilities, ACK typically completes its evaluation and releases the new version within 24 hours.
Support policy
Cluster creation
ACK supports the creation of clusters that run one of the three most recent Kubernetes minor versions. For example, if the latest three minor versions are 1.35, 1.34, and 1.33, cluster creation is no longer available for version 1.32 after ACK starts to support version 1.35. Cluster creation is also unavailable for outdated patch versions.
After a new patch version is released for a minor version, cluster creation is no longer available for earlier patch versions. For example, after version 1.30.7 is released, you can no longer create clusters that run version 1.30.1.
Cluster upgrade
You can only upgrade clusters one minor version at a time. Downgrades and skipping minor versions are not supported.
For patch versions, you can only upgrade to the latest available patch version. Upgrades to outdated patch versions are not supported.
Technical support
ACK provides technical support, including Q&A, online guidance, and troubleshooting, for all maintained Kubernetes versions.
Risks of outdated versions
Running an outdated version poses security and stability risks. After a version is no longer supported, your cluster cannot receive new features, bug fixes, or timely technical support, and is vulnerable to unpatched security flaws.
You must upgrade your cluster to a secure and stable version.
Manually upgrade a cluster: Upgrade your cluster one minor version at a time to the latest version. You can control the upgrade pace by specifying nodes to upgrade, setting the maximum number of concurrent nodes for an upgrade batch, and configuring upgrade intervals and pause policies.
Automatically upgrade a cluster: Enable automatic cluster upgrades and select a reasonable upgrade frequency to keep your cluster on a regular upgrade cycle.
Forced updates for outdated versions
For Kubernetes versions that are past the upstream support window, the Kubernetes community does not disclose CVE risks or provide patches. Potential security risks in outdated versions may not be discovered or fixed in time. Because ACK clusters use a managed architecture, these security risks can affect not only your cluster but also the overall security of Alibaba Cloud. Therefore, ACK does not allow clusters to run outdated versions for extended periods and will perform a forceful update to a secure and stable version.
ACK does not immediately perform a forceful update after a cluster's version becomes outdated. We recommend that you manually upgrade your cluster to a supported version. Before a forceful update is performed, ACK will send notifications via SMS, email, and internal messages at least one month in advance.
A forceful update includes the following actions:
Upgrade cluster components. Only components that are incompatible with the newer cluster version are upgraded.
Upgrade the cluster control plane.
Upgrade node pools and nodes.
Forceful updates are not performed in the following cases. You must perform the upgrade manually:
The cluster is an ACK dedicated cluster. We recommend that you migrate to an ACK Pro cluster. For more information, see Hot migrate an ACK dedicated cluster to an ACK Pro cluster.
The cluster runs Kubernetes 1.22 and uses Docker as the container runtime. You must migrate to the containerd runtime. For more information, see Migrate the node container runtime from Docker to containerd.
The installed NGINX Ingress controller is an older version with compatibility issues for the target ACK version. For component details, see the NGINX Ingress controller change log.
FAQ
Can I stay on a fixed version?
No. Potential security risks in outdated versions can affect not only your cluster but also the overall security of Alibaba Cloud. ACK does not allow clusters to run outdated versions for extended periods and will perform a forceful update to a secure and stable version.
Please upgrade your cluster version promptly (Manually upgrade a cluster) to take advantage of the latest features and technical support from ACK. Before upgrading, review the Release notes for Kubernetes versions supported by ACK to understand the feature changes and important notes for each version. We recommend enabling automatic cluster upgrades to ensure your cluster is upgraded regularly.
How to quickly upgrade an old cluster?
You can choose one of the following two solutions:
Solution 1: Upgrade one version at a time. After each upgrade, monitor your cluster to ensure your applications are running stably before you proceed with the next upgrade. For more information, see Manually upgrade a cluster.
Solution 2: Create a new cluster with the latest version, gradually migrate your applications to the new cluster, and then decommission the old cluster. For information about how to create and configure a cluster, see Create an ACK managed cluster.
Can I skip minor versions when upgrading?
No. ACK does not support skipping minor versions during an upgrade. You must upgrade your cluster one version at a time. In addition, before upgrading the cluster control plane, ensure your nodes run the same Kubernetes version as the control plane.
How to switch from Docker to containerd?
ACK no longer supports Docker as a built-in container runtime in Kubernetes v1.24 and later. You must migrate the node container runtime from Docker to containerd.
You can perform the runtime switch on the original node pool by using the node pool upgrade feature, or you can create a new containerd node pool to perform a rolling migration. For more information, see Migrate the node container runtime from Docker to containerd.
How does ACK ensure upgrade stability?
An ACK cluster consists of a control plane and one or more node pools.
Control plane upgrade: ACK provides a pre-upgrade check to inspect for deprecated APIs, component compatibility, feature configuration compatibility, and control plane component issues. Running the check does not affect the normal operation of your applications. If the check reports issues, you can follow the remediation advice provided in the console. For more information, see Manually upgrade a cluster.
Node pool upgrade: A node pool upgrade includes upgrading kubelet and containerd. ACK provides a pre-upgrade check to inspect the node status, system resources, disk status, and network environment. Running the check does not affect the normal operation of your applications. If the check reports issues, you can follow the remediation advice provided in the console.
You can also configure a custom upgrade policy. For example, you can control the upgrade pace by specifying which nodes to upgrade, setting the maximum number of concurrent nodes for an upgrade batch, and configuring a pause policy. If a node's system disk contains important application data, you can also create a snapshot of the node's system disk before upgrading the node pool. For more information, see Upgrade a node pool.
Upgrade precautions
Cluster upgrades cannot be rolled back. We recommend that you upgrade a test environment first and then upgrade the production environment after successful verification. During the upgrade process, you can also upgrade some nodes first for verification.
The supported component versions, features, and deprecated APIs vary between Kubernetes versions. For more information, see the Release notes for Kubernetes versions supported by ACK for different versions.
Follow the precautions for control plane upgrades.
Follow the precautions for node pool upgrades.
Related documents
For information about cluster upgrades, including impacts, procedures, precautions, and upgrade methods, see Upgrade clusters.
For information about the OS types and image versions that ACK supports, see OS image release notes.
For information about CVE fixes and corresponding solutions provided by ACK, see Fix CVEs.
For information about pre-upgrade checks and deprecated APIs, see Cluster check items and remediation solutions.
ACK Pro clusters enhance basic clusters with greater reliability and security for large-scale enterprise production environments, and are backed by a compensable SLA. If you need to migrate, see Hot migrate ACK managed basic clusters to ACK Pro clusters.