在 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 節流等問題。

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

設定傳播

使用代管式 Cloud Service Mesh 時，請務必瞭解設定傳播延遲時間的預期情況。

由於控制層會協調全球基礎架構，因此對 VirtualService 和 DestinationRule 等設定資源的修改，需要較長時間才會傳播至 Sidecar。持續推送軟體更新平台不應依賴靜態時間延遲或嚴格的時間閘，來傳播設定。請確保推出作業是冪等的，並著重於主動驗證流量轉移或設定傳播是否成功完成，再繼續進行下一個步驟。除了確認正確設定後套用的專屬浸泡時間外，請移除對「時間」的任何依附元件。

資料平面擴充問題的症狀

服務間通訊的延遲時間增加：對網格內服務的要求延遲時間較長或逾時，但服務容器的 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 Sidecar 定義資源要求和限制。避免資源爭用，確保效能一致。

您可以使用 Pod 規格中的資源註解，覆寫特定工作負載的資源限制。

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 補充 Proxy 只會查詢實際要通訊的服務，而不是服務網格中的每個叢集。

對於任何大規模部署作業，如果側車中的大型設定大小發生問題，強烈建議您將服務依附元件範圍限定在網格可擴充性內。

如要限制單一命名空間內所有工作負載的設定範圍，請在該命名空間中建立一個 Sidecar 資源。這會指示該命名空間中的所有 Envoy Proxy，只接收自身命名空間中服務的設定。

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: sidecar
  namespace: my-app
spec:
  egress:
  -   hosts:
    -   "my-app/*"

如要為網格中的每個命名空間套用預設行為，請將單一 Sidecar 資源套用至根命名空間 (通常是 istio-system)。

下列 Sidecar 會將網格中每個 Sidecar 的輸出流量，限制在自身命名空間內的服務。

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: sidear
  namespace: istio-system
spec:
  egress:
  -   hosts:
    -   "./*"

請注意，Cloud Service Mesh 對單一網格中可建立的 Sidecar 資源總數設有限制。因此建議您建立命名空間層級的 Sidecar。

最佳化流量拆分

如果您經常轉移流量 (例如逐步推出或藍綠部署)，用來分割流量的方法會影響設定延遲時間。

  • 避免使用子集進行快速轉移：在 VirtualService 中使用 subset 欄位分割流量，並搭配 DestinationRule，會導致控制層快速建立、分離及重新附加基礎網路端點群組 (NEG)。這項對帳作業會增加數分鐘的延遲，因此在快速自動推出期間，可能會略過中繼流量權重。
  • 偏好主機轉送：請設定部署作業，使用以主機為準的流量分割，而非使用子集。根據VirtualService主機設定在完全不同的後端 Kubernetes 服務之間路由流量，控制層可避免產生大量 NEG 設定。這可減少基礎架構的負擔，並大幅加快設定傳播速度。

監控及微調

設定初始資源限制後，請務必監控 Envoy 代理伺服器，確保效能達到最佳狀態。使用 GKE 資訊主頁監控 CPU 和記憶體用量，並視需要調整資源限制。

如要判斷 Envoy Proxy 是否需要提高資源限制，請監控其在一般和尖峰流量狀況下的資源消耗量。請注意以下事項：

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

    在這種情況下，您可能會傾向使用水平擴充功能進行擴充，但如果 Sidecar Proxy 無法持續以與應用程式容器相同的速度處理要求，調整 CPU 限制可能會產生最佳結果。

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

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

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

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

調整控制層規模

本節說明如何調整設定，以調度控制層資源。

探索選取器

探索選取器是 MeshConfig 中的欄位，可讓您指定控制平面在計算 Sidecar 的設定更新時，會考量的命名空間集。

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

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

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

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

盡量減少設定足跡

使用探索選取器可限制設定範圍。您可以使用 Sidecar 輸出設定來限制 Proxy 記憶體用量，但 Sidecar API 會建立更複雜的設定。請僅使用 Sidecar API 解決重大資料平面效能問題，因為這會增加控制平面負載，並降低網格的整體擴充性。

建構韌性

您可以調整下列設定，在服務網格中建構韌性：

離群值偵測

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

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

詳情請參閱 Istio 說明文件中的「離群值偵測」。

重試次數

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

  • 主要設定：
    • attempts：重試次數。
    • perTryTimeout：每次重試的逾時時間。設定的時間必須短於整體逾時時間。這項設定會決定每次重試嘗試的等待時間。
    • retryBudget：並行重試次數上限。
  • 優點：要求成功率提高，間歇性故障的影響減少。

考量因素：

  • 冪等性：確保重試的作業具有冪等性，也就是可以重複執行，不會產生非預期的連帶影響。
  • 重試次數上限：限制重試次數 (例如最多重試 3 次)，避免無限迴圈。
  • 斷路：整合重試與斷路器，防止服務持續失敗時重試。

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

逾時

使用逾時來定義要求處理允許的最長時間。

  • 主要設定：
    • timeout：特定服務的要求逾時。
    • idleTimeout：連線在關閉前可保持閒置的時間。
  • 優點：提升系統回應速度、防止資源洩漏、防範惡意流量。

考量因素：

  • 網路延遲：考量服務之間的預期封包往返時間 (RTT)。預留緩衝時間，以因應意外延誤。
  • 服務依附元件圖表：如果是鏈結要求，請確保呼叫服務的逾時時間短於依附元件的累計逾時時間，以免發生連鎖故障。
  • 作業類型：長時間執行的工作可能需要比資料擷取更長的逾時時間。
  • 錯誤處理：逾時應觸發適當的錯誤處理邏輯 (例如重試、備援、斷路)。

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

監控及微調

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

遙測

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

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

延伸閱讀