閘道流量管理

本頁說明 Gateway 流量管理的運作方式。

本頁面適用於想要使用 Gateway API 部署及管理流量的開發人員、營運人員和網路專家。

總覽

Google Kubernetes Engine (GKE) 網路是以 Cloud Load Balancing 為基礎建構而成。透過 Cloud Load Balancing，單一任播 IP 位址即可管理全球流量。Google 的流量管理功能提供全域和區域負載平衡、自動調度資源和容量管理，可確保流量分配平均、穩定且延遲時間短。GKE 使用者可以透過 GKE Gateway 控制器，以宣告式 Kubernetes 原生方式，運用 Google 的全球流量管理控制項。

如要試用叢集間的流量溢出功能，請參閱部署以容量為準的負載平衡。 如要試用根據流量自動調度資源的功能，請參閱根據負載平衡器流量自動調度資源。

流量管理

負載平衡、自動調度資源和容量管理是流量管理系統的基礎。兩者會共同運作，平衡及穩定系統負載。

• 負載平衡會根據位置、健康狀態和不同的負載平衡演算法，將流量分配給後端 Pod。
• 自動調度資源會調度工作負載副本，建立更多容量來吸收更多流量。
• 容量管理會監控服務的使用率，讓流量溢出至有容量的後端，避免影響應用程式可用性或效能。

您可以根據目標，以不同方式組合使用這些功能。 舉例來說：

• 如要利用低成本的 Spot VM，您可能需要以延遲時間為代價，盡量在 Spot VM 之間平均分配流量。透過負載平衡和容量管理，GKE 會根據容量在區域之間溢出流量，以便充分運用可用的 Spot VM。

• 如要以過度佈建為代價，盡量縮短使用者延遲時間，您可以在多個區域部署 GKE 叢集，並在負載增加時動態增加容量。使用負載平衡和自動調度資源功能時，GKE 會在流量暴增時自動調度 Pod 數量，因此流量不必溢出至其他地區。地區的容量會增加，盡可能在最靠近使用者的位置完全處理負載。

下圖顯示負載平衡、自動調度資源和容量管理如何共同運作：

在此圖中，gke-us 叢集中的工作負載發生故障。負載平衡和健康狀態檢查會排空有效連線，並將流量重新導向至下一個最接近的叢集。gke-asia 中的工作負載接收的流量超出容量，因此會將負載轉移至 gke-eu。由於 gke-us 和 gke-asia 中有事件，gke-eu 接收的負載量高於一般情況，因此 gke-eu 會自動擴充，以提高流量容量。

如要進一步瞭解 Cloud Load Balancing 如何處理流量管理，請參閱全域容量管理。

流量管理功能和服務擴充功能

閘道、HTTPRoute、服務和政策資源提供控管機制，可管理 GKE 中的流量。GKE Gateway 控制器是監控這些資源的控制層。

GKE Gateway 服務擴充功能可自訂及擴充 GKE 中的流量管理功能。擴充功能會插入自訂邏輯，以進行進階流量控制。

在 GKE 中部署服務時，可使用下列流量管理功能：

• 服務容量：指定服務可接收的流量容量，超過此容量時，系統會自動調度 Pod，或將流量溢流至其他可用叢集。
• 以流量為準的自動調度資源：根據每秒收到的 HTTP 要求，自動調度服務內的 Pod 資源。
• 多叢集負載平衡：能夠將負載平衡至多個 GKE 叢集或多個區域中代管的服務。
• 流量拆分：根據權重在後端之間明確分配流量。

• 透過 Service Extensions 自訂流量管理：

  服務擴充功能可讓您執行下列操作：

  • 修改 HTTP 要求和回應的標頭和酬載。
  • 導入自訂轉送邏輯，控管流量。
  • 與外部服務整合，執行授權等函式。

流量管理支援

可用的流量管理功能取決於您部署的 GatewayClass。如需完整的功能支援清單，請參閱「GatewayClass 功能」。下表摘要說明 GatewayClass 對流量管理的支援：

使用以自訂指標為準的負載平衡功能管理流量

Trusted Cloud by S3NS 應用程式負載平衡器會根據自訂指標分配流量。這些指標可能包括 GPU 使用率負載或其他應用程式專屬的使用率信號。自訂指標可更準確地呈現工作負載效能。您的應用程式會使用公開要求費用匯總 (ORCA) 標準，回報這些指標。詳情請參閱應用程式負載平衡器的自訂指標。

在 GKE 中，您可以透過 GKE Gateway API 整合這項進階流量管理功能。對於資源用量不一的工作負載 (例如生成式 AI 推論)，這項 API 相當實用。您可以設定下列政策，自訂流量行為：

