鯨品堂｜從Docker和Kubernetes看Containerd

在 Linux 內核中，容器不是一類對象。容器本質上由幾個底層的內核原語組成：namespace（允許你跟誰交談），cgroup（允許使用的資源量），和 LSM（Linux 安全模塊 —— 允許你做的事情）。這些湊在一起能夠為我們的進程設置安全、隔離和可計量的執行環境。

每次創建隔離進程時，都不需要手動隔離、自定義命名空間等，把這些組件捆綁在一起，我們稱之為容器。但是每次手動執行所有的操作將很麻煩，因此出現了容器運行時工具，它能將這些部分組合成一個隔離的、安全的執行環境變得很容易，讓我們能以重復的方式部署。

容器運行時是掌控容器運行的整個生命周期，以docker為例，其主要提供功能如下：

這些功能均可由小的組件單獨實現，因此容器運行時是運行和管理容器運行所需要的組件。

隨著容器運行時的發展，Docker公司與CoreOS和Google共同創建了OCI（開放容器標準），并提供了兩種規范：

在runc作為了OCI的一種實現參考之后，各種運行時工具和庫也慢慢出現。而根據這些運行時的功能不同，比如有的只運行容器（runc，lxc），有的還可以對鏡像進行管理（Containerd，cri-o），因此通俗的分為高級運行時（high-level）和低級運行時（low-level）。

Docker是第一個流行的容器技術，最初Docker使用的是LXC(0.7版本之前)但是隔離的層次不完善，后來Docker開發了libcontainer(0.7~1.10版本)，最后演變為runc和Containerd（Docker被逼無奈將libcontainer捐獻出來改名為runc）

從1.11版本之后，Docker容器運行開始通過集成Containerd和runc等多個組件完成?，F在的架構中，Containerd負責容器的生命周期管理，提供了在一個節點上執行容器和管理鏡像的最小功能集，并向上為Docker Daemon提供grpc接口。

當請求創建一個容器時，Docker Daemon并不會直接去創建，而且請求containerd創建容器，containerd在收到請求后，也不會去直接操作容器，而是創建containerd-shim的進程去操作容器（因為需要一個父進程去做狀態收集、維持stdin、stdout、stderr打開等工作，如果父進程是contaienrd，當containerd掛掉時，整個宿主機的容器都會退出），而containerd-shim會去調用runc來啟動容器，runc在啟動完容器后會直接退出，此時containerd-shim成為容器的父進程，負責收集容器進程的狀態上報給containerd，并在容器中 pid 為 1 的進程退出后接管容器中的子進程進行清，確保不會出現僵尸進程。

runc創建容器則是根據上述的OCI去做操作，例如namespaces、cgroups的配置，以及掛載root文件系統等操作。

Docker 將容器操作都遷移到 containerd 中去是因為當時做 Swarm，想要進軍 PaaS 市場，做了這個架構切分，讓 Docker Daemon 專門去負責上層的封裝編排，當然后面的結果我們知道 Swarm 在 Kubernetes 面前是慘敗，然后 Docker 公司就把 containerd 項目捐獻給了 CNCF 基金會，這個也是現在的 Docker 架構。

2014年Kubernetes誕生，由于當時Docker很流行，因此很自然的選擇了Docker，在CRI出現之前，Kubelet通過內嵌的dockershim操作Docker API來操作容器，進而達到一個面向終態的效果。

而隨著Docker將Containerd開源出以及更多的容器運行時出來，Kubernetes為了精簡和支持更多的容器運行時，Google和Redhat推出了CRI標準，用于Kubernetes平臺和容器運行時解耦CRI（容器運行時接口）。

CRI本質上是Kubernetes定義的一組與容器運行時進行交互的接口，因此容器運行時只要實現了CRI，就可以對接到Kubernetes平臺中。但是當時Kubernetes的地位不高，所以一些容器運行時不會去實現CRI接口，于是就出現了shim，shim的職責是作為適配器將各種容器運行時本身的接口適配到 Kubernetes 的 CRI 接口上，上圖的dockershim就是Kubernetes對接Docker到CRI接口的實現。

在引入CRI后，Kubelet的架構如圖所示：

通過觀察分析能夠發現，Kubernetes使用Docker的調用鏈比較長，而Docker的一些功能對于Kubernetes來說又不需要，所以自然的將容器運行時切換到Containerd。切換到Containerd后取消掉了中間環節，但操作體驗和以前一樣，在Containerd1.0時，對CRI的適配是通過一個單獨的CRI-Containerd實現（因為最開始containerd還會去適配其他系統，所以沒有直接實現CRI）。到了Containerd1.1版本后就去掉了CRI-Containerd，直接把適配邏輯作為插件集成到Containerd主進程中，變得更加簡潔。

CRI的接口主要分為兩類：

