Kubernetes 網絡模型的核心要求之一是每個 Pod 都擁有自己的 IP 地址并可以使用該 IP 地址進行通信。很多人剛開始使用 Kubernetes 時，還不清楚如何為每個 Pod 分配 IP 地址。他們了解各種組件如何獨立工作，但不清楚這些組件如何組合在一起使用。例如，他們了解什么是 CNI 插件，但是不知道它們是如何被調用的。本文就介紹了各種網絡組件在 Kubernetes 集群中是如何交互的，以及如何幫助每個 Pod 都獲取 IP 地址。

在 Kubernetes 中有多種網絡設置方法，以及 container runtime 的各種選項。這篇文章將使用 Flannel 作為network provider，并使用 Containered 作為 container runtime。

背景概念

容器網絡 同一主機上的容器 在同一主機上運行的容器通過 IP 地址相互通信的方法之一是使用 Linux Bridge，即在 Kubernetes（和 Docker）世界中，創建 veth（虛擬以太網）設備。該 veth 設備的一端連接在容器網絡命名空間，另一端連接到主機網絡上的 Linux Bridge。同一主機上的所有容器都將這 veth pair 的一端連接到 Linux Bridge，它們可以通過 Bridge 使用 IP 地址相互通信。Linux Bridge 也被分配了一個 IP 地址，它充當從目的地到不同節點的 Pod 流出流量的網關。

不同主機上的容器 在不同主機上運行的容器可以通過其 IP 地址相互通信的方式之一是使用數據包封裝（packet encapsulation）。Flannel 通過 vxlan 使用該功能，vxlan 將原始數據包封裝在 UDP 數據包中并將其發送到目的地。 在 Kubernetes 集群中，Flannel 會在每個節點上創建一個 vxlan 設備和一些路由表。每個發往不同主機上的容器的數據包都會通過 vxlan 設備，并封裝在 UDP 數據包中。在目標位置，它會提取封裝的數據包，然后將數據包路由到目的地 Pod。

注意：這只是配置容器之間網絡的方法之一。

CRI CRI（容器運行時接口）是一個插件接口，允許 kubelet 使用不同的 container runtimes。各種 container runtimes 都實現了 CRI API，這使用戶可以在 Kubernetes 安裝中使用他們想要的 container runtimes。 CNI

CNI（容器網絡接口）項目包含一個為 Linux 容器提供基于通用插件網絡解決方案的規則。它由各種插件組成，這些插件在配置 Pod 網絡時執行不同的功能。CNI 插件是遵循 CNI 規范的可執行文件。

為節點子網分配 Pod IP 地址

如果要求所有 Pod 具有 IP 地址，那么就要確保整個集群中的所有 Pod 的 IP 地址是唯一的。這可以通過為每個節點分配一個唯一的子網來實現，即從子網中為 Pod 分配節點 IP 地址。

節點 IPAM 控制器 當nodeipam傳遞給 kube-controller-manager 的--controllers命令行標志時，它將為每個節點分配來自集群 CIDR（集群網絡的 IP 范圍）的專用子網（podCIDR）。由于這些 podCIDR 是不相交的子網，因此它可以為每個 Pod 分配唯一的 IP 地址。 當 Kubernetes 節點首次在集群上注冊時，會被分配一個 podCIDR。要更改分配給集群中節點的 podCIDR，需要先注銷節點，然后使用應用于 Kubernetes 控制平面的任何配置更改來重新注冊節點。podCIDR可以使用以下命令列出節點的名稱：

Kubelet、Container Runtime 和 CNI 插件交互

當在節點上調度 Pod 時，一啟動 Pod 就會發生很多事情。這里我們僅關注與 Pod 配置網絡有關的動態。一旦在節點上調度了 Pod，將配置網絡并啟動應用程序容器。

