我用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服务，没有歧义 - 存在由PID 1拥有的的
containerd进程。再说一遍，这并不奇怪 - 存在运行实际容器的
containerd-shim进程，这些containerd-shim进程中的每个进程的父进程都是containerd
下面是我的问题
containerd-shim和containerd-shim-runc-v2之间有什么区别？他们似乎大多持有相似的旗帜等- 为什么在场景1中，垫片是PID 1的子级，而在场景2中，垫片是容器的子级
EDIT：刚刚想到了一个编辑。在一个ubuntu 20盒子上，如果我安装docker，dockerd是一个单独的进程，其父进程是PID 1，containerd是一个子进程，其其父进程为PID 1，所有容器都是container-shim-runc-v2的子进程，其PID为1？！？！为什么containerd不是dockerd的孩子？这是在哪里配置的？
我深入研究了这个主题，得出了以下结论和来源。
1.容器垫片和容器shim-runc-v2之间有什么区别？他们似乎采取了大部分类似的标志等。
这些只是不同的版本，containerd-shim-runc-v2是containerd-shim的最新版本。请参阅此处的源代码。
看起来docker仍然使用containerd-shim而不是containerd-shim-runc-v2。基本功能仍然是填充程序的相同功能，即填充程序监视runc容器，以在runc完成运行时告诉containerd。
如果您担心API中的差异，请参考源代码。但在功能上，它们只是垫片API的不同版本。
2.为什么在场景1中垫片是PID 1的子级，而场景2垫片是容器的子级
最终，它们都是PID 1的子级，其中垫片是作为PID 1子级的container的子级。
这篇博客文章很好地概述了k8s和worker节点上的运行时。特别是，Docker、containerd和垫片部分将为您的问题提供更多视角。
填充程序位于容器管理器和运行时之间，用于促进沟通，防止可能出现的集成问题发生它允许使用无后台进程的容器。它基本上是作为容器进程的父进程，以便于通信，以及消除了容器的长时间运行的运行时进程。这个垫片与容器的工艺结合紧密；然而它们与容器管理器的过程完全分离。
这里有一个关于containerd、shims以及它们如何与linux交互的更全面的资源。
本资源深入探讨了linux中的runc、containerd及其PID。