關於 LoadBalancer 服務

本頁面提供一般總覽，說明您套用 Kubernetes LoadBalancer 服務資訊清單時，Google Kubernetes Engine (GKE) 如何建立及管理 Google Cloud 負載平衡器。內容包括 LoadBalancer 類型、設定參數，以及最佳做法建議。

閱讀本頁內容前，請務必熟悉 GKE 網路概念。

總覽

建立 LoadBalancer Service 時，GKE 會設定 Google Cloud 直通負載平衡器，其特性取決於 Service 資訊清單的參數。

自訂 LoadBalancer Service

選擇要使用的 LoadBalancer 服務設定時，請考量下列層面：

LoadBalancer Service 決策樹。
圖： LoadBalancer Service 決策樹

負載平衡器類型 - 內部或外部

在 GKE 中建立 LoadBalancer Service 時，請指定負載平衡器是否具有內部或外部位址：

  • 外部 LoadBalancer 服務是使用區域外部直通式網路負載平衡器實作。 位於虛擬私有雲網路外部的用戶端和 Google Cloud 可存取網際網路的 VM，可以存取外部 LoadBalancer 服務。

    如要建立外部 LoadBalancer 服務，請使用下列其中一個技巧：

    • 在執行 GKE 1.37 以上版本的叢集中，GKE 會自動建立以區域外部直通式網路負載平衡器為基礎的後端服務，並使用 GCE_VM_IP NEG 後端。您不需要在服務資訊清單中新增任何註解或欄位。如要明確建立以舊版目標集區為基礎的負載平衡器，請新增 spec.loadBalancerClass: "networking.gke.io/l4-regional-external-legacy" 欄位值組。

    • 在執行 GKE 1.33.1-gke.1779000 至 1.36 的叢集中，請先在服務資訊清單中加入 spec.loadBalancerClass: "networking.gke.io/l4-regional-external"，再將資訊清單提交至叢集。建議您使用這個欄位，因為系統一律會建立以區域外部直通式網路負載平衡器為基礎的後端服務，並搭配 GCE_VM_IP NEG 後端。spec.loadBalancerClass 欄位不可變動，服務建立後即無法變更。

    • 在執行任何支援 GKE 版本的叢集中，您可以在將資訊清單提交至叢集前，將 cloud.google.com/l4-rbs: "enabled" 註解新增至 Service 資訊清單。這個註解也會建立以後端服務為基礎的區域性外部直通式網路負載平衡器。如果將資訊清單提交至執行 GKE 1.32.2-gke.1652000 以上版本的叢集，負載平衡器會使用 GCE_VM_IP NEG 後端。否則，負載平衡器會使用執行個體群組後端。只有在首次將 Service 資訊清單套用至叢集時，GKE 才會評估這項註解。

  • 內部 LoadBalancer 服務是透過內部直通式網路負載平衡器實作。位於相同虛擬私有雲網路或連線至叢集虛擬私有雲網路的網路中的用戶端，可以存取內部 LoadBalancer Service。

    最佳做法是先啟用 GKE 子集化，再建立內部 LoadBalancer Service。如果叢集執行 GKE 1.36 以上版本，系統會自動啟用 GKE 子集。如果是較舊的 GKE 版本，您應明確啟用 GKE 子集化。

    如要建立內部 LoadBalancer 服務，請使用下列其中一個技巧：

    • 在執行 GKE 1.33.1-gke.1779000 以上版本的叢集中，如果已啟用 GKE 子集，請先將 spec.loadBalancerClass: "networking.gke.io/l4-regional-internal" 新增至 Service 資訊清單，再將資訊清單提交至叢集。建議您使用這個欄位，因為系統一律會建立具有 GCE_VM_IP NEG 後端的內部直通式網路負載平衡器。spec.loadBalancerClass 欄位不可變動，且服務建立後即無法變更。

    • 在執行任何支援 GKE 版本的叢集中，您可以在將資訊清單提交至叢集前，將 networking.gke.io/load-balancer-type: "Internal" 註解新增至 Service 資訊清單。這也會建立內部直通式網路負載平衡器。如果將資訊清單提交至已啟用 GKE 子集化的叢集，負載平衡器會使用 GCE_VM_IP NEG 後端。否則負載平衡器會使用執行個體群組後端。

