时间戳

首页 > 解决方案 > 在 k8s 进程中，“kube-controller-manager”是来自 docker conainer 的“子进程”。为什么 k8s 有这样的架构？

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

问题描述

进程 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....

标签： dockerkubernetes

解决方案

这就是容器化一个符合OCI的核心容器运行时在 kubernetes 中的工作方式。

在此处输入图像描述

  1. Kubelet 通过 CRI 运行时服务 API 调用 cri-containerd 创建 pod；

  2. cri-containerd 使用 containerd 创建和启动一个特殊的暂停容器（沙盒容器），并将该容器放入 pod 的 cgroups 和命名空间（为简洁起见省略步骤）；

  3. cri-containerd 使用 CNI 配置 pod 的网络命名空间；

  4. Kubelet 随后通过 CRI 镜像服务 API 调用 cri-containerd 来拉取应用容器镜像；

  5. 如果节点上不存在镜像，cri-containerd 进一步使用 containerd 拉取镜像；

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

  7. cri-containerd 最后调用 containerd 来创建应用容器，将其放入 pod 的 cgroups 和命名空间中，然后启动 pod 的新应用容器。在这些步骤之后，一个 pod 及其对应的应用程序容器被创建并运行。

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

推荐阅读