RuntimeService 中 CRI 設計的一個重要原則，就是確保這個接口本身，只關注容器，不關注 Pod，這么做是因為：

雖然 CRI 里還是有一組叫做 RunPodSandbox 的接口。但是，這個 PodSandbox，對應的并不是 Kubernetes 里的 Pod API 對象，而只是抽取了 Pod 里的一部分與容器運行時相關的字段，比如 HostName、DnsConfig、CgroupParent 等。所以說，PodSandbox 這個接口描述的其實是 Kubernetes 將 Pod 這個概念映射到容器運行時層面所需要的字段，或者說是一個 Pod 對象的子集。而創建、管理 Pod 的邏輯則放置在 kubernetes 中，而不是 CRI 要實現的接口中。

隨著 CRI 方案的發展，以及其他容器運行時對 CRI 的支持越來越完善，Kubernetes 社區在2020年7月份就開始著手移除 dockershim 方案了，現在的移除計劃是在 1.20 版本中將 kubelet 中內置的 dockershim 代碼分離，將內置的 dockershim 標記為維護模式，當然這個時候仍然還可以使用 dockershim，目標是在 1.24 版本發布沒有 dockershim 的版本（代碼還在，但是要默認支持開箱即用的 docker 需要自己構建 kubelet，會在某個寬限期過后從 kubelet 中刪除內置的 dockershim 代碼）。

目前，CRI領域有兩個主要的參與者，一個是Docker的高級運行時Containerd，一個是RedHat專門為Kubernetes設計的運行時CRI-O。

當容器運行時的標準被提出以后，RedHat的一些人開始想他們可以構建一個更簡單的運行時，而且這個運行時僅僅為Kubernetes所用。這樣就有了skunkworks項目，最后定名為 CRI-O， 它實現了一個最小的CRI接口，旨在充當CRI和支持的OCI運行時的輕量級橋梁。

Containerd 是一個工業級標準的容器運行時，它強調簡單性、健壯性和可移植性，可以在宿主機中管理完整的容器生命周期：容器鏡像的傳輸和存儲、容器的執行和管理、存儲和網絡等，主要有以下功能：

Containerd在Docker或者Kunernetes中都是使用最多的運行時，同時也是我們環境中接觸最多的，因此后續著重學習Containerd。

Containerd 可用作 Linux 和 Windows 的守護程序，它管理其主機系統完整的容器生命周期，從鏡像傳輸和存儲到容器執行和監測，再到底層存儲到網絡附件等等。

為了解耦，Containerd 將系統劃分成了不同的組件，每個組件都由一個或多個模塊協作完成（Core 部分），每一種類型的模塊都以插件的形式集成到 Containerd 中，而且插件之間是相互依賴的，例如，上圖中的每一個長虛線的方框都表示一種類型的插件，包括 Service Plugin、Metadata Plugin、GC Plugin、Runtime Plugin 等，其中 Service Plugin 又會依賴 Metadata Plugin、GC Plugin 和 Runtime Plugin。每一個小方框都表示一個細分的插件，例如 Metadata Plugin 依賴 Containers Plugin、Content Plugin 等。比如:

總體來看 Containerd 可以分為三個大塊：

Containerd被設計成可以很容易的嵌入到更大的系統中，例如Docker使用containerd運行容器，Kubernetes通過CRI使用containerd管理單個 節點上的容器 除了編程方式使用外，它還可以通過命令行使用，但不像docker全面，主要用于調試和學習目的，主要有：

Containerd通過暴露的gRPC API給外部管理容器，而Containerd中主要提供的API有：

其他還包括events、diffs等，具體見containerd的gRPC API

Docker、ctr、nerdctl都是通過Containerd提供的API進行容器的管理，Kubernetes、crictl則是通過CRI接口實現。

Containerd創建任務流程

上述說的創建容器流程和創建Pod流程都是調用Containerd內部接口的邏輯，實際的過程由Containerd啟動Containerd-shim進程調用runc創建容器，具體步驟如下：

1.   Containerd 被設計成嵌入到一個更大的系統中，而不是直接由開發人員或終端用戶使用

2.   Docker有網絡功能模塊，比如它會創建 docker0 網橋，所以在使用 docker 時可以直接實現端口映射等功能，而這些網絡能力都是 Docker Daemon 實現的。但是Containerd 中不包含相應的網絡功能，想要啟動的容器有網絡能力，需要額外安裝 CNI 相關的工具和插件（bridge、flannel 等）

*Containerd一切皆插件

本文通過引入Docker和Kubernetes的發展介紹容器、容器運行時，將容器領域c常見的概念OCI、CRI、shim、runc，containerd串聯起來，能夠幫組我們進一步理解Docker和Kubernetes背后是怎么創建容器的，以及Containerd的實際運行原理。