一文搞懂Kubernetes容器運行原理

作者：Luga Lee 2023-09-22 10:45:47

今天我們來分享一下與云原生體系有關的話題- 云原生技術-Container。作為一個“核心”要素之一，容器技術在云原生生態中發揮著重要的意義。

1.Kubernetes容器概述

容器能夠有效地虛擬化主機操作系統（或內核）并將應用程序的依賴項與同一臺機器上運行的其他容器隔離開。在容器出現之前，在同一個虛擬機 (VM) 上部署了多個應用程序，共享依賴項的任何更改都可能導致奇怪的事情發生，從而導致排障較為困難。

容器主要通過兩個部分解決這個問題：容器引擎和容器鏡像，容器鏡像是應用程序及其依賴項的包。容器引擎在容器中運行應用程序，將其與主機上運行的其他應用程序隔離開來。這樣就無需為每個應用程序運行單獨的操作系統，從而提高資源利用率并降低成本。

當我們開始學習 Kubernetes 時，我們并不完全清楚每個 Pod 是如何分配 IP 地址以及微服務容器化后是如何正常工作。或許，我們可能或多或少了解各個組件的概念以及它們是如何獨立工作。但是，在特定的環境下可能不清楚這些組件是如何關聯起來。例如，我們知道什么是 CNI 插件，然而，卻不理解 Kubernetes 所涉獵的組件之間是如何相互調用。因此，基于對各種核心組件的了解，以及它們如何在 Kubernetes 集群中拼接在一起，以便使得每個 Container 能夠基于其所設定的環境變量正確運行，在實際的業務環境中進行有效維護便顯得尤為重要。

在當前的 Kubernetes 生態體系中有多種網絡解決方案以及容器運行時環境的各種選項。在本文中，筆者將試圖從整個 Kubernetes 編排架構角度來闡述 Container 容器運行的基本原理，以使得大家能夠更深入理解容器生態體系相關知識。

2.CRI（容器運行時接口）架構

CRI（Container Runtime Interface）是一個插件接口，允許 Kubelet 使用不同的容器運行時。各種容器運行時實現了 CRI API，這允許用戶在他們的 Kubernetes 安裝中使用他們選擇的容器運行時。

我們先簡要了解一下 Containerd 的 CRI 插件架構。

CRI 插件是 Kubernetes 容器運行時接口 (CRI) 的實現。Containerd 與 Kubelet 在同一節點上運行，Containerd 內部的 CRI 插件處理來自 Kubelet 的所有 CRI 服務請求，并使用 Containerd 內部結構來管理容器和容器鏡像。

CRI 插件使用 Containerd 來管理整個容器生命周期和所有容器鏡像。如下所示，CRI 通過 CNI（容器網絡接口）管理 Pod 網絡。

基于上述結構圖，讓我們梳理下 CRI 插件如何基于 Kubelet 創建容器并運行 Pod 過程：

1、Kubelet 通過 CRI 運行時服務 API 調用 CRI 插件來創建 Pod。

2、CRI 使用 Containerd Internal 來創建和啟動一個特殊的沙箱容器，并將該容器放在 Pod 的 Cgroups 和 NameSpace 命名空間中。

3、CRI 使用 CNI 配置 Pod 的網絡命名空間。

4、Kubelet 隨后通過 CRI 鏡像服務 API 調用 CRI 插件來拉取應用容器鏡像。若鏡像不存在于節點上，CRI 便進一步使用 Containerd 來拉取鏡像。

5、Kubelet 然后通過 CRI 運行時服務 API 調用 CRI，使用拉取的容器鏡像在 Pod 內創建和啟動應用程序容器。

6、CRI 使用 Containerd Internal 創建應用容器，將其放入 Pod 的 Cgroups 和 NameSpace 中，然后啟動 Pod 的新應用容器。在這些步驟之后，一個 Pod 及其相應的應用程序容器被創建并運行。

3.CNI（容器網絡接口）架構

作為另一個 CNCF 項目，CNI（容器網絡接口）也是一個云原生計算基金會項目，由用在 Linux 容器中配置網絡接口的規范和庫以及許多受支持的插件組成。CNI 只關心容器的網絡連接和刪除容器時刪除分配的資源。正因為如此，CNI 的支持范圍很廣，規范也很容易實現，為 Linux 容器提供基于插件的通用網絡解決方案。

通常來講，CNI 被容器運行時 CR 使用，例如 Kubernetes、Podman、CRI-O 、rkt 、Openshift、Cloud Foundry、Amazon ECS、Singularity、OpenSVC 以及 Mesos 等等。Container 或 Pod 本身最初并不具備網絡接口，容器運行時使用 ADD、DEL、CHECK 等操作命令調用 CNI 插件。例如，ADD 為容器創建一個新的網絡接口，并將要添加的內容的詳細信息通過 JSON 有效地傳遞給 CNI。

那么，通常如何在 Kubernetes 中使用 CNI ？一般來講，主要根據 CNI 配置文件以確定選用哪種 CNI 插件，具體如下所示：

1、在每個節點上配置 CNI 文件（/etc/cni/net.d/xxnet.conf），其中 xxnet.conf表示網絡配置文件的名稱。

2、基于 CNI 配置文件中進行二進制插件的安裝部署。

3、在節點上創建 Pod 后，Kubelet 會根據 CNI 配置文件運行前兩步安裝的 CNI 插件。

4、基于上述進行 Pod 網絡配置。

4.CRI 與 CNI 交互模型

每個網絡提供者都有一個 CNI 插件，容器運行時會調用其來為 Pod 啟動時配置網絡。若基于 Containerd 作為容器運行時，Containerd CRI 插件調用 CNI 插件。每個網絡提供商也有一個安裝在每個 Kubernetes 節點上的代理，用于配置 Pod 網絡。安裝網絡提供程序代理后，它要么隨 CNI 配置一起提供，要么在節點上創建一個，然后 CRI 插件使用該代理來確定要調用哪個 CNI 插件。

CNI 配置文件的位置是可配置的，默認值為 /etc/cni/net.d/<config-file>。集群管理員需要在每個節點上提供 CNI 插件。CNI 插件的位置也是可配置的，默認值為 /opt/cni/bin。

如果將 Containerd 作為容器運行時，可以在 Containerd 配置的 [plugins."io.containerd.grpc.v1.cri".cni] 部分下指定 CNI 配置和 CNI 插件二進制文件的路徑。我們以 Flannel 網絡方案為例，Flanneld 是 Flannel 守護進程，通常作為守護進程安裝在 kubernetes 集群上，使用 install-cni 作為初始化容器。install-cni 容器在每個節點上創建 CNI 配置文件 - /etc/cni/net.d/10-flannel.conflist。 Flanneld 創建一個 Vxlan 設備，從 Api Server 獲取網絡元數據并監視 Pod 上的更新。創建 Pod 時，它會為整個集群中的所有 Pod 分配路由，這些路由允許 Pod 通過其 IP 地址相互連接。

Containerd CRI Plugin 和 CNI Plugin 之間的交互模型，如下圖所示：