• GCPBackendPolicy 用於選取後端：GCPBackendPolicy資源可精確控管負載平衡器的後端服務如何將流量分配給後端。這項政策包含特定欄位，可供您設定各種負載平衡模式，例如使用自訂指標。如要使用 GCPBackendPolicy 設定後端選取作業，請參閱「使用 GCPBackendPolicy 設定後端選取作業」。

• GCPTrafficDistributionPolicy 用於端點層級的路由：GCPTrafficDistributionPolicy 會設定後端中端點挑選的負載平衡演算法。選取 WEIGHTED_ROUND_ROBIN 時，負載平衡器會使用從回報指標 (包括自訂指標) 衍生出的權重，將流量分配給個別執行個體或端點。如要設定端點層級指標，請參閱「使用 GCPTrafficDistributionPolicy 設定端點層級的路由」。

位置資訊政策

您可以使用位置指定符，將這些位置政策套用至特定 Trusted Cloud by S3NS 區域或地區。位置指定符可用於 Canary 部署、分階段推出，或在隔離區域測試政策變更。詳情請參閱「使用政策設定閘道資源」。

監控 GKE 後端的自訂指標

全域外部應用程式負載平衡器和內部應用程式負載平衡器提供記錄和監控功能，可讓您觀察 GKE 後端回報的自訂指標，深入瞭解流量。詳情請參閱「全域外部應用程式負載平衡器記錄與監控」。

您可以透過 GKE 指標標籤，查詢每個 GKE 服務、叢集和命名空間的自訂指標。

如要查看 GKE 後端回報的自訂指標，請前往 Cloud Monitoring，並在 network.googleapis.com/loadbalancer/backend/ 受監控資源下方查看自訂指標。您可以使用 GKE 專屬標籤查詢及篩選這些指標。

可用的指標包括：

• /error_rate：每個後端群組每秒提供的錯誤數。
• /custom_metrics：根據您定義的自訂指標，各後端群組目前的用量。
• /fullness：每個後端群組目前的飽和度 (負載或容量)，負載平衡器會根據這項指標做出轉送決策。
• /rate：每個後端群組每秒收到的要求數。

可強化這些指標監控功能的 GKE 專屬標籤包括 gke_service_name、gke_namespace 和 gke_cluster。您可以使用這些標籤，依 GKE 服務、命名空間和叢集探索指標資料。請注意，只有在 backend_type 為 ZONAL_NETWORK_ENDPOINT_GROUP 時，才會填入這些 GKE 標籤。

下表列出 GKE 專屬標籤：

全域外部應用程式負載平衡器的記錄項目包含的資訊實用，有助於監控 HTTP(S) 流量及執行偵錯作業。

全域、區域和可用區負載平衡

服務容量、位置和健康狀態都會決定負載平衡器傳送至特定後端的流量大小。負載平衡決策是在下列層級做出，從全域負載平衡器的全域層級，以及區域負載平衡器的區域層級開始：

• 全域：流量會傳送至最接近用戶端的 Trusted Cloud 地區，該地區必須有健康狀態良好的後端，且具備容量。只要該地區有容量，就會接收所有最接近的流量。如果某個地區沒有容量，多餘的流量就會溢流到下一個有容量的最接近地區。詳情請參閱全域負載平衡。
• 區域：負載平衡器會將流量傳送至特定區域。系統會根據各區域的可用服務容量，按比例在各區域間進行負載平衡。詳情請參閱區域負載平衡。
• 區域：判斷特定區域的流量後，負載平衡器會在該區域的後端平均分配流量。現有的 TCP 連線和工作階段持續性設定會保留，因此只要後端 Pod 狀態良好，日後的要求就會傳送至相同的後端。詳情請參閱區域負載平衡。

全域負載平衡和流量溢出

如要在自己的叢集中試用下列概念，請參閱以容量為準的負載平衡。

在正常情況下，流量會傳送至最接近用戶端的後端。流量會在最接近用戶端的 Google 服務據點 (PoP) 終止，然後通過 Google 骨幹網路，直到抵達最近的後端 (由網路延遲決定)。當某個地區的後端沒有剩餘容量時，流量會溢流到下一個最近的叢集，該叢集具有容量充足且運作正常的後端。如果可用區內超過 50% 的後端 Pod 狀況不佳，流量就會逐步容錯移轉至其他可用區或區域，與設定的容量無關。

只有在下列情況下，才會發生流量溢位：

