在 GKE 上擴充 Cloud Service Mesh 的最佳做法

本指南說明如何解決 Google Kubernetes Engine 中代管 Cloud Service Mesh 架構的縮放問題，並提供相關最佳做法。這些建議的主要目標，是確保微服務應用程式在成長過程中，能維持最佳效能、可靠性和資源使用率。

如要瞭解擴充性限制，請參閱「Cloud Service Mesh 擴充性限制」

GKE 上 Cloud Service Mesh 的可擴充性取決於其兩個主要元件 (資料層和控制層) 的運作效率。本文主要著重於資料層的擴充。

找出控制層和資料層的資源調度問題

在 Cloud Service Mesh 中，控制層或資料層都可能發生縮放問題。以下說明如何判斷遇到哪種類型的擴充問題：

控制層資源調度問題的症狀

服務探索速度緩慢：新服務或端點需要很長的時間才能偵測到並開放使用。

設定延遲：變更流量管理規則或安全性政策需要很長的時間才能生效。

控制平面作業的延遲時間增加：建立、更新或刪除 Cloud Service Mesh 資源等作業變得緩慢或無法回應。

與 Traffic Director 相關的錯誤：您可能會在 Cloud Service Mesh 記錄或控制層指標中看到錯誤，表示連線、資源耗盡或 API 節流出現問題。

影響範圍：控制層問題通常會影響整個網格，導致效能普遍降低。

資料平面縮放問題的症狀

服務間通訊的延遲時間增加：對內部結構服務的請求會出現較長的延遲時間或逾時，但服務容器中的 CPU/記憶體用量並未增加。

Envoy 代理程式中的 CPU 或記憶體使用率偏高：CPU 或記憶體使用率偏高，可能表示代理程式無法順利處理流量負載。

局部影響：資料層問題通常會影響特定服務或工作負載，具體取決於 Envoy 快取代理伺服器的流量模式和資源使用率。

調整資料層

如要調整資料平面，請嘗試下列技巧：

為工作負載設定水平 Pod 自動調度資源 (HPA)

使用水平 Pod 自動調度資源 (HPA)，根據資源使用率動態調度工作負載，並新增 Pod。設定 HPA 時，請考量下列事項：

  • 使用 --horizontal-pod-autoscaler-sync-period 參數調整 kube-controller-manager，以調整 HPA 控制器的輪詢率。預設的輪詢率為 15 秒，如果您預期流量會快速飆升，可以考慮將此值調低。如要進一步瞭解何時應在 GKE 中使用 HPA，請參閱「水平 Pod 自動調度資源」。

  • 預設的調整行為可能會導致大量 Pod 一次性部署 (或終止)，進而導致資源用量激增。建議您使用資源調度政策，限制 Pod 部署的速度。

  • 使用 EXIT_ON_ZERO_ACTIVE_CONNECTIONS 可避免在縮減時中斷連線。

如要進一步瞭解 HPA，請參閱 Kubernetes 說明文件中的「水平 Pod 自動調度」一文。

最佳化 Envoy Proxy 設定

如要最佳化 Envoy Proxy 設定，請考慮下列最佳化建議：

資源限制

您可以在 Pod 規格中為 Envoy 附屬程式定義資源要求和限制。這麼做可避免資源爭用，並確保效能一致。

您也可以使用資源註解，為網格中的所有 Envoy 代理程式設定預設資源限制。

Envoy 快取代理的最佳資源限制取決於流量量、工作負載複雜度和 GKE 節點資源等因素。持續監控及微調服務網格，確保最佳效能。

重要考量事項：

  • 服務品質 (QoS)：設定要求和限制，可確保 Envoy Proxy 提供可預測的服務品質。

範圍服務依附元件

建議您透過 Sidecar API 宣告所有依附元件，藉此精簡網格依附元件圖表。這會限制傳送至特定工作負載的設定大小和複雜度，這對較大的網格而言至關重要。

舉例來說，以下是網路精品店範例應用程式的流量圖表。

包含許多葉節的 Online Boutique 範例應用程式流量圖表樹狀圖

這些服務大多是圖中的葉節點，因此不需要包含網格中任何其他服務的傳出資訊。您可以套用 Sidecar 資源，限制這些葉子服務的 sidecar 設定範圍，如以下範例所示。

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: leafservices
  namespace: default
spec:
  workloadSelector:
    labels:
      app: cartservice
      app: shippingservice
      app: productcatalogservice
      app: paymentservice
      app: emailservice
      app: currencyservice
  egress:
  -   hosts:
    -   "~/*"

如要進一步瞭解如何部署這個範例應用程式，請參閱「Online Boutique 範例應用程式」。

側載範圍設定的另一個好處，是可減少不必要的 DNS 查詢。設定服務依附元件的範圍，可確保 Envoy 補充程式只針對實際要與其通訊的服務，而非服務網格中的每個叢集，執行 DNS 查詢。

對於任何大規模部署作業，如果其 Sidecar 中出現大型設定檔大小的問題，建議您務必設定服務依附元件的範圍，以便調整網格可擴充性。

監控及微調

設定初始資源限制後，請務必監控 Envoy 代理程式，確保其效能最佳化。使用 GKE 資訊主頁監控 CPU 和記憶體用量，並視需要調整資源限制。

