管理 GKE 中的 IP 位址遷移作業

本文說明如何管理 Google Kubernetes Engine (GKE) 的 IP 位址用量，以及如何在必要時使用 GKE 的替代網路模型。本文涵蓋下列概念：

  • 如何減少 GKE 中的 Pod IP 位址用量，讓 GKE 滿足大多數機構的 IP 位址需求。
  • 如果叢集架構不符合貴機構的需求，如何在 GKE 上導入替代網路模型。

本文適用於雲端架構師、作業工程師和網路工程師，他們計畫將 Kubernetes 叢集從其他環境遷移至 GKE。如果貴機構在為預期的 GKE 用量指派足夠的內部 IP 位址時遇到困難，請參考本文的指引。

這份文件假設您已熟悉 Kubernetes 及其網路模型。您也應熟悉網路概念，例如 IP 位址、網路位址轉譯 (NAT)、防火牆和 Proxy。

本文未涵蓋用於服務 IP 位址的位址範圍管理策略。Service 所需的位址數量遠小於 Pod，且減少位址數量的選項有限。在 GKE 上，Service IP 位址範圍在叢集生命週期內是固定的。因此，Service IP 位址範圍的大小必須能容納預期最大數量的 Service。由於 Service IP 位址無法在叢集外部連線，因此您可以在其他網路中重複使用這些位址。

本文也會提及不同的 Kubernetes 網路模型：完全整合、孤島模式和隔離模式。這些模型不同之處在於，Pod IP 位址在整個網路中的連線方式。這些差異會影響可用的 IP 位址管理策略。如要進一步瞭解這些模型和 GKE 網路模型，請參閱「GKE 和其他 Kubernetes 實作項目使用的網路模型比較」。

減少 GKE 中的內部 IP 位址用量

GKE 採用全方位整合的網路模型，叢集會部署在虛擬私有雲網路中，該網路也可以包含其他應用程式。GKE 模型有許多優點，不過，這類模型不允許重複使用 Pod IP 位址。由於無法重複使用，您必須使用在整個虛擬私有雲網路中獨一無二的 Pod IP 位址。因此，您必須仔細考量需要多少不重複的 IP 位址。

您需要的專屬地址數量會影響是否需要減少 IP 位址用量，如下所示：

  • 如果 IP 位址空間足以滿足需求，則不一定需要採取措施來減少 IP 位址用量。不過，瞭解如何減少 IP 位址用量，有助於找出要使用的最少 IP 位址數量。
  • 如果位址空間不足，您需要減少 IP 位址用量，才能建立符合位址空間限制的 GKE 叢集。

如要減少 GKE 中的 IP 位址用量，請考慮下列選項：

  • 變更每個節點的 Pod 數設定。根據預設，GKE Standard 叢集會為每個節點保留 /24 子網路範圍，且每個節點最多可有 110 個 Pod。如果您預期每個節點只會使用 64 個或更少的 Pod，可以調整每個節點的最大 Pod 數，藉此減少一半以上的 Pod IP 位址用量。Autopilot 叢集每個節點最多可有 32 個 Pod，且這項設定無法變更。
  • 使用多個 Pod IP 位址範圍。使用不連續的多 Pod 無類別跨網域路由 (CIDR)，即可將次要 Pod IP 位址範圍新增至現有叢集。您可以選取每個節點集區使用的 Pod IP 位址範圍。選取每個集區使用的 IP 位址範圍，即可在分配初始 Pod IP 位址空間時採取保守做法，同時仍能擴充叢集。

  • 使用非 RFC 1918 IP 位址。您的企業網路可能沒有足夠的未分配 RFC 1918 IP 位址，可供 Pod IP 位址使用。如果沒有足夠的未分配 RFC 1918 IP 位址，則可以使用非 RFC 1918 位址，例如 RFC 6598 位址空間 (100.64.0.0/10) 中的位址。

    如果您已在企業網路的其他位置使用 RFC 6598 空間，可以將E 類/RFC 5735 (240.0.0.0/4) 位址空間用於 Pod IP 位址。不過，來自這些 IP 位址的流量會在 Windows 主機和部分地端硬體上遭到封鎖。為避免封鎖 RFC 5735 位址，請考慮將傳送至這些外部目的地的流量偽裝成「僅向內部部署網路隱藏 Pod IP 位址」一節所述的流量。不過，當您將流量偽裝成外部目的地時，會遺失部分導向內部部署應用程式的遙測資料。

