關於 LoadBalancer 服務

---

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

閱讀本頁面之前，請先熟悉 GKE 網路概念。

總覽

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

為網路自訂 LoadBalancer 服務

選擇要使用的 LoadBalancer 服務設定時，請考慮下列事項：

• 負載平衡器類型：內部或外部
• 外部流量政策
• 加權負載平衡

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

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

• 外部 LoadBalancer 服務是透過外部直通式網路負載平衡器實作。位於 VPC 網路外部的用戶端和可存取網際網路的 VM，都可以存取外部 LoadBalancer 服務。 Google Cloud

  建立 LoadBalancer 服務時，如果未指定任何自訂設定，系統會預設採用這項設定。

  最佳做法是在建立外部 LoadBalancer Service 時，於 Service 資訊清單中加入 cloud.google.com/l4-rbs: "enabled" 註解。在 Service 資訊清單中加入這項註解，即可建立以後端服務為基礎的外部直通式網路負載平衡器。

  如果 LoadBalancer 服務資訊清單省略 cloud.google.com/l4-rbs: "enabled" 註解，系統會建立以目標集區為基礎的外部直通式網路負載平衡器。我們不再建議使用以目標集區為基礎的外部直通式網路負載平衡器。

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

  如要建立內部 LoadBalancer 服務，請按照下列步驟操作：

  • 最佳做法是確保已啟用 GKE 子集，這樣 GKE 就能使用 GCE_VM_IP 網路端點群組 (NEG) 有效率地將節點分組。GKE 子集並非必要，但強烈建議使用。

  • 在 Service 資訊清單中加入 networking.gke.io/load-balancer-type: "Internal" 註解。

externalTrafficPolicy 的影響

externalTrafficPolicy 參數可控制下列項目：

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

externalTrafficPolicy 可以是 Local 或 Cluster：

• 使用 externalTrafficPolicy: Local 可確保封包「只」傳送至至少有一個服務中、就緒、非終止 Pod 的節點，並保留原始用戶端來源 IP 位址。這個選項最適合節點數量相對穩定的工作負載，即使叢集中的節點總數有所變動，提供服務的 Pod 數量仍維持不變。如要支援加權負載平衡，就必須使用這個選項。

• 如果叢集中的節點總數相對穩定，但提供服務的 Pod 節點數量有所不同，請使用 externalTrafficPolicy: Cluster。這個選項不會保留原始用戶端來源 IP 位址，而且可能會增加延遲時間，因為封包從負載平衡器傳送到節點後，可能會轉送到另一個節點上的服務 Pod。這個選項與加權負載平衡不相容。

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

加權負載平衡

外部 LoadBalancer 服務支援加權負載平衡，因此與處理流量的 Pod 數量較少的節點相比，處理流量的 Pod 數量較多的節點會收到較大比例的新連線。

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

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

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

• 叢集必須啟用 HttpLoadBalancing 外掛程式。這項外掛程式預設為啟用。叢集可藉此管理使用後端服務的負載平衡器。

• 您必須在 LoadBalancer Service 資訊清單中加入 cloud.google.com/l4-rbs: "enabled" 註解，GKE 才會建立以後端服務為基礎的外部直通式網路負載平衡器。目標集區型外部直通式網路負載平衡器不支援加權負載平衡。

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

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

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

如要從負載平衡器的角度進一步瞭解加權負載平衡，請參閱後端服務型外部直通式網路負載平衡器的「加權負載平衡」。

內部 LoadBalancer 服務的特別注意事項

本節說明 GKE 子集選項 (內部 LoadBalancer 服務專屬)，以及 GKE 子集如何與 externalTrafficPolicy 互動，進而影響負載平衡節點的最大數量。

GKE 子設定

最佳做法：

啟用 GKE 子設定，提升內部 LoadBalancer 服務的擴充性。

GKE 子設定也稱為「適用於第 4 層內部負載平衡器的 GKE 子設定」，是一種叢集層級的設定選項，可將節點端點更有效率地分組到GCE_VM_IP網路端點群組 (NEG)，進而提升內部直通式網路負載平衡器的擴充性。NEG 會做為負載平衡器的後端。

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