如果叢集執行的 GKE 版本早於 1.37，且 LoadBalancer 服務資訊清單沒有 spec.loadBalancerClass，也沒有 cloud.google.com/l4-rbs: "enabled" 或 networking.gke.io/load-balancer-type: "Internal" 註解，就會建立以目標集區為基礎的區域外部直通網路負載平衡器。不建議使用以目標集區為基礎的區域性外部直通式網路負載平衡器。

HttpLoadBalancing 必要條件

如要建立由後端服務型區域外部直通式網路負載平衡器或內部直通式網路負載平衡器支援的 LoadBalancer Service，請確認叢集執行的 GKE 版本早於 1.36 時，已啟用 HttpLoadBalancing 外掛程式。HttpLoadBalancing 外掛程式預設為啟用。

在 GKE 1.36 以上版本中，LoadBalancer Service 不會依附於 HttpLoadBalancing 外掛程式。

externalTrafficPolicy 的影響

externalTrafficPolicy 參數可控制下列項目：

  • 哪些節點會接收負載平衡器的封包
  • 負載平衡器將封包傳送至節點後，封包是否可能會在叢集中的節點之間路由傳送
  • 原始用戶端 IP 位址是否保留或遺失

externalTrafficPolicy 可以是 Local 或 Cluster：

  • 使用 externalTrafficPolicy: Local 可確保封包「只」傳送至至少有一個服務中、就緒、非終止 Pod 的節點，並保留原始用戶端來源 IP 位址。如果工作負載的節點數量相對穩定，且節點提供 Pod 服務，即使叢集中的節點總數有所變動，也適合使用這個選項。如要支援加權負載平衡，就必須使用這個選項。
  • 如果叢集中的節點總數相對穩定，但提供 Pod 服務的節點數量有所變動，請使用 externalTrafficPolicy: Cluster。這個選項不會保留原始用戶端來源 IP 位址，而且可能會增加延遲時間，因為封包傳送到節點後，可能會從負載平衡器遞送至另一個節點上的服務 Pod。這個選項與加權負載平衡不相容。

如要進一步瞭解 externalTrafficPolicy 如何影響節點內的封包路徑，請參閱「封包處理」。

加權負載平衡

外部 LoadBalancer 服務支援加權負載平衡，因此與 Pod 數量較少的節點相比，處理流量的 Pod 數量較多的節點可接收較大比例的新連線。如要進一步瞭解負載平衡器設定如何隨著加權負載平衡而變更，請參閱「加權負載平衡的影響」。

加權負載平衡流量分配。
圖： 加權負載平衡流量分配

如圖所示，啟用加權負載平衡的服務會根據每個節點上就緒 Pod 的數量，按比例分配新連線。

如要使用加權負載平衡，必須符合下列所有條件：

  • GKE 叢集必須使用 1.31.0-gke.1506000 以上版本。

  • 您必須建立外部 LoadBalancer 服務，產生以後端服務為基礎的區域外部直通式網路負載平衡器。

    • 在執行 GKE 1.37 以上版本的叢集中，GKE 預設會建立這類負載平衡器。無須新增其他欄位或註解。

    • 在執行 GKE 1.33.1-gke.1779000 至 1.36 的叢集中，請先將 spec.loadBalancerClass: "networking.gke.io/l4-regional-external" 新增至 Service 資訊清單，再將資訊清單提交至叢集。建議使用這個方法。

    • 在執行任何支援 GKE 版本的叢集中，將 cloud.google.com/l4-rbs: "enabled" 註解新增至服務資訊清單，然後將資訊清單提交至叢集。

  • 您必須在 Service 資訊清單中加入 networking.gke.io/weighted-load-balancing: pods-per-node 註解，才能啟用加權負載平衡功能。

  • LoadBalancer Service 資訊清單必須使用 externalTrafficPolicy: Local。 GKE 不會禁止您使用 externalTrafficPolicy: Cluster，但 externalTrafficPolicy: Cluster 會有效停用加權負載平衡，因為封包可能會在負載平衡器之後，路由至其他節點。

如要使用加權負載平衡，請參閱「啟用加權負載平衡」。

可用區相依性

內部 LoadBalancer 服務支援可用區相依性，可將新連線轉送至與用戶端位於同一個可用區的節點，並提供 Pod 服務。如果可用區中沒有狀況良好的 Pod，GKE 會將流量轉送至其他可用區。將流量維持在單一區域內，可盡量減少跨區域流量，進而降低費用和延遲時間。如要在 GKE 叢集中啟用可用區親和性，必須先啟用 GKE 子集。

