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

Containerd 為 Kubernetes 帶來更多容器執行階段選項

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

更新：Kubernetes 透過 dockershim 對 Docker 的支援現在已被棄用。如需更多資訊，請閱讀棄用通知。您也可以透過專用的 GitHub issue 討論棄用事宜。

容器執行期是一種軟體，可在節點上執行容器並管理容器映像。今天，最廣為人知的容器執行期是 Docker，但生態系統中還有其他容器執行期，例如 rkt、containerd 和 lxd。Docker 是迄今為止在生產 Kubernetes 環境中最常用的容器執行期，但 Docker 較小的分支 containerd 可能證明是更好的選擇。這篇文章描述了將 containerd 與 Kubernetes 一起使用。

Kubernetes 1.5 引入了一個名為 容器執行期介面 (CRI) 的內部外掛程式 API，以提供對不同容器執行期的輕鬆存取。CRI 使 Kubernetes 能夠使用各種容器執行期，而無需重新編譯。理論上，Kubernetes 可以使用任何實作 CRI 的容器執行期來管理 Pod、容器和容器映像。

在過去 6 個月中，來自 Google、Docker、IBM、中興通訊和浙江大學的工程師一直致力於為 containerd 實作 CRI。該專案稱為 cri-containerd，其 功能完整的 v1.0.0-alpha.0 版本於 2017 年 9 月 25 日發布。透過 cri-containerd，使用者可以使用 containerd 作為底層執行期來執行 Kubernetes 叢集，而無需安裝 Docker。

containerd

Containerd 是一個 OCI 相容的核心容器執行期，旨在嵌入到更大的系統中。它提供執行容器和管理節點上映像的最小功能集。它由 Docker Inc. 發起，並於 2017 年 3 月 捐贈給 CNCF。Docker 引擎本身建立在早期版本的 containerd 之上，並將很快更新到最新版本。Containerd 接近功能完整的穩定版本，1.0.0-beta.1 版本現在即可使用。

Containerd 的範圍比 Docker 小得多，提供 golang 用戶端 API，並且更專注於可嵌入性。較小的範圍導致程式碼庫更小，隨著時間的推移更容易維護和支援，符合 Kubernetes 的需求，如下表所示

Containerd 範圍 (包含/排除)Kubernetes 需求
容器生命週期管理包含容器建立/啟動/停止/刪除/列出/檢查 (✔️)
映像管理包含提取/列出/檢查 (✔️)
網路排除 無具體網路解決方案。使用者可以設定網路命名空間並將容器放入其中。Kubernetes 網路處理 Pod，而不是容器，因此容器執行期不應提供不滿足需求的複雜網路解決方案。(✔️)
磁碟區排除，無磁碟區管理。使用者可以設定主機路徑，並將其掛載到容器中。Kubernetes 管理磁碟區。容器執行期不應提供可能與 Kubernetes 衝突的內部磁碟區管理。(✔️)
持久容器日誌記錄排除，無持久容器日誌。容器 STDIO 作為 FIFO 提供，可以根據需要重新導向/裝飾。Kubernetes 對持久容器日誌有特定要求，例如格式和路徑等。容器執行期不應持久化無法管理的容器日誌。(✔️)
指標包含 Containerd 提供容器和快照指標作為 API 的一部分。Kubernetes 期望容器執行期提供容器指標 (CPU、記憶體、可寫入層大小等) 和映像檔案系統使用量 (磁碟、Inode 使用量等)。(✔️)
總體而言，從技術角度來看，containerd 是 Kubernetes 非常好的替代容器執行期。

cri-containerd

Cri-containerd 正是如此：containerd 的 CRI 實作。它與 Kubelet 和 containerd 在同一個節點上運作。cri-containerd 位於 Kubernetes 和 containerd 之間，處理來自 Kubelet 的所有 CRI 服務請求，並使用 containerd 管理容器和容器映像。Cri-containerd 部分透過形成 containerd 服務請求來管理這些服務請求，同時新增足夠的額外功能來支援 CRI 需求。

