#Choosing a Container Runtime

#Overview

Container Runtime is a core component of Kubernetes, responsible for managing the lifecycle of images and containers.

When creating clusters through the platform, you can choose either Containerd or Docker as your runtime component.

Note: Kubernetes version 1.24 and above no longer officially supports Docker runtime. The officially recommended runtime is Containerd. If you still need to use Docker runtime, you must first enable cri-docker in the feature gate before you can select Docker as the runtime component when creating a cluster. For details on using feature gates, see Feature Gate Configuration.

#Quick Selection Guide

Choose Containerd	Choose Docker
Shorter call chain Fewer components More stable Consumes fewer node resources	Supports docker-in-docker Allows use of docker build/push/save/load commands on nodes Can call Docker API Supports docker compose or docker swarm

#Differences Between Docker and Containerd

#Common Commands

Containerd	Docker	Description
crictl ps	docker ps	View running containers
crictl inspect	docker inspect	View container details
crictl logs	docker logs	View container logs
crictl exec	docker exec	Execute commands in container
crictl attach	docker attach	Attach to container
crictl stats	docker stats	Display container resource usage
crictl create	docker create	Create container
crictl start	docker start	Start container
crictl stop	docker stop	Stop container
crictl rm	docker rm	Remove container
crictl images	docker images	View image list
crictl pull	docker pull	Pull image
None	docker push	Push image
crictl rmi	docker rmi	Delete image
crictl pods	None	View pod list
crictl inspectp	None	View pod details
crictl runp	None	Start pod
crictl stopp	docker images	View images
ctr images ls	None	Stop pod
crictl stopp	docker load/save	Import/export images
ctr images import/export	None	Stop pod
ctr images pull/push	docker pull/push	Pull/push images
ctr images tag	docker tag	Tag images

#Call Chain Differences

• Docker as Kubernetes container runtime has the following call relationship:

  kubelet > cri-dockerd > dockerd > containerd > runC

• Containerd as Kubernetes container runtime has the following call relationship:

  kubelet > cri plugin (in containerd process) > containerd > runC

Summary: Although dockerd adds features like swarm cluster, docker build, and Docker API, it can introduce bugs and adds an extra layer in the call chain. Containerd has a shorter call chain, fewer components, greater stability, and consumes fewer node resources.

#Log and Parameter Comparison

Comparison	Docker	Containerd
Storage Path	When Docker serves as the Kubernetes container runtime, container logs are stored by Docker in directories like /var/lib/docker/containers/$CONTAINERID. Kubelet creates symbolic links in /var/log/pods and /var/log/containers pointing to the container log files in this directory.	When Containerd serves as the Kubernetes container runtime, container logs are stored by Kubelet in the /var/log/pods/$CONTAINER_NAME directory, with symbolic links created in the /var/log/containers directory pointing to the log files.
Configuration Parameters	Specified in the Docker configuration file: "log-driver": "json-file", "log-opts": {"max-size": "100m","max-file": "5"}	Method 1: Specified in kubelet parameters: --container-log-max-files=5 --container-log-max-size="100Mi" Method 2: Specified in KubeletConfiguration: "containerLogMaxSize": "100Mi", "containerLogMaxFiles": 5,
Saving Container Logs to Data Disk	Mount the data disk to "data-root" (default is /var/lib/docker).	Create a symbolic link /var/log/pods pointing to a directory under the data disk mount point.

#CNI Network Comparison

Comparison	Docker	Containerd
Who Calls CNI	cri-dockerd	cri-plugin built into Containerd (after containerd 1.1)
How to Configure CNI	cri-dockerd parameters --cni-conf-dir --cni-bin-dir --cni-cache-dir	Containerd configuration file (toml): [plugins.cri.cni] bin_dir = "/opt/cni/bin" conf_dir = "/etc/cni/net.d"