為內部 LoadBalancer Service 設定可用區親和性時，GKE 會使用 ZONAL_AFFINITY_SPILL_CROSS_ZONE 選項和零溢出比率 (0.0)，設定對應的內部直通式網路負載平衡器。這項設定有助於確保流量在區域內下降，而不是溢出至其他區域。如果所有下列條件都成立，負載平衡器會將符合資格的節點後端原始集合，縮減為與用戶端位於相同區域的節點後端：

  • 用戶端與可用區相依性相容。

  • 用戶端所在區域至少有一個健康狀態良好且符合資格的節點後端。

在所有其他情況下，負載平衡器會繼續使用原始的一組符合資格的節點後端，不會套用任何區域親和性最佳化。

如要進一步瞭解可用區相依性設定對負載平衡器行為的影響，請參閱可用區相依性說明文件。如要進一步瞭解區域親和性和 externalTrafficPolicy 如何影響節點 VM 上的封包路徑，請參閱「節點上的來源網路位址轉譯和路徑」。

可用區相依性的擴充考量

由於區域親和性不會與 HorizontalPodAutoscaler (HPA) 原生整合，當區域內的流量超過該區域 Pod 的容量時，可能會發生擴縮問題。HPA 會根據叢集匯總指標 (而非每個區域的負載) 調度 Pod。因此，如果可用區流量過高 (可用區過載)，可能不會收到額外的 Pod，導致該可用區的用戶端效能降低或連線中斷，即使叢集整體使用率偏低也一樣。

���部 LoadBalancer Service 的特別注意事項

本節說明 GKE 子集功能 (內部 LoadBalancer Service 獨有)，以及 GKE 子集���何與 externalTrafficPolicy 互動，進而影響負載平衡節點的數量上限。

GKE 子設定

如果 GKE 叢集執行 1.36 以上版本，系統預設會啟用內部 LoadBalancer 服務的 GKE 子設定。對於這些版本，即使叢集層級 --enable-l4-ilb-subsetting 旗標在叢集設定或基礎架構即程式碼 (IaC) 工具 (例如 Terraform) 中設為 false，GKE 子集仍會保持啟用狀態。

這個叢集層級的設定選項可將節點端點更有效率地分組到GCE_VM_IP網路端點群組 (NEG) 中，進而提升內部直通式網路負載平衡器的擴充性。NEG 會做為負載平衡器的後端。

下圖顯示區域叢集中的兩個服務，該叢集有三個節點。叢集已啟用 GKE 子集。每個服務都有兩個 Pod。GKE 會為每個 Service 建立一個 GCE_VM_IP NEG。每個 NEG 中的端點都是節點，其中包含各個 Service 的服務 Pod。

可用區叢集上兩個服務的 GKE 子集。

對於執行 1.36 之前版本的叢集，您可以在建立叢集或更新現有叢集時，手動啟用 GKE 子設定。啟用 GKE 子設定後，就無法停用。

GKE 子設定需要：

  • GKE 1.18.19-gke.1400 以上版本，以及
  • 如果叢集版本低於 1.36，則必須啟用 HttpLoadBalancing 外掛程式。這項外掛程式預設為啟用。叢集可藉此管理使用後端服務的負載平衡器。如果叢集使用 1.36 以上版本，HttpLoadBalancing 外掛程式就不是 GKE 子集化的必要條件。

節點數

如果叢集的節點總數 (所有節點集區) 超過 250 個，停用 GKE 子設定的叢集可能會發生內部 LoadBalancer 服務問題。這是因為 GKE 建立的內部直通式網路負載平衡器，只能將封包分配給最多 250 個後端節點 VM。這項限制的原因如下：

  • GKE 不會使用負載平衡器後端子集。
  • 如果停用負載平衡器後端子設定，內部直通式網路負載平衡器最多只能將封包分配給 250 個後端。

如果叢集總節點數超過 250 個，具有 GKE 子集功能的叢集支援叢集中的內部 LoadBalancer 服務。

GKE 子集支援的節點數量取決於內部 LoadBalancer Service 的 externalTrafficPolicy 欄位值：

  • externalTrafficPolicy: Local：最多可支援 250 個節點，並為特定服務提供服務 Pod。

  • externalTrafficPolicy: Cluster：不會限制提供服務 Pod 的節點數量。發生這種情況的原因是，GKE 會為每個 Service 在 GCE_VM_IP NEG 中設定最多 25 個節點端點。詳情請參閱「節點在 GCE_VM_IP NEG 後端的成員資格」。

