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

創(chuàng)新互聯(lián)服務(wù)項目包括河源網(wǎng)站建設(shè)、河源網(wǎng)站制作、河源網(wǎng)頁制作以及河源網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，河源網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到河源省份的部分城市，未來相信會繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

初識 Containerd

Containerd 與 Docker

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

理解容器運行時

K8s、CRI 與 container

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

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

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

Containerd 架構(gòu)

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

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

• OCI 的容器運行時

• 鏡像的推送和拉取

• 容器運行時生命周期管理

• 多租戶的鏡像存儲

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

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

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

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

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

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

簡化一下上圖：

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

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

網(wǎng)站欄目：Containerd的架構(gòu)是怎樣的
文章源于：http://chinadenli.net/article8/gojeop.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供手機(jī)網(wǎng)站建設(shè)、定制網(wǎng)站、網(wǎng)站導(dǎo)航、建站公司、做網(wǎng)站、品牌網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)