kubelet创建容器的流程分析

kubelet发起创建命令到真正创建容器并启动容器的过程

流程内容分析

1. kubelet通过gRPC调用dockershim发起创建容器，CRI即容器运行时接口(container runtime interface)，目前dockershim的代码内嵌在kubele中，所以接受创建容器的就是kubelet进程。

2. dockershim把创建容器的命令转换成docker daemon可以识别的命令，之后发送给docker daemon创建容器。

3. docker daemon在1.12版本之后就会把创建容器的命令分发给另一个进程: comtainerd。

4. containerd收到创建容器的命令后，创建另一个进程：containerd-shim进程，由该进程执行具体的创建命令，containerd进程做为父进程存在。

5. 创建容器的时候需要namespace隔离容器启动和创建需要的资源，cgroup限制容器可以使用资源的大小等操作，这些事情该怎么做已经有看公开的规范OCI(open container initivtive 开放容器标准），它的一个参考实现叫做runc。于是containerd--shim在这一步需要调用runc命令，来启动容器。

6. runc启动容器之后就直接退出，containerd-shim则会成为容器进程的父进程，收集容器进程的状态，上报给contanierd，并在容器种pid为1的进程退出后接管容器中国的子进程进行清理，确保不会出现僵尸进程。

   
   

   
   

这其中有两个名词概念容易混淆

CRI:容器运行时接口 container runtime interface

其主要的作用：

1、针对容器操作的接口，包括容器的创建、启动和停止等

2、针对镜像的操作，拉去、删除镜像等

3、针对podsandbox（容器沙箱环境）

OCI:开放容器标准 open container initiative

主要作用，制作容器

1. 容器镜像制作内容，即imagespec

2. 容器需要接收哪些指令，即runtimespec