switching from docker to containerd
refer

The containerd CRI plugin is enabled by default and you can use containerd for Kubernetes while still allowing Docker to function.

If you run kubelet in a Docker container, make sure it has access to the following directories on the host file system:

/run/docker/libcontainerd/
/var/lib/containerd/
And that it has access to the following binaries on the host file system and that they are included in PATH:

/run/torcx/unpack/docker/bin/containerd-shim-runc-v1
/run/torcx/unpack/docker/bin/containerd-shim-runc-v2
Finally, tell kubelet to use containerd by adding to it the following flags:

--container-runtime=remote
--container-runtime-endpoint=unix:///run/docker/libcontainerd/docker-containerd.sock

cri
Container runtime interface, which is used by kubelet to communicate with container and sandbox(image)
kubelet is CRI client,
Runtime need to implement CRI server(RuntimeService and ImageService).

 kubelet --container-runtime=remote --container-runtime-endpoint=unix:///var/run/crio/crio.sock ..

architecture of cri plugin

runtime hierarchy
High level —————————————> Low level
Docker engine –> Containerd –> runC –> Container(namespaces,cgroups)

Runtimes

  • CRI-O
  • Docker
  • cri-containerd

Container Runtime Shim
A container runtime shim is a piece of software that resides in between a container manager (containerd, cri-o, podman) and a container runtime (runc, crun) solving the integration problem of these counterparts.
it’s purpose

  • It allows a runtime (runC) to exit after the container is started. Without this we would still be subject to long runtime processes
  • If Docker or containerd fails, it keeps STDIO open for the container. Without it the container would exit.

img(°0°)

The main process of the shim is short-lived and serves the purpose of the daemonization of the shim. It forks the actual shim daemon process, writes its PID on disk and exits immediately, leaving the shim detached from the launching process (i.e. a container manager). The long-lived shim daemon process starts from creating a new session and detaching its stdio streams from the parent (by redirecting them to /dev/null). This is somewhat common steps for any daemon-alike software. Then it forks one more process, the predecessor of the container process. This process execs runc create with the provided parameters (bundle dir, config.json, etc). The shim daemon process waits for the termination of the container predecessor and then reports the status of this operation back to the container manager. At this point, we have only a single shim daemon process and a detached container process. However, shim process is a subreaper of the container process. At last, the shim daemon process can start serving the container’s stdio streams as well as awaiting the container termination. Once the container termination status is known, the shim process writes it to a predefined location on disk and exits.

Container Runtime Interface(CRI) CLI
install crictl