GKE 網路的最佳做法

本文說明設定 Google Kubernetes Engine (GKE) 叢集網路選項的最佳做法。本指南旨在為雲端架構師和網路工程師提供架構規劃指引，並提供適用於大多數 GKE 叢集的叢集設定建議。建立 GKE 叢集之前，建議您先詳閱本頁所有章節，瞭解 GKE 支援的網路選項及其影響。

您選擇的網路選項會影響 GKE 叢集的架構。部分選項一經設定，就無法變更，除非重新建立叢集。

閱讀本頁內容前，請務必先熟悉 Kubernetes 網路概念和術語、一般網路概念，以及 Kubernetes 網路。詳情請參閱「 GKE 網路總覽」。

查看這些最佳做法時，請注意下列事項：

  • 您打算如何對虛擬私有雲 (VPC) 網路、叢集中的其他工作負載、其他 GKE 叢集，或網際網路公開工作負載。
  • 您打算如何調度工作負載資源。
  • 您想使用的 Google 服務類型。

如需所有最佳做法的檢查清單摘要，請參閱「檢查清單摘要」。

如要查看所有 GKE 最佳做法的整合式總覽，請參閱「GKE 最佳做法」。

VPC 設計最佳做法

設計虛擬私有雲網路時，請遵循虛擬私有雲設計的最佳做法。

下一節提供虛擬私有雲網路設計的 GKE 專屬建議。

最佳做法：

使用 VPC 原生叢集。
使用共用虛擬私有雲網路。

使用 VPC 原生叢集

建議使用 VPC 原生叢集。VPC 原生叢集會在 GKE 節點上使用別名 IP 位址範圍，且是根據虛擬私有雲網路對接的叢集和Shared VPC 上的叢集所需，並具有許多其他優點。在 Autopilot 模式下建立的叢集，虛擬私有雲原生模式一律會啟用，且無法關閉。

與使用路由的叢集相比，VPC 原生叢集更容易擴充，且不會耗用 Google Cloud 路由，因此較不容易達到路由限制。

使用 VPC 原生叢集的優點與別名 IP 支援息息相關。舉例來說，網路端點群組 (NEG) 只能搭配次要 IP 位址使用，因此僅支援 VPC 原生叢集。

使用共用虛擬私有雲網路

GKE 叢集需要審慎規劃 IP 位址。大多數機構都採用集中式管理結構，由網路管理團隊為叢集分配 IP 位址空間，並由平台管理員操作叢集。這類組織結構非常適合 Google Cloud的 Shared VPC 網路架構。在 Shared VPC 虛擬私有雲網路架構中，網路管理員可以建立子網路，並與 VPC 共用。您可以在服務專案中建立 GKE 叢集，並使用從主專案的 Shared VPC 共用的子網路。IP 位址元件會留在主專案中，其他叢集元件則位於服務專案。

一般來說，共用虛擬私有雲網路是常用的架構，適用於大多數有集中管理團隊的機構。建議使用 Shared VPC 網路為 GKE 叢集建立子網路，並避免整個機構發生 IP 位址衝突。您也可以使用 Shared VPC 來管理作業功能。舉例來說，您可以讓一個網路團隊專門負責網路元件和可靠性，另一個團隊則負責 GKE。

IP 位址管理策略

所有 Kubernetes 叢集 (包括 GKE 叢集) 都必須為每個 Pod 指派不重複的 IP 位址。詳情請參閱 GKE 網路模型。

在 GKE 中，所有這些 IP 位址都可在虛擬私有雲網路中路由傳送。因此，您必須規劃 IP 位址，因為位址不得與地端部署或其他連線環境中使用的內部 IP 位址空間重疊。以下各節提供使用 GKE 管理 IP 位址的策略建議。

最佳做法：

規劃所需的 IP 位址配額。
視需要使用非 RFC 1918 空間。
使用自訂子網路模式。
規劃每個節點的 Pod 密度。
避免與其他環境中使用的 IP 位址重疊。
建立負載平衡器子網路。
為叢集自動配置器保留足夠的 IP 位址空間。
跨叢集共用 IP 位址。
共用內部負載平衡器服務的 IP 位址。

規劃所需的 IP 位址配額

建議搭配使用 VPC 原生叢集和 Private Service Connect (PSC)。使用虛擬私有雲網路對等互連的叢集必須是 VPC 原生叢集。

