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

Kubernetes Containerd 整合正式發佈

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

Kubernetes Containerd 整合正式發佈

在之前的部落格 - Containerd 為 Kubernetes 帶來更多容器運行時選項 中，我們介紹了 Kubernetes containerd 整合的 alpha 版本。經過 6 個月的開發，containerd 的整合現在已正式發布！您現在可以使用 containerd 1.1 作為生產 Kubernetes 叢集的容器運行時！

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

我們很高興看到 containerd 迅速成長到這個重要的里程碑。阿里巴巴雲自第一天起就開始積極使用 containerd，並感謝它的簡潔性和強健性，使其成為我們無伺服器 Kubernetes 產品中運行的完美容器引擎，該產品在效能和穩定性方面具有很高的資質。毫無疑問，containerd 將成為容器時代的核心引擎，並繼續推動創新向前發展。

— 阿里巴巴雲資深工程師 Xinwei

架構改進

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 仍然是 2 個不同的守護程序，它們透過 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 和 命名空間，因此它無法提供容器和 Pod 的清晰視圖。一個範例是 docker ps 顯示有些模糊、冗長的 Docker 容器名稱，並將暫停容器和應用程式容器一起顯示

docker ps

然而，暫停容器 是一個 Pod 實作細節，其中每個 Pod 使用一個暫停容器，因此在列出作為 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。請參閱下方的架構圖，其中顯示了 Kubelet 和 Docker Engine 使用相同的 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 命令僅用於疑難排解。不建議在生產節點上手動啟動 Pod 或容器與 crictl。
  • 使用者不會使用 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、ZTE、ZJU 和許多其他個人的所有貢獻者，他們使這一切成為可能！

有關 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 在本機 VM 上安裝，請參閱此處。

貢獻

containerd CRI 外掛程式是 containerd 內的開放原始碼 github 專案 https://github.com/containerd/cri。歡迎任何關於想法、問題和/或修復的貢獻。開發人員入門指南 是貢獻者入門的好地方。

社群

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