怎么將Containerd用作Kubernetes runtime

這篇文章主要講解了“怎么將Containerd用作Kubernetes runtime”，文中的講解內(nèi)容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“怎么將Containerd用作Kubernetes runtime”吧！

Kubernetes 宣布棄用 dockershim

很多媒體將該事件宣稱為 Kubernetes 宣布棄用 Docker，其實這是一種誤導。那么應該如何正確的去看待呢？首先是了解整個事情的前因后果，得需要知道 dockershim 是什么。

dockershim

dockershim 是 Kubernetes 的一個組件，主要目的是為了通過 CRI 操作 Docker。Docker在 2013 年就出現(xiàn)了，2014 年 Kubernetes 發(fā)布并默認使用 Docker 作為容器運行時，而 dockershim首次正式出現(xiàn)是在 2016 年。Docker 在創(chuàng)建之初并沒有考慮到容器編排或者是考慮 Kubernetes，但 Kubernetes 在創(chuàng)建之初便采用Docker 作為它的默認容器進行時，后續(xù)代碼當中包含了很多對 Docker 相關的操作邏輯。后期 Kubernetes 為了能夠做解耦，兼容更多的容器進行時，將操作 Docker 相關邏輯整體獨立起來組成了 dockershim。

Container Runtime Interface

再說 CRI（Container Runtime Interface）即容器運行時接口，該概念是由Kubernetes 提出并在 2016 年底開始應用，其主要目標是增強 Kubernetes 的可擴展性，可以不固定、不捆綁某一個容器運行時，實現(xiàn)可插拔式的容器進行時。比如可以使用 Docker 為容器運行時也可以使用其他的例如 rkt，并且希望通過開放 CRI 這個統(tǒng)一的接口來提高代碼的可維護性，而不是需要支持 Docker 時就對 Docker 進行適配，需要支持另一個運行時就得對其做相關的適配。它希望是任何一個成為 Kubernetes 的容器運行時都遵守 CRI 統(tǒng)一的接口與規(guī)范，實現(xiàn)了 CRI 就可以作為 Kubernetes 的運行時，并不需要關注具體是什么。

為什么要棄用 dockershim

dockershim 的目的是為了 Kubernetes 通過 CRI 操作 Docker，所以Kubernetes 任何的功能變動或 Docker 有任何的功能特性變更，dockershim 代碼必須加以改動保證能夠支持變更。另外一個原因是隨著容器技術的推進，容器運行時已經(jīng)多種多樣了，比如本次分享的主角 Containerd，還有 cri-o 以及 rkt 的容器運行時，不過這個 rkt 容器運行時的項目已經(jīng)不維護了。

此外，原先 Kubernetes 需要去調(diào)用 dockershim 跟 Docker 做溝通，Docker 的底層運行時是 containerd，可以發(fā)現(xiàn)最終都是要調(diào)用 containerd，并且 containerd 自身也是可以支持 CRI 的。那為什么要先繞過一層 Docker 呢？是不是可以直接通過 CRI 跟 Containerd 進行交互呢？這也就造成了現(xiàn)在 Kubernetes 社區(qū)希望棄用 dockershim。

棄用 dockershim 的影響

終端???任何影響。這里指的是使用來自云廠商/使用別人提供的Kubernetes 集群的終端用戶，他們不需要關注集群本身的容器運行時到底是什么，因為和你交互的都是 Kubernetes 自身的 CRI，而任何一個可以作為 Kubernetes 底層容器運行時的東西都必須是兼容 CRI 接口的，上層就已經(jīng)屏蔽掉這個細節(jié)了。

對負責維護 Kubernetes 集群的工作人員有一定影響。當升級 Kubernetes 集群版本時，需要考慮是否切換容器進行時。如果目前在用最新版本 Kubernetes V1.20，并且使用 Docker 作為容器運行時，要考慮它能否正常工作。其實是可以正常工作的，只是在啟動 Kubernetes 的時候會發(fā)現(xiàn)一條日志，提醒你當前使用的容器運行時 Docker 已經(jīng)不再被 Kubernetes 支持，因為已經(jīng)準備棄用dockershim，因此會有這個提醒。

Kubernetes 社區(qū)計劃在 2021 年將dockershim 正式移除。換個角度考慮，既然社區(qū)不想在 Kubernetes 源代碼當中維護 dockershim 了，那是不是可以把 dockershim 組件給單獨的拿出來呢？答案是可以的，現(xiàn)在 Mirantis 和 Docker 已經(jīng)決定之后共同合作維護 dockershim 組件。此外，還可以通過樹外的 dockershim 獨立組件，繼續(xù)使用 Docker 作為容器運行時，并且使用這種方式只需要做一些簡單的配置，把原先使用內(nèi)置的Kubernetes 自身攜帶的 dockershim 組件，改成使用一個獨立的 dockershim 組件，本身變動很小。

