Kubernetes 1.24 no longer supports Docker as a built-in container runtime. The Dockershim component is also deprecated in Kubernetes 1.24. Therefore, you can no longer use the kubelet to interact with Docker to create or manage containers. Due to this update, ACK clusters that run Kubernetes 1.24 or later no longer support Docker as a built-in container runtime. To update the Kubernetes version of your ACK clusters to 1.24 or later, you must upgrade the container runtime from Docker to containerd.
containerd is a standard container runtime supported by Kubernetes. It surpasses Docker in terms of startup speed, resource saving, and security.
Solutions for upgrading from Docker to containerd
Important
Before you start, make sure that your workload does not rely on Docker to build container images. In most cases, Kubernetes workloads do not rely on the container runtime and the Docker backend is still containerd. Therefore, after you upgrade to containerd, your workload can continue to run as normal.
We recommend that you test the environment before you start the upgrade and perform this operation during off-peak hours.
You can use the following solutions to upgrade from Docker to containerd.
Solution 1: Upgrade the node pool that uses Docker (recommended)
You can click Kubelet Update on the Node Pools page of the ACK console to upgrade from Docker to containerd. This solution automatically replaces the system disks of the nodes in the node pool. Do not store important data in the system disks or back up the system disks in advance. Data disks are not affected by the upgrade.
Log on to the ACK console. In the left-side navigation pane, click Clusters.
On the Clusters page, find the cluster to manage and click its name. In the left-side navigation pane, choose .
On the Node Pools page, find the desired node pool and choose More > Kubelet Update.
Select Runtime Update and click Precheck. After the node pool passes the precheck, follow the on-screen instructions to complete the runtime upgrade.
Solution 2: Create a node pool that uses containerd and migrate nodes to the node pool (optional)
This solution requires you to create a node pool that uses containerd and then scale out the node pool. Then, you need to progressively migrate nodes from the original node pool to the node pool that uses containerd and delete the original node pool. To do this, you can set the nodes in the original node pool to the Unschedulable state or change the scheduling method of the original node pool, such as label-based scheduling.
For more information about how to create a node pool, see Create and manage a node pool. For more information about how to set nodes to the Unschedulable state, see Node.
Considerations after the upgrade
After you upgrade from Docker to containerd, the Dockerfile syntax remains unchanged. Pay close attention to the configuration related to the runtime environment, such as the compatibility of the base image, the settings of environment variables, and the definitions of runtime commands. Make sure that container images can be successfully built and run in the containerd environment.
containerd does not support image building. After you change the runtime to containerd, you cannot run the Docker build command to build images but you can still pull images.
After you change the container runtime from Docker to containerd, Docker is no longer the administrator of the container lifecycle. You can no longer run Docker commands or call the Docker API to query container status or manage containers. However, you can run containerd commands as an alternative. For more information about the mappings between containerd commands and Docker commands, see Comparison among Docker, containerd, and Sandboxed-Container.
How system disks are replaced
ACK automatically performs the following steps to replace the system disks of nodes to upgrade from Docker to containerd.
Drains nodes and sets them to the Unschedulable state.
Stops the ECS instances.
Replaces the system disk of each node and changes the ID of the disk. The category of the system disk, the IP addresses of the ECS instance, and the MAC addresses of the ENIs that are bound to the ECS instance remain unchanged.
Re-initializes the nodes and installs containerd.
Restarts the nodes and sets them to the Schedulable state.
FAQ
How long does it require for upgrading the nodes in a batch?
If you choose to upgrade from Docker to containerd from the Node Pools page of the ACK console, ACK upgrades the nodes by replacing their system disks. The upgrade usually requires less than 8 minutes if snapshots are not involved. If you select the Create Snapshot before Update check box, ACK starts to upgrade the nodes after the snapshots are created. The timeout period for snapshot creation is 40 minutes. If snapshot creation times out, the node upgrade fails. If no business data is stored on the system disks, we recommend that you unselect the Create Snapshot before Update check box.
The number of nodes to be upgraded per batch increases batch by batch in the following sequence: 1, 2, 4, 8... After the maximum concurrency is reached, the maximum number of nodes to be upgraded in each of the following batches is equal to the maximum concurrency. For example, the maximum concurrency is 4. In this case, one node is upgraded in the first batch, two nodes are concurrently upgraded in the second batch, and four nodes are concurrently upgraded in the third batch and subsequent batches.
Does the upgrade adversely affect my businesses?
If you choose to upgrade from Docker to containerd from the Node Pools page of the ACK console, ACK upgrades the nodes by replacing their system disks. ACK automatically drains nodes when replacing the system disks of the nodes. If graceful shutdown is enabled for the pods of the application and the pods are spread across multiple nodes, the upgrade does not affect your application. For more information about graceful shutdown, see Graceful shutdown and zero downtime deployments in Kubernetes. To prevent ACK from upgrading all pods of the application in one batch, you can manually adjust the maximum concurrency to a value smaller than the total number of pods.
Can I roll back after upgrading from Docker to containerd?
No, you cannot roll back once you upgrade from Docker to containerd.
Will node data be lost when I upgrade from Docker to containerd?
If you choose to upgrade from Docker to containerd from the Node Pools page of the ACK console, ACK upgrades the nodes by replacing their system disks. Therefore, do not store important data in the system disks of the nodes or back up the system disks in advance. Data disks are not affected by the upgrade.
Are the IP addresses of nodes changed after their system disks are replaced?
After the system disk of a node is replaced, the disk ID is changed but the category of the system disk, the IP addresses of the ECS instance, and the MAC addresses of the ENIs that are bound to the ECS instance remain unchanged. For more information, see Replace the system disk (operating system) of an instance.
How is the compatibility of containerd with Docker?
In most cases, Kubernetes workloads do not rely on the container runtime and the Docker backend is still containerd. Therefore, after you upgrade to containerd, your workloads can continue to run as normal.
containerd does not support image building. After you change the runtime to containerd, you cannot run the Docker build command to build images but you can still pull images.
After you change the container runtime from Docker to containerd, Docker is no longer the administrator of the container lifecycle. You can no longer run Docker commands or call the Docker API to query container status or manage containers.
What do I do if the nodes rely on Docker to build images before they are upgraded to containerd?
You can use Container Registry to build images or manually build images after you upgrade to containerd.
Use Container Registry (recommended): Container Registry can build images by using the BuildKit tool provided by Docker. You can create a Container Registry instance, and trigger Container Registry to automatically build images based on Dockerfiles and push the images to a repository. For more information, see Use Container Registry Enterprise Edition instances to build images.
Manually build images: To ensure the optimal performance of nodes, we recommend that create an additional ECS instance, install Docker, and then run the Docker build command to build images. For more information, see Install Docker.
What do I do if the Docker directory still exists and occupies disk space after I change the container runtime of a node from Docker to containerd?
In addition to cluster-related containers, images, and logs, the file paths that you created are included in the Docker directory. If you no longer require the data in the Docker directory, you can manually delete the directory.
Elastic Compute Service (ECS)
Lingma
