Docker 在剛剛釋出的 Docker Desktop 4.12.0 中，加入了實驗特性：進一步內建 containerd，使用 containerd 來管理和存儲鏡像。
為什麼說是“進一步內建”？這就要翻翻 Docker 和 containerd 的曆史了。
containerd 的誕生
containerd 最早出現在 Docker Engine 中，後來為了将 Docker Engine 做得更加輕量、快速和健壯，在 2016 年 Docker 将 containerd 從 daemon（
dockerd
） 中獨立出來，并完成了與 daemon 的內建。獨立出來的 containerd 全面支援 OCI（Open Container Initiative）資源的啟動和生命周期的管理，也是以 containerd 可以支援 runc（前身是 Docker 中的 libcontainer，後來捐贈給 LF）以外的其他 OCI 實作。2017 年 Docker 将 containerd 捐獻給 CNCF；2019 年 2 月，containerd 畢業。
containerd 獨立出來之後，發送到 Docker Engine 的請求：
- Docker daemon 完成鏡像管理的操作（拉取、更新鏡像）
- daemon 會為建立容器進行準備工作（建立 OCI bundles）：鏡像的資訊和運作時的資訊。
- daemon 調用 containerd 的 API。
- 收到請求的 containerd 不會直接去操作容器（不直接作為容器的父程序，防止 containerd 挂掉影響容器），而是先建立一個 container-shim 程序。
- container-shim 調用 runc cli 來運作容器，并啟動 Unix domain socket 暴露 API 提供給 containerd進行容器的管理。
随着 containerd 的不斷演進，除了容器建立和容器聲明周期管理以外，從 1.1 開始 containerd 加入了 CRI（Container Runtime Interface）的支援。
CRI
在《源碼解析 kubectl port-forward 工作原理》 中層提到 kubelet 會調用 rumtime service 的 gRPC 接口，除了用于 portforward 流的 stream server以外，其實還有實作 CRI 接口
RuntimeService
和
ImageService
的
RuntimeServiceServer
和
ImageServiceServer
。
RuntimeServiceServer
用于接收并處理容器及其生命周期相關的操作，而
ImageServiceServer
則是用來處理鏡像相關的操作。containerd 提供了鏡像拉取、删除、檢查、存儲等功能。
既然 containerd 可以進行鏡像的管理，而且 Docker 已經在使用，Docker 也沒有必要自己繼續維護一套相同的功能。
切換到 containerd 的鏡像管理
在 Docker Desktop 的設定中啟動 containerd 管理鏡像後，運作
docker info
會發現存儲的驅動從原來的
overlay2
變成了 containerd 的
stargz
。
切換前：
切換後：
既然使用了 containerd 的 snapshotters 來管理存儲（挂在容器的根檔案系統），就可以支援多種 snapshotters，比如 stargz 的延遲拉取。
此外，得益于 containerd 原生支援多平台鏡像的存儲，還是因為 snapshotters 的原因，可以使用 docker 來建構多平台的鏡像了。
#切換前
docker buildx build -t demo --no-cache --platform linux/amd64,linux/arm64 .
[+] Building 0.0s (0/0)
error: multiple platforms feature is currently not supported for docker driver. Please switch to a different driver (eg. "docker buildx create --use")
切換後：
圖檔來自 docker 官方部落格
總結
參考
- Extending Docker’s Integration with containerd
- Docker containerd integration
- Learning Containers From The Bottom Up