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

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)

分享創造快樂