1) k8s 將在 1.23 版本徹底棄用 docker ,改用 containerd ,但 Docker 作為容器鏡像構建工具的作用將不
受影響,用其構建的容器鏡像將一如既往地在集群中與所有容器運行時正常運轉。 Docker 生成的鏡像實
際上並不特定於 Docker ,更准確地說它應該屬於 OCI(Open Container Initiative- 開放容器倡議 ) 鏡像。
2) docker 當年的實現被拆分出了幾個標准化的模塊,標准化的目的是模塊是可被其他實現替換的,不
由任何一個廠商控制。 docker 由 docker-client ,dockerd,containerd,docker-shim,runc 組成,所
以 containerd 是 docker 的基礎組件之一, containerd 被捐贈給 CNCF 社區后,社區給其添加了鏡像管
理模塊和 CRI 模塊,這樣 containerd 不只可以管理容器的生命周期,還可以直接作為 K8s 的運行時使用。
3) 在 kubernetes 平台中,為了解決與容器運行時 ( 例如 docker) ,集成的問題,在早期社區推出 CRI(
container Runtime interface, 容器運行時接口 ) ,以支持更多的容器運行時,比如紅帽的 CRI-O 、 Podman
。當我們使用 docker 作為容器運行時之后,架構圖如下所示, kubernetes 計划棄用的是 kubelet
中 dockershim ,即 kubernetes kubelet 實現中的組件之一,它能夠與 docker engine 進行通信。
![clip_image002[4] clip_image002[4]](/image/aHR0cHM6Ly9pbWcyMDIwLmNuYmxvZ3MuY29tL2Jsb2cvMTYxNjYwMC8yMDIxMDgvMTYxNjYwMC0yMDIxMDgyNzE1MzYxOTE2Ny05MDQ5NzIxMjguanBn.png)
4) kubelet 調用鏈
# Docker 作為 k8s 容器運行時,調用關系如下
kubelet --> dockershim ( 在 kubelet 進程中 ) --> dockerd --> containerd
# Containerd 作為 k8s 容器運行時,調用關系如下
kubelet --> cri plugin( 在 containerd 進程中 ) --> containerd
5) 從 k8s 的角度看,可以選擇 containerd 或 docker 作為運行時組件, Containerd 調用鏈更短,組件更少,更穩定,占用節點資源更少。
docker 內部調用鏈比較復雜,多層封裝和調用,導致性能降低,提升故障率,不易排查, docker 還會在宿主機上創建網絡規則,存儲卷,也帶來了安全隱患。
K8s 提供了更強的卷掛載能力和集群級別的網絡能力,在集群中 kubelet 只會使用到 docker 提供的鏡像下載和容器管理功能,而編排、網絡、存儲等功能都不會用到。
containerd 與 docker 相兼容,相比 docker 輕量很多,目前較為成熟。