问题描述
我使用 minikube 设置了 2 个 k8s 环境。一种带有 --container-runtime=docker 标志，一种带有 --container-runtime=containerd 标志。以下是我看到的差异。
当我设置 container-runtime=docker 时，这些事情就会发生
- 有一个
dockerd服务正在运行 -
dockerd服务将containerd作为自己的子项生成 - 有
/usr/bin/containerd-shim-runc-v2个进程运行实际的容器，每个进程的 父进程containerd-shim-runc-v2是系统上的 PID 1。
当我设置 container-runtime=containerd 时，这些事情就会发生
- 没有
dockerd服务，没有歧义。 - 有一个
containerd进程，它由 PID 1 拥有。同样，这里没有任何意外。 - 有
containerd-shim个进程运行实际容器，每个containerd-shim进程的父进程是containerd
这是我的问题
-
containerd-shim和containerd-shim-runc-v2之间有什么区别？他们似乎大多采用相似的标志等。 - 为什么在场景 1 中，shims 是 PID 1 的子代，而在场景 2 中，shims 是 containerd 的子代？
编辑：刚刚想到了一个编辑。在 ubuntu 20 机器上，如果我安装 docker，dockerd 是一个单独的进程，其父进程的 PID 为 1，containerd 是一个单独的进程，其父进程的 PID 为 1，所有容器都是 PID 为 1 的 container-shim-runc-v2 的子进程？！？！为什么 containerd 不是 dockerd 的孩子？这是在哪里配置的？
解决方法
我深入研究了这个话题，得出了以下结论和来源。
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 中，垫片是 containerd 的子代？
最终，它们都是 PID 1 的子代，其中垫片是 containerd 的子代，而 containerd 是 PID 1 的子代。
This blog post 很好地概述了 k8s 和工作节点上的运行时。特别是关于 Docker、containerd 和 shims 的部分将更深入地了解您的问题。
垫片位于容器管理器和运行时之间 促进沟通并防止可能出现的集成问题 出现。它允许无守护进程的容器。它基本上是作为 容器进程的父进程以促进通信，以及 消除了容器的长时间运行的运行时进程。这 垫片与容器的工艺结合紧密；然而， 它们与容器管理器的进程完全分离。
Here 是关于 containerd、shims 以及它们如何与 linux 交互的更全面的资源。
和 this resource 深入了解 Linux 中的 runc、containerd 及其 PID。