比較 GKE 中的網路模型

本文說明 Google Kubernetes Engine (GKE) 使用的網路模型，以及該模型與其他 Kubernetes 環境中網路模型的差異。本文涵蓋下列概念：

  • 各種 Kubernetes 實作項目最常使用的網路模型。
  • 最常見網路模型的 IP 位址指派機制。
  • 各個網路模型帶來的優缺點。
  • 詳細說明 GKE 使用的預設網路模型。

這份文件適用於可能熟悉其他 Kubernetes 實作方式，並打算使用 GKE 的雲端架構師、作業工程師和網路工程師。本文假設您熟悉 Kubernetes 和基本網路模型。您也應熟悉網路概念，例如 IP 位址、網路位址轉譯 (NAT)、防火牆和 Proxy。

本文未說明如何修改預設 GKE 網路模型，以符合各種 IP 位址限制。如果遷移至 GKE 時 IP 位址不足，請參閱遷移至 GKE 時的 IP 位址管理策略。

典型的網路模型實作方式

您可以透過各種方式實作 Kubernetes 網路模型。不過，任何實作方式都必須符合下列規定：

  • 每個 Pod 都需要專屬的 IP 位址。
  • Pod 可以與所有節點上的其他 Pod 通訊，不必使用 NAT。
  • 節點上的代理程式 (例如 kubelet) 可以與該節點上的所有 Pod 通訊。
  • 節點主機網路上的 Pod 可以與所有節點上的所有 Pod 通訊，無需使用 NAT。

目前已開發出超過 20 種不同的 Kubernetes 網路模型實作方式，可滿足這些需求。

這些實作可歸類為三種網路模型。這三種模型有以下差異：

  • Pod 如何與公司網路上的非 Kubernetes 服務通訊。
  • Pod 如何與同一機構中的其他 Kubernetes 叢集通訊。
  • 是否需要 NAT 才能在叢集外部通訊。
  • Pod IP 位址是否可在其他叢集或企業網路的其他位置重複使用。

各雲端供應商都已實作一或多種模型類型。

下表列出三種常用的模型，以及這些模型適用的 Kubernetes 實作方式：

網路模型名稱 用於下列導入方式
完全整合或平面
島嶼模式或橋接
隔離或與網路中斷連線
  • Kubernetes 實作項目不常使用，但叢集部署在獨立網路或虛擬私有雲 (VPC) 時，可與任何實作項目搭配使用