流量分配

根據預設，內部和外部 LoadBalancer 服務會建立直通式網路負載平衡器，並將工作階段相依性設為 NONE。直通式網路負載平衡器會使用工作階段親和性、健康狀態資訊，以及 (在特定情況下) 權重等詳���資料，找出並選取符合資格的節點後端來建立新連線。

新連線會建立連線追蹤資料表項目，用於將連線的後續封包快速路由至先前選取的合格節點後端。如要進一步瞭解直通式網路負載平衡器如何識別及選取符合資格的後端，以及如何使用連線追蹤功能，請參閱下列文章：

加權負載平衡的影響

為外部負載平衡器服務設定加權負載平衡時，GKE 會在對應的區域外部直通式網路負載平衡器上啟用加權負載平衡。GKE 會設定 kube-proxy 或 cilium-agent 軟體，在負載平衡器健康狀態檢查的回應中加入回應標頭。這個回應標頭定義的權重，與每個節點上放送、就緒且未終止的 Pod 數量成正比。

負載平衡器會依下列方式使用權重資訊：

  • 負載平衡器的合格節點後端集包含所有運作狀態良好、權重不為零的節點。

  • 負載平衡器選取符合資格的節點後端時，會將權重納入考量。如果 Service 使用 externalTrafficPolicy: Local (加權負載平衡必須使用此設定)，系統會優先選取有較多服務中、就緒且不會終止的 Pod 的合格節點後端，而非 Pod 較少的合格節點後端。

節點分組

GKE 版本、Service 資訊清單註解，以及內部 LoadBalancer Service 的 GKE 子設定選項，會決定產生的 Google Cloud 負載平衡器和後端類型。

下表列出不同 LoadBalancer 服務設定的節點分組方法：

服務和叢集詳細資料 產生的 Google Cloud 負載平衡器 節點分組方式
內部 LoadBalancer 服務
叢集中的 GKE 版本為 1.33.1-gke.1779000 以上，且已啟用 GKE 子設定 1。提交至叢集的服務資訊清單，其中包含 spec.loadBalancerClass: "networking.gke.io/l4-regional-internal"。 後端服務使用GCE_VM_IP網路端點群組 (NEG) 後端的內部直通式網路負載平衡器

節點 VM 會根據服務和叢集中的節點數量，按服務分組到區域 NEG 中GCE_VM_IPexternalTrafficPolicy。

Service 的 externalTrafficPolicy 也會控管哪些節點通過負載平衡器健康狀態檢查，以及封包處理。

叢集中所有支援的 GKE 版本，且已啟用 GKE 子集1。提交至叢集的服務資訊清單，並附上 networking.gke.io/load-balancer-type: "Internal" 註解。
叢集中的 GKE 版本早於 1.36，且 GKE 子集已停用1。提交至叢集的服務資訊清單，並附上 networking.gke.io/load-balancer-type: "Internal" 註解。 後端服務使用區域性非受管理執行個體群組後端的內部直通式網路負載平衡器

所有節點 VM 都會放置在區域非代管執行個體群組中，GKE 會將這些群組做為內部直通式網路負載平衡器後端服務的後端。

Service 的 externalTrafficPolicy 控制項會決定哪些節點通過負載平衡器健康狀態檢查，以及封包處理。

由於單一負載平衡執行個體群組的限制，叢集中建立的其他負載平衡器後端服務也會使用相同的非受管理執行個體群組。
外部 LoadBalancer 服務
GKE 1.37 以上版本。服務資訊清單已提交至叢集，但未包含 spec.loadBalancerClass: "networking.gke.io/l4-regional-external-legacy" 欄位值配對。 以後端服務為基礎的區域外部直通式網路負載平衡器，具有GCE_VM_IP 網路端點群組 (NEG) 後端

節點 VM 會根據服務和叢集中的節點數量，按服務分組到區域 NEG 中GCE_VM_IP。externalTrafficPolicy

Service 的 externalTrafficPolicy 也會控管哪些節點通過負載平衡器健康狀態檢查，以及封包處理。

