Search code examples
minikubecontainerdruncdocker-daemon

What process is the parent process of containerd-shim?

I setup 2 k8s environments with minikube. One with the --container-runtime=docker flag and one with --container-runtime=containerd flag. Here are the differences I see.

When I set container-runtime=docker , these things happen

  1. there is a dockerd service that is running
  2. The dockerd service spawns containerd as its own child
  3. There are /usr/bin/containerd-shim-runc-v2 processes that run the actual containers, and the parent of each of these containerd-shim-runc-v2 is PID 1 on the system.

When I set container-runtime=containerd, these things happen

  1. there is no dockerd service, no ambiguities there.
  2. there is a containerd process, which is owned by PID 1. Again, no surprises there.
  3. There are containerd-shim processes that run actual containers, and the parent of each of these containerd-shim processes is containerd

So here are my questions

  1. What are the differences between containerd-shim and containerd-shim-runc-v2 ? They seem to take mostly similar flags etc.
  2. Why in scenario 1 the shims are children of PID 1 whereas scenario 2 the shims are children of containerd ?

EDIT: Just thought of an edit. On a ubuntu 20 box, if I install docker, dockerd is a separate process whose parent is PID 1, containerd is a separate process whose parent is PID 1, and all containers are children of container-shim-runc-v2 whose PID is 1 ?!?! Why is containerd not a child of dockerd ? Where is this configured?

Solution

  • I have dug into this topic and came to the following conclusions and sources.

    1. What are the differences between containerd-shim and containerd-shim-runc-v2? They seem to take mostly similar flags etc.

    These are just different versions, containerd-shim-runc-v2 being the newest version of the containerd-shim. See the source code here.

    It looks like that docker still uses containerd-shim instead of containerd-shim-runc-v2. The base functionality will still be the same function of the shim, being that the shim monitors runc containers to tell containerd when runc has finished a run time.

    If you are concerned about differences in the API, please reference the source code. But in functionality they are just different versions of the shim API.

    2. Why in scenario 1 the shims are children of PID 1 whereas scenario 2 the shims are children of containerd?

    Ultimately, they are both children of PID 1 where the shims are children of containerd which is a child of PID 1.

    This blog post gives a good overview of runtimes on k8s and worker nodes. Particularly, the sections on Docker, containerd and shims will give more perspective on your questions.

    The shim sits between the container manager and a runtime to facilitate communication and prevent integration problems that may arise. It allows for daemon-less containers. It basically sits as the parent of the container’s processes to facilitate communications, and eliminates the long-running runtime processes for containers. The processes of the shim and the container are bound tightly; however, they are totally separated from the process of the container manager.

    Here is a more thorough resource into containerd, shims, and how they interact with linux.

    And this resource dives into runc, containerd and their PIDs in linux.