Cloud Service Mesh 和 Traffic Director 現已改名為 Cloud Service Mesh。詳情請參閱 Cloud Service Mesh 總覽。

本頁面由 Cloud Translation API 翻譯而成。

GKE 上的 Cloud Service Mesh 擴充限制

本文說明 GKE 上代管 Cloud Service Mesh 架構的控制層資源調度限制，協助您根據相關資訊做出部署決策。

總覽

GKE 上的 Cloud Service Mesh 擴充性取決於兩個主要元件 (資料層和控制層) 的運作效率。本文著重於控制層的擴充限制。如需資料平面擴充性的最佳做法，請參閱「擴充性最佳做法」。

部分記載的擴充限制會受到配額限制強制執行。如要超過這些限制，請提出配額提高要求。其他限制則不會嚴格執行，但如果超出限制，可能會導致未定義的行為和效能問題。

如要瞭解 Istio 資源如何轉換為 Google Cloud 資源，請先參閱「瞭解 API 資源」指南。

服務資源調度限制

服務資源調度受限於兩個維度

每個專案：每個Google Cloud 專案最多支援 1000 個 Cloud Service Mesh 服務 (Kubernetes 無介面服務除外)。
每個專案的每個區域：由於 Cloud Service Mesh 會為叢集中的 GKE 服務在每個區域建立網路端點群組，因此區域性 NEG 配額限制會套用至每個專案的服務數量，這些服務在該區域中可以有端點。

請注意，為特定成員 (即 GKE 叢集) 啟用 Cloud Service Mesh 後，叢集中的所有 Kubernetes 服務都會轉換為 Cloud Service Mesh 服務，包括以沒有 Cloud Service Mesh Sidecar 的工作負載為目標的服務。Cloud Service Mesh 會為 GKE 叢集中的所有服務建立區域網路端點群組。如果叢集是地區叢集，系統會為該地區的所有節點集區區域建立網路端點群組。

Cloud Service Mesh 服務與 Kubernetes 服務

Cloud Service Mesh 服務與 Kubernetes 服務不同，因為 Cloud Service Mesh 服務是每個連接埠對應一項服務。

舉例來說，這個 Kubernetes 服務會在內部轉換為兩個 Cloud Service Mesh 服務，每個通訊埠各有一個服務。

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    -   port: 80
      targetPort: 80
      protocol: TCP
      name: http
    -   port: 443
      targetPort: 443
      protocol: TCP
      name: https

目的地規則子集

使用子集設定 Istio Destination Rule API 時，每個子集可能會產生多個新的 Cloud Service Mesh 服務。

舉例來說，假設有下列 DestinationRule，目標是先前定義的 Kubernetes 服務：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-service-destinationrule
spec:
  host: my-service
  subsets:
  -   name: testversion
    labels:
      version: v3
  -   name: prodversion
    labels:
      version: v2

系統會為定義的每個子集建立新的合成服務。如果原始 Kubernetes 服務建立了兩個 Cloud Service Mesh 服務，DestinationRule 會為每個子集建立 2 個額外的 Cloud Service Mesh 服務，因此總共會有 6 個 Cloud Service Mesh 服務。

多專案部署作業

如果單一網格部署在不同專案的工作負載中，所有 Cloud Service Mesh 服務資源都會在機群主機專案中建立。 Google Cloud也就是說，這些叢集都會受到車隊主專案中 Cloud Service Mesh 可擴充性限制的影響。

Kubernetes 無標頭服務

相較於一般服務，Kubernetes 無介面服務的上限較低。每個叢集僅支援 50 個無標題 Cloud Service Mesh 服務。如需範例，請參閱 Kubernetes 網路說明文件。

Istio Sidecar 資源

Istio Sidecar API 的限制如下：

沒有 workloadSelector 的 Sidecar：每個叢集 150 個
補充資訊：每個叢集 20 個workloadSelector

端點資源調度限制

端點的資源調度限制通常如下：

Cloud Service Mesh 服務
GKE 叢集

一般 Kubernetes 服務

每個 NEG 的端點配額會影響單一 Kubernetes 服務可擁有的端點數量上限。

Kubernetes 無標頭服務

對於 Kubernetes 無標頭服務，Cloud Service Mesh 支援每個無標頭服務最多 36 個端點。如需範例，請參閱 Kubernetes 網路說明文件。

GKE 叢集限制

每個叢集最多可支援 5000 個端點 (Pod IP)。

閘道調度上限

使用 Istio Gateway 時，尤其是使用 Kubernetes Secret 中的 TLS 憑證終止 HTTPS 連線時，Cloud Service Mesh 最多支援下列數量的 Pod：

使用區域 GKE 叢集時，閘道 Pod 數量為 1500 個
使用區域或 Autopilot GKE 叢集時，最多可有 500 個閘道 Pod