GKE 1.33.1-gke.1779000 至 1.36 版。提交至叢集的服務資訊清單，其中包含 spec.loadBalancerClass: "networking.gke.io/l4-regional-external" 欄位值組。
GKE 版本 1.32.2-gke.1652000 至 1.36。提交至叢集的 Service 資訊清單，並附上 cloud.google.com/l4-rbs: "enabled" 註解2。
GKE 版本早於 1.32.2-gke.16520003。提交至叢集的 Service 資訊清單，並附上 cloud.google.com/l4-rbs: "enabled" 註解2。 後端服務型區域外部直通式網路負載平衡器，具有區域 非受管理執行個體群組後端

所有節點 VM 都會放入區域性非受管理執行個體群組，GKE 會將這些群組做為區域外部直通式網路負載平衡器後端服務的後端。

Service 的 externalTrafficPolicy 控制項會決定哪些節點通過負載平衡器健康狀態檢查，以及封包處理。

由於單一負載平衡執行個體群組的限制，叢集中建立的其他負載平衡器後端服務也會使用相同的非受管理執行個體群組。

1.37 版之前的 GKE 版本。提交至叢集的服務資訊清單缺少下列所有項目：

  • spec.loadBalancerClass
  • networking.gke.io/load-balancer-type 個註解
  • cloud.google.com/l4-rbs 個註解


或

GKE 1.37 以上版本。提交至叢集的服務資訊清單，其中包含 spec.loadBalancerClass: "networking.gke.io/l4-regional-external-legacy" 欄位值組。

 目標集區型區域性外部直通式網路負載平衡器，其目標集區包含叢集的所有節點

目標集區是較舊的 API，不依賴 NEG 或執行個體群組。所有節點都直接屬於目標集區。

Service 的 externalTrafficPolicy 控制項會決定哪些節點通過負載平衡器健康狀態檢查，以及封包處理。

1在 GKE 1.36 以上版本中，系統會自動啟用 GKE 子設定。啟用 GKE 子網路後即無法停用。

2只有在將 Service 資訊清單提交至叢集時，系統才會採用 cloud.google.com/l4-rbs: "enabled" 註解。在現有服務資訊清單中新增這項註解，不會將目標集區型區域外部直通式網路負載平衡器，轉換為後端服務型區域外部直通式網路負載平衡器。

3 GKE 不會自動將具備執行個體群組後端的後端服務型區域外部直通式網路負載平衡器，更新為具備 GCE_VM_IP NEG 後端的後端服務型區域外部直通式網路負載平衡器。如需手動遷移操作說明，請參閱「 遷移至 GCE_VM_IP NEG 後端」。

GCE_VM_IP NEG 後端的節點成員資格

當 GKE 建立內部直通式網路負載平衡器，或以後端服務為基礎的區域外部直通式網路負載平衡器 (含 GCE_VM_IP NEG 後端) 時，會建立及管理 NEG，如下所示：

  • GKE 會為每個 LoadBalancer 服務，在每個可用區中建立專屬的 NEG。GCE_VM_IP與執行個體群組不同，節點可以屬於多個負載平衡的 GCE_VM_IP NEG。

  • Service 的 externalTrafficPolicy 和叢集中的節點數量，決定要將哪些節點新增為 Service 的 GCE_VM_IP NEG。

叢集的控制層會根據 Service 的 externalTrafficPolicy 值和叢集中的節點數量，管理 GCE_VM_IP NEG 中的節點端點，如下表所示。

內部直通式網路負載平衡器中的節點

externalTrafficPolicy 叢集中的節點數量 端點成員資格
Cluster 1 到 25 個節點 即使節點不含 Service 的服務 Pod，GKE 仍會將叢集中的所有節點做為 Service 的 NEG 端點。
Cluster 超過 25 個節點 即使節點不含 Service 的服務 Pod，GKE 仍會使用最多 25 個節點的隨機子集，做為 Service 的 NEG 端點。
Local 任意數量的節點1 GKE 只會使用至少有一個 Service 的服務 Pod 做為 Service NEG 端點的節點。

1最多 250 個提供服務的 Pod 節點。叢集中可以有超過 250 個節點，但如果停用內部直通式網路負載平衡器後端子設定，內部直通式網路負載平衡器就只能分配給 250 個後端 VM。即使啟用 GKE 子設定，GKE 也絕不會設定內部直通式網路負載平衡器後端子設定，如要瞭解這項限制的詳細資訊，請參閱「每個內部後端服務的 VM 執行個體數量上限」。

區域性外部直通式網路負載平衡器中的節點

