初識 Containerd
Containerd 與 Docker
在以前的工做中，containerd 一直都是薛定諤的存在，只聞其名但沒啥用武之地，直到前一段時間 K8s 官方宣佈要廢棄 Docker 時，才把這傢伙又拉回到大衆視野裏。在技術層面上，我在以前的文章中也討論過 CRI、containerd 以及 Docker 這些容器運行時之間的關係。有興趣的小夥伴能夠去看一下這幾篇文章：windows
理解容器運行時網絡
如今只是單純好奇在非技術層面上 CNCF 爲啥要這麼作呢，因此仍是去八卦一下 Containerd 和 Docker 的前世此生以及愛恨情仇。優化
在幾年以前，Docker 公司在容器技術領域強勢崛起，一家獨大，Google、RedHat 這樣的巨頭們都產生了很大的危機感，所以他們想與 Docker 公司一塊兒聯合研發推動一個開源的容器運行時做爲 Docker 技術的核心依賴。然鵝 Docker 公司很高冷的表示：我不幹！巨頭們聽到這個反饋就很不爽啊，所以經過一些手段對 Docker 公司軟硬兼施，使其將 libcontainer 捐給了開源社區，也就是如今的 runc，一個 low level 的容器運行時。此外，巨頭們又成立了 CNCF 去對抗 Docker 公司的一家獨大，CNCF 成立的思路很明確：在容器領域幹不過 Docker，那就搞容器上層的建設——容器編排，今後 K8s 誕生了。雖然 Docker 公司也嘗試使用 Swarm 去對抗 K8s，但最終也失敗了。url
自此，K8s 慢慢成爲雲原生領域的標配，其生態也越作越大、越作越完善。Docker 公司爲了融入生態，開源了 Docker 的核心依賴 containerd 。此外 K8s 爲了對接下一層的容器，也由於其中立性搞了一個運行時接口，也就是 CRI（Container Runtime Interface），runc、containerd 等運行時都去支持此接口。因爲當時確實沒有啥 high level 的 runtime，oci-o 雖然支持 CRI 接口，但其功能太弱；containerd 也還沒有成熟，並且其當時的定位是嵌入到系統中，並不是給終端用戶使用；rkt 有本身的一套體系（後來這個項目也失敗了）。只能暫時爲了適配 Docker 搞了個 shim，將 CRI 轉換爲 Docker API。K8s 和 Docker 進入了冷靜期，雙方都在各自優化本身，互不干擾。然而平靜之下還是暗潮洶涌，CNCF 社區一直在不斷完善 containerd，其定位也發生了改變，由原來的系統嵌入組件，變成了今天的「工業標準容器運行時」，並提供給終端用戶使用。直到去年，K8s 宣佈廢棄使用 Docker，而改用 Containerd。其實除了這些商業因素，另外一方面 K8s 已經提供了標準接口對接底層容器運行時，再也不想單獨維護一個 相似於 Docker shim 的適配層去迎合不一樣的運行時，這樣作也無可厚非（其實我看就是本身作大了，把鍋扔給底層了~噓~）。spa
Containerd 架構
好了，如今瓜也吃完了，回到技術層面上來看看 Containerd 的架構是什麼樣的。首先看 containerd 的功能：.net
- 官網宣稱本身支持 OCI 的鏡像標準
- OCI 的容器運行時
- 鏡像的推送和拉取
- 容器運行時生命週期管理
- 多租戶的鏡像存儲
- 網絡管理以及網絡 namespace 管理，支持容器網絡加入已有的 namespace
我就直接好傢伙，Docker 核心功能該有的都有了。再看看架構圖插件
Containerd 的設計是一個大的插件系統，圖中每個虛線框其實就對應一個插件。命令行
從下往上看，底層支持 arm 和 x86 架構，支持 Linux 和 windows 系統。設計
中間 containerd 包含三層： Backend、core、API。其中 Backend 中 Runtime plugin 提供了容器運行時的具體操做，爲了支持不一樣的容器運行時 containerd 也提供了一系列的 containerd-shim，如以前的文章 K8s & kata container 原理實踐 提到的 shim 就是這個。 Core 則是核心部分，提供了各類功能的服務，其中比較經常使用的是 Content service ，提供對鏡像中可尋址內容的訪問，全部不可變的內容都被存儲在這裏；Images Service 提供鏡像相關的操做；Snapshot Plugin : 用來管理容器鏡像的文件系統快照。鏡像中的每個 layer 都會被解壓成文件系統快照，相似於 Docker 中的 graphdriver。再往上則是 API 層，經過 GRPC 與客戶端鏈接，這其中提供了給 Prometheus 使用 API 來進行監控，這裏給個好評！
最上層則是各類客戶端，包括 K8s 的 kubelet，containerd 本身的命令行 ctr 等。
簡化一下上圖：
簡化後，Containerd 分爲三大塊： Storage 管理鏡像文件的存儲； Metadata 管理鏡像和容器的元數據；另外由 Task 觸發運行時。對外提供 GRPC 方式的 API 以及 Metrics 接口。
總結
其實 containerd 的社區一直很活躍，這個項目的成熟離不開社區各位的貢獻。這篇文章重點在於回顧一下歷史，以及如今它如今的架構。做爲使用者就暫時不去研究其內部設計，相信也是及其複雜且精妙的。僅在使用方面，我發現 containerd 和 Docker 仍是有不少共同之處的，那麼下一篇文章則着重聊一聊 containerd 的實踐吧。