VPC 原生叢集需要下列 IP 位址範圍：

  • 控制層 IP 位址範圍：使用 RFC 1918 中包含的 IP 位址私人範圍內的 /28 子網路。請務必確認這個子網路不會與虛擬私有雲網路中的任何其他無類別跨網域路由 (CIDR) 重疊。
  • 節點子網路：您要為叢集中的所有節點分配主要 IP 位址範圍的子網路。使用 cloud.google.com/load-balancer-type: "Internal" 註解的 LoadBalancer 類型服務也會預設使用這個子網路。您也可以使用專用子網路做為內部負載平衡器。
  • Pod IP 位址範圍：為叢集中的所有 Pod 分配的 IP 範圍。GKE 會將這個範圍佈建為子網路的別名。 詳情請參閱「虛擬私有雲原生叢集的 IP 位址範圍」。
  • 服務 IP 位址範圍：為叢集中的所有服務分配的 IP 位址範圍。GKE 會將這個範圍佈建為子網路的別名。

設定叢集網路時，您必須定義節點子網路、Pod IP 位址範圍和 Service IP 位址範圍。

如要更有效率地使用 IP 位址空間，請參閱「減少 GKE 中的內部 IP 位址用量」。

控制層 IP 位址範圍專用於 GKE 管理的控制層，該控制層位於與虛擬私有雲對等互連的 Google 管理租戶專案中。這個 IP 位址範圍不得與虛擬私有雲對等群組中的任何 IP 位址重疊，因為 GKE 會將這個路由匯入您的專案。也就是說，如果專案中有任何路徑指向相同的 CIDR，可能會發生轉送問題。

建立叢集時，子網路會為叢集的節點提供主要範圍，且子網路應在叢集建立前就存在。子網路應可容納叢集中的預期節點數上限，以及叢集內使用子網路的內部負載平衡器 IP 位址。

您可以使用叢集自動配置器限制節點數量上限。

Pod 和服務 IP 位址範圍會以子網路的不同次要範圍表示，並在 VPC 原生叢集中以別名 IP 位址的形式實作。

請選擇足夠寬廣的 IP 位址範圍，以便容納叢集的所有節點、Pod 和 Service。

請注意下列限制：

使用私人 RFC 1918 IP 位址以外的位址

在某些環境中，大型連續 CIDR 區塊中的 RFC 1918 空間可能已在機構中分配。如果 GKE 叢集的額外 CIDR 與 Google 擁有的公開 IP 位址不重疊，您可以使用非 RFC 1918 空間。建議使用 RFC 位址空間的 100.64.0.0/10 部分，因為E 類位址空間可能會導致地端部署硬體互通性問題。您可以使用私人重複使用的公開 IP (PUPI)。

使用私人的公開 IP 位址時，請謹慎操作，並考慮在選擇這個選項時，控管內部網路到網際網路的路由通告。

在具有 Pod 對 Pod 和 Pod 對 Service 流量的叢集中，不應使用來源網路位址轉譯 (SNAT)。這會破壞 Kubernetes 網路模型。

Kubernetes 會假設所有非 RFC 1918 IP 位址都是私人重複使用的公開 IP 位址，並對源自這些位址的所有流量使用 SNAT。

如果 GKE 叢集使用非 RFC 1918 IP 位址，對於 Standard 叢集，您需要明確停用 SNAT，或是設定 IP 偽裝代理程式，將叢集的 Pod IP 位址和 Service 的次要 IP 位址範圍從 SNAT 中排除。如為 Autopilot 叢集，則不需要任何額外步驟。

使用自訂子網路模式

設定網路時，您也會選取子網路模式：auto (預設) 或 custom (建議)。auto 模式會將子網路分配作業交由 Google 處理，因此是開始使用的好選擇，不必規劃 IP 位址。不過，建議您選取 custom 模式，因為這個模式可讓您選擇不會與環境中其他範圍重疊的 IP 位址範圍。如果您使用 Shared VPC，組織管理員或網路管理員都可以選取這個模式。

以下範例會建立名為 my-net-1 的網路，並使用自訂子網路模式：

gcloud compute networks create my-net-1 --subnet-mode custom

規劃每個節點的 Pod 密度

