本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

Kubernetes Containerd 整合進入 GA 階段

作者：Lantao Liu (Google), Mike Brown (IBM) |

Kubernetes Containerd 整合進入 GA 階段

在之前的部落格《Containerd 為 Kubernetes 帶來更多容器執行時選項》中，我們介紹了 Kubernetes containerd 整合的 Alpha 版本。經過 6 個月的開發，與 containerd 的整合現在已正式釋出！您現在可以將 containerd 1.1 作為生產 Kubernetes 叢集的容器執行時！

Containerd 1.1 可與 Kubernetes 1.10 及更高版本配合使用，並支援所有 Kubernetes 功能。在 Kubernetes 測試基礎設施中，containerd 整合在 Google Cloud Platform 上的測試覆蓋率現在與 Docker 整合相當（參見：測試儀表板）。

我們很高興看到 containerd 迅速發展到這一重要里程碑。阿里雲從第一天起就積極使用 containerd，憑藉其簡單性和健壯性，使其成為我們 Serverless Kubernetes 產品中執行的完美容器引擎，該產品對效能和穩定性有很高的要求。毫無疑問，containerd 將成為容器時代的核心引擎，並繼續推動創新向前發展。

— 欣慰，阿里雲高階工程師

架構改進

Kubernetes containerd 整合架構已演進兩次。每次演進都使堆疊更加穩定和高效。

Containerd 1.0 - CRI-Containerd (已停止維護)

cri-containerd architecture

對於 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 外掛 (當前)

containerd architecture

在 containerd 1.1 中，cri-containerd 守護程式現在被重構為 containerd CRI 外掛。CRI 外掛內置於 containerd 1.1 中，並預設啟用。與 cri-containerd 不同，CRI 外掛透過直接函式呼叫與 containerd 互動。這種新架構使整合更加穩定和高效，並消除了堆疊中另一個 grpc 跳數。使用者現在可以直接使用 Kubernetes 和 containerd 1.1。不再需要 cri-containerd 守護程式。

效能

提高效能是 containerd 1.1 版本的主要關注點之一。效能在 Pod 啟動延遲和守護程式資源使用方面進行了最佳化。

以下結果是 containerd 1.1 和 Docker 18.03 CE 之間的比較。containerd 1.1 整合使用內置於 containerd 的 CRI 外掛；Docker 18.03 CE 整合使用 dockershim。

這些結果是使用 Kubernetes 節點效能基準測試生成的，該基準測試是 Kubernetes 節點 e2e 測試的一部分。大多數 containerd 基準測試資料都可以在 節點效能儀表板上公開訪問。

Pod 啟動延遲

“105 個 Pod 批次啟動基準測試”結果顯示，containerd 1.1 整合比帶有 dockershim 的 Docker 18.03 CE 整合具有更低的 Pod 啟動延遲（越低越好）。

latency

CPU 和記憶體

在穩定狀態下，執行 105 個 Pod 時，與帶有 dockershim 的 Docker 18.03 CE 整合相比，containerd 1.1 整合總體消耗的 CPU 和記憶體更少。結果因節點上執行的 Pod 數量而異，選擇 105 是因為它是目前每個節點最大使用者 Pod 數量的預設值。

如下圖所示，與使用 dockershim 的 Docker 18.03 CE 整合相比，containerd 1.1 整合使 kubelet CPU 使用率降低 30.89%，容器執行時 CPU 使用率降低 68.13%，kubelet 常駐集大小 (RSS) 記憶體使用率降低 11.30%，容器執行時 RSS 記憶體使用率降低 12.78%。

cpumemory

crictl

容器執行時命令列介面 (CLI) 是系統和應用程式故障排除的有用工具。當使用 Docker 作為 Kubernetes 的容器執行時時，系統管理員有時會登入到 Kubernetes 節點，執行 Docker 命令以收集系統和/或應用程式資訊。例如，可以使用 docker ps 和 docker inspect 檢查應用程式程序狀態，使用 docker images 列出節點上的映象，使用 docker info 識別容器執行時配置等。

對於 containerd 和所有其他 CRI 相容的容器執行時（例如 dockershim），我們建議使用 crictl 作為 Docker CLI 的替代 CLI，用於 Kubernetes 節點上的 Pod、容器和容器映象故障排除。

crictl 是一個工具，為 Kubernetes 節點故障排除提供類似於 Docker CLI 的體驗，並且 crictl 在所有 CRI 相容的容器執行時中始終如一地工作。它託管在 kubernetes-incubator/cri-tools 儲存庫中，當前版本是 v1.0.0-beta.1。crictl 的設計旨在類似於 Docker CLI，為使用者提供更好的過渡體驗，但它並不完全相同。有一些重要的區別，如下所述。

有限範圍 - crictl 是一個故障排除工具

crictl 的範圍僅限於故障排除，它不能替代 docker 或 kubectl。Docker 的 CLI 提供了豐富的命令集，使其成為一個非常有用的開發工具。但它不是 Kubernetes 節點上故障排除的最佳選擇。一些 Docker 命令對 Kubernetes 沒有用處，例如 docker network 和 docker build；有些甚至可能破壞系統，例如 docker rename。crictl 提供了足夠多的命令用於節點故障排除，這在生產節點上使用可以說更安全。

