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
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