建立叢集時或更新現有叢集時，可以啟用 GKE 子設定。啟用後即無法停用 GKE 子設定。GKE 子設定需要：

• GKE 1.18.19-gke.1400 以上版本，以及
• 叢集已啟用 HttpLoadBalancing 外掛程式。這項外掛程式預設為啟用。叢集可藉此管理使用後端服務的負載平衡器。

節點數

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

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

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

• 在啟用 GKE 子集化的叢集中，使用 externalTrafficPolicy: Local 的內部 LoadBalancer 服務最多支援 250 個節點，這些節點提供支援這項服務的 Pod。

• 在啟用 GKE 子集的叢集中，使用 externalTrafficPolicy: Cluster 的內部 LoadBalancer 服務不會對提供服務的 Pod 節點數量設限，因為 GKE 在 GCE_VM_IP NEG 中設定的節點端點不會超過 25 個。詳情請參閱「節點在 GCE_VM_IP NEG 後端的成員資格」。

工作階段相依性和流量分配

工作階段相依性可讓您控管負載平衡器將用戶端要求指派給後端的方式，並確保用戶端的所有後續要求都會轉送回該後端。

使用內部直通式網路負載平衡器時，如果將工作階段親和性設為 CLIENT_IP，您可能會發現流量分配至後端不平均。這是因為負載平衡器一律會將來自特定用戶端 IP 位址的流量傳送至同一個後端。如果只有少數幾個客戶的流量很高，可能會導致部分後端過載，其他後端則未充分利用。

詳情請參閱工作階段相依性選項。

節點分組

GKE 版本、服務資訊清單註解，以及內部 LoadBalancer 服務的 GKE 子集選項，都會決定產生的 Google Cloud 負載平衡器和後端類型。負載平衡器和後端類型會決定節點的分組方式，也就是分到 GCE_VM_IP NEG、執行個體群組或目標集區。在所有情況下， Google Cloud直通負載平衡器都會識別 GKE 節點的網路介面 (NIC)，而非特定節點或 Pod IP 位址。

GKE LoadBalancer Service	產生的 Google Cloud 負載平衡器	節點分組方式
在啟用 GKE 子設定的叢集中建立的 Internal LoadBalancer Service1	後端服務使用GCE_VM_IP網路端點群組 (NEG) 後端的內部直通式網路負載平衡器	節點 VM 會依據服務和叢集中的節點數量，按區域分組到 GCE_VM_IP NEG 中。externalTrafficPolicy Service 的 externalTrafficPolicy 也會控管哪些節點通過負載平衡器健康狀態檢查，以及封包處理。
在 GKE 子集停用的叢集中建立 Internal LoadBalancer 服務	後端服務使用區域性 非代管執行個體群組 後端的內部直通式網路負載平衡器	所有節點 VM 都會放入區域非代管執行個體群組，GKE 會將這些群組做為內部直通式網路負載平衡器後端服務的後端。 服務的 externalTrafficPolicy 會控管哪些節點通過負載平衡器健康狀態檢查，以及封包處理。 由於單一負載平衡執行個體群組的限制，叢集中建立的其他負載平衡器後端服務會使用相同的非代管執行個體群組。
外部 LoadBalancer Service，並將 cloud.google.com/l4-rbs: "enabled" 註解2套用至執行 GKE 1.32.2-gke.1652000 版以上4的叢集。	後端服務型外部直通式網路負載平衡器，其後端服務使用GCE_VM_IP網路端點群組 (NEG) 後端	節點 VM 會依據服務和叢集中的節點數量，按區域分組到 GCE_VM_IP NEG 中。externalTrafficPolicy Service 的 externalTrafficPolicy 也會控管哪些節點通過負載平衡器健康狀態檢查，以及封包處理。
外部 LoadBalancer Service，且 cloud.google.com/l4-rbs: "enabled" 註解2已套用至執行 GKE 1.32.2-gke.16520004 之前版本的叢集	後端服務型外部直通式網路負載平衡器，其後端服務使用區域性 非受管理執行個體群組 後端	所有節點 VM 都會放入區域非受管理執行個體群組，GKE 會將這些群組做為外部直通式網路負載平衡器後端服務的後端。 服務的 externalTrafficPolicy 會控管哪些節點通過負載平衡器健康狀態檢查，以及封包處理。 由於單一負載平衡執行個體群組的限制，叢集中建立的其他負載平衡器後端服務會使用相同的非代管執行個體群組。
外部 LoadBalancer 服務沒有 cloud.google.com/l4-rbs: "enabled" 註解3	以目標集區為基礎的外部直通式網路負載平衡器，其目標集區包含叢集的所有節點	目標集區是舊版 API，不依賴執行個體群組。所有節點都直接屬於目標集區。 服務的 externalTrafficPolicy 會控管哪些節點通過負載平衡器健康狀態檢查，以及封包處理。