根據預設，Standard 叢集會從子網路的 Pod 位址空間中，為每個節點保留 /24 範圍，且每個節點最多可有 110 個 Pod。不過，您可以將 Standard 叢集設為每個節點最多支援 512 個 Pod，並為每個節點保留 /22 範圍。視節點大小和 Pod 的應用程式設定檔而定，每個節點上執行的 Pod 數量可能會大幅減少。

如果您預期每個節點不會執行超過 64 個 Pod，建議調整每個節點的 Pod 數量上限，以保留 Pod 子網路中的 IP 位址空間。

如果預期每個節點會執行超過預設的 110 個 Pod，您可以將每個節點的 Pod 數量上限調高至 512 個，每個節點保留 /22。如果採用這類高 Pod 密度設定，建議使用具備 16 個以上 CPU 核心的執行個體，確保叢集的可擴充性和效能。

如果是 Autopilot 叢集，每個節點的 Pod 數量上限會動態設為 256 個 (每個節點最多保留 /23 範圍)。您無法在 Autopilot 叢集中調整這項設定。

避免與其他環境中使用的 IP 位址重疊

您可以透過 Cloud VPN 或 Cloud Interconnect，將虛擬私有雲網路連線至地端部署環境或其他雲端服務供應商。這些環境可以共用路由，因此在規劃 GKE 的 IP 位址時，請務必考量地端部署 IP 位址管理機制。建議您確認 IP 位址不會與其他環境使用的 IP 位址重疊。

建立負載平衡器子網路

建立獨立的負載平衡器子網路，透過內部 TCP/UDP 負載平衡公開服務。如不使用獨立的負載平衡器子網路，這些服務會透過節點子網路的 IP 位址公開，這可能會導致該子網路中所有分配的空間提早用盡，並導致您無法將 GKE 叢集擴充至預期的節點數量。

使用獨立的負載平衡器子網路，也代表您可以將傳入和傳出 GKE 節點的流量，與內部 TCP/UDP 負載平衡公開的服務分開篩選，藉此設定更嚴格的安全邊界。

為叢集自動調度器預留足夠的 IP 位址空間

您可以使用叢集自動配置器，動態新增及移除叢集中的節點，藉此控管成本並提升使用率。不過，使用叢集自動配置器時，請務必確保 IP 位址規劃考量所有節點集區的大小上限。每個新節點都需要專屬的節點 IP 位址，以及根據每個節點設定的 Pod 數量，分配專屬的 Pod IP 位址集。每個節點的 Pod 數量可以與叢集層級的設定不同。叢集或節點集區建立後，您就無法變更每個節點的 Pod 數量。您應考量工作負載類型，並將其指派給不同的節點集區，以利最佳化 IP 位址分配。

建議搭配叢集自動調度器使用節點自動佈建功能，特別是使用 VPC 原生叢集時。詳情請參閱「節點限制範圍」。

在叢集間共用 IP 位址

如果您有集中式團隊負責管理叢集基礎架構，可能需要跨叢集共用 IP 位址。如要在 GKE 叢集之間共用 IP 位址，請參閱「在 GKE 叢集之間共用 IP 位址範圍」。您可以為 Pod、Service 和節點建立三個範圍，並重複使用或共用這些範圍，特別是在 Shared VPC 模型中，這樣就能減少 IP 耗盡的情況。這種設定也能讓網路管理員更輕鬆地管理 IP 位址，因為他們不必為每個叢集建立特定子網路。

請考量下列事項：

  • 最佳做法是為所有叢集使用不同的子網路和 IP 位址範圍。
  • 您可以共用次要 Pod IP 位址範圍，但建議不要這麼做，因為一個叢集可能會用完所有 IP 位址。
  • 您可以共用次要服務 IP 位址範圍，但這項功能不適用於 GKE 的虛擬私有雲範圍 Cloud DNS。

如果 IP 位址用盡，可以使用不連續的多 Pod CIDR 建立其他 Pod IP 位址範圍。

共用內部 LoadBalancer 服務的 IP 位址

單一 IP 位址最多可與 50 個後端共用，但須使用不同通訊埠。這樣一來，您就能減少內部 LoadBalancer 服務所需的 IP 位址數量。

詳情請參閱「共用 IP」。

網路安全最佳做法

本節將概述幾項叢集隔離的重要建議。GKE 叢集的網路安全是 Google 和叢集管理員的共同責任。

最佳做法：