如果貴機構有大量的公開 IP 位址空間，也可以使用私人的公開 IP (PUPI) 位址。 使用 PUPI 位址時，您必須在 nonMasqueradeCIDRs 清單中加入 PUPI 位址，才能在叢集外部連線，而不必使用 NAT。

選擇 GKE 中的網路模型

GKE 網路模型文件說明瞭 GKE 中 Standard 叢集的運作方式，包括相關的 Pod IP 位址。本文的「減少 GKE 中的內部 IP 位址用量」一節，說明如何減少這些叢集所需的內部 IP 位址數量。瞭解 GKE 網路模型運作方式和如何減少內部 IP 位址，是您在 GKE 中使用任何網路模型時的基礎。

不過，光是瞭解及套用這些概念，可能無法提供符合您需求的網路實作項目。下方的決策樹可協助您決定如何導入最適合的 GKE 網路模型：

GKE 中 IP 位址遷移策略的決策樹。

決策樹一律從建立 GKE Standard 叢集開始，這些叢集是以完全整合的網路模型為基礎。樹狀結構的下一個步驟是套用本文所述的所有選項，減少 IP 位址用量。

如果您已盡可能減少 IP 位址用量，但仍沒有足夠的位址空間供 GKE 叢集使用，則需要替代網路模型。決策樹可協助您決定要使用下列哪種替代網路模型：

請注意，這張決策樹狀圖僅供參考。根據您的具體用途，您可能仍會偏好其他模型，因為每個模型都有優缺點。通常有多種模式可行，您可以選擇更適合貴機構的方法。

在極少數情況下，決策樹中顯示的替代模型可能無法滿足您的需求。在這些罕見情況下，您或許可以使用「使用多個 NIC 執行個體隱藏叢集位址」一文所述的模型。

模擬其他網路模型

如要充分運用完全整合式網路模型的優點，建議您將 GKE 叢集與其他雲端資源放在同一個邏輯網路中。不過，您可能無法按照這項建議操作。您可能沒有足夠的 IP 位址空間，或者可能需要向貴機構較大的網路隱藏 Pod IP 位址。

本節提供使用全方位整合網路模型的選項，說明各種架構模式，模擬 GKE 上不同的替代網路模型。這些替代架構模式會為 GKE 建立類似於孤島模式網路模型或獨立模式網路模型的操作模式。

每種替代架構模式都包含下列資訊：

僅向地端網路隱藏 Pod IP 位址

在架構模式中，您會使用下列路由目標的組合，向內部部署網路隱藏 IP 位址：

  • 讓 GKE 叢集 Google Cloud 指派 Pod IP 位址，這些位址會透過整個部署作業進行路由。 Google Cloud
  • 防止這些 IP 位址透過 Cloud VPN 或 Cloud Interconnect，在沒有 NAT 的情況下，轉送至地端部署資源或其他雲端環境。

這個架構模式通常會搭配使用 E 類/RFC 5735 IP 位址空間，因為這個空間包含許多 IP 位址。這麼多可用的 IP 位址有助於滿足為每個 Pod 提供專屬 IP 位址的需求。不過，由於許多網路硬體供應商會封鎖這類流量，因此 Class E/RFC 5735 IP 位址無法輕鬆轉送至內部部署資源。

您可以改用 RFC 1918 IP 位址，或一組內部非 RFC 1918 IP 位址，而非使用 E 類/RFC 5735 IP 位址空間。如果您使用其他 IP 位址集，請判斷 Pod 使用的位址與內部部署網路使用的位址之間，是否有任何 IP 位址重疊。如有重疊，請確保使用這些位址的叢集與使用相同位址的內部部署應用程式之間，絕不會有任何通訊。

以下步驟概述如何設定這個架構模式：

  1. 為 Pod 子網路建立次要 IP 位址範圍。如本節先前所述，您可以從 E 類/RFC 5735 空間、RFC 1918 空間或一組內部非 RFC 1918 IP 位址建立這個位址範圍。通常會使用 E 類別/RFC 5735 空間。
  2. 使用自訂通告路徑，並從 Cloud Router 上的通告中移除 Pod IP 位址範圍。移除這些位址有助於確保系統不會透過邊界閘道協定 (BGP) 向內部部署路由器通告 Pod IP 範圍。
  3. 使用次要 IP 位址範圍做為 Pod 的無類別跨網域路由 (CIDR)，建立 GKE 叢集。您可以採用「減少 GKE 中的內部 IP 位址用量」一文所述的策略，減少 IP 位址用量。

  4. 將下列 IP 位址新增至偽裝代理程式中的 nonMasqueradeCIDRs 清單：

    • 您用於 Pod 的 IP 位址範圍。
    • 用於節點的 IP 位址範圍。
    • 僅在 Google Cloud上使用的其他 IP 位址，例如 Google Cloud上使用的主要 IP 位址範圍。

    請勿納入內部部署環境或其他雲端環境中使用的內部 IP 位址範圍。如果 Google Cloud中有 Windows 工作負載，請將這些工作負載放在不同的子網路中，且不要納入這些範圍。