GCE_VM_IP NEG 後端的節點成員資格

為叢集啟用 GKE 子設定，或在 GKE 1.32.2-gke.1652000 以上版本建立具有 cloud.google.com/l4-rbs: "enabled" 的外部直通式網路負載平衡器時，GKE 會為每個 LoadBalancer Service 在每個區域中建立專屬的 GCE_VM_IP NEG。與執行個體群組不同，節點可以屬於多個負載平衡 GCE_VM_IP NEG。Service 的 externalTrafficPolicy 和叢集中的節點數量，會決定要將哪些節點做為端點加入 Service 的 GCE_VM_IP NEG。

叢集的控制層會根據服務的 externalTrafficPolicy 值和叢集中的節點數量，將節點新增為 GCE_VM_IP NEG 的端點，如下表所示。

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

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

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

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

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

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

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

• 停用 GKE 子設定時，為內部 LoadBalancer 服務建立的內部直通式網路負載平衡器。
• 為具有 cloud.google.com/l4-rbs: "enabled" 註解的外部 LoadBalancer 服務建立後端服務型外部直通式網路負載平衡器。
• 使用 GKE Ingress 控制器為外部 GKE Ingress 資源建立的外部應用程式負載平衡器，但未使用容器原生負載平衡。

由於節點 VM 無法成為多個負載平衡執行個體群組的成員，因此如果符合下列任一條件，GKE 就無法建立及管理內部直通式網路負載平衡器、以後端服務為基礎的外部直通式網路負載平衡器，以及為 GKE Ingress 資源建立的外部應用程式負載平衡器：

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

如要解決這項限制，您可以指示 GKE 盡可能使用 NEG 後端：

• 啟用 GKE 子集。因此，新的內部 LoadBalancer 服務會改用 GCE_VM_IP NEG。
• 設定外部 GKE Ingress 資源，以使用容器原生負載平衡。詳情請參閱 GKE 容器原生負載平衡。

負載平衡器健康狀態檢查

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

負載平衡器健康狀態檢查封包會由每個節點上執行的 kube-proxy (舊版資料層) 或 cilium-agent (GKE Dataplane V2) 軟體回應。Pod 無法回應 LoadBalancer 服務的負載平衡器健康狀態檢查。

服務的 externalTrafficPolicy 會決定哪些節點通過負載平衡器健康狀態檢查：

externalTrafficPolicy	哪些節點通過健康狀態檢查	使用哪個通訊埠
Cluster	叢集的所有節點都通過健康狀態檢查，包括沒有服務 Pod 的節點。如果節點上至少有一個提供服務的 Pod，無論 Pod 的狀態為何，該節點都會通過負載平衡器健康狀態檢查。	負載平衡器健康狀態檢查通訊埠必須是 TCP 通訊埠 10256。無法自訂。
Local	如果節點上至少有一個處於就緒狀態且未終止的服務 Pod，負載平衡器健康狀態檢查就會將該節點視為健康狀態良好，無論其他 Pod 的狀態為何。如果節點沒有服務 Pod、服務 Pod 全都無法通過完備性探查，或是服務 Pod 全都終止，就會無法通過負載平衡器健康狀態檢查。 在狀態轉換期間，節點仍會通過負載平衡器健康狀態檢查，直到達到負載平衡器健康狀態檢查不良門檻為止。當節點上的所有服務 Pod 開始無法通過完備性探查，或節點上的所有服務 Pod 正在終止時，就會發生轉換狀態。在這種情況下，封包的處理方式取決於 GKE 版本。詳情請參閱下一節「封包處理」。	除非您 指定自訂健康狀態檢查通訊埠，否則 Kubernetes 控制層會從節點通訊埠範圍指派健康狀態檢查通訊埠。

