Docker?Rkt？Lxd?細說K8S容器進行時的又一選項Containerd

器運行時是執行容器並在節點上管理容器鏡像的軟件，目前，最廣爲人知的容器運行時是Docker，但在生態系統中還有其餘容器運行時軟件，好比Rkt、Containerd和Lxd。Docker是如今於Kubernetes環境中使用的最多見的容器運行時，今天數人云給你們推薦一個Docker的組件——Containerd，它多是更好的選擇。

本文是由谷歌的軟件工程師Lantao Liu和IBM的開源開發者Mike Brown基於自身相關實踐，共同編寫。

Kubernetes 1.5引入了一個名爲容器運行時接口（CRI）的內部插件API，以方便地訪問不一樣的容器運行時，CRI容許Kubernetes使用各類容器運行時，而不須要從新編譯。從理論上說，Kubernetes能夠使用任何實現CRI的容器運行時管理容器和容器鏡像。

在過去的6個月中，來自Google、Docker、IBM、中興和ZJU的工程師們一直在努力爲CRI For Containerd，這個項目被稱爲cri-containerd，用戶能夠使用容器做爲底層運行時運行Kubernetes集羣，而且無需安裝Docker。

Containerd

Containerd是一個兼容OCI的核心容器運行時，它被設計爲嵌入到更大的系統當中，提供了在一個節點上執行容器和管理鏡像的最小功能集，它是由Docker公司發起，並於2017年3月加入了CNCF，Docker引擎自己是創建在早期版本的容器之上，而且很快將更新到最新版本。

與Docker相比，Containerd的規模要小得多，提供了Golang客戶端API，並且更專一於可嵌入，較小範圍會致使一個更小的代碼庫，隨着時間的推移，其更容器維護以及匹配Kubernetes的需求，以下圖所示：

綜上所述，從技術的角度來看，Containerd是Kubernetes的容器進行時比較好的選擇。

Cri-Containerd

Cri-Containerd是對於容器的一個實現，它在與Kubelet和 Containerd相同的節點上運行，在Kuberntes和Containerd之間的分層中，Cri-Containerd處理來自Kubelet的全部國際服務請求，並使用Containerd管理容器和容器鏡像，Cri-Containerd管理這些服務請求，在必定程度上是經過造成Containerd服務請求，同時添加足夠的附加功能來去支持CRI需求。

與當前的Docker CRI實現（Dockershim）相比，Cri-Containerd消除了棧中的額外跳轉，使堆棧更加穩定和高效。

體系結構

能夠經過下面這個例子來演示當Kubele建立一個單一容器的時候，如何使用Cri-Containerd。

• Kubelet經過國際運行時服務API調用了Cri-Containerd，用以建立一個Pod；

• Cri-Containerd使用Containerd建立和啓動一個特殊的暫停容器（沙箱容器），並將該容器放在Pod的Cgroups和名稱空間中；

• Containerd使用CNI配置了Pod的網絡名稱空間；

• Kubelet隨後經過國際服務API調用了「容器」，以拉出應用程序的容器的鏡像；

• 若是鏡像不存在於節點，則Cri-Containerd將進一步使用Containerd來拉出鏡像；

• 而後，Kubelet經過「CRI」服務API調了「Cri-Containerd」經過拉取容器的鏡像來建立和啓動應用程序容器；

• Cri-Containerd最終調用Containerd來建立應用程序容器，將其放入Pod的Cgroups和命名空間中，而後啓動該容器的新應用程序容器。

在這些步驟以後，將建立並運行一個Pod及其相應的應用程序容器。

現階段狀態

Cri-Containerd V1.0.0-alpha.0是在2017年9月25日發佈的。

其功能完備，全部的Kubernetes的特性都獲得了支持。

全部的CRI validation test（CRI validation test是一種測試框架，用於驗證是否符合Kubernetes的全部要求。地址：https://github.com/kubernetes...）

全部的 Node e2e Test都已經過（用於測試Kubernetes節點級功能的測試框架如Managing Pods、Mounting Volumes等，地址：https://github.com/kubernetes...）。

若想了解更多關於V1.0-Alpha的相關內容，請前往：https://github.com/kubernetes...

延伸閱讀

對於一個多節點集羣安裝程序，並使用能應用和Kubeadm啓動步驟請參見：https://github.com/kubernetes...

若想在Google雲端從頭建立一個集羣，請參見：https://github.com/kelseyhigh...

對於一個自發布Tarball的自定義安裝，請參見：https://github.com/kubernetes...

對於在本地VM上安裝LinuxKit，請參見：https://github.com/linuxkit/l...

下一階段

Containerd承諾，在下一階段將主要改進穩定性和可用性方面的問題：

穩定性：

在Kubernetes的測試基礎設施上創建一套完整的Kubernetes集成測試，包括Ubuntu、COS（容器化的OS 地址：https://cloud.google.com/cont...）等等。

積極解決用戶報告的任何測試失敗和其餘問題。

可用性：

提升Crictl（https://github.com/kubernetes...）的用戶體驗，Crictl是全部的CRI容器運行時的可移植命令行工具，這裏的目標是使其易於用於調試和開發場景。

集成Kube-up.sh（https://kubernetes.io/docs/ge...）幫助用戶使用Cri-Containerd來提升Kubernetes集羣的生產質量。

改進文檔。

預計在2017年末發佈V1.0-Beta。

提供建議

Cri-Containerd是一個Kubernetes的孵化器項目，地址：ttps://github.com/kubernetes-incubator/cri-containerd。歡迎提供任何具備建設性的意見和建議，具體的使用入門指南請參見：https://github.com/kubernetes...

社區

Cri-Containerd是由Kubernetes Signode社區開發和維護的，若有相關的建議，能夠加入社區：

Sig-Node社區網站：https://github.com/kubernetes...

Slack:Kubernetes(kubernet.slack.com)的sig-節點通道：https://kubernetes.slack.com/

原文做者：Kubernetes
原文連接：http://blog.kubernetes.io/201...