Containerd的架構是怎樣的

本篇內容主要講解“Containerd的架構是怎樣的”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Containerd的架構是怎樣的”吧!

初識 Containerd

Containerd 與 Docker

在之前的工作中，containerd 一直都是薛定諤的存在，只聞其名但沒啥用武之地，直到前一段時間 K8s 官方宣布要廢棄 Docker 時，才把這家伙又拉回到大眾視野里。在技術層面上，我在之前的文章中也討論過 CRI、containerd 以及 Docker 這些容器運行時之間的關系。有興趣的小伙伴可以去看一下這幾篇文章：

理解容器運行時

K8s、CRI 與 container

現在只是單純好奇在非技術層面上 CNCF 為啥要這么做呢，所以還是去八卦一下 Containerd 和 Docker 的前世今生以及愛恨情仇。

在幾年之前，Docker 公司在容器技術領域強勢崛起，一家獨大，Google、RedHat 這樣的巨頭們都產生了很大的危機感，因此他們想與 Docker 公司一起聯合研發推進一個開源的容器運行時作為 Docker 技術的核心依賴。然鵝 Docker 公司很高冷的表示：我不干！巨頭們聽到這個反饋就很不爽啊，因此通過一些手段對 Docker 公司軟硬兼施，使其將 libcontainer 捐給了開源社區，也就是現在的 runc，一個 low level 的容器運行時。此外，巨頭們又成立了 CNCF 去對抗 Docker 公司的一家獨大，CNCF 成立的思路很明確：在容器領域干不過 Docker，那就搞容器上層的建設——容器編排，從此 K8s 誕生了。雖然 Docker 公司也嘗試使用 Swarm 去對抗 K8s，但最終也失敗了。

自此，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 的適配層去迎合不同的運行時，這樣做也無可厚非（其實我看就是自己做大了，把鍋扔給底層了~噓~）。

Containerd 架構

好了，現在瓜也吃完了，回到技術層面上來看看 Containerd 的架構是什么樣的。首先看 containerd 的功能：

• 官網宣稱自己支持 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的架構是怎樣的”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！