使用上述步驟設定這個模式時，您設定的叢集會具有下列行為：

  • 在 Google Cloud中扮演完全整合的網路模型。
  • 與內部部署網路互動時，就像是島嶼模式網路模型。

如要讓這個替代模式完全模擬島嶼模式網路模型，您需要將偽裝代理程式中的 nonMasqueradeCIDRs 清單變更為只包含叢集節點和 Pod IP 位址範圍的清單。建立這類清單會導致系統一律將叢集外部的流量偽裝成節點 IP 位址，即使在 Google Cloud內也是如此。不過，變更後您就無法在 VPC 網路中收集 Pod 層級的遙測資料。

下圖顯示這個架構模式的實作方式：

網路圖：僅從內部部署網路隱藏 IP 位址的實作方式。

上圖顯示如何對外部網路隱藏 Pod IP 位址。如圖所示，Pod 之間 Google Cloud 可以彼此直接通訊，即使是跨叢集也沒問題。這個 Pod 通訊方式與 GKE 模型類似。請注意，圖表也顯示 Pod 使用 Class E/RFC 5735 空間中的位址。

對於傳送至叢集外部的流量，圖表會顯示來源 NAT (SNAT) 如何套用至該流量，因為流量會離開節點。無論流量是透過 Cloud VPN 路由至地端部署應用程式，還是透過 Cloud NAT 路由至外部應用程式，系統都會使用 SNAT。

這種架構模式會使用 Pod IP 位址，在 Google Cloud內進行通訊。只有在流量導向地端部署應用程式或其他雲端環境時，才會進行偽裝。雖然您無法直接從地端應用程式連線至 Pod，但可以連線至透過內部負載平衡公開的服務。

從地端網路隱藏 Pod IP 位址具有下列優點：

  • 您仍然可以充分利用 Google Cloud內完全整合的網路模型，例如使用防火牆，以及根據 Pod IP 位址收集遙測資料。此外，您也可以直接連線至 Pod，以便在 Google Cloud中進行偵錯。
  • 您還是可以在 Google Cloud中使用多叢集服務網格和 Pod IP 位址。

不過，向外部網路隱藏 Pod IP 位址有下列缺點：

  • 您無法在 Google Cloud內的不同叢集重複使用 Pod 或服務 IP 位址範圍。
  • 您可能需要管理兩組不同的防火牆規則：一組用於內部部署網路之間的流量，另一組則用於完全在 Google Cloud內的流量。
  • 在跨越 Google Cloud 和地端部署或其他雲端服務供應商環境的多叢集服務網格中，您無法直接進行 Pod 對 Pod 通訊。舉例來說，使用 Istio 時，所有通訊都必須在 Istio Gateway 之間進行。

使用 Private Service Connect 隱藏 Pod IP 位址

這個架構模式會使用 Private Service Connect 隱藏 Pod IP 位址。如有下列需求，請使用這個架構模式：

  • 您只需要公開 GKE 叢集中的少數服務。
  • GKE 叢集可以獨立運作，不需要與公司網路中的許多應用程式進行輸出通訊。

Private Service Connect 可讓您發布服務，供其他網路使用。您可以使用內部直通式網路負載平衡器和服務連結公開 GKE 服務，並從其他虛擬私有雲網路使用端點來取用這些服務。

以下步驟概述如何設定這個架構模式：

  1. 在另一個虛擬私有雲網路中，建立 GKE 叢集。虛擬私有雲網路應只包含該叢集。
  2. 針對叢集中需要從其他叢集或虛擬私有雲網路中應用程式存取的每個 GKE 服務，請使用 Private Service Connect 建立內部直通網路負載平衡器。

  3. (選用) 如果 GKE 叢集需要與公司網路中的某些應用程式進行輸出通訊，請透過 Private Service Connect 發布服務，公開這些應用程式。

    下圖顯示這個架構模式的實作方式：