啟用加權負載平衡後，kube-proxy 或 cilium-agent 軟體會在回覆負載平衡器健康狀態檢查時，於答案中加入回應標頭。這個回應標頭定義的權重與節點上放送、就緒且未終止的 Pod 數量成正比。負載平衡器會根據這個權重，將新連線路由至服務 Pod。

封包處理

下列各節詳細說明負載平衡器和叢集節點如何共同運作，將為 LoadBalancer 服務收到的封包路由傳送。

直通式負載平衡

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

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

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

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

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

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

externalTrafficPolicy 會判斷節點層級的封包處理是否也執行來源網路位址轉譯 (SNAT)，以及封包從節點到 Pod 的路徑：

externalTrafficPolicy	節點 SNAT 行為	轉送行為
Cluster	在沒有 GKE Dataplane V2 的 GKE 叢集中，節點會變更負載平衡封包的來源 IP 位址，使其與從負載平衡器接收封包的節點 IP 位址相符。 在採用 GKE Dataplane V2 的 GKE 叢集中，節點將流量轉送至同一節點上的服務 Pod 時，不會變更負載平衡封包的來源 IP 位址。不過，如果流量轉送至不同節點上的 Pod，系統就會執行 SNAT。	節點會將封包轉送至任何處理流量的 Pod。服務 Pod 可能位於相同節點，也可能不在。 如果從負載平衡器接收封包的節點沒有準備就緒且正在提供服務的 Pod，該節點會將封包轉送至含有這類 Pod 的其他節點。Pod 的回應封包會從節點傳回，再傳送至接收負載平衡器要求封包的節點。接著，第一個節點會使用直接伺服器回傳，將回應封包傳送至原始用戶端。
Local	節點不會變更經過負載平衡的封包來源 IP 位址。	在多數情況下，節點會將封包路由至節點上執行的服務 Pod，該節點會從負載平衡器接收封包。該節點會使用直接伺服器回傳功能，將回應封包傳送至原始用戶端。這類流量政策的主要目的如下： 在某些情況下，即使節點缺少 Service 的就緒狀態、非終止服務 Pod，節點仍會收到負載平衡器的封包。如果負載平衡器的健康狀態檢查尚未達到失敗門檻，但先前已準備就緒並提供服務的 Pod 不再就緒或正在終止 (例如執行滾動更新時)，就會發生這種情況。在此情況下，封包的處理方式取決於 GKE 版本、叢集是否使用 GKE Dataplane V2，以及 externalTrafficPolicy 的值： 如果沒有 GKE Dataplane V2，在 GKE 1.26 以上版本中，以及在 GKE 1.26.4-gke.500 以上版本中，使用 GKE Dataplane V2 時，Proxy Terminating Endpoints 會啟用。如果符合下列所有條件，封包會以最後手段的方式，路由至終止 Pod： 如果所有放送 Pod 均終止，且 externalTrafficPolicy 為 Cluster。 如果節點上的所有服務 Pod 都在終止，且 externalTrafficPolicy 為 Local。 如果是其他 GKE 版本，節點核心會以 TCP 重設回應封包。

定價與配額

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

您可以建立的轉送規則數量取決於負載平衡器配額：

• 內部直通式網路負載平衡器會使用每個專案的後端服務配額、每個專案的健康狀態檢查配額，以及每個虛擬私有雲網路的內部直通式網路負載平衡器轉送規則配額。
• 後端服務型外部直通式網路負載平衡器會使用每個專案的後端服務配額、每個專案的健康狀態檢查配額，以及每個專案的外部直通式網路負載平衡器轉送規則配額。
• 以目標集區為基礎的外部直通式網路負載平衡器會使用每個專案的目標集區配額、每個專案的健康狀態檢查配額，以及每個專案的外部直通式網路負載平衡器轉送規則配額。

後續步驟

• 瞭解 GKE LoadBalancer Service 參數。
• 瞭解 Kubernetes 服務。