Kubernetes 導向

crictl 提供了更友好的 Kubernetes 容器檢視。Docker CLI 缺乏核心 Kubernetes 概念，例如 pod 和 namespace，因此它無法提供清晰的容器和 Pod 檢視。一個例子是 docker ps 顯示了一些晦澀的、長長的 Docker 容器名稱，並且將 pause 容器和應用程式容器一起顯示。

docker ps

然而，pause 容器是 Pod 的實現細節，每個 Pod 使用一個 pause 容器，因此在列出屬於 Pod 的容器時，不應顯示它們。

相比之下，crictl 專為 Kubernetes 設計。它為 Pod 和容器提供了不同的命令集。例如，crictl pods 列出 Pod 資訊，而 crictl ps 僅列出應用程式容器資訊。所有資訊都以表格列的形式良好格式化。

crictl pods crictl ps

另一個例子是，crictl pods 包含一個 --namespace 選項，用於根據 Kubernetes 中指定的名稱空間過濾 Pod。

crictl pods filter

有關如何將 crictl 與 containerd 結合使用的更多詳細資訊

Docker Engine 呢？

“切換到 containerd 意味著我不能再使用 Docker Engine 了嗎？”我們經常聽到這個問題，簡短的答案是“不”。

Docker Engine 構建在 containerd 之上。Docker Community Edition (Docker CE) 的下一個版本將使用 containerd 1.1 版本。當然，它將內建並預設啟用 CRI 外掛。這意味著使用者可以選擇繼續將 Docker Engine 用於 Docker 使用者典型的其他目的，同時還可以配置 Kubernetes 以使用與 Docker Engine 在同一節點上附帶並同時使用的底層 containerd。請參見下面的架構圖，其中顯示了 Docker Engine 和 Kubelet 使用相同的 containerd。

docker-ce

由於 Kubelet 和 Docker Engine 都使用 containerd，這意味著選擇 containerd 整合的使用者不僅可以獲得新的 Kubernetes 功能、效能和穩定性改進，還可以選擇保留 Docker Engine 用於其他用例。

Containerd 名稱空間機制用於保證 Kubelet 和 Docker Engine 不會看到或訪問彼此建立的容器和映象。這確保它們不會相互干擾。這也意味著

  • 使用者將無法使用 docker ps 命令檢視 Kubernetes 建立的容器。請改用 crictl ps。反之亦然，使用者將無法在 Kubernetes 中或使用 crictl ps 命令檢視 Docker CLI 建立的容器。crictl create 和 crictl runp 命令僅用於故障排除。不建議在生產節點上手動使用 crictl 啟動 Pod 或容器。
  • 使用者將無法使用 docker images 命令檢視 Kubernetes 拉取的映象。請改用 crictl images 命令。反之亦然，Kubernetes 將無法檢視由 docker pull、docker load 或 docker build 命令建立的映象。請改用 crictl pull 命令，如果您必須載入映象，請使用 ctr cri load。

總結

  • Containerd 1.1 原生支援 CRI。它可以直接被 Kubernetes 使用。
  • Containerd 1.1 已達到生產就緒狀態。
  • Containerd 1.1 在 Pod 啟動延遲和系統資源利用方面表現出良好的效能。
  • crictl 是與 containerd 1.1 及其他符合 CRI 標準的容器執行時進行節點故障排除的 CLI 工具。
  • Docker CE 的下一個穩定版本將包含 containerd 1.1。使用者可以選擇繼續使用 Docker 處理非 Kubernetes 特定的用例，並配置 Kubernetes 以使用 Docker 附帶的相同底層 containerd。

我們衷心感謝來自 Google、IBM、Docker、中興、浙大以及許多其他為實現這一目標做出貢獻的個人！

有關 containerd 1.1 版本中更改的詳細列表，請參閱此處釋出的說明：https://github.com/containerd/containerd/releases/tag/v1.1.0

立即試用

使用 containerd 作為容器執行時設定 Kubernetes 叢集

  • 對於使用 kube-up.sh 在 GCE 上搭建的生產級叢集，請參閱此處。
  • 對於使用 Ansible 和 kubeadm 的多節點叢集安裝程式和搭建步驟，請參閱此處。
  • 要在 Google Cloud 上從頭建立叢集，請參閱Kubernetes the Hard Way。
  • 對於從釋出 tarball 進行自定義安裝，請參閱此處。
  • 要在本地虛擬機器上使用 LinuxKit 進行安裝，請參閱此處。

貢獻

containerd CRI 外掛是 containerd 中的一個開源 github 專案 https://github.com/containerd/cri。歡迎提出任何想法、問題和/或修復方面的貢獻。開發者入門指南是貢獻者入門的好地方。

社群

該專案由 Kubernetes SIG-Node 社群和 containerd 社群的成員共同開發和維護。我們很樂意聽取您的反饋。加入社群