那么 Docker 到底還能否使用呢？在我看來，毋庸置疑，Docker 仍然是現(xiàn)階段容器構建和運行的最佳選擇。

快速了解 Containerd

Containerd 是中間層的容器運行時。它構建在平臺之下，作為平臺下層的一個容器運行時，但又比最底層的容器運行時像 runc、gVisor 要高一點，所以被稱為中間層的容器運行時。除此之外也可稱作為資源管理器，可以用來管理容器的進程、鏡像以及管理文件系統(tǒng)的快照，還有元數(shù)據(jù)和依賴的管理。既然它可以作為一個資源管理器來使用，如果想要在此之上構建一個屬于自己的容器平臺就會很方便。

Containerd 是由 Docker 公司創(chuàng)建，并且在 2017年捐贈給了 CNCF，2019 年 Containerd 從 CNCF 正式畢業(yè)。Containerd 項目一開始的目標是用來管理容器的進程，之后逐步變更成為一個完整的容器運行時，是 Docker 的底層容器運行時。需要說明的是，containerd 是可以拋開 Docker 與 Kubernetes 自身獨立工作的。

Containerd 與 CRI

Containerd 在之前的版本中考慮到了 CRI，但它是將CRI 作為獨立的進程存在的。CRI-Containerd 其實是一個獨立組件，Kubernetes 通過 CRI 接口調(diào)用 CRI-Containerd，再由這個組件去調(diào)用 containerd。在 Containerd1.1 版本之后對該特性做了重新的設計，它將 CRI 的支持通過插件化的方式來實現(xiàn)，Kubernetes 通過 CRI 接口調(diào)用的其實是 Containerd 當中 CNI 的插件，以此來達到通信的目的，調(diào)用鏈更少更短了。

Containerd 的特性

• 支持 OCI 鏡像規(guī)范，即前文所提到的 runc

• 支持 OCI 運行時規(guī)范。Docker 引導了 OCI 組織的成立，該組織主要有兩個規(guī)范：鏡像規(guī)范與運行時規(guī)范。這兩個規(guī)范在 Docker 成立時把 Docker 鏡像規(guī)范與底層容器運行時規(guī)范都給捐贈出來作為它的初始工作

• 支持鏡像的 push/pull 作用

• 支持容器網(wǎng)絡管理。因為可以啟動和運行容器，容器啟動后支持相互之間的訪問，或彼此之間網(wǎng)絡的隔離，所以需要支持容器網(wǎng)絡的管理

• 存儲支持多租戶。Containerd 的相關操作有通過 namespace 來做隔離的，可以指定不同的 namespace 來實現(xiàn)，它默認的 namespace 叫 default，在 default 的 namespace下面下載多個鏡像。但是在其他的 namespace 下看不到這些鏡像，也用不到，以此來達到多租戶的隔離

• 支持容器運行時和容器的生命周期管理

• 支持管理網(wǎng)絡名稱空間容器以加入現(xiàn)有名稱空間，可以讓某一個容器加入到現(xiàn)有的 namespace 當中

Containerd 的整體架構

上圖是 Containerd 整體的架構。由下往上，Containerd支持的操作系統(tǒng)和架構有 Linux、Windows 以及像 ARM 的一些平臺。在這些底層的操作系統(tǒng)之上運行的就是底層容器運行時，其中有上文提到的runc、gVisor 等。在底層容器運行時之上的是Containerd 相關的組件，比如 Containerd 的 runtime、core、API、backend、store 還有metadata 等等。構筑在 Containerd 組件之上以及跟這些組件做交互的都是 Containerd 的 client，Kubernetes 跟 Containerd 通過 CRI 做交互時，本身也作為 Containerd 的一個 client。Containerd 本身有提供了一個 CRI，叫 ctr，不過這個命令行工具并不是很好用。

在這些組件之上就是真正的平臺，Google Cloud、Docker、IBM、阿里云、微軟云還有RANCHER等等都是，這些平臺目前都已經(jīng)支持 containerd， 并且有些已經(jīng)作為自己的默認容器運行時了。

Containerd 主要功能與上手實踐

鏡像管理

首先是上文中頻繁提到的鏡像管理。具體操作是需要通過一個 client 去跟 Containerd 做交互。如圖中所示，這里選擇了ctr 的命令行工具。ctr指定一個address 參數(shù)跟 Containerd交互，它是在后臺持續(xù)運行的一個服務，需要指定它的地址。圖中是通過 pull 一個 redis alpine linux 的鏡像，接下來通過 image ls就可以看到已經(jīng)成功 pull 下來的鏡像。

容器管理