網路圖表：顯示如何使用 Private Service Connect 隱藏 IP 位址。

上圖顯示，Private Service Connect 模型中叢集內和跨叢集的通訊，與獨立網路模型類似。不過，允許的通訊是透過 Private Service Connect 端點進行，而不是透過公開 IP 位址。如圖所示，每個叢集都有自己的獨立虛擬私有雲網路。此外，每個 VPC 網路可以共用相同的 IP 位址，每個叢集也可以共用相同的 IP 位址空間。只有叢集內的 Pod 才能直接通訊。

如要從叢集外部進行通訊，請參閱圖表，瞭解外部應用程式如何透過 Private Service Connect 端點連線至叢集。該端點會連線至叢集 VPC 網路中服務生產者提供的服務連結。叢集之間的通訊也會經過 Private Service Connect 端點和服務供應商的服務附件。

使用 Private Service Connect 隱藏 Pod IP 位址具有下列優點：

  • 您不必規劃 IP 位址，因為 GKE 叢集的 IP 位址空間會對網路其餘部分隱藏。這種做法只會向取用端虛擬私有雲網路公開每個服務的單一 IP 位址。
  • 這個模型清楚定義了公開的服務，只有這些服務可從虛擬私有雲網路的其餘部分存取，因此叢集安全防護更加容易。

不過，使用 Private Service Connect 隱藏 Pod IP 位址有下列缺點：

  • 叢集內的 Pod 無法在叢集外部建立私人通訊。Pod 只能與公開服務 (Pod 具備網際網路連線時) 或 Google API (使用私人 Google 存取權) 通訊。如果叢集外部的服務是透過 Private Service Connect 公開，Pod 也可以連線至這些服務。不過，並非所有內部服務供應商都會建立服務附件。因此，只有在這些服務的數量僅限於提供附件的供應商時，才能使用 Private Service Connect。
  • 端點只能從服務所在的相同區域連線。此外，這些端點只能從已連線的虛擬私有雲網路本身連線，無法從對等互連的虛擬私有雲網路，或透過 Cloud VPN 或 Cloud Interconnect 連線的網路連線。

使用 Cloud VPN 隱藏 Pod IP 位址

這個架構模式會使用 Cloud VPN，在 GKE 叢集和主要 VPC 網路之間建立區隔。建立這種區隔後，產生的網路功能會與孤島模式網路模型類似。與孤島模式模型一樣，這個模式的優點是可在叢集之間重複使用 Pod 和 Service IP 位址範圍。由於與叢集外部應用程式的通訊會使用 SNAT，因此可以重複使用。節點會使用 SNAT 將 Pod IP 位址對應至本身的節點 IP 位址，然後流量才會離開節點。

以下步驟概述如何設定這個模型：

  1. 在另一個虛擬私有雲網路中，建立 GKE 叢集。虛擬私有雲網路應只包含該叢集。

    針對叢集，請使用您指派的公開 IP 位址中未使用的部分，定義兩個 IP 位址範圍：一個用於 Pod，另一個用於 Service。請根據您預期使用的最大 GKE 叢集需求，調整這些 IP 位址範圍的大小。請保留這些範圍，供 GKE 專用。您也可以在貴機構的所有 GKE 叢集重複使用這些範圍。

    有時無法保留這麼大的 IP 位址範圍。貴機構可能已將 Pod 和 Service IP 位址範圍用於其他應用程式。如果 IP 位址範圍正在使用中，且無法保留，請確認使用這些 IP 位址的應用程式不需要與 GKE 叢集通訊。

  2. 針對您剛建立的叢集，請將偽裝代理程式中的 nonMasqueradeCIDRs 清單設定為包含叢集節點和 Pod IP 位址範圍的清單。這個清單會導致 GKE 一律將離開叢集的流量偽裝成節點 IP 位址，即使在Google Cloud內也是如此。

  3. 使用 Cloud VPN 將包含 GKE 叢集的虛擬私有雲網路，連線至現有的 (主要) 虛擬私有雲網路。

  4. 使用自訂通告路徑，停止叢集的虛擬私有雲網路通告導向主要虛擬私有雲網路的 Pod 和服務 IP 位址範圍。

  5. 針對您需要的其他 GKE 叢集，重複執行步驟 1 到 4。所有叢集都使用相同的 Pod 和 Service IP 位址範圍。不過，請為每個節點使用不同的 IP 位址。

  6. 如果您透過 Cloud VPN 或 Cloud Interconnect 連線至內部部署網路，請使用自訂通告路徑手動通告節點 IP 範圍。

  7. 如果您透過虛擬私有雲網路對等互連，將其他網路連線至主要虛擬私有雲網路，請在這些對等互連上匯出自訂路徑，確保 GKE 叢集節點可以連線至對等互連網路。

