GKE 上の Cloud Service Mesh のスケーリングの上限

このドキュメントでは、GKE のマネージド Cloud Service Mesh アーキテクチャのコントロールプレーンのスケーリングの上限について説明します。これにより、デプロイに関する十分な情報に基づいて決定できます。

概要

GKE 上の Cloud Service Mesh のスケーラビリティは、2 つの主要コンポーネント（データプレーンとコントロールプレーン）の効率的な運用に依存します。このドキュメントでは、コントロールプレーンのスケーリングの上限について説明します。データプレーンのスケーラビリティのベストプラクティスについては、スケーラビリティのベストプラクティスをご覧ください。

記載されているスケーリングの上限の一部は、割り当て制限によって適用されます。上限を超える場合は、割り当て増加リクエストが必要になります。その他の制限は厳密に適用されませんが、超過すると動作やパフォーマンスが未定義になる可能性があります。

Istio リソースが Google Cloud リソースに変換される仕組みについては、まず API リソースの理解ガイドをご覧ください。

サービスのスケーリングの上限

サービスのスケーリングは 2 つのディメンションで制限される

プロジェクトごと:Google Cloud プロジェクトごとに最大 1,000 個の Cloud Service Mesh サービスがサポートされます（Kubernetes ヘッドレスサービスを除く）。
ゾーンごと、プロジェクトごと: Cloud Service Mesh は、クラスタ内の GKE サービスにゾーンごとのネットワークエンドポイントグループを作成するため、ゾーン NEG の割り当て上限は、そのゾーンにエンドポイントを持つことができるプロジェクトあたりのサービス数に適用されます。

特定のメンバーシップ（GKE クラスタなど）で Cloud Service Mesh が有効になると、クラスタ内の すべての Kubernetes サービスが Cloud Service Mesh サービスに変換されます。これには、Cloud Service Mesh サイドカーのないワークロードをターゲットとするサービスも含まれます。Cloud Service Mesh は、GKE クラスタ内のすべてのサービスにゾーンネットワークエンドポイントグループを作成します。クラスタがリージョンの場合、リージョン内のすべてのノードプールゾーンにネットワークエンドポイントグループが作成されます。

Cloud Service Mesh サービスと Kubernetes サービス

Cloud Service Mesh サービスは、ポートごとに 1 つのサービスであるという点で、Kubernetes サービスとは異なります。

たとえば、この Kubernetes サービスは内部で 2 つの Cloud Service Mesh サービス（ポートごとに 1 つ）に変換されます。

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 サービスが生成される可能性があります。

たとえば、前述の Kubernetes サービスをターゲットとする次の DestinationRule について考えてみましょう。

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 Service が 2 つの Cloud Service Mesh サービスを作成した場合、DestinationRule はサブセットごとに 2 つずつ、合計 6 つの Cloud Service Mesh サービスを作成します。

マルチプロジェクトのデプロイ

1 つのメッシュが異なるプロジェクトのワークロードにデプロイされている場合、すべての Cloud Service Mesh サービスリソースはフリートホストプロジェクトに作成されます。 Google Cloudつまり、これらはすべて、フリートホストプロジェクトの Cloud Service Mesh のスケーラビリティの制限を受けます。

Kubernetes Headless Service

Kubernetes ヘッドレスサービスには、通常のサービスと比較して下限があります。Cloud Service Mesh は、クラスタごとに 50 個のヘッドレス Cloud Service Mesh サービスのみをサポートします。例については、Kubernetes ネットワークのドキュメントをご覧ください。

エンドポイントのスケーリングの上限

エンドポイントのスケーリングの上限は通常、次のとおりです。

Cloud Service Mesh サービス
GKE クラスタ

通常の Kubernetes サービス

NEG あたりのエンドポイントの割り当ては、単一の Kubernetes サービスに属するエンドポイントの最大数に影響します。

Kubernetes Headless Service

Kubernetes ヘッドレスサービスの場合、Cloud Service Mesh はヘッドレスサービスごとに最大 36 個のエンドポイントをサポートします。例については、Kubernetes ネットワークのドキュメントをご覧ください。

GKE クラスタの上限

Cloud Service Mesh は、クラスタごとに最大 5,000 個のエンドポイント（Pod IP）をサポートしています。

ゲートウェイのスケーリングの上限

Istio Gateway を使用する場合、特に Kubernetes Secret の TLS 認証情報を使用して HTTPS 接続を終端する場合、Cloud Service Mesh は最大で次の数の Pod をサポートします。

リージョン GKE クラスタを使用する場合: 1,500 個のゲートウェイ Pod
ゾーンまたは Autopilot GKE クラスタを使用する場合: 500 個の Gateway Pod