使用 GKE Dataplane V2。
盡可能減少節點曝光。
盡量避免叢集控制層曝露。
授權存取控制層。
允許控制層連線。
從對等互連網路部署 Proxy，以存取控制層。
使用網路政策限制叢集流量。
為 Ingress 啟用 Google Cloud Armor 安全性政策。
使用 Identity-Aware Proxy 為 IAM 使用者驗證應用程式。
使用機構政策限制進一步提升安全性。

使用 GKE Dataplane V2

GKE Dataplane V2 以 eBPF 為基礎，提供整合式網路安全性和資料透明度體驗。使用 GKE Dataplane V2 建立叢集時，您不需要明確啟用網路政策，因為 GKE Dataplane V2 會管理服務轉送、網路政策強制執行和記錄。建立叢集時，請使用 Google Cloud CLI --enable-dataplane-v2 選項啟用新的資料平面。設定網路政策後，可以設定預設 NetworkLogging CRD 物件，記錄允許和拒絕的網路連線。建議您使用 GKE Dataplane V2 建立叢集，充分運用網路政策記錄等內建功能。

盡量減少節點曝光

在只有私人節點的叢集中，Pod 會與傳入和傳出通訊 (叢集邊界) 隔離。如要控制這些方向性流量，請使用負載平衡和 Cloud NAT 公開服務，詳情請參閱本文的「叢集連線」一節。下圖顯示這類設定：

圖 1： 私有節點通訊

這張圖表顯示具有私人節點的叢集如何通訊。地端部署用戶端可透過 kubectl 用戶端連線至叢集。Google 服務的存取權是透過 Private Google Access 提供，且只能使用 Cloud NAT 與網際網路通訊。

盡量減少叢集控制層的曝露風險

控制層有兩種叢集存取端點：

  • DNS 端點
  • 以 IP 為基礎的端點
最佳做法：

只使用以 DNS 為基礎的端點存取控制層，即可簡化設定，並享有彈性且以政策為基礎的安全層。

只要網路可透過 Google Cloud API 存取，就能存取 DNS 端點，包括地端部署或其他雲端網路。如要啟用 DNS 端點，請使用 --enable-dns-access 旗標。

GKE API 伺服器也可以公開或私人 IP 型端點的形式公開。建立叢集時，您可以決定要使用哪個端點。您可以透過授權網路控管存取權，公開和私人端點預設都會允許叢集中 Pod 和節點 IP 位址之間的所有通訊。如要在建立叢集時啟用私人端點，請使用 --enable-private-endpoint 旗標。

授權存取控制層

授權網路可協助指定哪些 IP 位址子網路可以存取 GKE 控制層節點。啟用這些網路後，您可以限制特定來源 IP 位址範圍的存取權。如果停用公開端點，這些來源 IP 位址範圍應為私人。如果啟用公開端點，您可以允許公開或內部 IP 位址範圍。設定自訂路由通告，允許從地端部署環境連線至叢集控制層的私人端點。建立叢集時，可以使用 --enable-master-global-access 選項，讓私有 GKE API 端點可從全球存取。

下圖顯示使用授權網路的典型控制層連線：

圖 2： 使用授權網路的控制層連線

這張圖表顯示受信任的使用者屬於授權網路，因此可以透過公開端點與 GKE 控制層通訊，而不受信任的行為人則會遭到封鎖。與 GKE 叢集之間的通訊會透過控制層的私人端點進行。

允許控制層連線

每個工作節點上的特定系統 Pod 都需要存取 Kubernetes API 伺服器 (kube-apiserver)、Google API 或中繼資料伺服器等服務。kube-apiserver 也需要與某些系統 Pod 通訊，例如 event-exporter。這項通訊預設為允許。如果您在專案中部署虛擬私有雲防火牆規則 (詳情請參閱「限制叢集流量」一節)，請確保這些 Pod 可以持續與 kube-apiserver 和 Google API 通訊。

部署 Proxy，以便從對等互連網路存取控制層

如果您的叢集使用 虛擬私有雲網路對等互連，您就無法從其他對等互連網路存取叢集的控制層。

如果使用中樞輻射架構，且想從其他對等互連網路或地端部署環境直接存取，請部署控制層流量的 Proxy。

使用網路政策限制叢集流量