下圖顯示如何使用 Cloud VPN 隱藏 Pod IP 位址：

網路圖：顯示透過 Cloud VPN 隱藏 IP 位址的實作方式。

上圖顯示如何使用 Cloud VPN 隱藏 Pod IP 位址，建立類似於島嶼模式網路模型的做法。如圖所示，每個 GKE 叢集都有自己的獨立 VPC 網路。每個網路都有不同的節點 IP 位址空間，但使用相同的 Pod IP 位址空間。Cloud VPN 通道會將這些虛擬私有雲網路彼此連線，並連線至公司網路，且系統不會從含有叢集的虛擬私有雲網路宣傳 Pod IP 位址空間。

請注意，在圖表中，只有叢集內的 Pod 才能直接通訊。節點會使用 SNAT 偽裝 Pod IP 位址空間，在叢集外部與其他叢集、公司網路或連線的內部部署網路通訊時，Pod 無法直接從其他叢集或公司網路連線。只有透過內部負載平衡器公開的叢集服務，才能透過 Cloud VPN 連線存取。

使用 Cloud VPN 隱藏 Pod IP 位址具有下列優點：

  • 如孤島模式網路模型所述，您可以在叢集之間重複使用 Pod 和 Service IP 位址範圍。
  • 由於 Pod IP 位址無法直接從主要虛擬私有雲網路和連線網路存取，因此防火牆可能不需要太多設定。因此您不需要設定明確的防火牆規則，即可封鎖與 Pod 的通訊。

不過，使用 Cloud VPN 隱藏 Pod IP 位址有下列缺點：

  • 與島嶼模式網路模型相同的缺點也適用於此。舉例來說，您無法在 Pod 層級設定防火牆規則。您也無法在主要 VPC 網路或連線網路中，收集 Pod 層級的遙測資料。
  • 相較於預設的 GKE 網路模型，這個模式會導致額外費用，包括與 Cloud VPN 通道相關的費用和資料移轉費用。
  • Cloud VPN 每個 VPN 通道都有頻寬限制。如果達到頻寬上限，您可以設定多個 Cloud VPN 通道，並使用等價多路徑 (ECMP) 分配流量。但執行這些動作會增加設定和維護 GKE 實作的複雜度。
  • 讓路徑通告保持同步會增加叢集建立的複雜度。每當您建立新的 GKE 叢集時，都需要設定 Cloud VPN 通道，並在這些通道上建立自訂的已放送路徑，以及前往地端部署應用程式的路徑。

使用內部使用的公開 IP 位址和虛擬私有雲網路對等互連，隱藏 Pod IP 位址

如果貴機構擁有未使用的公開 IP 位址，可以採用類似島嶼模式網路模型的架構模式，但透過私人使用這個公開 IP 位址空間。這個架構與使用 Cloud VPN 的模型類似，但改用 VPC 網路對等互連，在 GKE 叢集和主要網路之間建立區隔。

以下步驟概述如何設定這個架構模式：

  1. 在另一個虛擬私有雲網路中，建立 GKE 叢集。虛擬私有雲網路應只包含該叢集。

    針對叢集，請使用您指派的公開 IP 位址中未使用的部分，定義兩個 IP 位址範圍：一個用於 Pod，另一個用於 Service。請根據您預期使用的最大 GKE 叢集需求，調整這些 IP 位址範圍的大小。請保留這些範圍，供 GKE 專用。您也可以在貴機構的所有 GKE 叢集重複使用這些範圍。

    理論上，您可以使用第三方擁有的較大未用公開 IP 位址區塊，而不必使用公開 IP 位址指派。不過，我們強烈建議不要這樣設定，因為這類 IP 位址隨時可能出售或公開使用。販售或使用位址會導致安全性和連線問題，進而影響網際網路上的公開服務。

  2. 針對您剛建立的叢集，請將偽裝代理程式中的 nonMasqueradeCIDRs 清單設定為包含叢集節點和 Pod IP 位址範圍的清單。這個清單會導致 GKE 一律將離開叢集的流量偽裝成節點 IP 位址，即使在 Google Cloud內也是如此。

  3. 使用虛擬私有雲網路對等互連，將包含 GKE 叢集的虛擬私有雲網路連線至現有 (主要) 虛擬私有雲網路。由於您不希望在這個模型中交換 PUPI 位址，請在設定對等互連時設定 --no-export-subnet-routes-with-public-ip 旗標。

  4. 針對您需要的其他 GKE 叢集重複執行步驟 1 到 3。所有叢集都使用相同的 Pod 和 Service IP 位址範圍。不過，請為每個節點使用不同的 IP 位址。

  5. 如果您透過 Cloud VPN 或 Cloud Interconnect 連線至內部部署網路，請使用自訂路徑通告 手動通告節點 IP 位址範圍。

