Containerd的架構(gòu)是怎樣的

本篇內(nèi)容主要講解“Containerd的架構(gòu)是怎樣的”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“Containerd的架構(gòu)是怎樣的”吧!

初識(shí) Containerd

Containerd 與 Docker

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

理解容器運(yùn)行時(shí)

K8s、CRI 與 container

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

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

自此，K8s 慢慢成為云原生領(lǐng)域的標(biāo)配，其生態(tài)也越做越大、越做越完善。Docker 公司為了融入生態(tài)，開源了 Docker 的核心依賴 containerd 。此外 K8s 為了對(duì)接下一層的容器，也因?yàn)槠渲辛⑿愿懔艘粋€(gè)運(yùn)行時(shí)接口，也就是 CRI（Container Runtime Interface），runc、containerd 等運(yùn)行時(shí)都去支持此接口。由于當(dāng)時(shí)確實(shí)沒有啥 high level 的 runtime，oci-o 雖然支持 CRI 接口，但其功能太弱；containerd 也尚未成熟，而且其當(dāng)時(shí)的定位是嵌入到系統(tǒng)中，并非給終端用戶使用；rkt 有自己的一套體系（后來這個(gè)項(xiàng)目也失敗了）。只能暫時(shí)為了適配 Docker 搞了個(gè) shim，將 CRI 轉(zhuǎn)換為 Docker API。K8s 和 Docker 進(jìn)入了冷靜期，雙方都在各自優(yōu)化自己，互不干擾。然而平靜之下仍是暗潮洶涌，CNCF 社區(qū)一直在不斷完善 containerd，其定位也發(fā)生了改變，由原來的系統(tǒng)嵌入組件，變成了今天的“工業(yè)標(biāo)準(zhǔn)容器運(yùn)行時(shí)”，并提供給終端用戶使用。直到去年，K8s 宣布廢棄使用 Docker，而改用 Containerd。其實(shí)除了這些商業(yè)因素，另一方面 K8s 已經(jīng)提供了標(biāo)準(zhǔn)接口對(duì)接底層容器運(yùn)行時(shí)，不再想單獨(dú)維護(hù)一個(gè) 類似于 Docker shim 的適配層去迎合不同的運(yùn)行時(shí)，這樣做也無可厚非（其實(shí)我看就是自己做大了，把鍋扔給底層了~噓~）。

Containerd 架構(gòu)

好了，現(xiàn)在瓜也吃完了，回到技術(shù)層面上來看看 Containerd 的架構(gòu)是什么樣的。首先看 containerd 的功能：

• 官網(wǎng)宣稱自己支持 OCI 的鏡像標(biāo)準(zhǔn)

• OCI 的容器運(yùn)行時(shí)

• 鏡像的推送和拉取

• 容器運(yùn)行時(shí)生命周期管理

• 多租戶的鏡像存儲(chǔ)

• 網(wǎng)絡(luò)管理以及網(wǎng)絡(luò) namespace 管理，支持容器網(wǎng)絡(luò)加入已有的 namespace

我就直接好家伙，Docker 核心功能該有的都有了。再看看架構(gòu)圖

Containerd 的設(shè)計(jì)是一個(gè)大的插件系統(tǒng)，圖中每一個(gè)虛線框其實(shí)就對(duì)應(yīng)一個(gè)插件。

從下往上看，底層支持 arm 和 x86 架構(gòu)，支持 Linux 和 windows 系統(tǒng)。

中間 containerd 包含三層： Backend、core、API。其中 Backend 中 Runtime plugin 提供了容器運(yùn)行時(shí)的具體操作，為了支持不同的容器運(yùn)行時(shí) containerd 也提供了一系列的 containerd-shim，如之前的文章 K8s & kata container 原理實(shí)踐 提到的 shim 就是這個(gè)。 Core 則是核心部分，提供了各種功能的服務(wù)，其中比較常用的是 Content service ，提供對(duì)鏡像中可尋址內(nèi)容的訪問，所有不可變的內(nèi)容都被存儲(chǔ)在這里；Images Service 提供鏡像相關(guān)的操作；Snapshot Plugin : 用來管理容器鏡像的文件系統(tǒng)快照。鏡像中的每一個(gè) layer 都會(huì)被解壓成文件系統(tǒng)快照，類似于 Docker 中的 graphdriver。再往上則是 API 層，通過 GRPC 與客戶端連接，這其中提供了給 Prometheus 使用 API 來進(jìn)行監(jiān)控，這里給個(gè)好評(píng)！

最上層則是各種客戶端，包括 K8s 的 kubelet，containerd 自己的命令行 ctr 等。

簡化一下上圖：

簡化后，Containerd 分為三大塊： Storage 管理鏡像文件的存儲(chǔ)； Metadata 管理鏡像和容器的元數(shù)據(jù)；另外由 Task 觸發(fā)運(yùn)行時(shí)。對(duì)外提供 GRPC 方式的 API 以及 Metrics 接口。

到此，相信大家對(duì)“Containerd的架構(gòu)是怎樣的”有了更深的了解，不妨來實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！