叢集工作負載可結合多個層級的網路安全性：虛擬私有雲防火牆規則、階層式防火牆政策和 Kubernetes 網路政策。虛擬私有雲防火牆規則和階層式防火牆政策會在虛擬機器 (VM) 層級套用，也就是 GKE 叢集 Pod 所在的 worker 節點。Kubernetes 網路政策會在 Pod 層級套用，以強制執行 Pod 到 Pod 的流量路徑。

如果您實作虛擬私有雲防火牆，可能會中斷預設的必要控制層通訊，例如 kubelet 與控制層之間的通訊。GKE 預設會建立必要防火牆規則，但這些規則可以覆寫。部分部署作業可能需要控制層連線至服務上的叢集。您可以透過虛擬私有雲防火牆設定連入政策，讓服務可供存取。

GKE 網路政策是透過 Kubernetes 網路政策 API 設定，用於強制執行叢集的 Pod 通訊。建立叢集時，可以使用 gcloud container clusters create 選項 --enable-network-policy 啟用網路政策。如要使用網路政策限制流量，請參閱 Anthos 限制流量藍圖實作指南。

為 Ingress 啟用 Google Cloud Armor 安全性政策

您可以使用 Google Cloud Armor 安全性政策，在網路邊緣封鎖這類流量，保護使用外部應用程式負載平衡器的應用程式，免受 DDoS 攻擊和其他網路式攻擊。在 GKE 中，如要為應用程式啟用 Google Cloud Armor 安全性政策，請使用外部應用程式負載平衡器的 Ingress，並將安全性政策新增至附加至 Ingress 物件的 BackendConfig。

使用 Identity-Aware Proxy 為 IAM 使用者驗證應用程式

如果您想部署只有貴機構使用者才能存取的服務，但不想要求他們必須連上公司網路，可以使用 Identity-Aware Proxy 為這些應用程式建立驗證層。如要為 GKE 啟用 Identity-Aware Proxy，請按照設定步驟操作，將 Identity-Aware Proxy 新增為服務 Ingress 的 BackendConfig 一部分。Identity-Aware Proxy 可與 Google Cloud Armor 搭配使用。

使用機構政策限制進一步提升安全性

您可以使用組織政策限制設定政策，進一步強化資安態勢。舉例來說，您可以使用限制將負載平衡器建立作業限制為特定類型，例如僅限內部負載平衡器。

叢集連線能力資源調度

本節說明從叢集到網際網路和 Google 服務的 DNS 和輸出連線可擴充選項。

最佳做法：

將 Cloud DNS 用於 GKE。
啟用 NodeLocal DNSCache。
使用 Cloud NAT，以便透過叢集存取網際網路。
使用 Private Google Access 存取 Google 服務。

將 Cloud DNS 用於 GKE

您可以透過 Cloud DNS for GKE，使用代管 DNS 提供 Pod 和服務 DNS 解析功能，不必使用叢集代管 DNS 供應商。Cloud DNS 是 Google 代管服務，因此可免除管理叢集代管 DNS 伺服器的負擔，也不需要擴充、監控或管理 DNS 執行個體。

啟用 NodeLocal DNSCache

GKE 會使用 kube-dns，將叢集的本機 DNS 服務做為預設叢集外掛程式。kube-dns 會根據叢集中的核心和節點總數，在整個叢集中複製。

您可以透過 NodeLocal DNSCache 提升 DNS 效能。NodeLocal DNSCache 是以 DaemonSet 形式部署的外掛程式，不需要變更任何 Pod 設定。對本機 Pod 服務的 DNS 查詢不會建立需要在節點上追蹤的開啟連線，因此可擴大規模。外部主機名稱查詢會轉送至 Cloud DNS，所有其他 DNS 查詢則會傳送至 kube-dns。

啟用 NodeLocal DNSCache，確保 DNS 查詢的查詢時間更加一致，並提升叢集規模。如為 Autopilot 叢集，NodeLocal DNSCache 預設為啟用，且無法覆寫。

建立叢集時，下列 Google Cloud CLI 選項會啟用 NodeLocal DNSCache：--addons NodeLocalDNS.

如果您可以控制應用程式要解析的名稱，可以透過一些方法改善 DNS 擴充。舉例來說，請使用 FQDN (以半形句號結尾的主機名稱)，或透過 Pod.dnsConfig 資訊清單選項停用搜尋路徑擴展功能。

使用 Cloud NAT，以便透過叢集存取網際網路