作為一個容器運行時對容器進行管理是必不可少的功能。同樣的通過 -a 參數(shù)來指定 address 與Containerd 進行通信，通過 container create+鏡像名稱+容器名稱來創(chuàng)建一個容器，通過 container ls 可以看到剛才創(chuàng)建的容器。需要注意的是，最后一列叫做 runtime，它的 runtime 叫做 io.containerd.runc.v2，表明是 v2 版本的 Containerd API。

在 Containerd 中通過 container create 創(chuàng)建出來的容器其實并不管用，還需要讓其運行起來。這時通常會把它當作一個 task，對它執(zhí)行 task start，就可以把剛才創(chuàng)建的鏡像跑起來了。通過 task ls 就可以看到名叫 redis 的 Containerd，其中有一個正在運行的進程，并且展現(xiàn)出了進程號。

命名空間

需要說明的是，可以通過 -n 來指定一個默認的叫做 default 的命名空間，而后通過 task ls 就看到剛才啟動容器的進程，它其實是在運行中的。如果把 namespace 換一個，比如圖中的 moby 就是 Docker 項目當前使用的 namespace 名稱，Docker 在使用 Containerd 作為容器運行時的時候，會默認使用它。

繼續(xù)往下看，通過 ctr -n 指定使用 moby 命名空間，-a 參數(shù)指定containerd 的地址，然后 task ls 來看看moby 項目當中到底運行著什么?？梢钥吹接幸粭l記錄是正在運行當中的。這條記錄如何和 Docker 當中的容器或任務做匹配比較呢？一個簡單的辦法就是通過 docker ps --no-trunc-- format 跟容器完整的 ID，然后 grep 就可以看到剛才通過 ctr 命令得到的ID 了。

需要注意的是，如果使用 Containerd 作為 Kubernetes 的容器運行時，那么它的 namespace 叫 k8s.io。到這里可能有些人已經(jīng)發(fā)現(xiàn)，Containerd 作為 Docker 的運行時可以使用不同的命名空間，比如 moby。用作 Kubernetes 容器運行時也可以使用不同的命名空間，比如 k8s.io。那是否存在一種辦法可以讓平臺當中既有 Kubernetes 又有 Docker，還有 Containerd 呢？答案是肯定的，直接將其全部裝到一起，但不配置 Docker 作為容器運行時，先觀察一段時間看看，這也是一種辦法。

Containerd 用作 Kubernetes 的 runtime

上圖是 Containerd 用作 Kubernetes 的 runtime 整個流程圖。Kubernetes 通過 CRI 接口，調(diào)用到 CRI plugin，plugin 是Containerd 一個內(nèi)置的插件，其中包含了最主要的兩部分：一是 image service，包含了鏡像服務相關的；二是 runtime service，即運行時的服務。如果在 containerd 當中部署了一個項目或服務，它首先會調(diào)度到某一臺機器，這臺機器上的 Kubernetes 就會開始工作，它會查詢服務、需要哪些鏡像，而后把相關的鏡像讓運行時給拉下來，再去啟動對應的 pod 或者相關的容器。

其次它還會跟 CNI 做交互。CNI 即 Container Network Interface，是Kubernetes 提供的一個容器網(wǎng)絡接口）。主要注意的是，交互過程中可能會提前創(chuàng)建出來 pause的 container，是一個占位的過程，這里先不對此做更深入的介紹。

當 Containerd 作為 Kubernetes 的容器運行時，配置相對很簡單：通過 containerd config default命令可以直接查詢到 Containerd 完整的默認配置，下圖中可以看到主要是配置 CRI。所以在這里的配置文件當中，通過 plugins.io.containerd.grpc.vi.cri 對其進行配置，首先是 default-runtime，其次配置一個 runtime.runc。

這里簡單介紹配置 runc 需要注意的參數(shù)。比如 io.containerd.runc.v2 需要配置runtime.type；涉及配置與 runc 相關的一些配置會包含一些 CNI 的配置、目錄之類的，具體的配置上圖中已經(jīng)展示了?？偠灾绻胍崞饋硪粋€服務、一個 pod 或是 container，要注意都是需要配置的。它都會有一個 pause的鏡像，即 sandbox_image，可以從中指定一個默認的鏡像。當然也可以通過此處換源，加快國內(nèi)環(huán)境下的拉取速度。

最后還有些其他的資源，如本人長期參與的一個項目 KIND（ Kubernetes in docker）。這個項目相當于是使用docker 容器作為不同的 node，可以把這些 node 組成一個集群網(wǎng)絡，搭建一套 Kubernetes。而這個集群使用的容器運行時就是 containerd，雖然一開始使用的是 Docker，但后期逐步都將其替換成了 containerd，類似的還有包括 K3C、K3S，效果都是差不多的。

感謝各位的閱讀，以上就是“怎么將Containerd用作Kubernetes runtime”的內(nèi)容了，經(jīng)過本文的學習后，相信大家對怎么將Containerd用作Kubernetes runtime這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！