本文說明這些網路模型時，是指這些模型對連線的內部部署網路造成的影響。不過，您可以將連線地端部署網路的概念，套用至透過虛擬私人網路 (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 容器網路介面 (CNI) 外掛程式，直接從 VPC 位址空間指派 Pod IP 位址。CNI 外掛程式會從節點所在的預設子網路或自訂子網路指派 IP 位址。Pod IP 位址並非來自每個節點專用的 Pod IP 位址範圍。
  • 在 Azure 中，使用 Azure CNI (進階網路) 時，AKS 會實作這個模型。這項實作並非預設設定。在這個實作方式中，每個 Pod 都會從子網路取得 IP 位址。您也可以設定每個節點的最大 Pod 數。因此，預先為該節點上的 Pod 保留的 IP 位址數量，與每個節點的最大 Pod 數相同。

優點

使用完全整合的聯播網模型有下列優點：

  • 更優質的遙測資料。Pod IP 位址會在整個網路中顯示。相較於其他模型，這種可見度讓遙測資料更加實用，因為即使是從叢集外部收集的遙測資料，也能識別 Pod。
  • 簡化防火牆設定。設定防火牆規則時，與其他模型相比，在完全整合的網路模型中，區分節點和 Pod 流量會更加容易。
  • 相容性更佳。Pod 可以使用不支援 NAT 的通訊協定進行通訊。
  • 更完善的偵錯功能。如果防火牆允許，叢集外部的資源可以在偵錯程序中直接連線至 Pod。
  • 與服務網格相容。服務網格 (例如 Istio 或 Cloud Service Mesh) 可輕鬆跨叢集通訊，因為 Pod 可以直接彼此通訊。部分服務網格實作項目僅支援多叢集服務網格的 Pod 對 Pod 連線。

缺點

使用完全整合的網路模型有下列缺點：

  • IP 位址使用情形。您無法在網路中重複使用 Pod IP 位址，且每個 IP 位址都不得重複。這些需求可能會導致需要為 Pod 保留大量 IP 位址。
  • SDN 規定。全方位整合的網路模型需要與基礎網路深度整合，因為 Kubernetes 實作項目必須直接程式設計 SDN。SDN 的程式設計對使用者而言是透明的，不會造成任何使用者可見的缺點。不過，這類深度整合的網路模型無法在自行管理的內部部署環境中輕鬆導入。

孤島模式網路模型

島嶼模式 (或橋接) 網路模型通常用於無法與基礎網路深度整合的內部部署 Kubernetes 實作項目。使用孤島模式網路模型時，Kubernetes 叢集中的 Pod 可以透過某種閘道或 Proxy，與叢集外部的資源通訊。

下圖顯示在「孤島模式」網路模型中，Pod 的通訊選項：

網路圖表：顯示孤島模式網路模型中的通訊模式。

上圖顯示島嶼模式網路模型，說明 Kubernetes 叢集中的 Pod 如何直接彼此通訊。圖中也顯示，叢集中的 Pod 與叢集外部的應用程式或與其他叢集中的 Pod 通訊時，必須使用閘道或 Proxy。叢集與外部應用程式之間的通訊需要單一閘道，但叢集之間的通訊需要兩個閘道。兩個叢集之間的流量會通過閘道，離開第一個叢集，然後通過另一個閘道，進入另一個叢集。

在獨立網路模型中，您可以透過不同方式實作閘道或 Proxy。以下是兩種最常見的閘道或 Proxy 實作方式：

  • 將節點做為閘道。如果叢集中的節點屬於現有網路，且其 IP 位址可在該網路中原生路由傳送，通常會使用這種實作方式。在這種情況下，節點本身就是閘道，可提供從叢集內部到較大網路的連線。從 Pod 輸出至叢集外部的流量可導向其他叢集，或導向非 Kubernetes 應用程式，例如呼叫公司網路上的內部部署 API。對於這類輸出流量，包含 Pod 的節點會使用來源 NAT (SNAT)，將 Pod 的 IP 位址對應至節點 IP 位址。如要允許叢集外部的應用程式與叢集內的服務通訊，您可以在大多數實作項目中使用 NodePort 服務類型。在某些實作方式中，您可以使用 LoadBalancer 服務類型公開發布服務。使用 LoadBalancer 服務類型時，您會為這些服務提供虛擬 IP 位址，在節點之間進行負載平衡，並將流量路由至屬於服務的 Pod。

    下圖顯示使用節點做為閘道時的實作模式：

    網路圖：顯示使用節點做為閘道的孤島模式網路模型中的通訊模式。

    上圖顯示，使用節點做為閘道不會影響叢集內的 Pod 間通訊。叢集中的 Pod 仍可直接通訊。不過，圖表也顯示叢集外的下列通訊模式：

    • Pod 離開節點時，如何使用 SNAT 與其他叢集或非 Kubernetes 應用程式通訊。
    • 來自其他叢集服務或非 Kubernetes 應用程式的流量，如何透過 NodePort 服務進入叢集，然後轉送至叢集中的正確 Pod。

  • 使用具備多個網路介面的 Proxy 虛擬機器 (VM)。這個實作模式會使用 Proxy 存取包含 Kubernetes 叢集的網路。Proxy 必須有權存取 Pod 和節點 IP 位址空間。在這個模式中，每個 Proxy VM 都有兩個網路介面：一個介面位於較大的企業網路中，另一個介面位於包含 Kubernetes 叢集的網路中。

    下圖顯示使用 Proxy VM 時的實作模式：

    網路圖：顯示使用 Proxy VM 的孤島模式網路模型中的通訊模式。

    上圖顯示在島嶼模式中使用 Proxy 不會影響叢集內的通訊。叢集中的 Pod 仍可直接通訊。不過，這張圖也顯示 Pod 與其他叢集或非 Kubernetes 應用程式之間的通訊，如何透過可存取叢集網路和目的地網路的 Proxy 傳輸。此外，從外部進入叢集的通訊也會通過相同類型的 Proxy。

可用性

島嶼模式網路模型適用於下列實作方式：

  • 預設情況下，使用 Kubenet (基本) 網路時，Azure Kubernetes Service (AKS) 會使用島嶼模式網路。當 AKS 使用孤島模式網路時，包含叢集的虛擬網路只會包含節點 IP 位址。Pod IP 位址不屬於虛擬網路。Pod 則是從不同的邏輯空間取得 IP 位址。AKS 使用的島嶼模式也會透過使用者定義的路徑，在節點之間傳送 Pod 對 Pod 的流量，並在節點介面上啟用 IP 轉送。如要讓 Pod 與叢集外部的資源通訊，節點會使用 SNAT 將 Pod IP 位址對應至節點 IP 位址，然後傳送輸出流量。
  • 在 Oracle Container Engine for Kubernetes (OKE) 中，Pod 對 Pod 通訊會使用 VXLAN 覆蓋網路。此外，從 Pod 到叢集外部應用程式的流量會使用 SNAT，將 Pod IP 位址對應至節點 IP 位址。

優點

使用孤島模式網路模型具有下列優點：

  • IP 位址使用情形。叢集中的 Pod IP 位址可供其他叢集重複使用。不過，GKE 的預設虛擬私有雲原生叢集不支援在同一虛擬私有雲網路內，跨叢集重複使用 Pod IP 位址範圍。在 GKE 中，Pod IP 位址可在虛擬私有雲網路中直接路由傳送。因此，在單一 VPC 中，所有叢集和資源的 Pod IP 位址都不得重複。如要重複使用 IP 位址，請將 GKE 叢集部署到不同的虛擬私有雲網路。無論採用哪種網路模型，需要與企業網路中的外部服務通訊的 Pod 都不能使用這些外部服務已使用的 IP 位址。如果是孤島模式網路，最佳做法是保留企業網路中專屬的 Pod IP 位址空間，並將這個 IP 位址空間用於所有採用孤島模式設定的叢集。

  • 更輕鬆地設定安全性。由於 Pod 不會直接暴露在企業網路的其餘部分，因此您不需要防範來自企業網路其餘部分的連入流量，確保 Pod 安全無虞。

缺點

使用孤島模式網路模型有下列缺點：

  • 不精確的遙測資料。在叢集外部收集的遙測資料只會包含節點 IP 位址，不會包含 Pod IP 位址。缺少 Pod IP 位址會導致流量來源和目的地難以識別。
  • 較難偵錯。進行偵錯時，您無法從叢集外部直接連線至 Pod。
  • 防火牆設定較為困難。設定防火牆時，只能使用節點 IP 位址。因此，產生的防火牆設定會允許節點上的所有 Pod 和節點本身連線至外部服務，或禁止所有 Pod 和節點連線至外部服務。

  • 與服務網格相容。在孤島模式下，無法在服務網格 (例如 Istio 或 Cloud Service Mesh) 的叢集之間，直接進行 Pod 對 Pod 通訊。

    部分服務網格實作項目有其他限制。 Cloud Service Mesh 多叢集支援適用於Google Cloud 上的 GKE 叢集，但僅支援位於相同網路的叢集。對於支援多網路模型的 Istio 實作項目，通訊必須透過 Istio Gateway 進行，這會使多叢集服務網格部署作業更加複雜。

獨立網路模型

隔離 (或氣隙) 網路模型最常用於不需要存取較大型企業網路的叢集，但可透過面向公眾的 API 存取。使用獨立網路模型時，每個 Kubernetes 叢集都會獨立運作，無法使用內部 IP 位址與網路的其餘部分通訊。叢集位於專屬的私人網路上。如果叢集中的任何 Pod 需要與叢集外部的服務通訊，則無論是傳入或傳出，這類通訊都必須使用公開 IP 位址。

下圖顯示隔離網路模型中的 Pod 通訊選項：

網路圖表：顯示獨立網路模型中的通訊模式。

從上述隔離網路模型圖中可以看出，Kubernetes 叢集內的 Pod 可以直接互相通訊。圖中也顯示 Pod 無法使用內部 IP 位址與其他叢集中的 Pod 通訊。此外，只有在符合下列條件時，Pod 才能與叢集外部的應用程式通訊：

  • 有網際網路閘道可將叢集連線至外部。
  • 外部應用程式會使用外部 IP 位址進行通訊。

最後，這張圖顯示 Pod 和節點的相同 IP 位址空間如何在不同環境之間重複使用。

可用性

Kubernetes 實作項目通常不會使用獨立網路模型。不過，您可以在任何實作中達成隔離網路模型。您只需要在獨立網路或虛擬私有雲中部署 Kubernetes 叢集，不必連線至其他服務或企業網路。產生的實作項目與獨立網路模型具有相同的優缺點。

優點

使用獨立網路模式有下列優點：

  • IP 位址使用情形。您可以重複使用叢集中的所有內部 IP 位址：節點 IP 位址、服務 IP 位址和 Pod IP 位址。由於每個叢集都有自己的私人網路，且與叢集外部資源的通訊只會透過公開 IP 位址進行，因此可以重複使用內部 IP 位址。
  • 控管。叢集管理員可全面控管叢集中的 IP 位址，不必執行任何 IP 位址管理工作。舉例來說，管理員可以將完整的 10.0.0.0/8 位址空間分配給叢集中的 Pod 和服務，即使這些位址已在機構中使用也沒問題。
  • 安全性：叢集外部的通訊受到嚴格控管，且在允許的情況下，會使用明確定義的外部介面和 NAT。

缺點

使用獨立網路模式有下列缺點：

  • 請勿進行私人通訊。使用內部 IP 位址進行通訊時，不得連線至網路中的其他叢集或其他服務。

GKE 網路模型

GKE 採用完全整合的網路模型，叢集會部署在虛擬私有雲 (VPC) 網路中，該網路也可以包含其他應用程式。

建議您為 GKE 環境使用虛擬私有雲原生叢集。您可以在Standard 或 Autopilot 中建立 VPC 原生叢集。如果您選擇「Autopilot」模式，虛擬私有雲原生模式一律會開啟，且無法關閉。以下段落將說明 Standard 中的 GKE 網路模型，並附註 Autopilot 的差異。

瞭解虛擬私有雲原生叢集中的 IP 位址管理

使用虛擬私有雲原生叢集時，Pod IP 位址是每個節點上的次要 IP 位址。建立叢集時，系統會從內部 IP 位址空間中選取 Pod IP 位址範圍，並為每個節點指派該範圍的特定子網路。根據預設，虛擬私有雲原生叢集會為每個節點指派一個 /24 子網路，做為 Pod IP 位址。一個 /24 子網路對應 256 個 IP 位址。在 Autopilot 模式中，叢集會使用對應 64 個位址的 /26 子網路，且您無法變更這項子網路設定。

GKE 網路模型不允許在網路中重複使用 IP 位址。遷移至 GKE 時，您必須規劃 IP 位址分配，以減少 GKE 中的內部 IP 位址用量。

由於 Pod IP 位址可在虛擬私有雲網路中轉送，Pod 預設可接收下列資源的流量：

使用 IP 偽裝代理程式管理外部流量通訊

從 Pod 與叢集外部的服務通訊時，IP 偽裝代理程式會控管流量對這些服務的顯示方式。IP 偽裝代理程式會以不同方式處理私人和外部 IP 位址，如下列項目所述：

您也可以在虛擬私有雲網路或連線網路中使用私用公開 IP (PUPI) 位址。如果您使用 PUPI 位址，仍可享有完全整合的網路模型，並直接將 Pod IP 位址視為來源。如要達成這兩個目標，您必須在 nonMasqueradeCIDRs 清單中加入 PUPI 位址。

瞭解 GKE 網路中的 Pod 流量

下圖顯示 Pod 如何在 GKE 網路模型中通訊：

網路圖表，顯示 GKE 網路模型中的通訊模式。

上圖顯示 GKE 環境中的 Pod 如何使用內部 IP 位址，直接與下列資源通訊：

  • 同一叢集中的其他 Pod。
  • 相同虛擬私有雲網路中其他 GKE 叢集的 Pod。
  • 相同虛擬私有雲網路中的其他 Google Cloud 應用程式。
  • 透過 Cloud VPN 連線的內部部署應用程式。

這張圖也顯示 Pod 需要使用外部 IP 位址與應用程式通訊時，會發生什麼情況。流量離開節點時，Pod 所在的節點會使用 SNAT，將 Pod 的 IP 位址對應至節點的 IP 位址。流量離開節點後，Cloud NAT 會將節點的 IP 位址轉換為外部 IP 位址。

為獲得本文件先前所述的優點，尤其是讓所有遙測資料都能顯示 Pod IP 位址，Google 選擇了完全整合的網路模型。在 GKE 中，Pod IP 位址會顯示在虛擬私有雲流程記錄檔 (包括中繼資料中的 Pod 名稱)、封包鏡像、防火牆規則記錄功能，以及您自己的應用程式記錄檔 (適用於非遮蓋目的地)。

後續步驟