docker - 在k8s进程中， “kube-controller-manager”是来自docker容器的 “child process”。为什么k8s具有这种架构？

Question

进程ID 21186为runc。 21257是kube-controller-manager。

我不明白为什么宿主的进程是子进程。

而且，我不知道Docker容器可以运行主机的进程。

为什么k8s采用这种架构。

其他过程是相同的形式。

你能帮忙吗？谢谢

[root@instance-3 ~]# ps -ef | grep 21186
root     21186 10930  0 06:20 ?        00:00:00 containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/moby/3fd66799d02cb2c2f195fd85fadf852b7a7c0905707e6c25d1fdec93c1dc850b -address /run/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc
root     21257 21186  1 06:20 ?        00:00:08 kube-controller-manager --aut....

Answer 1

这是containerd和OCI兼容的核心容器运行时在kubernetes中的工作方式。

Kubelet通过CRI运行时服务API调用cri-containerd创建一个pod。

cri-containerd使用容器创建并启动一个特殊的暂停容器(沙盒容器)，并将该容器放入pod的cgroup和 namespace 中(为简便起见，省略了步骤)；

cri-containerd使用CNI配置广告连播的网络 namespace ；

Kubelet随后通过CRI图像服务API调用cri-containerd，以提取应用程序容器图像；

如果该节点上不存在该图像，

cri-containerd进一步使用容器来拉该图像。

Kubelet然后通过CRI运行时服务API调用cri-containerd，以使用拉出的容器镜像在pod内部创建和启动应用程序容器；

cri-containerd最终调用containered创建应用程序容器，将其放入pod的cgroup和 namespace 中，然后启动pod的新应用程序容器。这些步骤之后，将创建一个Pod及其相应的应用程序容器并运行。

https://kubernetes.io/blog/2017/11/containerd-container-runtime-options-kubernetes/