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 中，垫片是 PID 1 的子级，而场景 2 中的垫片是 containerd 的子级？

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

Answer 1

我深入研究了这个主题并得出以下结论和来源。

\n

1.containerd-shim和containerd-shim-runc-v2有什么区别？他们似乎大多采用相似的旗帜等。

\n

这些只是不同的版本，containerd-shim-runc-v2是containerd-shim. 请参阅此处的源代码。

\n

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

\n

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

\n\n

2. 为什么在场景 1 中，垫片是 PID 1 的子级，而场景 2 中的垫片是 Containerd 的子级？

\n

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

\n

这篇博文很好地概述了 k8s 和工作节点上的运行时。特别是，有关 Docker、containerd 和 shims 的部分将为您的问题提供更多视角。

\n

\n

填充程序位于容器管理器和运行时之间，以促进通信并防止可能出现的集成问题。它允许无守护程序容器。它基本上作为容器\xe2\x80\x99s 进程的父进程来促进通信，并\n消除了容器的长时间运行的运行时进程。\nshim 和容器的进程绑定紧密；然而，它们与容器管理器的进程完全分离。

\n

\n

这里是关于 Containerd、Shims 以及它们如何与 Linux 交互的更全面的资源。

\n

本资源深入探讨了 Linux 中的 runc、containerd 及其 PID。

\n