All Products
Search

This Product

    Container Service for Kubernetes:Manually upgrade an ACK cluster

    Document Center

    Container Service for Kubernetes:Manually upgrade an ACK cluster

    Last Updated:Aug 26, 2025

    To avoid security vulnerabilities and stability risks associated with outdated software, it's essential to upgrade your cluster in a timely manner. A cluster upgrade consists of two main phases: control plane upgrade and node pool upgrade.

    Important

    Before proceeding, review the full process in Upgrade a cluster to learn about the available methods, compatibility requirements, and best practices.

    Upgrade procedure

    You can upgrade the control plane first, followed by the node pools. However, ensure that the kubelet and container runtime versions on your nodes are compatible with the target control plane version to avoid failures or service disruptions.

    Example:

    If your control plane is at version 1.32 and your nodes are at 1.31, you must first upgrade the nodes to 1.32 before upgrading the control plane to 1.33.

    Steps

    1. Log on to the ACK console. In the navigation pane on the left, click Clusters.

    2. On the Clusters page, find the cluster you want and click its name. In the left-side pane, choose Operations > Upgrade Cluster.

    3. On the Cluster Upgrade page, select a Target Version for the upgrade and follow the on-screen instructions to complete the upgrade.

    Step 1: Upgrade the control plane

    1. Precheck

    Before upgrading, run a precheck to identify potential risks. This includes:

    • Use of deprecated APIs

    • Component compatibility

    • Overall cluster health

    Note

    For clusters running Kubernetes 1.20 or later, the system checks for deprecated APIs. While this doesn't block the upgrade, we recommend resolving any issues beforehand to ensure smooth operations post-upgrade.

    How to run precheck

    On the Cluster Upgrade page, click Precheck.

    After the scan completes, view the results in the Precheck Result section.

    Example:

    image

    Result

    Action

    Normal

    Proceed with the upgrade.

    Abnormal

    Address issues using the console guidance or refer to Cluster check items and remediation solutions.

    2. Perform the upgrade

    Duration:

    • ACK managed and ACK Serverless clusters: Upgrade is fast and highly available.

    • ACK dedicated clusters: Master nodes are upgraded one by one, taking about 8 minutes per node.

    Once precheck issues are resolved:

    1. Click Upgrade Now.

    2. Follow the prompts to complete the control plane upgrade.

    After the upgrade, new nodes added during scaling will automatically use the upgraded version.

    image

    3. Post-upgrade verification

    After the control plane is upgraded, verify the following:

    Check item

    Expected outcome

    Cluster version

    Updated to the target version on the Clusters page.

    API server & core components

    Status is Normal.

    Business applications

    Running as expected.

    Pod creation

    New pods can be created successfully.

    Node addition

    New nodes can be added without issues.

    Step 2: Upgrade a node pool

    After the control plane is upgraded, upgrade the node pool during off-peak hours to minimize impact.

    A node pool upgrade updates the kubelet and container runtime on each node.

    1. Precheck

    The precheck evaluates:

    • Node status

    • System resources

    • Disk health

    • Network environment

    How to run precheck

    1. On the Node Pool Upgrade page, find the target node pool and click Upgrade in the Actions column.

    2. Click Precheck at the bottom of the page.

    3. Review results in the Precheck Result section.

    image

    Result

    Action

    Normal

    Proceed with the upgrade.

    Abnormal

    Address issues using the console guidance or refer to Cluster check items and remediation solutions.

    2. Configure upgrade policy and start

    Duration:

    • In-place upgrade: about 5–10 minutes per batch.

    • System disk replacement (no snapshots): about 8 minutes per batch.

    • Time to drain nodes also affects total duration.

    • If snapshots are enabled, upgrade starts only after snapshot creation (time varies with data volume).

    Upgrade configuration

    Configuration item

    Description

    Version Information

    Shows current and available versions for kubelet and container runtime.

    Nodes To Upgrade

    Choose to upgrade all nodes, or upgrade a subset first and validate before upgrading the rest.

    Upgrade Method

    • In-place Upgrade: Components are updated in place. System disks are not replaced. Node data such as on data disks) is preserved.

    • System Disk Replacement Upgrade: Nodes are reinitialized with new system disks. Node name, instance ID, and IP remain unchanged. Data on system disks isdeleted. Data disks are unaffected.

      For details, see In-place upgrade and system disk replacement upgrade.

    Batch Upgrade Policy

    • Maximum Number Of Nodes Per Batch: Nodes are upgraded in batches (1, 2, 4, 8, and so on) until the maximum is reached, then fixed-size batches continue.

    • Auto Pause Policy: Choose whether to pause between batches. If you select Do Not Pause, set Interval Between Batches (5–120 minutes).

    • Automatic Snapshot: Recommended for system disk replacement upgrades. Snapshots back up node system disks before upgrade.

      Important

      Snapshots incur costs and are retained for 7 days by default. Delete them after the upgrade if no longer needed.

    Click Upgrade Now and follow the prompts to start.

    3. Post-upgrade verification

    After the node pool upgrade, verify the following:

    Check item

    Expected outcome

    Node versions

    On the node details page, kubelet and containerd versions match the target.

    Pod schedling

    Pods are scheduled normally.

    Business applications

    Function as expected.

    References

    Important