• 您正在使用多叢集閘道。
• 您在多個叢集中部署了相同的 Service，並由多叢集閘道提供服務。
• 您已設定服務容量，導致某個叢集的流量超出服務容量，但其他叢集並未發生這種情況。

下圖說明全域負載平衡如何處理流量溢位：

在圖表中：

• 多叢集閘道可為 store 服務提供全域網際網路負載平衡。這項服務部署在兩個 GKE 叢集，分別位於 us-west1 和 europe-west1。每個叢集都執行 2 個副本。
• 每個 Service 都設為 max-rate-per-endpoint="10"，也就是說，每個 Service 在每個叢集中的總容量為 2 個副本 * 10 RPS = 20 RPS。
• 北美洲的 Google PoP 接收 6 RPS。所有流量都會傳送至最近的健康後端 (即 us-west1 中的 GKE 叢集)，且該後端有足夠容量。
• 歐洲 PoP 累積收到 30 個 RPS。距離最近的後端位於「europe-west1」，但容量只有 20 RPS。由於 us-west1 中的後端有過剩容量，因此 10 RPS 會溢位至 us-west1，使後者總共收到 16 RPS，並將 8 RPS 分配給每個 Pod。

防止流量溢出

流量溢流有助於避免超出應用程式容量，進而影響效能或可用性。

不過，您可能不希望流量溢出。舉例來說，對延遲時間敏感的應用程式可能無法從流量溢出到遠得多的後端獲益。

您可以採用下列任一方法，避免流量溢出：

• 請只使用單一叢集閘道，這類閘道只能在單一叢集代管服務。

• 即使使用多叢集閘道，部署在多個叢集中的應用程式副本仍可部署為個別服務。從閘道的角度來看，這項功能可啟用多叢集負載平衡，但不會匯總叢集之間服務的所有端點。

• 將服務容量設在足夠高的層級，除非絕對必要，否則流量容量絕不會實際超出。

區域內的負載平衡

在某個區域內，流量會根據後端的可用容量分配到各個區域。這並非使用溢位，而是直接根據各區域的服務容量進行負載平衡。任何個別流程或工作階段一律會傳送至單一且一致的後端 Pod，不會分割。

下圖顯示區域內的流量分配方式：

在圖表中：

• 服務部署在區域性 GKE 叢集中。這項服務有 4 個 Pod，但部署在各個可用區的 Pod 數量不平均。3 個 Pod 位於區域 A、1 個 Pod 位於區域 B，0 個 Pod 位於區域 C。
• Service 已設定 maxRatePerEndpoint=10。可用區 A 的總容量為 30 RPS，可用區 B 的總容量為 10 RPS，可用區 C 的總容量為 0 RPS，因為沒有任何 Pod。
• 閘道會從不同用戶端接收總共 16 RPS 的流量。 系統會根據各可用區的剩餘容量，將流量分配至各可用區。
• 根據工作階段持續性設定，來自任何個別來源或用戶端的流量，都會持續負載平衡至單一後端 Pod。流量拆分會分配到不同的來源流量流程，因此不會拆分任何個別流程。因此，您必須提供最低量的來源或用戶端多樣性，才能在後端之間細分流量。

舉例來說，如果傳入流量從每秒 16 個要求暴增至每秒 60 個要求，就會發生下列任一情況：

• 如果使用單一叢集閘道，則沒有其他叢集或區域可供流量溢出。即使傳入流量超出總容量，系統仍會根據相對可用區容量分配流量。因此，可用區 A 會收到 45 個 RPS，可用區 B 則會收到 15 個 RPS。
• 如果使用多叢集閘道，且服務分散在多個叢集，流量可能會溢位至其他叢集和其他區域，如「全域負載平衡和流量溢位」一文所述。可用區 A 收到 30 個 RPS，可用區 B 收到 10 個 RPS，另外 20 個 RPS 溢出至另一個叢集。

可用區內的負載平衡

流量傳送至可用區後，系統會平均分配給該可用區內的所有後端。HTTP 工作階段是否會持續存在，取決於工作階段相依性設定。除非後端變得無法使用，否則現有的 TCP 連線絕不會移至另一個後端。也就是說，即使容量有限導致新連線溢位，長期連線仍會繼續連往同一個後端 Pod。負載平衡器會優先維護現有連線，而非建立新連線。

服務容量

透過服務容量，您可以在服務中為每個 Pod 定義每秒要求數 (RPS) 值。這個值代表服務平均每個 Pod 可接收的最高 RPS。這項值可在服務上設定，用於判斷以流量為準的自動調度資源和以容量為準的負載平衡。

需求條件

服務容量須符合下列規定和限制：