externalTrafficPolicy 叢集中的節點數量 端點成員資格
Cluster 1 到 250 個節點 即使節點不含 Service 的服務 Pod，GKE 仍會將叢集中的所有節點做為 Service 的 NEG 端點。
Cluster 超過 250 個節點 即使節點不含 Service 的服務 Pod，GKE 仍會使用最多 250 個節點的隨機子集，做為 Service 的 NEG 端點。
Local 任意數量的節點1 GKE 只會使用至少有一個 Service 的服務 Pod 做為 Service NEG 端點的節點。

1最多 3,000 個節點(含供應 Pod)。叢集中可有超過 3,000 個節點，但 GKE 建立使用 GCE_VM_IP NEG 後端的後端服務型區域外部直通式網路負載平衡器時，最多只支援建立 3,000 個端點。

單一負載平衡執行個體群組限制

Compute Engine API 禁止 VM 成為多個負載平衡執行個體群組的成員。GKE 節點會受到這項限制。

使用非代管執行個體群組後端時，GKE 會建立或更新非代管執行個體群組，其中包含叢集所用每個區域中所有節點集區的所有節點。這些非代管執行個體群組是下列 GKE 建立的負載平衡器後端：

  • 為內部 LoadBalancer 服務建立的內部直通式網路負載平衡器，其資訊清單具有 networking.gke.io/load-balancer-type: "Internal" 註解，並提交至執行 GKE 1.36「之前」版本的叢集，且 GKE 子設定已停用。
  • 為外部 LoadBalancer 服務建立的後端服務型區域外部直通式網路負載平衡器，該服務的資訊清單具有 cloud.google.com/l4-rbs: "enabled" 註解，並提交至執行 GKE 版本早於 1.32.2-gke.1652000 的叢集。
  • 使用 GKE Ingress 控制器為外部 GKE Ingress 建立的外部應用程式負載平衡器，但未使用容器原生負載平衡。

由於節點 VM 無法成為多個負載平衡執行個體群組的成員，因此如果符合下列任一條件，GKE 就無法建立及管理下列項目：

  • 在 GKE 外部，您至少建立了一個以負載平衡器為基礎的後端服務，並使用叢集的代管執行個體群組做為負載平衡器後端服務的後端。
  • 在 GKE 外部，您可以建立自訂非代管執行個體群組，其中包含部分或所有叢集節點，然後將該自訂非代管執行個體群組附加至負載平衡器的後端服務。

如要避開這項限制，可以指示 GKE 使用 NEG 後端：

  • 建立使用 GCE_VM_IP NEG 的 LoadBalancer Service。詳情請參閱「節點分組」。
  • 設定外部 GKE Ingress 資源，以使用容器原生負載平衡。詳情請參閱「GKE 容器原生負載平衡」。

負載平衡器健康狀態檢查

所有 GKE LoadBalancer Service 都會實作負載平衡器健康狀態檢查。負載平衡器健康狀態檢查系統是在叢集外部運作，與 Pod 的就緒、存活或啟動探測不同。

負載平衡器健康狀態檢查封包會由每個節點上執行的kube-proxy軟體 (適用於未使用 GKE Dataplane V2 的叢集) 或cilium-agent軟體 (適用於使用 GKE Dataplane V2 的叢集) 回應。Pod 無法回應 LoadBalancer 服務的負載平衡器健康狀態檢查。

Service 的 externalTrafficPolicy 會決定哪些節點通過負載平衡器健康狀態檢查。如要進一步瞭解負載平衡器如何使用健康狀態檢查資訊，請參閱「流量分配」。

externalTrafficPolicy 哪些節點通過健康狀態檢查 使用哪個通訊埠
Cluster 叢集的所有節點都通過健康狀態檢查，包括沒有服務 Pod 的節點。如果節點上至少有一個提供服務的 Pod，無論 Pod 的狀態為何，該節點都會通過負載平衡器健康狀態檢查。 負載平衡器健康狀態檢查通訊埠必須是 TCP 通訊埠 10256。無法自訂。
Local

如果節點上至少有一個就緒且未終止的服務 Pod，負載平衡器健康狀態檢查就會將節點視為健康狀態良好，無論其他 Pod 的狀態為何。如果節點沒有服務 Pod、服務 Pod 全都無法通過完備性探查，或是服務 Pod 全都終止，就會無法通過負載平衡器健康狀態檢查。