如要判斷 Envoy 代理程式是否需要提高資源限制，請在一般和流量高峰情況下監控其資源耗用量。請注意以下事項：

  • 高 CPU 使用率：如果 Envoy 的 CPU 使用率持續接近或超過上限，可能會導致處理要求出現困難，導致延遲時間增加或要求遭到捨棄。建議您調高 CPU 限制。

    在這種情況下，您可能會傾向使用水平調整資源配置，但如果附加元件 Proxy 無法持續以與應用程式容器一樣的速度處理要求，調整 CPU 限制可能會帶來最佳成效。

  • 記憶體用量偏高：如果 Envoy 的記憶體用量接近或超過上限，可能會開始捨棄連線或發生記憶體不足 (OOM) 錯誤。請提高記憶體限制，以免發生這些問題。

  • 錯誤記錄：檢查 Envoy 的記錄，找出與資源耗盡相關的錯誤，例如上游連線錯誤或在標頭前中斷連線或重設或開啟太多檔案錯誤。這些錯誤可能表示 Proxy 需要更多資源。如要瞭解與資源調度相關的其他錯誤，請參閱資源調度疑難排解說明文件。

  • 效能指標：監控要求延遲時間、錯誤率和傳輸量等重要效能指標。如果您發現效能降低與資源使用率偏高有關，可能就需要提高限制。

積極設定及監控資料層 Proxy 的資源限制，可確保服務網格在 GKE 上能有效擴充。

控制層的調整

本節說明如何調整控制平面設定以進行擴充。

探索選取器

探索選取器是 MeshConfig 中的欄位，可讓您指定控制平面在計算側邊車設定更新時，要考量的命名空間組合。

根據預設，Cloud Service Mesh 會監控叢集中的所有命名空間。對於不需要監控所有資源的大型叢集而言，這可能會造成瓶頸。

使用 discoverySelectors 限制監控及處理的 Kubernetes 資源 (例如服務、Pod 和端點) 數量，藉此減少控制平面的運算負載。

使用 TRAFFIC_DIRECTOR 控制平面實作時，Cloud Service Mesh 只會為 discoverySelectors 中指定命名空間的 Kubernetes 資源建立 Google Cloud 資源，例如後端服務和網路端點群組。

詳情請參閱 Istio 說明文件中的「探索選取器」。

建構韌性

您可以調整下列設定，為服務網格建立復原能力：

離群值偵測

異常情況偵測功能會監控上游服務中的主機，並在達到某些錯誤門檻時，將這些主機從負載平衡集區中移除。

  • 主要設定：
    • outlierDetection：用來將健康狀態不良的主機從負載平衡集區中移除的控管設定。
  • 優點：在負載平衡集區中維持健康的主機組合。

詳情請參閱 Istio 說明文件中的「異常值偵測」一節。

重試

自動重試失敗的要求，以減輕暫時性錯誤。

  • 主要設定：
    • attempts：重試次數。
    • perTryTimeout：重試嘗試次數的逾時時間。請將此值設為低於整體逾時時間。這項設定會決定每次重試嘗試之間的等待時間長度。
    • retryBudget：並行重試次數上限。
  • 優點：提高要求成功率，減少間歇性失敗的影響。

考量因素：

  • 冪等性：請確認要重試的作業是冪等的，也就是說，重複執行該作業不會產生意外的副作用。
  • 重試次數上限：限制重試次數 (例如最多 3 次重試)，以免發生無限迴圈。
  • 斷路器：將重試與斷路器整合，以免在服務持續失敗時重試。

詳情請參閱 Istio 說明文件中的「重試」。

逾時

使用逾時時間，定義允許的請求處理時間上限。

  • 主要設定：
    • timeout：特定服務的要求逾時。
    • idleTimeout：連線可閒置的時間長度，超過時間就會關閉。
  • 優點：改善系統回應速度、防範資源外洩，並強化防範惡意流量。

考量因素：

  • 網路延遲：考量服務之間的預期往返時間 (RTT)。為意外延誤留出一些緩衝時間。
  • 服務依附元件圖：針對鏈結要求，請確保呼叫服務的逾時時間短於其依附元件的累積逾時時間，以免發生連鎖失敗。
  • 作業類型：長時間執行的工作可能需要比資料擷取作業更長的逾時時間。
  • 錯誤處理：逾時應觸發適當的錯誤處理邏輯 (例如重試、備用、電路中斷)。

詳情請參閱 Istio 說明文件中的「逾時」一節。

監控及微調

建議您先從逾時、異常值偵測和重試的預設設定開始，然後根據特定服務需求和觀察到的流量模式，逐步調整這些設定。舉例來說，請查看實際資料，瞭解服務通常需要多久才能回應。然後調整逾時值，以符合各服務或端點的特定特性。

遙測

使用遙測資料持續監控服務網格，並調整其設定，以便提升效能和可靠性。

  • 指標：使用全面的指標，特別是要求量、延遲時間和錯誤率。整合 Cloud Monitoring 以進行視覺化和警示。
  • 分散式追蹤：啟用分散式追蹤整合功能，與 Cloud Trace 整合，深入瞭解各項服務的請求流程。
  • 記錄：設定存取記錄，擷取有關要求和回應的詳細資訊。

延伸閱讀