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