歡迎光臨
每天分享高質量文章

Kubernetes Containerd整合進入GA階段

在之前的部落格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將成為容器時代的核心引擎並且繼續驅動進一步的創新。
——Xinwei,阿裡巴巴工程師
架構提升

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]公開訪問。
Pod啟動延遲
下圖的是105個Pod批次啟動的資料。結果顯示使用containerd 1.1比Docker 18.03 CE更加快。(數字越低越好)。

CPU和記憶體
穩定情況下的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記憶體使用率。

Crictl

容器執行命令列介面(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是一個故障排除工具
Crictl的適用範圍是有限的故障排除工具,並非是Docker或者kubectl的替代品。Docker的CLI提供了一系列豐富的命令,使其成為非常有用的開發工具。但是它不是最適合作為Kubernetes nodes的故障排除工具。一些Docker的命令,如docker network和docker build並不適用於Kubernetes;甚至有些命令會破壞Kubernetes系統,如docker rename。Crictl提供剛剛適合的命令來為生產環境中的node故障排除。
Kubernetes為導向
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。

想要更多關於如何在容器中使用Crictl:
  • 檔案:https://github.com/containerd/cri/blob/master/docs/crictl.md

  • Demo影片:https://asciinema.org/a/179047


Docker Engine怎麼辦?

“切換到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不會看到和進入對方的建立的容器和映象。這是為了不讓二者互相干擾。也意味著:
  • 使用者將不能使用docker ps命令檢視到Kubernetes建立的容器。請使用crictl ps替代。反之亦然。使用者不能使用crictl ps命令檢視到Docker CLI建立的融洽。crictl create和crictl runp命令只用於故障排除。不建議手動在生產環境下的nodes上使用crictl on來啟動pod或容器。

  • 使用者不能使用docker images命令檢視到Kubernetes拉取的映象。請使用crictl images命令替代。反之亦然,Kubernetes看不到docker pull,docker load或docker build建立的映象。請使用crictl pull命令替代,如果你需要載入一個映象請使用ctr cri load。


Summary

  • 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
相關連結:
  1. https://kubernetes.io/blog/2017/11/containerd-container-runtime-options-kubernetes

  2. https://github.com/containerd/containerd/releases/tag/v1.1.0

  3. https://k8s-testgrid.appspot.com/sig-node-containerd

  4. https://github.com/kubernetes/community/blob/master/contributors/devel/e2e-node-tests.md

  5. http://node-perf-dash.k8s.io/

  6. https://github.com/kubernetes-incubator/cri-tools

  7. https://github.com/kubernetes-incubator/cri-tools/releases/tag/v1.0.0-beta.1

  8. https://www.ianlewis.org/en/almighty-pause-container

原文連結:https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/

Kubernetes入門與進階實戰培訓

本次培訓內容包括:Docker基礎、容器技術、Docker映象、資料共享與持久化、Docker三駕馬車、Docker實踐、Kubernetes基礎、Pod基礎與進階、常用物件操作、服務發現、Helm、Kubernetes核心元件原理分析、Kubernetes服務質量保證、排程詳解與應用場景、網路、基於Kubernetes的CI/CD、基於Kubernetes的配置管理等,點選瞭解具體培訓內容
6月22日正式上課,點選閱讀原文連結即可報名。
贊(0)

分享創造快樂