我們可以把 docker 抽象為下圖所示的結構(此圖來自互聯網)：

從圖中可以看出，docker 對容器的管理和操作基本都是通過 containerd 完成的。 那么，containerd 是什么呢？
Containerd 是一個工業級標準的容器運行時，它強調簡單性、健壯性和可移植性。Containerd 可以在宿主機中管理完整的容器生命周期：容器鏡像的傳輸和存儲、容器的執行和管理、存儲和網絡等。詳細點說，Containerd 負責干下面這些事情：

• 管理容器的生命周期(從創建容器到銷毀容器)
• 拉取/推送容器鏡像
• 存儲管理(管理鏡像及容器數據的存儲)
• 調用 runC 運行容器(與 runC 等容器運行時交互)
• 管理容器網絡接口及網絡

注意：Containerd 被設計成嵌入到一個更大的系統中，而不是直接由開發人員或終端用戶使用。

為什么需要 containerd

我們可以從下面幾點來理解為什么需要獨立的 containerd：

• 繼續從整體 docker 引擎中分離出的項目(開源項目的思路)
• 可以被 Kubernetes CRI 等項目使用(通用化)
• 為廣泛的行業合作打下基礎(就像 runC 一樣)

重復一遍：Containerd 被設計成嵌入到一個更大的系統中，而不是直接由開發人員或終端用戶使用。所以 containerd 具有宏大的愿景(此圖來自互聯網)：

當 containerd 和 runC 成為標準化容器服務的基石后，上層的應用就可以直接建立在 containerd 和 runC 之上。上圖中展示的容器平臺都已經支持 containerd 和 runC 的組合了，相信接下來會有更多類似的容器平臺出現。

Containerd 的技術方向和目標

• 簡潔的基于 gRPC 的 API 和 client library
• 完整的 OCI 支持(runtime 和 image spec)
• 同時具備穩定性和高性能的定義良好的容器核心功能
• 一個解耦的系統(讓 image、filesystem、runtime 解耦合)，實現插件式的擴展和重用

下圖展示了 containerd 的架構(此圖來自互聯網)：

在架構設計和實現方面，核心開發人員在他們的博客里提到了通過反思 graphdriver 的實現，他們將 containerd 設計成了 snapshotter 的模式，這也使得 containerd 對于 overlay 文件系、snapshot 文件系統的支持比較好。
storage、metadata 和 runtime 的三大塊劃分非常清晰，通過抽象出 events 的設計，containerd 也得以將網絡層面的復雜度交給了上層處理，僅提供 network namespace 相關的一些接口添加和配置 API。這樣做的好處無疑是巨大的，保留最小功能集合的純粹和高效，而將更多的復雜性及靈活性交給了插件及上層系統。

docker安裝后containerd默認已安裝，containerd包含如下命令組件：

?containerd：高性能容器運行時。

?ctr：containerd的命令行客戶端。

?runc：運行容器的命令行工具。

docker、containerd、docker-shim、runC關系：

docker：docker本身而言，包括了docker client和dockerd，dockerd實屬是對容器相關操作的api的最上層封裝，直接面向操作用戶。

containerd：dockerd實際真實調用的還是containerd的api接口（rpc方式實現），containerd是dockerd和runC之間的一個中間交流組件。

docker-shim：一個真實運行容器的載體，每啟動一個容器都會起一個新的docker-shim的進程。它通過指定三個參數：容器ID、boundle目錄（containerd對應某個容器生成目錄）、運行時二進制（默認是runC）來調用runC的api創建一個容器。

runC：一個命令行工具端，根據OCI的標準來創建和運行容器。