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

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

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

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

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

本文不涵蓋用於服務 IP 位址的位址範圍管理策略。服務所需的地址數量遠少於 Pod，且減少地址數量的選項有限。在 GKE 上，Service IP 位址範圍在叢集生命週期內是固定的。因此，服務 IP 位址範圍的大小必須能容納預期最大數量的服務。由於 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 Standard 叢集開始，這些叢集是以完全整合的網路模型為基礎。樹狀結構的下一個步驟是套用本文所述的所有選項，減少 IP 位址用量。

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

• 僅對地端部署網路隱藏 Pod IP 位址。符合下列條件時，請使用這個模型：
  • 您無法使用 RFC 6598 空間來減少內部 IP 位址用量。
  • 您可以使用 E 類/RFC 5735 位址空間，並向地端部署網路隱藏這個空間。
• 使用 Private Service Connect 隱藏 Pod IP 位址。 符合下列條件時，請使用這個模型：
  • 您無法使用 E 類/RFC 5735 位址空間。
  • 叢集不需要與較大網路上的服務進行私密通訊。
  • 您不需要從叢集區域以外的任何區域連線至叢集。
• 透過內部使用公開 IP 位址和虛擬私有雲網路對等互連，隱藏 Pod IP 位址。 雖然很少需要，但如果符合下列條件，請使用這個模型：
  • 您無法使用 E 類/RFC 5735 位址空間。
  • 叢集需要與較大網路上的服務進行私密通訊。
  • 貴組織已獲派一個未使用的公開 IP 位址空間，且空間大小足以容納最大的叢集。
• 使用 Cloud VPN 隱藏 Pod IP 位址。如果叢集不符合決策樹狀圖中列出的任何其他條件，請使用這個模型。

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

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

模擬其他網路模型

為充分發揮完全整合網路模型的優勢，建議您將 GKE 叢集與其他雲端資源放在同一個邏輯網路中。不過，您可能無法按照這項建議操作。您可能沒有足夠的 IP 位址空間，或必須對組織的大型網路隱藏 Pod IP 位址。

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

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

• 架構模式的說明。

• 圖表：說明如何實作該模式。

  每張實作圖表都顯示內部負載平衡器的使用情形。如果圖表中未顯示特定負載平衡器，建議您使用內部直通式網路負載平衡器。如要使用多個後端服務，建議改用內部應用程式負載平衡器。

• 討論該模式的優缺點。

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

隱藏地端部署網路 IP 位址的架構模式會結合下列路由目標：

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

這個架構模式通常會搭配 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 位址建立這個位址範圍。通常會使用 Class E/RFC 5735 空間。
2. 使用自訂廣告路由，並從 Cloud Router 的廣告中移除 Pod IP 位址範圍。移除這些位址有助於確保 Pod IP 範圍不會透過邊界閘道通訊協定 (BGP) 傳送至地端部署路由器。
3. 使用次要 IP 位址範圍做為 Pod 的無類別跨網域路由 (CIDR)，建立 GKE 叢集。您可以採用「減少 GKE 中的內部 IP 位址用量」一文所述的策略，減少 IP 位址用量。

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

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

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

按照上述步驟設定這個模式後，叢集就會有下列行為：

• Act like a fully integrated network model within Google Cloud.
• 與地端部署網路互動時，請採用島嶼模式網路模型。

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

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

上圖顯示如何對外部網路隱藏 Pod IP 位址。如這張圖所示，Pod 之間可以直接通訊，即使是跨叢集也沒問題。 Google Cloud 這種 Pod 通訊方式與 GKE 模型類似。請注意，圖表也顯示 Pod 使用 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 或 Service IP 位址範圍。
• 您可能需要管理兩組不同的防火牆規則：一組用於地端部署網路之間的流量，另一組用於完全在 Google Cloud內的流量。
• 在橫跨 Google Cloud 和地端部署或其他雲端服務供應商環境的多叢集服務網格中，您無法直接進行 Pod 對 Pod 通訊。舉例來說，使用 Istio 時，所有通訊都必須在 Istio 閘道之間進行。

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

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

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

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

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

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

使用 Cloud VPN 隱藏 Pod IP 位址

這種架構模式會使用 Cloud VPN，在 GKE 叢集和主要虛擬私有雲網路之間建立區隔。建立這項區隔後，產生的網路會與島嶼模式網路模型類似。與孤島模式模型一樣，這個模式的優點是可在叢集之間重複使用 Pod 和 Service IP 位址範圍。之所以能重複使用，是因為與叢集外部應用程式通訊時會使用 SNAT。流量離開節點前，節點會使用 SNAT 將 Pod IP 位址對應至自己的節點 IP 位址。

以下步驟說明如何設定這個模型：

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

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

   有時無法保留這麼大的 IP 位址範圍。 貴機構可能已將 Pod 和服務 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 隱藏 Pod IP 位址，建立類似於孤島模式網路模型的做法。如圖所示，每個 GKE 叢集都有專屬的虛擬私有雲網路。每個網路都有不同的節點 IP 位址空間，但使用相同的 Pod IP 位址空間。Cloud VPN 通道會將這些虛擬私有雲網路彼此連線，並連線至公司網路，且系統不會從含有叢集的虛擬私有雲網路宣傳 Pod IP 位址空間。

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

使用 Cloud VPN 隱藏 Pod IP 位址的優點如下：

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

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

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

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

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

如要設定這個架構模式，請按照下列步驟操作：

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

   針對叢集，請使用您公開 IP 位址指派作業中未使用的部分，定義兩個 IP 位址範圍：一個用於 Pod，另一個用於服務。請根據預計使用的最大 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 位址範圍。

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

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

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

這種架構模式與先前所述的 Cloud VPN 做法類似，但具有下列優點：

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

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

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

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

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

• 這個模式會使用具備多個網路介面卡 (多 NIC) 的 Compute Engine 執行個體，在 GKE 叢集和主要虛擬私有雲網路之間建立分隔層。
• 並在這些環境之間傳送的 IP 位址上使用 NAT。

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

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

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

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

• 這個模式比其他方法更難實作，因為除了實作模式，還需要為多 NIC 執行個體設定監控和記錄功能。
• 多 NIC 執行個體有頻寬限制，且須遵守 VM 執行個體定價。
• 您必須管理及升級多 NIC 執行個體。

後續步驟

• 隨附文件：比較 GKE 和其他 Kubernetes 實作項目使用的網路模型
• GKE 網路最佳做法
• 比較 AWS 和 Azure 服務與 Google Cloud
• 將容器遷移至 Google Cloud：將 Kubernetes 遷移至 GKE