本文檔描述了 Google Kubernetes Engine (GKE) 使用的網路模型，以及它與其他 Kubernetes 環境中的網路模型有何不同。本文檔介紹了以下概念：
各種 Kubernetes 實現使用的最常見網路模型。
最常見的網路模型的 IP 位址機制。
每種網路模型的優缺點。
GKE 使用的預設網路模型的詳細說明。
典型的網路模型實現
您可以通過各種方式實現 Kubernetes 網路模型。但是，任何實現都始終需要滿足以下要求：
每個 Pod 都需要唯一的 IP 位址。
Pod 無需使用 NAT 即可與所有節點上的其他 Pod 通信。
節點上的代理（例如 kubelet）可以與該節點上的所有 Pod 通信。
節點託管網路上的 Pod 可與所有節點上的所有 Pod 通信，而無需使用 NAT。
有 20 多種不同的 Kubernetes 網路模型實現可以滿足這些要求。
這些實現可以分為三種類型的網路模型。這三種模型的不同體現在以下方面：
Pod 如何與公司網路上的非 Kubernetes 服務通信。
Pod 如何與同一組織中的其他 Kubernetes 集群通信。
集群外部的通信是否需要 NAT。
Pod IP 位址是否可以在其他集群或企業網路中的其他位置重複使用。
每種成熟的雲都實現了上述一個或多個模型類型。
下表列出了三種常用的模型類型，以及使用這些模型的 Kubernetes 實現：
本文檔在介紹這些網路模型時會說明其對連接的本地網路的影響。但是，您可以將針對連接的本地網路描述的概念應用於通過虛擬私人網路 (VPN) 或專用互連（包括與其他雲提供商的連接）連接的網路。對於 GKE，這些連接包括通過 Cloud VPN 或 Cloud Interconnect 的所有連接。
完全集成的網路模型
完全集成的網路（或平面）模型可讓您輕鬆地與 Kubernetes 外部以及其他 Kubernetes 集群中的應用進行通信。主要的雲服務提供者通常會實現此模型，因為這些提供商可以將其 Kubernetes 實現與其軟體定義網路 (SDN) 緊密集成。
使用完全集成的模型時，用於 Pod 的 IP 位址會在 Kubernetes 集群所在的網路中路由。此外，底層網路知道 Pod IP 位址位於哪個節點上。在許多實現中，同一節點上的 Pod IP 位址來自預先分配的特定 Pod IP 位址範圍。但是，此預先分配的地址範圍不是必需的。
下圖展示了完全集成的網路模型中的 Pod 通信選項：
上面的完全集成的網路模型圖表顯示了以下通信模式：
Kubernetes 集群中的 Pod 可以直接相互通信。
Pod 可以與其他集群中的其他 Pod 通信，前提是這些集群位於同一網路中。
Pod 不需要 NAT 即可與集群外部的其他應用進行通信，無論這些應用是位於同一網路還是互連的網路中。
該圖還顯示，不同集群的 Pod IP 位址範圍也不同。
完全集成的網路模型可用於以下實現：
預設情況下，GKE 會實現此模型。如需詳細瞭解此實現，請參閱本文檔後面的 GKE 網路模型。
預設情況下，Amazon EKS 會實現此模型。在此實現中，Amazon EKS 使用適用於 Kubernetes 的 Amazon VPC Container Networking 介面 (CNI) 外掛程式直接從 VPC 位址空間分配 Pod IP 地址。CNI 外掛程式從節點所在的默認子網或自訂子網分配 IP 地址。Pod IP 位址並非來自每個節點的專用 Pod IP 位址範圍。
在 Azure 中，AKS 在使用 Azure CNI（高級網路）時實現此模型。此實現不是預設配置。在此實現中，每個 Pod 都會從子網獲取 IP 位址。您還可以配置每個節點的最大 Pod 數量。因此，該節點上 Pod 的預留 IP 位址數量與每個節點的最大 Pod 數量相同。
使用完全集成的網路模型有以下優勢：
更好的遙測資料。Pod IP 位址在網路中可見。這種可見性使遙測資料比其他模型中的資料更有用，因為即使在從集群外部收集的遙測資料中，也可以識別 Pod。
更容易的防火牆配置。設置防火牆規則時，完全集成的網路模型比其他模型更容易區分節點和 Pod 流量。
更好的相容性。Pod 可以使用不支援 NAT 的協議進行通信。
更好的調試功能。如果防火牆允許，集群外部的資源可以在調試過程中直接訪問 Pod。
與服務網格的相容性。Istio 或 Anthos Service Mesh 等服務網格可以輕鬆跨集群進行通信，因為 Pod 可以直接相互通信。某些服務網格實現僅支援多集群服務網格的 Pod 到 Pod 連接。
使用完全集成的網路模型有以下缺點：
IP 位址使用。您無法重複使用網路中的 Pod IP 位址，並且每個 IP 位址必須是唯一的。這些要求可能會導致大量 IP 位址需要為 Pod 預留。
SDN 要求。完全集成的網路模型需要與底層網路的深度集成，因為 Kubernetes 實現需要直接對 SDN 進行程式設計。SDN 程式設計對用戶來說是透明的，不會產生任何面向使用者的缺點。但是，此類深度集成的網路模型無法在自行管理的本地環境中輕鬆實現。
孤島模式網路模型
孤島模式網路模型（或橋接器模式）通常用於無法與底層網路進行深度集成的本地 Kubernetes 實現。使用孤島模式網路模型時，Kubernetes 集群中的 Pod 可以通過某種閘道或代理與集群外部的資源進行通信。
下圖展示了孤島模式網路模型中的 Pod 通信選項：
上面的孤島模式網路模型示意圖展示了 Kubernetes 集群中的 Pod 如何直接相互通信。該圖還顯示，在與集群外部的應用或其他集群中的 Pod 通信時，集群中的 Pod 需要使用閘道或代理。集群和外部應用之間的通信需要單個閘道，而集群到集群的通信需要兩個閘道。兩個集群之間的流量在離開第一個集群時通過閘道，在進入另一個集群時通過另一個閘道。
在隔離的網路模型中實現閘道或代理有不同的方法。以下實現是兩種最常見的閘道或代理：
使用節點作為閘道。當集群中的節點是現有網路的一部分，並且其 IP 位址在此網路中原生可路由時，通常使用此實現。在這種情況下，節點本身就是閘道，這些閘道提供從集群內部到更大的網路的連接。從 Pod 到集群外部的出站流量可以定向到其他集群或非 Kubernetes 應用，例如調用公司網路上的本地 API。對於此出站流量，包含 Pod 的節點使用來源 NAT (SNAT) 將 Pod 的 IP 位址映射到節點 IP 位址。如需允許集群外部的應用與集群中的 Service 通信，您可以將 NodePort 服務類型用於大多數實現。在某些實現中，您可以使用 LoadBalancer 服務類型來公開 Service。使用 LoadBalancer 服務類型時，您可以為這些 Service 提供一個虛擬 IP 位址，該位址在節點之間負載均衡並路由到作為 Service 一部分的 Pod。下圖展示了將節點用作閘道時的實現模式：
上圖顯示將節點用作閘道對集群內的 Pod 間通信沒有影響。集群中的 Pod 仍會直接相互通信。但是，該圖還顯示了集群外部的以下通信模式：
Pod 如何在離開節點時使用 SNAT 與其他集群或非 Kubernetes 應用進行通信。
來自其他集群或非 Kubernetes 應用的外部 Service 的流量如何通過 NodePort Service 進入集群，然後再轉發到集群中的正確 Pod。
使用具有多個網路介面的代理虛擬機器 (VM)。此實現模式使用代理訪問包含 Kubernetes 集群的網路。代理必須有權訪問 Pod 和節點 IP 位址空間。在此模式中，每個代理虛擬機具有兩個網路介面：一個介面位於較大的企業網路中，另一個介面位於包含 Kubernetes 集群的網路中。下圖顯示了使用代理虛擬機器時的實現模式：
上圖顯示，在孤島模式下使用代理不會影響集群內的通信。集群中的 Pod 仍然可以彼此直接通信。但是，該圖還顯示了從 Pod 到其他集群或非 Kubernetes 應用的通信如何通過可訪問集群網路和目標網路的代理。此外，從外部進入集群的通信也會通過相同類型的代理。
孤島模式網路模型可用於以下實現：
預設情況下，當使用 Kubenet（基本）網路時，Azure Kubernetes Service (AKS) 使用孤島模式網路。當 AKS 使用孤島模式網路時，包含集群的虛擬網路僅包含節點 IP 位址。Pod IP 位址不屬於虛擬網路。相反，Pod 會從其他邏輯空間接收 IP 位址。AKS 使用的孤島模式模型還通過使用用戶定義的路由並在節點介面上啟動 IP 轉發來路由節點之間的 Pod 到 Pod 流量。對於 Pod 與集群外部資源的通信，在出站流量離開節點之前，節點會使用 SNAT 將 Pod IP 位址映射到節點 IP 位址。
在 Oracle Container Engine for Kubernetes (OKE) 中，Pod 到 Pod 通信使用 VXLAN 疊加網路。此外，從 Pod 到集群外部的應用的流量使用 SNAT 將 Pod IP 位址映射到節點 IP 位址。
使用孤島模式網路模型有以下優勢：
IP 位址使用。集群中的 Pod IP 位址可以在其他集群中重複使用。但是，如果 Pod 與企業網路中的外部服務之間需要進行通信，則已被這些服務使用 IP 位址不能用於 Pod。因此，孤島模式網路的最佳實踐是預留網路中唯一的 Pod IP 位址空間，並對所有集群使用此 IP 位址空間。
更輕鬆的安全設置。由於 Pod 不會直接公開到企業網路的其餘部分，因此您無需保護 Pod 免受來自企業網路其餘部分的入站流量的影響。
使用孤島模式網路模型有以下缺點：
遙測資料不精確。從集群外部收集的遙測資料僅包含節點 IP 位址，不包含 Pod IP 位址。如果缺少 Pod IP 地址，則很難識別流量來源和目的地。
調試更困難。調試時，您無法從集群外部直接連接到 Pod。
防火牆的配置更困難。只有在配置防火牆時，才能使用節點 IP 位址。因此，生成的防火牆設置允許節點上的所有 Pod 以及節點本身訪問外部服務，或者不允許它們訪問外部服務。
與服務網格的相容性。使用孤島模式時，跨服務網格（例如 Istio 或 Anthos Service Mesh）中集群的直接 Pod 到 Pod 通信無法實現。某些服務網格實現還存在進一步限制。對 Google Cloud 上的 GKE 集群的 Anthos Service Mesh 多集群支持僅對同一網路上的集群有效。對於支持多網路模型的 Istio 實現，必須通過 Istio 閘道進行通信，從而使多集群服務網格部署變得更複雜。
隔離網路模型
隔離（或網閘隔離）網路模型最常用於不需要訪問更大的公司網路的集群（除非通過面向公眾的 API）。使用隔離網路模型時，每個 Kubernetes 集群都是獨立的，並且無法使用內部 IP 位址與網路的其餘部分通信。集群位於其私人網路絡上。如果集群中的任何 Pod 需要與集群外部的服務進行通信，則此通信需要為入站流量和出站流量使用公共 IP 位址。
下圖展示了隔離網路模型中的 Pod 通信選項：
上面的隔離網路模型示意圖展示了 Kubernetes 集群中的 Pod 可以直接相互通信。該圖還顯示，Pod 無法使用內部 IP 位址與其他集群中的 Pod 通信。此外，Pod 只有在滿足以下條件時才能與集群外部的應用通信：
有一個將集群連接到外部的互聯網閘道。
外部應用使用外部 IP 位址進行通信。
最後，上圖顯示了如何在不同的環境之間重複使用 Pod 和節點的同一 IP 位址空間。
Kubernetes 實現通常不使用隔離網路模型。但是，您可以在任何實現中實施隔離網路模型。您只需在單獨的網路或 VPC 中部署 Kubernetes 集群，而無需連接到其他服務或企業網路。生成的實現具有與隔離網路模型相同的優缺點。
使用隔離網路模式有以下優勢：
IP 位址使用。您可以重複使用集群中的所有內部 IP 位址：節點 IP 地址、Service IP 地址和 Pod IP 地址。可以重複使用內部 IP 位址是因為每個集群都有自己的私人網路絡，並且與集群外部資源的通信只能通過公共 IP 位址進行。
控制。集群管理員可以完全控制集群中的 IP 位址，並且無需執行任何 IP 位址管理任務。例如，管理員可以將完整的 10.0.0.0/8 位址空間分配給集群中的 Pod 和 Service，即使這些位址已在組織中使用也是如此。
安全性。集群外部的通信受到嚴格控制，並在允許的情況下使用明確定義的外部介面和 NAT。
使用隔離網路模型有以下缺點：
無私密通信。不允許使用內部 IP 位址與網路中的其他集群或其他服務進行通信。
GKE 網路模型
GKE 使用完全集成的網路模型，在該模型中，集群部署在 Virtual Private Cloud (VPC) 網路中，該網路也可以包含其他應用。如需創建 GKE 集群，您可以使用 VPC 原生集群或基於路由的集群。這兩種情況下，Pod IP 位址在 VPC 網路中以原生方式路由。
我們建議您為 GKE 環境使用 VPC 原生集群。您可以在標準模式或 Autopilot 模式下創建 VPC 原生集群。如果您選擇 Autopilot 模式，VPC 原生模式始終處於啟用狀態，且無法關閉。以下段落介紹了標準模式下的 GKE 網路模型，以及有關 Autopilot 模式差異的說明。
使用 VPC 原生集群時，Pod IP 位址是每個節點上的次要 IP 地址。此外，每個節點都分配有一個 Pod IP 位址範圍的特定子網，該子網是您在創建集群時從內部 IP 位址空間中選擇的。預設情況下，VPC 原生集群會為每個節點分配一個 /24 子網，以用作 Pod IP 地址。/24 子網對應於 256 個 IP 位址。在 Autopilot 模式下，集群使用對應於 64 個位址的 /26 子網，您無法更改此子網設置。
由於 Pod IP 位址在 VPC 網路中可路由，因此預設情況下 Pod 可以從以下資源接收流量：
VPC 網路中的其他服務。
通過 VPC 網路對等互連連接的 VPC 網路。
通過 Cloud VPN 或 Cloud Interconnect 連接的本地網路。
從 Pod 與集群外部的服務進行通信時，IP 位址偽裝代理會控制流量對這些服務的顯示方式。IP 位址偽裝代理處理專用和外部 IP 位址的方式不同，如以下專案符號清單所述：
預設情況下，IP 位址偽裝代理不會偽裝流向內部 IP 位址（包括 RFC 1918 IP 地址以及內部常用的非 RFC 1918 IP 地址）的流量。如需瞭解詳情，請參閱預設非偽裝目標的清單。由於內部 IP 位址未被偽裝，因此節點不會對這些位址使用 NAT。
對於外部 IP 位址，IP 位址偽裝代理會將這些位址偽裝成節點 IP 地址。因此，這些偽裝的位址會被 Cloud NAT 轉換為外部 IP 位址，或者轉換為虛擬機器 (VM) 實例的外部 IP 位址。
您還可以在 VPC 網路或連接的網路中使用以非公開方式使用的公共 IP (PUPI) 位址。如果您使用 PUPI 位址，您仍然可以從完全集成的網路模型中受益，並直接將 Pod IP 位址視為來源。如需實現這兩個目標，您必須在 nonMasqueradeCIDRs 列表中添加 PUPI 地址。
下圖展示了 Pod 如何在 GKE 網路模型中進行通信：
上圖顯示了 GKE 環境中的 Pod 如何使用內部 IP 位址直接與以下資源進行通信：
同一集群中的其他 Pod。
同一 VPC 網路中其他 GKE 集群的 Pod。
同一 VPC 網路中的其他 Google Cloud 應用。
通過 Cloud VPN 連接的本地應用。
該圖還顯示了當 Pod 需要使用外部 IP 位址與應用通信時會發生什麼情況。當流量離開節點時，Pod 所在的節點會使用 SNAT 將 Pod 的 IP 位址映射到節點的 IP 位址。流量離開節點後，Cloud NAT 會將節點的 IP 位址轉換為外部 IP 位址。
為了獲得本文檔前面介紹的優勢（尤其是使 Pod IP 位址在所有遙測資料中可見的優勢），Google 選擇了完全集成的網路模型。在 GKE 中，Pod IP 地址在 VPC 流日誌（包括中繼資料中的 Pod 名稱）、數據包鏡像、防火牆規則日誌記錄以及您自己的應用日誌中對非偽裝目標公開。
コメント