containerd-shim的父进程是什么进程？

Question

我用 minikube 设置了 2 个 k8s 环境。一种带有--container-runtime=docker 标志，另一种带有--container-runtime=containerd 标志。以下是我看到的差异。

当我设置 container-runtime=docker 时，会发生这些事情

1. 有一个dockerd 服务正在运行
2. dockerd 服务生成 containerd 作为它自己的孩子
3. 有运行实际容器的/usr/bin/containerd-shim-runc-v2 进程，并且每个containerd-shim-runc-v2 的父进程是系统上的PID 1。

当我设置container-runtime=containerd时，会发生这些事情

1. 没有dockerd 服务，没有歧义。
2. 有一个containerd 进程，由 PID 1拥有。同样，这并不奇怪。
3. 有运行实际容器的containerd-shim 进程，每个containerd-shim 进程的父进程是containerd

这是我的问题

1. containerd-shim 和 containerd-shim-runc-v2 之间有什么区别？他们似乎采取了类似的标志等。
2. 为什么在场景 1 中 shims 是 PID 1 的子代 而场景 2 shims 是 containerd 的子代？

编辑：只是想到了一个编辑。在 ubuntu 20 机器上，如果我安装 docker，dockerd 是一个独立进程，其父进程为 PID 1，containerd 是一个独立进程，其父进程为 PID 1，所有容器都是 PID 为 1 的 container-shim-runc-v2 的子进程？！？！为什么 containerd 不是 dockerd 的孩子？这是在哪里配置的？

Answer 1

我已经深入研究了这个话题，得出了以下结论和来源。

1. containerd-shim 和 containerd-shim-runc-v2 有什么区别？他们似乎采取了类似的标志等。

这些只是不同的版本，containerd-shim-runc-v2 是containerd-shim 的最新版本。见源代码here。

看起来码头工人仍然使用containerd-shim 而不是containerd-shim-runc-v2。基本功能仍然是 shim 的相同功能，即 shim 监视 runc 容器以在 runc 完成运行时间时告诉 containerd。

如果您担心 API 的差异，请参考源代码。但在功能上，它们只是 shim API 的不同版本。

---

2。为什么在场景 1 中垫片是 PID 1 的子代，而在场景 2 中垫片是容器的子代？

最终，它们都是 PID 1 的子代，其中垫片是 containerd 的子代，而 containerd 是 PID 1 的子代。

This blog post 很好地概述了 k8s 和工作节点上的运行时。特别是关于 Docker、containerd 和 shims 的部分将更深入地了解您的问题。

垫片位于容器管理器和运行时之间 促进沟通并防止可能出现的集成问题 出现。它允许无守护进程的容器。它基本上作为 容器进程的父进程以促进通信，以及 消除了容器长时间运行的运行时进程。这 垫片与容器的工艺结合紧密；然而， 它们与容器管理器的进程完全分离。

Here 是关于容器、垫片以及它们如何与 linux 交互的更全面的资源。

this resource 深入研究了 runc、containerd 及其在 linux 中的 PID。