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

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

概要

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

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

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

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

サービスのスケーリングは 2 つの項目に沿って制限されます。

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

Cloud Service Mesh サービスと Kubernetes Service

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

たとえば、この Kubernetes Service は内部で 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 Service をターゲットとする次の 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 つずつ、さらに 4 つの Cloud Service Mesh サービスを作成し、合計で 6 つの Cloud Service Mesh サービスが作成されます。

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

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

Kubernetes Headless Service

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

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

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

  • Cloud Service Mesh サービス

  • GKE クラスタ

通常の Kubernetes Service

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

Kubernetes Headless Service

Kubernetes Headless Service の場合、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 個のゲートウェイ Pod