kubelet发起创建命令到真正创建容器并启动容器的过程
流程内容分析
kubelet通过gRPC调用dockershim发起创建容器,CRI即容器运行时接口(container runtime interface),目前dockershim的代码内嵌在kubele中,所以接受创建容器的就是kubelet进程。
dockershim把创建容器的命令转换成docker daemon可以识别的命令,之后发送给docker daemon创建容器。
docker daemon在1.12版本之后就会把创建容器的命令分发给另一个进程: comtainerd。
containerd收到创建容器的命令后,创建另一个进程:containerd-shim进程,由该进程执行具体的创建命令,containerd进程做为父进程存在。
创建容器的时候需要namespace隔离容器启动和创建需要的资源,cgroup限制容器可以使用资源的大小等操作,这些事情该怎么做已经有看公开的规范OCI(open container initivtive 开放容器标准),它的一个参考实现叫做runc。于是containerd--shim在这一步需要调用runc命令,来启动容器。
runc启动容器之后就直接退出,containerd-shim则会成为容器进程的父进程,收集容器进程的状态,上报给contanierd,并在容器种pid为1的进程退出后接管容器中国的子进程进行清理,确保不会出现僵尸进程。
这其中有两个名词概念容易混淆
CRI:容器运行时接口 container runtime interface
其主要的作用:
1、针对容器操作的接口,包括容器的创建、启动和停止等
2、针对镜像的操作,拉去、删除镜像等
3、针对podsandbox(容器沙箱环境)
OCI:开放容器标准 open container initiative
主要作用,制作容器
容器镜像制作内容,即imagespec
容器需要接收哪些指令,即runtimespec