根據預設，啟用私人節點的叢集沒有網路連線能力。如要允許 Pod 存取網際網路，請為每個區域啟用 Cloud NAT。至少要為 GKE 子網路的主要和次要範圍啟用 Cloud NAT。請務必為 Cloud NAT 和每個 VM 的通訊埠分配足夠的 IP 位址。

為叢集使用 Cloud NAT 時，請採用下列 Cloud NAT 閘道設定最佳做法：

  • 建立 Cloud NAT 閘道時，請只為叢集使用的子網路範圍啟用閘道。計算所有叢集中的所有節點，即可判斷專案中的 NAT 消費者 VM 數量。

  • 使用動態通訊埠分配功能，根據 VM 的用量，為每個 VM 分配不同數量的通訊埠。從最少 64 個連接埠和最多 2048 個連接埠開始。

  • 如果需要管理多個連線，且這些連線同時連往同一個 3 元組目的地，請將 TCP TIME_WAIT 逾時從預設值 120s 降低至 5s。詳情請參閱「修改 NAT 超時」。

  • 啟用 Cloud NAT 錯誤記錄，查看相關記錄。

  • 設定閘道後，請檢查 Cloud NAT 閘道記錄。如要減少分配狀態遭捨棄的問題，可能需要增加每個 VM 的通訊埠數量上限。

您應避免對 Pod 流量進行雙重 SNAT (先在 GKE 節點進行 SNAT，然後再次使用 Cloud NAT)。除非您需要 SNAT 來隱藏 Pod IP 位址，以連線至透過 Cloud VPN 或 Cloud Interconnect 連線的地端部署網路，否則請disable-default-snat將 SNAT 追蹤作業卸載至 Cloud NAT，以提高擴充性。這項解決方案適用於所有主要和次要子網路 IP 範圍。啟用 Cloud NAT 後，請使用網路政策限制外部流量。存取 Google 服務時，不需要 Cloud NAT。

使用 Private Google Access 存取 Google 服務

在具有私人節點的叢集中，Pod 沒有公開 IP 位址，因此無法連上公開服務，包括 Google API 和服務。Private Google Access 可讓私人Google Cloud 資源存取 Google 服務。

對於具有私人節點的叢集 (Shared VPC 叢集除外)，系統預設會啟用 Private Google Access。

應用程式擴充最佳做法

建立可從外部或貴機構內部存取的應用程式時，請務必使用正確的負載平衡器類型和選項。本節提供建議，說明如何使用 Cloud Load Balancing 公開及擴充應用程式。

最佳做法：

使用容器原生負載平衡。
選擇正確的 GKE 資源來公開應用程式。
根據 BackendConfig 建立健康狀態檢查。
使用本機流量政策保留原始 IP 位址。
使用 Private Service Connect。

使用容器原生負載平衡

使用 HTTP(S) 對外公開 Service 時，請使用容器原生負載平衡 。容器原生負載平衡可減少網路躍點、縮短延遲時間，並提供更精確的流量分配。此外，這項功能還能提高封包往返時間的能見度，並讓您使用負載平衡功能，例如 Google Cloud Armor。

選擇正確的 GKE 資源來公開應用程式

視用戶端範圍 (內部、外部，甚至是叢集內部)、應用程式的區域性，以及您使用的通訊協定而定，您可以選擇使用不同的 GKE 資源來公開應用程式。服務網路總覽說明瞭這些選項，並可協助您選擇最佳資源，透過 Google Cloud 負載平衡選項公開應用程式的各個部分。

根據 BackendConfig 建立健康狀態檢查

如果您使用 Ingress 公開服務，請在 BackendConfig CRD 中使用健康狀態檢查設定，以便使用外部應用程式負載平衡器的健康狀態檢查功能。您可以將健康狀態檢查導向適當的端點，並設定自己的門檻。如果沒有 BackendConfig CRD，系統會從完備性探測參數推論健康狀態檢查，或使用預設參數。

使用本機流量政策保留原始 IP 位址

使用內部直通式網路負載平衡器搭配 GKE 時，請將 externalTrafficPolicy 選項設為 Local，保留要求的來源 IP 位址。如果應用程式需要原始來源 IP 位址，請使用這個選項。不過，externalTrafficPolicy local 選項可能會導致負載分散效果不佳，因此請僅在必要時使用這項功能。如果是 HTTP(S) 服務，您可以使用 Ingress 控制器，並讀取 HTTP 要求中的 X-Forwarded-For 標頭，取得原始 IP 位址。

