在k8s进程中，"kube-controller-manager“是docker conainer的”子进程“。为什么k8s会有这样的架构？

Question

运行进程ID 21186。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

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

​

​

容器Kubelet通过CRI运行时服务API调用CRI -

1. 来创建容器，使用image;
2. cri-containerd创建并启动一个特殊的暂停容器(沙箱容器)，并将该容器放入实例的cgroup和命名空间中(对于省略的步骤使用CNI配置实例的网络命名空间；
   1. Kubelet随后通过CRI镜像服务API调用CRI-
   2. 来拉取应用容器，如果节点上不存在镜像，则进一步使用container CRI来拉取镜像；

   容器Kubelet然后通过CRI运行时服务API调用CRI-

   1. 来创建和启动pod内的应用程序容器，使用拉出的容器image;
   2. cri-containerd最后调用container来创建应用程序容器，将其放入pod的cgroup和命名空间中，然后启动pod的新应用程序容器。完成这些步骤后，pod及其对应的应用程序容器将创建并运行。

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

Answer 2

虽然不是必需的，但是Kubernetes控制平面服务的一个非常常见的部署策略是“静态pod”。它们被放在Kubelet启动时查看的一个特殊文件夹中，它从无到有地创建pods (这是必需的，因为我们显然不能使用API来启动API服务器)。这很好，因为这意味着控制平面服务在Kubernetes中是可见的，您可以像对待普通pod一样对待它们(使用kubectl日志、端口转发等)。