Container Service for Kubernetes:Migrate the container runtime from Docker to containerd

The container runtime containerd is an industry-standard runtime supported by Kubernetes. It overweighs Docker in terms of cost-effectiveness and security. For more information about containerd, see containerd.

Introduction about migrating from Docker to containerd

Upgrade plan

The migration of the container runtime from Docker to containerd uses the following two node pool update plans:

• Plan 1: Update by creating a new node pool and migrating workloads to the new node pool. Create a new node pool and select containerd as the container runtime when you create the node pool. Then, redeploy workloads, schedule the application pod to the new node pool, and delete the legacy node pool to migrate the workloads to the new node pool.

• Plan 2: Update by replacing the system disk. This plan requires replacing the system disk of the nodes. Do not store important data in the system disk, or back up the data in the system disk before the update. The data disks are not affected by the update.

  The following sections describe the scheme and configuration methods for this update plan.

How a node pool is updated by replacing the system disk

1. Precheck: The background program automatically checks whether the cluster and the versions of the dependent components meet the runtime requirements of containerd. Otherwise, handle failed checks before the update.

2. Update the node pool: You can specify the maximum number of nodes that can be concurrently updated in a batch. The maximum concurrency does not exceed 10% of the total number of nodes. The number of nodes to be updated 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 updated in each of the following batches is equal to the maximum concurrency. If you set the maximum concurrency to 4, one node is updated in the first batch, two nodes are concurrently updated in the second batch, and four nodes are concurrently updated in the third batch and subsequent batches.

How a node is updated by replacing the system disk

1. The node is drained. When the node is drained, it is set to unschedulable.

2. The Elastic Compute Service (ECS) instance is stopped.

3. The system disk is replaced and the disk ID is changed. The category of the system disk, the IP addresses of the ECS instance, and the MAC addresses of the elastic network interfaces (ENIs) that are bound to the ECS instance remain unchanged.

4. Re-initialize the node.

5. The node is restarted and ready. When the node is ready, it is set to schedulable.

Precautions

After you migrate 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.

Procedure

We recommend that you change and update the runtime in the console during off-peak hours. The following section introduces how to update the runtime in a node. For more information about how to update a node pool, see Update a node pool.

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

2. On the Clusters page, find the cluster that you want to manage and click its name. In the left-side navigation pane, choose Nodes > Node Pools.

3. On the Node Pools page, select the node pool that you want to manage and choose More > Kubelet Update.

4. Select Container Runtime Update and click Precheck. After the cluster passes the precheck, update the runtime as prompted.

How long does it require for updating the nodes in a batch?

Migrate from Docker to containerd through the node pool update page is performed by replacing the system disk. If snapshots are not created, the migration is complete within 8 minutes. If you select Create Snapshot before Update, ACK starts to update the nodes after the snapshots are created. The timeout period for snapshot creation is 40 minutes. If snapshot creation times out, the node update fails. If no business data is stored in the system disks, we recommend that you clear Create Snapshot before Update.

Are applications affected during the update?

Migrate Docker to containerd through the node pool update page is performed by replacing the system disk. Nodes are drained during the update. If an application runs in multiple pods that are spread across multiple nodes and graceful shutdown is enabled for the pods, the application is not affected. For more information about graceful shutdown, see Graceful shutdown and zero downtime deployments in Kubernetes. To ensure that all the nodes that run the pods of an application are not updated in the same batch, we recommend that you set the maximum concurrency to a value less than the number of pods in which the application runs.

Can I roll back after I migrate Docker to containerd?

You cannot roll back the container runtime after you update it.

Does data loss occur when I migrate from Docker to containerd?

Migrate from Docker to containerd through the node pool update page is performed by replacing the system disk. Back up the data in the system disk of the node before the update and do not store important data in the system disk. Data disks are not affected by the update.

Does the IP address of a node change after the system disk of the node is replaced?

After the system disk 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.

How compatible is containerd with Docker?

In most cases, your workloads are not dependent on the container runtime. Docker implements containerd. Theoretically, your workloads are not affected after you change the container runtime from Docker to containerd.

containerd does not support image building. After you change the runtime to containerd, you cannot run the docker build command to build images. You can pull images as normal.

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.

If I previously built images on cluster nodes based on Docker, what should I do after I update the container runtime to containerd?

You can build images based on the Container Registry or manually build images.

• Use Container Registry to build (recommended): Container Registry is based on the official image building tool BuildKit of Docker. After you create a Container Registry instance, it automates the build and delivery of images from source code repositories to Container Registry repositories based on Dockerfiles. When the source code is updated, Container Registry automatically builds an image by using a Dockerfile and uploads the image to a Container Registry repository. For more information, see Use a Container Registry Enterprise Edition instance to build an image.

• Manually build: We recommended that you create an extra ECS instance to ensure the node performance. After you manually install Docker, use Docker commands 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 also included in the Docker directory. If you no longer need the data in the Docker directory, you can manually delete the directory.