與目前的 Docker CRI 實作 (dockershim) 相比，cri-containerd 消除了堆疊中的額外躍點，使堆疊更穩定且更有效率。

架構

Cri-containerd 使用 containerd 管理完整的容器生命週期和所有容器映像。如下所示，cri-containerd 也透過 CNI (另一個 CNCF 專案) 管理 Pod 網路。

讓我們使用一個範例來說明當 Kubelet 建立單容器 Pod 時，cri-containerd 如何運作

  1. Kubelet 透過 CRI 執行期服務 API 呼叫 cri-containerd 以建立 Pod；
  2. cri-containerd 使用 containerd 建立並啟動特殊的 pause 容器 (sandbox 容器)，並將該容器放入 Pod 的 cgroup 和命名空間中 (步驟為簡潔起見已省略)；
  3. cri-containerd 使用 CNI 設定 Pod 的網路命名空間；
  4. Kubelet 隨後透過 CRI 映像服務 API 呼叫 cri-containerd 以提取應用程式容器映像；
  5. 如果映像在節點上不存在，cri-containerd 會進一步使用 containerd 提取映像；
  6. 然後 Kubelet 透過 CRI 執行期服務 API 呼叫 cri-containerd，以使用提取的容器映像在 Pod 內建立並啟動應用程式容器；
  7. cri-containerd 最終呼叫 containerd 以建立應用程式容器，將其放入 Pod 的 cgroup 和命名空間中，然後啟動 Pod 的新應用程式容器。完成這些步驟後，Pod 及其對應的應用程式容器即已建立並執行中。

狀態

Cri-containerd v1.0.0-alpha.0 已於 2017 年 9 月 25 日發布。

它具有完整的功能。支援所有 Kubernetes 功能。

所有 CRI 驗證測試 都已通過。(CRI 驗證是一個測試框架，用於驗證 CRI 實作是否滿足 Kubernetes 期望的所有需求。)

所有常規 節點 e2e 測試 都已通過。(用於測試 Kubernetes 節點級別功能的 Kubernetes 測試框架，例如管理 Pod、掛載磁碟區等。)

若要深入瞭解 v1.0.0-alpha.0 版本，請參閱專案儲存庫。

試用看看

對於使用 ansible 和 kubeadm 的多節點叢集安裝程式和啟動步驟，請參閱此儲存庫連結。

對於在 Google Cloud 上從頭開始建立叢集，請參閱Kubernetes the Hard Way。

對於從發布 tarball 進行自訂安裝，請參閱此儲存庫連結。

對於在本地 VM 上使用 LinuxKit 進行安裝，請參閱此儲存庫連結。

後續步驟

我們的後續步驟將專注於穩定性和可用性改進。

  • 穩定性

    • 在 Kubernetes 測試基礎架構上，針對各種作業系統發行版 (例如 Ubuntu、COS (Container-Optimized OS) 等) 建立完整的 Kubernetes 整合測試。
    • 主動修復使用者報告的任何測試失敗和其他問題。

  • 可用性

    • 改善 crictl 的使用者體驗。Crictl 是適用於所有 CRI 容器執行期的可攜式命令列工具。此處的目標是使其易於在偵錯和開發情境中使用。
    • 將 cri-containerd 與 kube-up.sh 整合，以協助使用者使用 cri-containerd 和 containerd 啟動生產品質的 Kubernetes 叢集。
    • 改善我們針對使用者和管理員的文件。

我們計劃在 2017 年底之前發布 v1.0.0-beta.0 版本。

貢獻

Cri-containerd 是一個 Kubernetes 孵化器專案，位於 https://github.com/kubernetes-incubator/cri-containerd。歡迎任何關於想法、問題和/或修復的貢獻。開發人員入門指南是貢獻者的良好起點。

社群

Cri-containerd 由 Kubernetes SIG-Node 社群開發和維護。我們很樂意聽取您的意見回饋。若要加入社群