Reference articles：
K8s will eventually abandon docker, and TKE already supports containerd
Using docker as image building service in containerd cluster
1. Background
When comparing Kubernetes clusters using different docker versions (1.18, 1.19) as container runs, we found some differences in the underlying implementation. I will make a record here.
2. Issue analysis
docker 1.18
Container process tree:
containerd is not a system service, but a process started by dockerd
The path of the kubelet control container:
kubelet —— docker-shim.sock —— dockerd —— containerd —(ttrpc communication) — containerd-shim —— container process No. 1
The impact of each process exiting:
- The exit of dockerd and containerd processes will cause containerd-shim to be directly taken over by systemd process No. 1, without affecting the container process.
-
containerd-shim process exit will cause its container process to be recycled
-
The exit of the container process will cause its parent process containerd-shim to also be recycled
-
The docker restart container will cause containerd to re-create the containerd-shim process and container process No. 1
docker 1.19
containerd is a separate system service
The path of the kubelet control container is the same as version 1.18:
kubelet —— docker-shim.sock —— dockerd —— containerd —(ttrpc communication) — containerd-shim —— container process No. 1
-
Dockerd restart will not affect pstree or container process
-
The exit of the containerd process will cause containerd-shim to be directly taken over by systemd process No. 1, without affecting the container process.
-
containerd-shim process exit will cause its container process to be recycled
-
The exit of the container process will cause its parent process containerd-shim to also be recycled
-
The docker restart container will cause containerd to re-create the containerd-shim process and container process No. 1
3、Additional information
This article mainly explains the relationship between dockerd, docker-shim, containerd, and containerd-shim.
In addition, there are runc and cotainerd-ctr not mentioned.
runc
containerd uses containerd-shim to call runc to start the container. After runc starts the container, it will exit directly, and containerd-shim will become the parent process of the container process. , is responsible for collecting the status of the container process, reporting it to containerd, and taking over the child processes in the container to clean up after the process with pid 1 in the container exits to ensure that no zombie processes will appear.
It can be understood that runc is the CLI tool of containerd-shim.
containerd-ctr
Like the Docker CLI tool, containerd also provides a corresponding CLI tool: ctr. However, the function of ctr is not yet complete as docker, and only has basic functions related to images and containers.
- For Mirrors:
# Pull the image (docker pull)
ctr image pull docker.io/library/nginx:alpine
# View images (docker images)
ctr image ls
# Delete image (docker rmi)
ctr image rm docker.io/library/nginx:alpine
- For Containers:
#Create container
# After creation, the container is not running, it is just a static container. A container object only contains the resources and related configuration data required to run a container, which means that the namespaces, rootfs, and container configurations have been initialized successfully, but the user process has not yet been started.
ctr container create docker.io/library/nginx:alpine nginx
# View container
ctr container ls
# View container information (docker inspect)
ctr container info nginx
# Delete container (docker rm)
ctr container rm nginx
- For tasks：
# Start actually running the container (docker run -d)
ctr task start -d nginx
# View container process (docker ps)
ctr -n moby task ls
# Enter the container (docker exec)
ctr task exec --exec-id 0 -t nginx sh
- For Namespaces:
# View namespace
ctr namespace ls
#Create namespace
ctr namespace create test
# View the containers started by docker (default is under the moby namespace)
ctr -n moby container ls