下圖顯示這個架構模式的實作方式：

網路圖：顯示透過 PUPI 和 VPC 網路對等互連隱藏 IP 位址的實作方式。

上圖顯示如何使用虛擬私有雲網路對等互連隱藏 IP 位址。如圖所示，每個 GKE 叢集都有自己的獨立 VPC 網路。每個節點都有不同的節點 IP 位址空間，但使用與貴機構 PUPI 位址空間定義的相同 Pod IP 位址空間。虛擬私有雲網路會透過虛擬私有雲網路對等互連，彼此連線並連線至Google Cloud 中的非 Kubernetes 應用程式。對等互連之間不會宣傳 PUPI 位址空間。虛擬私有雲網路會透過 Cloud VPN 通道連線至公司網路。

只有叢集內的 Pod 才能直接通訊。節點會使用 SNAT 遮蓋 Pod IP 空間，以便與叢集外部的其他叢集、公司網路或連線的內部部署網路通訊。Pod 無法直接從其他叢集或公司網路連線。只有透過內部負載平衡器公開的服務，才能透過 VPC 網路對等互連連線存取。

這個架構模式與先前所述的 Cloud VPN 方法類似，但相較於該模式，具有下列優點：

  • 與 Cloud VPN 架構模式不同，虛擬私有雲網路對等互連不會產生任何額外費用，包括 Cloud VPN 通道或環境間的頻寬。
  • 虛擬私有雲網路對等互連沒有頻寬限制，且完全整合到 Google 的軟體定義網路中。因此，虛擬私有雲網路對等互連的延遲時間可能比 Cloud VPN 稍短，因為對等互連不需要 Cloud VPN 所需的閘道和處理程序。

不過，相較於 Cloud VPN 模型，虛擬私有雲網路對等互連模型也有下列缺點：

  • 貴機構需要未使用的公開 IP 位址空間，且空間大小足以容納您預期擁有的最大 GKE 叢集所需的 Pod IP 位址空間。
  • 虛擬私有雲網路對等互連不具遞移性。因此，透過虛擬私有雲網路對等互連連線至主要虛擬私有雲網路的 GKE 叢集，無法直接與彼此通訊，也無法與主要虛擬私有雲網路對等互連的虛擬私有雲網路中的應用程式通訊。您必須透過虛擬私有雲網路對等互連直接連線至這些網路，才能啟用這類通訊，或在主要虛擬私有雲網路中使用 Proxy VM。

使用多重 NIC 執行個體隱藏叢集位址

這個架構模式包含下列元件和技術，可建立類似於島嶼模式網路模型的模型：

  • 這項功能會使用多個網路介面卡 (多重 NIC) 的 Compute Engine 執行個體，在 GKE 叢集和主要 VPC 網路之間建立分隔層。
  • 並對這些環境之間傳送的 IP 位址使用 NAT。

當您需要檢查、轉換或篩選進出 GKE 叢集的特定流量時，可能會使用這個模式。如需執行這類檢查、轉換或篩選作業，請使用已部署的 Compute Engine 執行個體。

使用多重 NIC 執行個體隱藏叢集位址的優點如下：

  • GKE 叢集的 IP 位址空間會對網路其餘部分隱藏。每個服務只會向取用端 VPC 網路公開單一 IP 位址。
  • 服務可從已連線的內部部署網路和對等互連網路，在全球各地存取。

不過，使用多重 NIC 執行個體隱藏叢集位址有下列缺點：

  • 相較於其他方法，這個模型實作起來較為複雜，因為不僅需要實作模型，還需要為多重 NIC 執行個體設定監控和記錄功能。
  • 多重 NIC 執行個體有頻寬限制，且適用於 VM 執行個體定價。
  • 您需要管理及升級多 NIC 執行個體。

後續步驟