使用 Private Service Connect

您可以使用 Private Service Connect，在其他虛擬私有雲網路之間共用內部直通式網路負載平衡器服務。如果服務代管於 GKE 叢集，但為在不同專案和不同 VPC 中執行的客戶提供服務，這項功能就非常實用。

您可以透過 Private Service Connect，在 IP 位址重疊的虛擬私有雲之間建立連線，減少 IP 位址耗用量。

營運最佳做法

最佳做法：

使用 GKE 權限的 IAM，控管共用虛擬私有雲網路中的政策。
使用區域叢集並分配工作負載，以確保高可用性。
使用 Cloud Logging 和 Cloud Monitoring，並啟用網路政策記錄功能。

下列各節說明作業最佳做法，有助於確保工作負載的細部授權選項。如要避免手動建立防火牆規則，請按照本節的操作最佳做法執行相關作業。此外，這份指南也提供工作負載分配建議，以及如何在 GKE 中監控及記錄。

使用 GKE 權限的 IAM 控制共用虛擬私有雲網路中的政策

使用共用虛擬私有雲網路時，系統會在主專案中自動建立負載平衡器的防火牆規則。

為避免手動建立防火牆規則，請在名為 service-HOST_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com 的主機專案中，將最低權限的自訂角色指派給 GKE 服務帳戶。

將 HOST_PROJECT_NUMBER 替換為 Shared VPC 的主專案專案編號。

您建立的自訂角色應具備下列權限：

  • compute.firewalls.create
  • compute.firewalls.get
  • compute.firewalls.list
  • compute.firewalls.delete

此外，GKE 建立的防火牆規則一律採用預設優先順序 1000，因此您可以建立優先順序較高的防火牆規則，禁止特定流量流動。

如要限制建立特定類型的負載平衡器，請使用組織政策限制負載平衡器建立作業。

使用區域叢集並分配工作負載，確保高可用性

區域叢集：可提高叢集中應用程式的可用性，因為叢集控制層和節點會分散在多個可用區。

不過，為確保可用區發生故障時能提供最佳使用者體驗，請使用叢集自動配置器，確保叢集隨時都能處理所需負載。

您也可以使用 Pod 反相依性，確保特定服務的 Pod 會排程到多個可用區。

如要進一步瞭解如何設定這些選項，以實現高可用性和成本最佳化，請參閱「高可用性 GKE 叢集最佳做法」。

使用 Cloud Logging 和 Cloud Monitoring，並啟用網路政策記錄

雖然每個機構對可見度和稽核有不同的要求，但我們建議啟用網路政策記錄。這項功能僅適用於 GKE Dataplane V2。網路政策記錄檔可讓您瞭解政策強制執行情況和 Pod 流量模式。請注意，網路政策記錄會產生費用。

如果 GKE 叢集使用 1.14 以上版本，系統預設會啟用 記錄和監控功能。Monitoring 提供 GKE 叢集的資訊主頁。啟用記錄功能後，您也可以使用 VPC 流量記錄的 GKE 註解。根據預設，Logging 會收集部署至叢集的所有工作負載記錄，但您也可以只收集系統記錄。使用 GKE 資訊主頁觀察及設定快訊。如為在 Autopilot 模式建立的叢集，系統會自動啟用監控和記錄功能，且無法進行設定。

請注意，Google Cloud Observability 會產生費用。

平均分配流量的最佳做法

本節提供平均分配流量的建議做法。實作這些做法前，請務必先適當監控 (例如使用 Prometheus、Cloud Monitoring 或雲端服務供應商的監控服務)，找出並確認分配不均的模式。

停用或謹慎設定工作階段相依性

如要解決這個問題，請停用工作階段相依性 (除非絕對必要)。在 Service 資訊清單中設定 sessionAffinity: None。如果必須使用工作階段親和性，請仔細考量影響，並監控 Pod 負載。工作階段相依性可確保使用者在工作階段期間，持續連線至同一個後端。

使用加權負載平衡

如要採用這項做法，請將服務設為使用加權負載平衡。加權負載平衡會根據每個節點的正常 Pod 數量分配流量。負載平衡器會根據 GKE 節點中健康 Pod 的數量，按比例將新連線傳送至該節點。在 GKE 中，外部直通式網路負載平衡器可使用加權負載平衡，讓處理流量的 Pod 數量較多的節點，接收較大比例的新連線。