• 僅支援「流量管理支援」中定義的 GatewayClass 資源和 Ingress 類型。
• 如果您使用以流量為準的自動調度資源或多叢集閘道，負載平衡就會受到影響。如果您未使用這些功能，服務容量不會影響網路流量。

設定服務容量

apiVersion: v1
kind: Service
metadata:
  name: store
spec:
  ports:
  - port: 8080
    targetPort: 8080
    name: http
  selector:
    app: store
  type: ClusterIP

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: store
spec:
  default:
    maxRatePerEndpoint: RATE_PER_SECOND
  targetRef:
    group: ""
    kind: Service
    name: store

apiVersion: v1
kind: Service
metadata:
  name: store
  annotations:
    networking.gke.io/max-rate-per-endpoint: "RATE_PER_SECOND"
spec:
  ports:
  - port: 8080
    targetPort: 8080
    name: http
  selector:
    app: store
  type: ClusterIP

將 RATE_PER_SECOND 替換為此服務中單一 Pod 每秒應接收的 HTTP/HTTPS 要求數上限。

maxRatePerEndpoint 值會根據服務中的 Pod 數量，為服務建立動態容量。服務總容量值的計算方式是將 maxRatePerEndpoint 值乘以副本數量，如下列公式所示：

Total Service capacity = maxRatePerEndpoint * number of replicas

如果自動配置器擴充服務中的 Pod 數量，系統會相應計算服務的總容量。如果 Service 縮減至零個 Pod，則容量為零，不會收到負載平衡器的任何流量。

服務容量和獨立 NEG

使用獨立 NEG 時，也可以設定服務容量，但不會使用 maxRatePerEndpoint 設定。使用獨立 NEG 時，將 NEG 新增至後端服務資源時，會手動設定 maxRatePerEndpoint。使用 gcloud compute backend-services add-backend 指令時，--max-rate-per-endpoint 標記可個別設定每個 NEG 的容量。

這項功能適用於下列任一工作流程：

• 使用獨立 NEG 手動部署內部和外部負載平衡器時
• 使用獨立 NEG 在 GKE 上部署 Cloud Service Mesh 時，

使用獨立 NEG 設定服務容量時，功能上沒有任何差異。支援流量自動調度資源和流量溢出。

決定服務容量

如要判斷 maxRatePerEndpoint 的值，您必須瞭解應用程式的效能特性和負載平衡目標。以下策略有助於定義應用程式效能特性：

• 如果設定時未指定服務容量，請在測試和正式環境中觀察應用程式。

• 使用 Cloud Monitoring 建立流量要求與效能服務等級目標 (SLO) 之間的關聯。

• 使用負載平衡器指標 (例如 https 或 request_count) 對應每秒要求數層級。

• 定義應用程式的效能 SLO。視您認為「不佳」或「不穩定」的成效而定，可能包含下列一或多項。您可以從 Cloud Monitoring 負載平衡器指標收集下列所有資訊：

  • 回應錯誤代碼
  • 回應或總延遲時間
  • 後端健康狀態不良或停機

• 在測試和正式環境中，觀察應用程式在流量負載下的情況。在測試環境中，請在要求負載不斷增加的情況下，對應用程式進行壓力測試，瞭解流量增加時，不同效能指標會受到哪些影響。在實際工作環境中，觀察實際的流量模式層級。

預設服務容量

即使未明確設定，附加至 GKE 資源的所有服務都會設定預設服務容量。詳情請參閱預設服務容量。

下表說明預設容量：

根據流量自動調度資源

GKE 的流量型自動調度資源功能會整合負載平衡器的流量信號，自動調度 Pod 資源。以流量為準的自動調度資源功能僅支援單一叢集閘道。

如要使用以流量為準的自動調度資源功能，請參閱根據負載平衡器流量自動調度資源。

根據流量自動調度資源具有下列優點：

• 如果應用程式並非嚴格受 CPU 或記憶體限制，則可能會有容量限制，但 CPU 或記憶體用量不會反映這類限制。
• 在某些情況下，流量或每秒要求數 (RPS) 是較容易瞭解的指標，因為這類指標與應用程式用量和業務指標 (例如網頁瀏覽或每日活躍使用者 (DAU)) 更為一致。
• 流量是領先指標，代表與 CPU 或記憶體 (落後指標) 相比的即時需求。
• 結合 CPU、記憶體和流量自動調度資源指標，可全面自動調度應用程式，並使用多個維度確保適當配置容量。

下圖說明以流量為準的自動調整功能運作方式：

在圖表中：

