在之前的部落格Containerd給Kubernetes帶來更多的容器執行選項[1]，我們介紹了Kubernetes containerd integration的內部測試版。經歷了6個月的開發，正式版推出了！現在，你可以在生產環境的Kubernetes叢集使用containerd 1.1[2]作為容器執行時元件！
Containerd 1.1執行在Kubernetes 1.10或以上版本，支援所有Kubernetes特性。在Google雲上的Kubernetes測試設施，containerd integration的功能已經和Docker integration旗鼓相當。（見：test dashboard[3]）。
我們很樂見於containerd迅速成長到這個重要的里程碑。阿裡雲從第一天開始就積極地使用containerd，簡單和註重穩健，使其成為完美地容器引擎，執行在我們的無伺服器化Kubernetes產品中，提供了高標準的表現和穩定。毫無疑問，containerd將成為容器時代的核心引擎並且繼續驅動進一步的創新。
Kubernetes的containerd架構進化了兩次。每次進化使整個體系更加穩定和有效率。
Containerd 1.0 – CRI-Containerd（已完成）
在containerd 1.0中，Kubelet和containerd之間的操作使由一個叫做cri-containerd的行程來完成的。Cri-containerd處理來自Kubelet的容器執行介面（CRI）服務請求，並且使用containerd來管理容器和相應的容器映象。相比較於Docker CRI方案（dockershim），淘汰了體系中一個額外的步驟。
當然，cri-containerd和containerd 1.0仍然是透過grpc連線的兩個不同的行程。額外的行程使整個流程複雜，使用者不容易理解和部署，帶來不必要的溝通成本。
Containerd 1.1 – CRI Plugin（當前版本）
在containerd 1.1中，cri-containerd行程被重構成為containerd CRI plugin。CRI plugin被構造進containerd 1.1，並且預設啟用。不同於cri-containerd，CRI plugin直接透過函式呼叫來和containerd互動。這個新架構使整合更加穩定和有效，並淘汰了額外的grpc hop。使用者可以直接在Kubernetes使用containerd 1.1。Cri-containerd行程不再需要了。
提高效能是containerd 1.1釋出的主要關註指標之一。效能最佳化主要包括Pod啟動延遲和行程資源的佔用。
下麵是containerd 1.1 and Docker 18.03 CE的比較結果。Containerd 1.1使用內建的CRI plugin；Docker 18.03 CE使用dockershim。
結果是由Kubernetes node e2e test[4]的元件Kubernetes node performance benchmark生成。大部分containerd基準資料可以在node performance dashboard[5]公開訪問。
下圖的是105個Pod批次啟動的資料。結果顯示使用containerd 1.1比Docker 18.03 CE更加快。（數字越低越好）。
穩定情況下的105個Pod，containerd 1.1比Docker 18.03 dockershim消耗更少的CPU和記憶體。Node中Pod數量的不同會使結果也不同，之所以選擇105個Pod是因為這是每個Node的最大Pod數量。
下圖的資料顯示，和Docker 18.03 dockershim比較，containerd 1.1降低了30.80%的Kubelet的CPU使用率，降低了68.13%的容器執行CPU使用率，降低了11.30%Kubelet resident set size（RSS）記憶體使用率，降低了12.78%容器執行RSS記憶體使用率。
容器執行命令列介面（CLI）是一個有用的系統和應用故障排除工具。使用Docker作為Kubernetes的容器執行時，系統管理員有時登陸到Kubernetes node去執行Docker命令來蒐集系統和應用的資訊。例如，使用docker ps和docker inspect檢查應用行程的狀態，使用docker images列出node上的映象，以及使用docker info驗證容器執行配置等。
對於containerd和所有其他CRI相容容器執行，如dockershim，我們建議使用crictl作為Docker CLI的替代來為Kubernetes nodes上的Pod，容器和容器映象做故障排除。
Crictl是一個提供了和Docker CLI類似經驗來為Kubernetes node故障排除的工具。始終如一地執行在所有CRI相容容器執行。託管在kubernetes-incubator/cri-tools[6]，目前版本是v1.0.0-beta.1[7]。Crictl被設計成類似於Docker CLI為使用者提供更好的過渡體驗，但不是完全一樣。下麵將解釋一些重要的區別。
Crictl的適用範圍是有限的故障排除工具，並非是Docker或者kubectl的替代品。Docker的CLI提供了一系列豐富的命令，使其成為非常有用的開發工具。但是它不是最適合作為Kubernetes nodes的故障排除工具。一些Docker的命令，如docker network和docker build並不適用於Kubernetes；甚至有些命令會破壞Kubernetes系統，如docker rename。Crictl提供剛剛適合的命令來為生產環境中的node故障排除。
Crictl提供對Kubernetes更友好的容器介面。Docker CLI缺少核心的Kubernetes概念，如pod和namespace，因此它不能提供清晰的容器和pods的資訊。比如，docker ps顯示有些混亂，長的容器名字，Pause容器和應用容器顯示在一起：
Pause容器[8]是一個Pod的實行細節，每個Pod都有一個Pause容器，因此沒有必要被列出。
恰恰相反，Crictl是為Kubernetes設計的。針對pods和容器有不同的命令組。如，crictl pods列出Pod資訊，crictl ps只列出應用容器的資訊。所有的資訊都被格式化成串列。
另一個例子，crictl pods有一個-namespace選項，依據Kubernetes中特定的namespaces來過濾pods。
“切換到containerd是否意味著不再使用Docker Engine？”我們很多次聽到這個問題，答案是NO。
Docker Engine是構建在containerd之上的。下一個Docker社群版（Docker CE）將使用containerd 1.1。當然，預設內建和啟用了CRI plugin。這意味著有特定需求的Docker使用者可以選擇繼續使用Docker Engine，與此同時，也能夠用內建的，同時也被Docker Engine使用的containerd來配置Kubernetes。下圖說明瞭containerd同時被Docker Engine和Kubelet使用：
既然containerd同時被Docker Engine和Kubelet使用，那這意味著使用者選擇使用了containerd後，不僅可以得到新的Kubernetes特性，效能和穩定的提升，也將同時為了保留使用Docker Engine的選項以便滿足其他的情況。
Containerd namespace機制是被用於保證Kubelet和Docker Engine不會看到和進入對方的建立的容器和映象。這是為了不讓二者互相干擾。也意味著：
-
Containerd 1.1原生支援CRI，Kubernetes直接呼叫。
-
Containerd 1.1適用於生產環境。
-
Containerd 1.1就啟動延遲和系統資源利用率而言，有好的表現。
-
Crictl是CLI工具，containerd透過它來和其他CRI相容的容器執行互動，從而為node做故障排除。
-
下一個穩定版本的Docker CE將包含containerd 1.1,。使用者選擇繼續使用Docker Engine，與此同時，也能夠用內建的，同時也被Docker Engine使用的containerd來配置Kubernetes。
我們這裡感謝所有來自Google，IBM，Docker，ZTE，ZJU和很多其他獨立開發者的貢獻！
詳細的containerd 1.1更新串列，請點選下麵的連線：https://github.com/containerd/containerd/releases/tag/v1.1.0
-
https://kubernetes.io/blog/2017/11/containerd-container-runtime-options-kubernetes
-
https://github.com/containerd/containerd/releases/tag/v1.1.0
-
https://k8s-testgrid.appspot.com/sig-node-containerd
-
https://github.com/kubernetes/community/blob/master/contributors/devel/e2e-node-tests.md
-
http://node-perf-dash.k8s.io/
-
https://github.com/kubernetes-incubator/cri-tools
-
https://github.com/kubernetes-incubator/cri-tools/releases/tag/v1.0.0-beta.1
-
https://www.ianlewis.org/en/almighty-pause-container
原文連結：https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/
本次培訓內容包括：Docker基礎、容器技術、Docker映象、資料共享與持久化、Docker三駕馬車、Docker實踐、Kubernetes基礎、Pod基礎與進階、常用物件操作、服務發現、Helm、Kubernetes核心元件原理分析、Kubernetes服務質量保證、排程詳解與應用場景、網路、基於Kubernetes的CI/CD、基於Kubernetes的配置管理等，點選瞭解具體培訓內容。
長按二維碼向我轉賬
![]()
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
知識星球