在狀態轉換期間，節點仍會通過負載平衡器健康狀態檢查，直到達到負載平衡器健康狀態檢查不佳的門檻為止。當節點上的所有服務 Pod 開始無法通過完備性探查，或節點上的所有服務 Pod 正在終止時，就會進入轉換狀態。在這種情況下，封包的處理方式取決於 GKE 版本。詳情請參閱下一節「封包處理」。

 除非 指定自訂健康狀態檢查通訊埠，否則 Kubernetes 控制層會從節點通訊埠範圍指派健康狀態檢查通訊埠。

啟用加權負載平衡後，負載平衡器會同時使用健康狀態和權重資訊，找出符合資格的節點後端集。詳情請參閱「加權負載平衡的影響」。

啟用區域親和性後，負載平衡器可能會縮減符合資格的節點後端集。詳情請參閱「區域親和性」。

NEG 與 MIG 健康狀態檢查

LoadBalancer 服務使用的後端類型，決定了 Google Cloud 如何設定及執行負載平衡器健康狀態檢查：

  • GKE 子集化 (NEG 後端)：當您的服務使用 GCE_VM_IP 網路端點群組 (NEG) 時 (例如啟用 GKE 子集化時)，GKE 會設定區域健康狀態檢查。如果是區域 NEG，健康狀態檢查探測會直接以服務的通訊埠為目標。
  • 執行個體群組設定 (MIG 後端)：當您的服務使用非受管理執行個體群組 (MIG) 做為後端時，GKE 會設定全域健康狀態檢查。如果是執行個體群組，健康狀態檢查探測器會以服務分配的 nodePort 為目標。

排解健康狀態檢查失敗問題

如果負載平衡器後端回報為不正常 (例如在 Google Cloud 控制台中顯示 0/X healthy)，請調查下列常見原因：

  • 缺少防火牆規則： Google Cloud 負載平衡器需要 allow-ingress 防火牆規則，允許來自 Google 健康狀態檢查 IP 位址範圍 (例如 130.211.0.0/22 和 35.191.0.0/16) 的健康狀態檢查探測器連線至叢集節點。如果刪除或修改這些防火牆規則，健康狀態檢查就會失敗。
  • 探測目標通訊埠不符：任何自訂網路安全規則或節點層級防火牆設定，都必須考量正確的健康狀態檢查目的地通訊埠。探測會直接以服務的通訊埠為目標 (適用於 NEG 後端)，但會以 nodePort 為目標 (適用於執行個體群組 (MIG) 後端)。如果預期的通訊埠設定不符，探測就會失敗。
  • externalTrafficPolicy: Local 行為：如果您的服務已設定 externalTrafficPolicy: Local，未代管該服務就緒且可提供服務的 Pod 的節點，會��意讓負載平衡器健康狀態檢查失敗。如果叢集中所有服務的 Pod 均未就緒或正在終止，所有後端節點都會回報為健康狀態不良 (0/X healthy)。

封包處理

以下各節將詳細說明負載平衡器和叢集節點如何共同運作，將 LoadBalancer 服務收到的封包轉送至適當位置。

直通式負載平衡

直通式網路負載平衡器會將封包轉送至 GKE 叢集節點的 nic0 介面。節點上收到的每個負載平衡封包都具有下列特徵：

  • 封包的目的地 IP 位址與負載平衡器的轉送規則 IP 位址相符。
  • 封包的通訊協定和目的地通訊埠符合下列條件：
    • Service 資訊清單 spec.ports[] 中指定的通訊協定和通訊埠
    • 負載平衡器轉送規則中設定的通訊協定和通訊埠

節點上的目的地網路位址轉譯

節點收到封包後，會執行額外的封包處理作業。在未使用 GKE Dataplane V2 的 GKE 叢集中，節點會使用 iptables 處理負載平衡封包。在啟用 GKE Dataplane V2 的 GKE 叢集中，節點會改用 eBPF。節點層級的封包處理作業一律包含下列動作：

  • 節點會對封包執行目的地網路位址轉譯 (DNAT)，將目的地 IP 位址設為提供服務的 Pod IP 位址。
  • 節點會將封包的目的地通訊埠變更為對應服務的 spec.ports[] targetPort。

節點上的來源網路位址轉譯和路由

下表顯示 externalTrafficPolicy 之間的關係，以及接收負載平衡封包的節點是否會在將負載平衡封包傳送至 Pod 前，執行來源網路位址轉譯 (SNAT)：