• 服務擁有者會為部署作業設定服務容量和目標使用率。
• 閘道會接收來自用戶端的流量，並將流量導向 store 服務。閘道會將使用率遙測資料傳送至 GKE Pod 自動配置器。使用率等於個別 Pod 收到的實際流量，除以 Pod 的設定容量。
• GKE Pod 自動配置器會根據設定的目標使用率，調度 Pod 的資源。

自動調度資源行為

下圖顯示應用程式透過負載平衡器接收 10 個 RPS 時，流量型自動調整資源配置的運作方式：

在圖表中，服務擁有者已將商店服務的容量設為 10 RPS，也就是說每個 Pod 最多可接收 10 RPS。HorizontalPodAutoscaler 設定為 averageValue，表示目標使用率為每個 Pod 10 RPS 的 70%。70

自動調度器會嘗試調度副本，以達到下列方程式：

replicas = ceiling[ current traffic / ( averageValue * maxRatePerEndpoint) ]

在圖表中，這個方程式的計算結果為：

ceiling[ 10 rps / (0.7 * 10 rps) ] = ceiling[ 1.4 ] = 2 replicas

10 RPS 的流量會產生 2 個副本。每個副本會收到 5 RPS，低於 7 RPS 的目標用量。

流量拆分

流量拆分會使用明確比例 (稱為「權重」)，定義傳送至服務的 HTTP 要求比例。您可以使用 HTTPRoute 資源，在服務清單中設定權重。服務之間的相對權重會決定流量分配比例。這項功能適用於在推出期間分割流量、進行 Canary 測試變更，或是在緊急情況下使用。

下圖說明流量分配設定範例：

在圖表中：

• 服務擁有者為單一路線設定兩項服務，並透過規則將流量分配至 store-v1 和 store-v2，比例分別為 90% 和 10%。
• 閘道會接收來自用戶端的流量，這些流量會前往商店應用程式的網址，並根據設定的規則分配流量。90% 的流量路徑前往 store-v1，10% 的流量路徑前往 store-v2。

流量拆分功能支援相同叢集中的服務，也支援不同叢集中的服務：

• 服務間的流量分配：用於分配流量，以便推出應用程式版本。以流量分配範例來說，您會有兩個不同的 Deployment，分別是 store-v1 和 store-v2，各自有自己的 Service，分別是 store-v1 和 store-v2。在兩個服務之間設定權重，逐步轉移流量，直到 store-v2 完全推出為止。

• ServiceImport 之間的流量分配：用於將流量轉移至特定叢集或從特定叢集轉移流量，以進行維護、遷移或處理緊急狀況。ServiceImport 代表多叢集服務，可讓您在不同叢集的不同服務之間分割流量。練習：使用閘道進行藍綠部署和多叢集轉送，示範如何在叢集之間分配流量。

重量與容量

權重和容量都會控管傳送至不同服務的流量。雖然效果類似，但運作方式和用途不同。雖然用途不同，但這兩項工具可以也應該一起使用。

權重

權重是流量的明確控制項。這項功能可定義確切的流量比例，不受傳入流量和後端使用率影響。在流量拆分範例中，如果 store-v2 超載，或所有副本都失敗，系統仍會將 10% 的流量分配給 store-v2，可能導致流量遭到捨棄。這是因為權重不會根據使用率或健康狀態，改變流量比例。

權重最適合用於下列用途：

• 在服務的不同版本之間轉移流量，以便推出新版本。
• 使用明確的流量拆分功能手動導入服務。
• 基於緊急或維護目的，將流量從一組後端移開。

容量

容量是流量的隱含控制項。這項設定會間接定義流量比例，因為流量比例取決於傳入流量、後端使用率和流量來源位置。容量是服務的固有屬性，通常不會經常更新。

容量最適合下列用途：

• 在流量遽增期間，避免後端過度使用資源。
• 根據流量控制自動調度資源的速率。

設定服務容量以溢出流量，不見得是您想要的行為。請參考全域負載平衡範例。 服務容量會溢流流量，避免後端過度使用資源，但這可能會導致溢流的要求延遲時間增加，因為這些要求會傳送至較遠的地區。

如果應用程式對過度使用資源的情況不太敏感，建議您設定非常高的服務容量，這樣流量就不太可能溢出到其他地區。如果應用程式的可用性或延遲時間對過度使用情況很敏感，那麼將溢出的流量導向其他叢集或區域，可能比在過度使用的後端吸收過多流量更好。如要進一步瞭解如何為應用程式設定服務容量，請參閱「判斷服務容量」。

後續步驟

• 瞭解如何部署閘道。
• 瞭解如何部署多叢集閘道。