如要啟用加權負載平衡，您必須符合下列規定，並使用特定註解設定 Service：

  • GKE 叢集版本：GKE 叢集必須使用 1.31.0-gke.1506000 以上版本。
  • HTTP 負載平衡外掛程式：必須為叢集啟用 HttpLoadBalancing 外掛程式 (預設為啟用)。如果叢集版本為 1.36 以上，則後端服務不需使用這個外掛程式。
  • 後端服務型負載平衡器：將 Service 資訊清單中的 spec.loadBalancerClass 欄位設為 networking.gke.io/l4-regional-external，確保 GKE 建立後端服務型外部直通式網路負載平衡器。這個欄位需要 GKE 1.33.1-gke.1779000 以上版本。目標集區型負載平衡器不支援加權負載平衡。
  • 加權負載平衡註解：在 Service 資訊清單中加入 networking.gke.io/weighted-load-balancing: pods-per-node 註解。
  • 外部流量政策：Service 資訊清單必須使用 externalTrafficPolicy: Local。雖然允許使用 externalTrafficPolicy: Cluster，但這會有效停用加權負載平衡，因為封包可能會在初始負載平衡器分配後，路由至其他節點。
  1. 將下列資訊清單範例儲存為 weighted-lb-service.yaml：
apiVersion: v1
kind: Service
metadata:
  name: my-weighted-service
  annotations:
    networking.gke.io/weighted-load-balancing: pods-per-node
spec:
  type: LoadBalancer
  loadBalancerClass: networking.gke.io/l4-regional-external
  externalTrafficPolicy: Local
  selector:
    app: my-app
  ports:
    -   protocol: TCP
      port: 80
      targetPort: 8080

  1. 將資訊清單套用至叢集：

    kubectl apply -f weighted-lb-service.yaml

這項設定會根據每個節點上的 Pod 數量，按比例分配新連線，避免後端執行個體過度負載。此外，由於 externalTrafficPolicy: Local，這項功能也會保留用戶端 IP 位址親和性和應用程式的原始用戶端來源 IP 位址。

確保 Pod 平均分配到各個節點

使用 Pod 反相依性，避免將相同服務的 Pod 排程至同一節點。在 Deployment 資訊清單中定義 Pod 反親和性規則。

以下範例顯示具有 Pod 反親和性的 Deployment 資訊清單：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 6
  template:
    metadata:
      labels:
        app: my-app
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          -   labelSelector:
              matchExpressions:
              -   key: app
                operator: In
                values:
                -   my-app
            topologyKey: "kubernetes.io/hostname"

查看外部流量政策

使用 Cluster 做為 externalTrafficPolicy，讓負載平衡器將流量分配到叢集中的任何節點。在 Service 資訊清單中設定 externalTrafficPolicy: Cluster。如要將流量平均分配到所有節點，請使用這項設定。

如果使用 Local，請確保 Pod 平均分配到各個節點。

停用節點親和性

如果發生熱點，請從部署作業中移除親和性設定。

使用完備性探測

在 Pod 上設定 readiness 探測。在 Pod 資訊清單中定義就緒探測。這可確保負載平衡器只會將流量傳送至準備好處理要求的 Pod。

以下範例顯示含有就緒探針的 Pod 資訊清單：

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  -   name: my-container
    image: my-image
    readinessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10

使用容器原生負載平衡

盡可能使用容器原生負載平衡。負載平衡器會直接將流量分配給 Pod，而非節點。這可改善流量分配並縮短延遲時間。詳情請參閱「關於 GKE 中的負載平衡」。

考慮使用拓撲感知路由

建議使用拓撲感知路由。這項功能可將流量保留在來源區域，藉此提升效能並降低成本。如果傳入流量平均分配，且 Kubernetes 服務在每個可用區都有三個以上的端點，這項功能就能發揮最大效益。詳情請參閱「流量分配疑難排解」。

Cloud Service Mesh

如要更精細地控制流量分配、進階路由政策和觀測功能，請考慮導入 Istio 等 Cloud Service Mesh。Cloud Service Mesh 在應用程式層運作，並提供進階的流量管理功能。

檢查清單摘要

區 練習
虛擬私有雲設計
IP 位址管理策略
網路安全性選項
縮放
提供應用程式
營運與管理
平均分配流量

後續步驟