溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
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進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