參考：容器式 cri 插件架構 Container Runtime 與 CNI 插件的交互 每個 network provider 都有一個 CNI 插件，container runtime 會調用該插件，在 Pod 啟動時配置網絡。使用容器化作為 container runtime，容器化 CRI 插件將調用 CNI 插件。每個 network provider 都在每個 Kubernetes 節點上安裝了一個代理，以配置 Pod 網絡。安裝 network provider agent 后，它會隨 CNI 一起配置或者在節點上創建，CRI 插件會使用它來確定要調用哪個 CNI 插件。 CNI 配置文件的位置是可配置的，默認值為/etc/cni/net.d/。集群管理員需要在每個節點上交付 CNI 插件。CNI 插件的位置也是可配置的，默認值為/opt/cni/bin。 如果使用 containerd 作為 container runtime，則可以在 containerd config 部分下[plugins."io.containerd.grpc.v1.cri".cni]指定 CNI 配置和 CNI 插件的路徑。 本文中我們將 Flannel 作為 network provider，這里簡單介紹一下 Flannel 的設置。Flanneld 是 Flannel 守護程序，通常 install-cni 作為帶有初始化容器的守護程序安裝在 Kubernetes 集群上。install-cni 容器創建 CNI 配置文件在每個節點上/etc/cni/net.d/10-flannel.conflist。Flanneld 創建一個 vxlan 設備，從 apiserver 獲取網絡元數據，并監控 Pod 上的更新。創建 Pod 時，它將在整個集群中為所有 Pod 分配路由，這些路由允許 Pod 通過 IP 地址相互連接。 Containerd CRI 插件和 CNI 插件之間的交互可以如下所示：

如上所述，kubelet 調用 Containered CRI 插件創建容器，再調用 CNI 插件為容器配置網絡。Network provider CNI 插件調用其他基本 CNI 插件來配置網絡。CNI 插件之間的交互如下所述。 CNI 插件之間的交互 有多種 CNI 插件可幫助配置主機上容器之間的網絡，本文主要討論以下 3 個插件。 Flannel CNI 插件 當使用 Flannel 作為network provider時，Containered CRI 插件使用 CNI 配置文件，調用 Flannel CNI 插件：/etc/cni/net.d/10-flannel.conflist。

Fannel CNI 插件與 Flanneld 結合使用，當 Flanneld 啟動時，它將從 apiserver 中獲取 podCIDR和其他與網絡相關的詳細信息，并將它們存儲在文件中/run/flannel/subnet.env。

Flannel CNI 插件使用/run/flannel/subnet.env的信息來配置和調用 Bridge CNI 插件。 Bridge CNI 插件 Flannel CNI 插件使用以下配置調用 Bridge CNI 插件：

當 Bridge CNI 插件第一次調用時，它會創建一個 Linux Bridge"name": "cni0"在配置文件中，然后為每個 Pod 創建 veth pair，其一端在容器的網絡命名空間中，另一端連接到主機網絡上的 Linux Bridge。使用 Bridge CNI 插件，主機上的所有容器都連接到主機網絡上的 Linux Bridge。 配置完 veth pair 后，Bridge 插件將調用主機本地 IPAM CNI 插件。我們可以在 CNI config 中配置要使用的 IPAM 插件，CRI 插件用于調用 Flannel CNI插件。 主機本地 IPAM CNI 插件 Bridge CNI 插件使用以下配置調用主機本地 IPAM CNI 插件：

主機本地 IPAM（IP 地址管理）插件從中返回容器的 IP 地址，subnet將分配的 IP 本地存儲在主機下dataDir指定的目錄中 /var/lib/cni/networks// /var/lib/cni/networks//文件包含 IP 分配到的容器 ID。 調用時，主機本地 IPAM 插件返回以下有效負載：

總結

Kube-controller-manager 為每個節點分配一個 podCIDR。從 podCIDR 中的子網值為節點上的 Pod 分配了 IP 地址。由于所有節點上的 podCIDR 是不相交的子網，因此它允許為每個 pod 分配唯一的IP地址。

Kubernetes 集群管理員可配置和安裝 kubelet、container runtime、network provider，并在每個節點上分發 CNI 插件。Network provider agent 啟動時，將生成 CNI 配置。在節點上調度 Pod 后，kubelet 會調用 CRI 插件來創建 Pod。在容器情況下，容器的 CRI 插件調用 CNI 配置中指定的 CNI 插件來配置 Pod 網絡。所有這些都會影響 Pod 獲取 IP地址。