externalTrafficPolicy SNAT 行為
Cluster

在未使用 GKE Dataplane V2 的 GKE 叢集中，無論節點是將封包路由至本機 Pod，還是不同節點上的 Pod，收到負載平衡封包的每個節點一律會變更這些封包的來源 IP 位址，以符合節點的 IP 位址。

在採用 GKE Dataplane V2 的 GKE 叢集中，只有在接收節點將封包路由至不同節點上的 Pod 時，收到負載平衡封包的每個節點，才會將這些封包的來源 IP 位址變更為與節點的 IP 位址相符。如果接收負載平衡封包的節點將封包路由至本機 Pod，節點不會變更這些封包的來源 IP 位址。
Local

收到負載平衡封包的每個節點，都會將封包專屬地轉送至本機 Pod，且節點不會變更這些封包的來源 IP 位址。

下表說明 externalTrafficPolicy 如何控制節點路由負載平衡封包和回應封包：

externalTrafficPolicy 負載平衡封包路由 回覆封包轉送
Cluster

以下是轉送負載平衡封包的基準行為：

  • 如果收到負載平衡封包的節點沒有服務中、就緒且不會終止的 Pod，該節點會將封包轉送到有服務中、就緒且不會終止的 Pod 的其他節點。
  • 如果接收負載平衡封包的節點確實有可提供服務、已準備就緒且不會終止的 Pod，節點可能會將封包轉送至下列任一位置：
    • 本機 Pod。
    • 具有服務、就緒、非終止 Pod 的其他節點。

在區域叢集中，如果接收負載平衡封包的節點將封包轉送至其他節點，可用區相依性會產生下列影響：

  • 如果未啟用可用區親和性，不同節點可能位於任何可用區。
  • 如果啟用可用區相依性，接收負載平衡封包的節點會嘗試將封包轉送至同一可用區中的其他節點。如果無法這麼做，不同節點可能位於任何區域。

如果叢集所有節點上都沒有可提供服務、就緒且不會終止的 Pod，最後會發生下列情況：

  • 如果啟用「Proxy Terminating Endpoints」1，接收負載平衡封包的節點會將封包轉送至服務，但如果可以，會終止 Pod。
  • 如果停用 Proxy Terminating Endpoints，或整個叢集中沒有任何 Pod，接收負載平衡封包的節點會以 TCP 重設關閉連線。

節點一律會使用直接伺服器回傳功能傳送回應封包：

  • 如果提供服務 Pod 的節點並非收到對應負載平衡封包的節點，提供服務的節點會將回應封包傳回接收節點。接著，接收節點會使用直接伺服器回傳功能傳送回應封包。
  • 如果提供 Pod 的節點是收到負載平衡封包的節點，該節點會使用直接伺服器回傳傳送回應封包。
Local

以下是負載平衡封包的轉送基準行為：接收負載平衡封包的節點通常會有服務中、就緒、非終止的 Pod (因為必須有這類 Pod 才能通過負載平衡器健康狀態檢查)。節點會將負載平衡的封包轉送至本機 Pod。

在區域叢集中，區域親和性不會改變負載平衡封包的路由傳送基準行為。

最後手段：如果接收負載平衡封包的節點上，沒有可提供服務、準備就緒且不會終止的 Pod，就會發生下列情況：

  • 如果啟用「Proxy Terminating Endpoints」1，接收負載平衡封包的節點會將封包路由至本機服務，但如果可以，會路由至終止 Pod。
  • 如果停用「Proxy Terminating Endpoints」，或接收負載平衡封包的節點沒有任何服務 Pod，該節點會以 TCP 重設關閉連線。

提供 Pod 的節點一律是接收負載平衡封包的節點，且該節點會使用直接伺服器回傳功能傳送回應封包。

1 在下列設定中啟用「Proxy Terminating Endpoints」：

  • 未使用 GKE Dataplane V2 的 GKE 叢集：GKE 1.26 以上版本
  • 使用 GKE Dataplane V2 的 GKE 叢集：GKE 1.26.4-gke.500 以上版本

定價與配額

負載平衡器處理的封包適用網路價格。詳情請參閱「Cloud Load Balancing 和轉送規則定價」。您也可以使用 Google Cloud 價格計算機估算帳單費用。

您可以建立的轉送規則數量受負載平衡器配額限制：

後續步驟