マルチクラスタ GKE Inference Gateway を設定する

このドキュメントでは、マルチクラスタ Google Kubernetes Engine（GKE）Inference Gateway を設定して、異なるリージョンにまたがる複数の GKE クラスタ間で AI/ML 推論ワークロードをインテリジェントにロード バランシングする方法について説明します。この設定では、Gateway API、マルチクラスタ Ingress、InferencePool や InferenceObjective などのカスタム リソースを使用して、モデル サービング デプロイのスケーラビリティの向上、高可用性の確保、リソース使用率の最適化を実現します。

このドキュメントを理解するには、次の内容を理解しておく必要があります。

このドキュメントは、次のペルソナを対象としています。

  • AI / ML ワークロードの提供に GKE のコンテナ オーケストレーション機能を使用する ML エンジニア、プラットフォーム管理者 / オペレーター、データ / AI スペシャリスト。
  • GKE ネットワーキングを操作するクラウド アーキテクトまたはネットワーキング スペシャリスト。

Cloud de Confiance by S3NS のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE Enterprise ユーザーのロールとタスクをご覧ください。

始める前に

作業を始める前に、次のタスクが完了していることを確認してください。

  • Google Kubernetes Engine API を有効にする。
    • Google Kubernetes Engine API を有効化
  • このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化します。gcloud CLI をインストール済みの場合は、gcloud components update コマンドを実行して最新のバージョンを取得します。以前のバージョンの gcloud CLI では、このドキュメントのコマンドを実行できない場合があります。

  • Compute Engine API、Kubernetes Engine API、Model Armor、Network Services API を有効にします。

    API へのアクセスを有効にするに移動し、手順に沿って操作します。

  • Autoscaling API を有効にします。

    Autoscaling API に移動し、手順に沿って操作します。

  • GKE Hub API を有効にします。

    GKE Hub API に移動し、手順に沿って操作します。

    または、Google Cloud CLI を使用します。

    gcloud services enable gkehub.googleapis.com --project=PROJECT_ID

  • Hugging Face の前提条件:

    • Hugging Face アカウントを作成します（まだ作成していない場合）。
    • Hugging Face の Qwen3-32B モデルへのアクセスをリクエストして承認を取得します。
    • Hugging Face のモデルのページでライセンス同意契約に署名します。
    • 少なくとも Read 権限を持つ Hugging Face アクセス トークンを生成します。

要件

  • H100 GPU 用にプロジェクトに十分な割り当てがあることを確認します。詳細については、GPU 割り当てを計画すると数量に基づく割り当てをご覧ください。
  • GKE バージョン 1.34.1-gke.1127000 以降を使用します。
  • gcloud CLI バージョン 480.0.0 以降を使用します。
  • ノード サービス アカウントには、Autoscaling API に指標を書き込む権限が必要です。
  • プロジェクトに roles/container.admin と roles/iam.serviceAccountAdmin の IAM ロールが必要です。
  • 構成クラスタを含む、フリートに登録するすべてのクラスタは、同じ VPC ネットワークに存在する必要があります。マルチクラスタ Gateway は、異なる VPC ネットワーク内のクラスタ間のロード バランシングをサポートしていません。

マルチポートと NEG の上限

マルチクラスタ設定でマルチポート InferencePool リソースをデプロイする場合は、 Cloud de Confiance by S3NS バックエンド サービスの NEG 制限を考慮してください。各ゾーンの各ポートは、専用の NEG を作成します。たとえば、3 つのゾーンと 8 つのポートで構成された InferencePool を持つリージョン クラスタは、24 個の NEG を使用します。Backend Service は 50 個の NEG に制限されているため、この特定の InferencePool を集約できるクラスタは最大 2 つです。

マルチクラスタ推論ゲートウェイを設定する

マルチクラスタ GKE Inference Gateway を設定する手順は次のとおりです。

クラスタとノードプールを作成する

AI/ML 推論ワークロードをホストし、リージョン間のロード バランシングを有効にするには、異なるリージョンに 2 つの GKE クラスタを作成します。各クラスタには H100 GPU ノードプールがあります。

  1. 最初のクラスタを作成します。

    gcloud container clusters create CLUSTER_1_NAME \
    --region LOCATION \
    --project=PROJECT_ID \
    --gateway-api=standard \
    --release-channel "rapid" \
    --cluster-version=GKE_VERSION \
    --machine-type="MACHINE_TYPE" \
    --disk-type="DISK_TYPE" \
    --enable-managed-prometheus --monitoring=SYSTEM,DCGM \
    --hpa-profile=performance \
    --async # Allows the command to return immediately

    次のように置き換えます。

    • CLUSTER_1_NAME: 最初のクラスタの名前（gke-west など）。
    • LOCATION: 最初のクラスタのリージョン（europe-west3 など）。
    • PROJECT_ID: プロジェクト ID。
    • GKE_VERSION: 使用する GKE のバージョン（1.34.1-gke.1127000 など）。
    • MACHINE_TYPE: クラスタノードのマシンタイプ（例: c2-standard-16）。
    • DISK_TYPE: クラスタノードのディスクタイプ（例: pd-standard）。

  2. 最初のクラスタに H100 ノードプールを作成します。

    gcloud container node-pools create NODE_POOL_NAME \
    --accelerator "type=nvidia-h100-80gb,count=2,gpu-driver-version=latest" \
    --project=PROJECT_ID \
    --location=CLUSTER_1_ZONE \
    --node-locations=CLUSTER_1_ZONE \
    --cluster=CLUSTER_1_NAME \
    --machine-type=NODE_POOL_MACHINE_TYPE \
    --num-nodes=NUM_NODES \
    --spot \
    --async # Allows the command to return immediately

    次のように置き換えます。

    • NODE_POOL_NAME: ノードプールの名前（h100 など）。
    • PROJECT_ID: プロジェクト ID。
    • CLUSTER_1_ZONE: 最初のクラスタのゾーン（europe-west3-c など）。
    • CLUSTER_1_NAME: 最初のクラスタの名前（gke-west など）。
    • NODE_POOL_MACHINE_TYPE: ノードプールのマシンタイプ（例: a3-highgpu-2g）。
    • NUM_NODES: ノードプール内のノード数（例: 3）。

  3. 認証情報を取得します。

    gcloud container clusters get-credentials CLUSTER_1_NAME \
    --location CLUSTER_1_ZONE \
    --project=PROJECT_ID

    次のように置き換えます。

    • PROJECT_ID: プロジェクト ID。
    • CLUSTER_1_NAME: 最初のクラスタの名前（gke-west など）。
    • CLUSTER_1_ZONE: 最初のクラスタのゾーン（europe-west3-c など）。

  4. 最初のクラスタで、Hugging Face トークンのシークレットを作成します。

    kubectl create secret generic hf-token \
    --from-literal=token=HF_TOKEN

    HF_TOKEN は、Hugging Face アクセス トークンに置き換えます。

  5. 最初のクラスタとは異なるリージョンに 2 番目のクラスタを作成します。

    gcloud container clusters create gke-east --region LOCATION \
    --project=PROJECT_ID \
    --gateway-api=standard \
    --release-channel "rapid" \
    --cluster-version=GKE_VERSION \
    --machine-type="MACHINE_TYPE" \
    --disk-type="DISK_TYPE" \
    --enable-managed-prometheus \
    --monitoring=SYSTEM,DCGM \
    --hpa-profile=performance \
    --async # Allows the command to return immediately while the
cluster is created in the background.

    次のように置き換えます。

    • LOCATION: 2 番目のクラスタのリージョン。これは、最初のクラスタとは異なるリージョンにする必要があります。例: us-east4
    • PROJECT_ID: プロジェクト ID。
    • GKE_VERSION: 使用する GKE のバージョン（1.34.1-gke.1127000 など）。
    • MACHINE_TYPE: クラスタノードのマシンタイプ（例: c2-standard-16）。
    • DISK_TYPE: クラスタノードのディスクタイプ（例: pd-standard）。

  6. 2 番目のクラスタに H100 ノードプールを作成します。

    gcloud container node-pools create h100 \
    --accelerator "type=nvidia-h100-80gb,count=2,gpu-driver-version=latest" \
    --project=PROJECT_ID \
    --location=CLUSTER_2_ZONE \
    --node-locations=CLUSTER_2_ZONE \
    --cluster=CLUSTER_2_NAME \
    --machine-type=NODE_POOL_MACHINE_TYPE \
    --num-nodes=NUM_NODES \
    --spot \
    --async # Allows the command to return immediately

    次のように置き換えます。

    • PROJECT_ID: プロジェクト ID。
    • CLUSTER_2_ZONE: 2 番目のクラスタのゾーン（us-east4-a など）。
    • CLUSTER_2_NAME: 2 番目のクラスタの名前（gke-east など）。
    • NODE_POOL_MACHINE_TYPE: ノードプールのマシンタイプ（例: a3-highgpu-2g）。
    • NUM_NODES: ノードプール内のノード数（例: 3）。

  7. 2 番目のクラスタで、認証情報を取得し、Hugging Face トークンのシークレットを作成します。

    gcloud container clusters get-credentials CLUSTER_2_NAME \
    --location CLUSTER_2_ZONE \
    --project=PROJECT_ID

kubectl create secret generic hf-token --from-literal=token=HF_TOKEN

    次のように置き換えます。

    • CLUSTER_2_NAME: 2 番目のクラスタの名前（gke-east など）。
    • CLUSTER_2_ZONE: 2 番目のクラスタのゾーン（us-east4-a など）。
    • PROJECT_ID: プロジェクト ID。
    • HF_TOKEN: Hugging Face アクセス トークン。

クラスタをフリートに登録する

マルチクラスタ GKE Inference Gateway などのマルチクラスタ機能を有効にするには、クラスタをフリートに登録します。

  1. 登録中に mTLS の問題が発生しないように、API エンドポイントのオーバーライドを設定します。

    gcloud config set api_endpoint_overrides/container https://container.googleapis.com/

  2. 両方のクラスタをプロジェクトのフリートに登録します。

    gcloud container fleet memberships register CLUSTER_1_NAME \
    --gke-cluster CLUSTER_1_ZONE/CLUSTER_1_NAME \
    --location=global \
    --project=PROJECT_ID

gcloud container fleet memberships register CLUSTER_2_NAME \
    --gke-cluster CLUSTER_2_ZONE/CLUSTER_2_NAME \
    --location=global \
    --project=PROJECT_ID

    次のように置き換えます。

    • CLUSTER_1_NAME: 最初のクラスタの名前（gke-west など）。
    • CLUSTER_1_ZONE: 最初のクラスタのゾーン（europe-west3-c など）。
    • PROJECT_ID: プロジェクト ID。
    • CLUSTER_2_NAME: 2 番目のクラスタの名前（gke-east など）。
    • CLUSTER_2_ZONE: 2 番目のクラスタのゾーン（us-east4-a など）。

  3. 単一の Gateway で複数のクラスタ間のトラフィックを管理できるようにするには、マルチクラスタ Ingress 機能を有効にして、構成クラスタを指定します。

    gcloud container fleet ingress enable \
    --config-membership=projects/PROJECT_ID/locations/global/memberships/CLUSTER_1_NAME

    次のように置き換えます。

    • PROJECT_ID: プロジェクト ID。
    • CLUSTER_1_NAME: 最初のクラスタの名前（gke-west など）。

プロキシ専用サブネットを作成する

内部ゲートウェイの場合は、各リージョンにプロキシ専用サブネットを作成します。内部 Gateway の Envoy プロキシは、これらの専用サブネットを使用して VPC ネットワーク内のトラフィックを処理します。

警告: Cloud de Confiance by S3NS は、各 VPC ネットワークのリージョンごとに 1 つのプロキシ専用サブネットのみを許可します。ターゲット リージョンに purpose=REGIONAL_MANAGED_PROXY 設定のプロキシ専用サブネットがすでに存在する場合、GLOBAL_MANAGED_PROXY サブネットの作成は失敗します。既存のリージョン プロキシ専用サブネットを削除する必要があります。リージョン プロキシ専用サブネットを削除すると、そのサブネットを使用するリージョン内のリージョン Envoy ベースのロードバランサに影響するため、それに応じて変更を計画してください。

  1. 最初のクラスタのリージョンにサブネットを作成します。

    gcloud compute networks subnets create CLUSTER_1_REGION-subnet \
    --purpose=GLOBAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=CLUSTER_1_REGION \
    --network=default \
    --range=10.0.0.0/23 \
    --project=PROJECT_ID

  2. 2 番目のクラスタのリージョンにサブネットを作成します。

    gcloud compute networks subnets create CLUSTER_2_REGION-subnet \
    --purpose=GLOBAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=CLUSTER_2_REGION \
    --network=default \
    --range=10.5.0.0/23 \
    --project=PROJECT_ID

    次のように置き換えます。

    • PROJECT_ID: プロジェクト ID。
    • CLUSTER_1_REGION: 最初のクラスタのリージョン（例: europe-west3）。
    • CLUSTER_2_REGION: 2 番目のクラスタのリージョン（例: us-east4）。

必要な CustomResourceDefinition をインストールする

マルチクラスタ GKE Inference Gateway は、InferencePool や InferenceObjective などのカスタム リソースを使用します。GKE Gateway API コントローラは、InferencePool CustomResourceDefinition を管理します。ただし、アルファ版の InferenceObjective CustomResourceDefinition をクラスタに手動でインストールする必要があります。

  1. クラスタのコンテキスト変数を定義します。

    CLUSTER1_CONTEXT="gke_PROJECT_ID_CLUSTER_1_ZONE_CLUSTER_1_NAME"
CLUSTER2_CONTEXT="gke_PROJECT_ID_CLUSTER_2_ZONE_CLUSTER_2_NAME"

    次のように置き換えます。

    • PROJECT_ID: プロジェクト ID。
    • CLUSTER_1_ZONE: 最初のクラスタのゾーン（europe-west3-c など）。
    • CLUSTER_1_NAME: 最初のクラスタの名前（gke-west など）。
    • CLUSTER_2_ZONE: 2 番目のクラスタのゾーン（us-east4-a など）。
    • CLUSTER_2_NAME: 2 番目のクラスタの名前（gke-east など）。

  2. 両方のクラスタに InferenceObjective CustomResourceDefinition をインストールします。

    kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api-inference-extension/v1.5.0/config/crd/bases/inference.networking.x-k8s.io_inferenceobjectives.yaml --context=$CLUSTER1_CONTEXT

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api-inference-extension/v1.5.0/config/crd/bases/inference.networking.x-k8s.io_inferenceobjectives.yaml --context=$CLUSTER2_CONTEXT

リソースをターゲット クラスタにデプロイする

各クラスタで AI/ML 推論ワークロードを使用できるようにするには、モデルサーバーや InferenceObjective カスタム リソースなどの必要なリソースをデプロイします。

注: このドキュメントの例では vLLM を使用していますが、マルチクラスタ推論ゲートウェイはモデルサーバー プラットフォームに依存せず、SGLang などの他のモデルサーバーでも動作します。別のモデルサーバーを使用する場合は、次の設定を調整します。

  • サービスポート。InferencePool ターゲット ポート、HealthCheckPolicy ポート、AutoscalingMetric エンドポイント ポートをモデルサーバーのサービング ポートに設定します。たとえば、SGLang はデフォルトでポート 8000 ではなくポート 30000 で提供されます。
  • 指標名。指標名はモデルサーバーごとに異なります。たとえば、SGLang は KV キャッシュ使用率を vllm:kv_cache_usage_perc 指標ではなく sglang:token_usage 指標としてレポートします。モデルサーバーの指標を AutoscalingMetric リソースの kv-cache エクスポート名にマッピングします。vLLM 以外のモデルサーバーのカスタム指標を抽出するには、互換性のある Endpoint Picker（EPP）イメージが必要です。サポートされている最新のチャート リリースを使用してください。
  • マルチノード モデル提供。1 つのモデル レプリカが複数のノードにまたがっている場合（たとえば、LeaderWorkerSet API を使用して大規模なモデルをサービングする場合）、リーダー Pod（ランク 0）のみが API をサービングします。InferencePool modelServers.matchLabels セレクタを構成して、リーダー Pod のみと一致するようにします（apps.kubernetes.io/pod-index: "0" ラベルを追加するなど）。セレクタがワーカー Pod にも一致する場合、ゲートウェイはリクエストを処理できない Pod に転送し、これらのリクエストは HTTP 404 Not Found ステータス コードで失敗します。

  1. 両方のクラスタにモデルサーバーをデプロイします。

    kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api-inference-extension/v1.5.0/config/manifests/vllm/gpu-deployment.yaml --context=$CLUSTER1_CONTEXT

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api-inference-extension/v1.5.0/config/manifests/vllm/gpu-deployment.yaml --context=$CLUSTER2_CONTEXT

  2. 両方のクラスタに InferenceObjective リソースをデプロイします。次のサンプル マニフェストを inference-objective.yaml という名前のファイルに保存します。

    apiVersion: inference.networking.x-k8s.io/v1alpha2
kind: InferenceObjective
metadata:
  name: food-review
spec:
  priority: 10
  poolRef:
    name: vllm-qwen3-32b
    group: "inference.networking.k8s.io"

  3. マニフェストを両方のクラスタに適用します。

    kubectl apply -f inference-objective.yaml --context=$CLUSTER1_CONTEXT
kubectl apply -f inference-objective.yaml --context=$CLUSTER2_CONTEXT

    次のように置き換えます。

    • $CLUSTER1_CONTEXT: 最初のクラスタのコンテキスト（例: gke_my-project_europe-west3-c_gke-west）。
    • $CLUSTER2_CONTEXT: 2 番目のクラスタのコンテキスト（gke_my-project_us-east4-a_gke-east など）。

  4. Helm を使用して、両方のクラスタに InferencePool リソースをデプロイします。

      helm install vllm-qwen3-32b \
  --kube-context $CLUSTER1_CONTEXT \
  --set inferencePool.modelServers.matchLabels.app=vllm-qwen3-32b \
  --set provider.name=gke \
  --set inferenceExtension.monitoring.gke.enabled=true \
  --version v1.5.0 \
  oci://registry.k8s.io/gateway-api-inference-extension/charts/inferencepool

    helm install vllm-qwen3-32b \
  --kube-context $CLUSTER2_CONTEXT \
  --set inferencePool.modelServers.matchLabels.app=vllm-qwen3-32b \
  --set provider.name=gke \
  --set inferenceExtension.monitoring.gke.enabled=true \
  --version v1.5.0 \
  oci://registry.k8s.io/gateway-api-inference-extension/charts/inferencepool

    上記のコマンドでは、この設定で推奨されるバージョンである Helm チャートのバージョン v1.5.0 を使用しています。Helm チャートは、単一クラスタでの使用を目的とした GCPBackendPolicy カスタム リソースと HealthCheckPolicy カスタム リソースもインストールします。

    InferencePool Helm チャートのバージョン v1.1.0 では、--set inferencePool.targetPortNumber フラグが無視され、ターゲット ポートがデフォルトの 8000 になることがあります。モデルサーバーが別のポートをリッスンしている場合（たとえば、SGLang はデフォルトでポート 30000 でサービスを提供します）、インストール後にポートを確認します。

    kubectl get inferencepool POOL_NAME -o jsonpath='{.spec.targetPorts}' \
    --context=CLUSTER_CONTEXT

    ポートが正しくない場合は、エクスポートする前に InferencePool カスタム リソースにパッチを適用します。

    kubectl patch inferencepool POOL_NAME --type=merge \
    -p '{"spec":{"targetPorts":[{"number":TARGET_PORT}]}}' \
    --context=CLUSTER_CONTEXT

  5. 両方のクラスタで InferencePool リソースをエクスポート済みとしてマークします。このアノテーションにより、InferencePool を構成クラスタでインポートできるようになります。これは、マルチクラスタ ルーティングに必要な手順です。

    kubectl annotate inferencepool vllm-qwen3-32b networking.gke.io/export="True" \
    --context=$CLUSTER1_CONTEXT

    kubectl annotate inferencepool vllm-qwen3-32b networking.gke.io/export="True" \
    --context=$CLUSTER2_CONTEXT

リソースを構成クラスタにデプロイする

登録されているすべてのクラスタの InferencePool リソース間でトラフィックをルーティングしてロードバランスする方法を定義するには、Gateway、HTTPRoute、HealthCheckPolicy リソースをデプロイします。これらのリソースは、このドキュメントでは gke-west と指定されている構成クラスタにのみデプロイします。

  1. 次の内容で mcig.yaml という名前のファイルを作成します。

    ---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: cross-region-gateway
  namespace: default
spec:
  gatewayClassName: gke-l7-cross-regional-internal-managed-mc
  addresses:
  - type: networking.gke.io/ephemeral-ipv4-address/europe-west3
    value: "europe-west3"
  - type: networking.gke.io/ephemeral-ipv4-address/us-east4
    value: "us-east4"
  listeners:
  - name: http
    protocol: HTTP
    port: 80
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: vllm-qwen3-32b-default
spec:
  parentRefs:
  - name: cross-region-gateway
    kind: Gateway
  rules:
  - backendRefs:
    - group: networking.gke.io
      kind: GCPInferencePoolImport
      name: vllm-qwen3-32b
---
apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: health-check-policy
  namespace: default
spec:
  targetRef:
    group: "networking.gke.io"
    kind: GCPInferencePoolImport
    name: vllm-qwen3-32b
  default:
    config:
      type: HTTP
      httpHealthCheck:
        requestPath: /health
        port: 8000

  2. 次のようにマニフェストを適用します。

    kubectl apply -f mcig.yaml --context=$CLUSTER1_CONTEXT

カスタム指標レポートを有効にする

カスタム指標のレポートを有効にして、クロスリージョン ロード バランシングの改善に役立てるには、すべてのクラスタから KV キャッシュ使用率指標をエクスポートします。ロードバランサは、このエクスポートされた KV キャッシュ使用状況データをカスタム ロードシグナルとして使用します。このカスタム ロード シグナルを使用すると、各クラスタの実際のワークロードに基づいて、よりインテリジェントなロード バランシングの決定が可能になります。

  1. 次の内容で metrics.yaml という名前のファイルを作成します。

    apiVersion: autoscaling.gke.io/v1beta1
kind: AutoscalingMetric
metadata:
  name: gpu-cache
  namespace: default
spec:
  selector:
    matchLabels:
      app: vllm-qwen3-32b
  endpoints:
  - port: 8000
    path: /metrics
    metrics:
    - name: vllm:kv_cache_usage_perc # For vLLM versions v0.10.2 and newer
      exportName: kv-cache
    - name: vllm:gpu_cache_usage_perc # For vLLM versions v0.6.2 and newer
      exportName: kv-cache-old

  2. 両方のクラスタに指標構成を適用します。

    kubectl apply -f metrics.yaml --context=$CLUSTER1_CONTEXT
kubectl apply -f metrics.yaml --context=$CLUSTER2_CONTEXT

ロード バランシング ポリシーを構成する

AI/ML 推論のリクエストが GKE クラスタ間で分散される方法を最適化するには、ロード バランシング ポリシーを構成します。適切なバランシング モードを使用すると、リソースを効率的に使用し、個々のクラスタの過負荷を防ぎ、推論サービスのパフォーマンスと応答性を向上させることができます。

タイムアウトを構成する

リクエストの所要時間が長くなることが予想される場合は、ロードバランサのタイムアウトを長く構成します。GCPBackendPolicy で、timeoutSec フィールドを推定 P99 リクエスト レイテンシの 2 倍以上に設定します。同時実行性の高い長文コンテキスト推論ワークロードの場合は、最大 3600 秒のタイムアウトが必要になることがあります。たとえば、次のマニフェストでは、ロードバランサのタイムアウトを 600 秒に設定しています。

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
spec:
  targetRef:
    group: "networking.gke.io"
    kind: GCPInferencePoolImport
    name: vllm-qwen3-32b
  default:
    timeoutSec: 600
    balancingMode: CUSTOM_METRICS
    trafficDuration: LONG
    customMetrics:
      - name: gke.named_metrics.kv-cache
        dryRun: false
        maxUtilizationPercent: 60

詳細については、マルチクラスタ Gateway の制限事項をご覧ください。

カスタム指標と処理中のリクエストのロード バランシング モードは相互に排他的であるため、GCPBackendPolicy でこれらのモードのいずれか 1 つのみを構成します。

デプロイのロード バランシング モードを選択します。

カスタム指標

ロード バランシングを最適化するには、まず目標使用率を 60% に設定します。このターゲットを達成するには、GCPBackendPolicy の customMetrics 構成で maxUtilizationPercent: 60 を設定します。

  1. 次の内容で backend-policy.yaml という名前のファイルを作成し、kv-cache カスタム指標に基づくロード バランシングを有効にします。

    apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
spec:
  targetRef:
    group: "networking.gke.io"
    kind: GCPInferencePoolImport
    name: vllm-qwen3-32b
  default:
    balancingMode: CUSTOM_METRICS
    trafficDuration: LONG
    customMetrics:
      - name: gke.named_metrics.kv-cache
        dryRun: false
        maxUtilizationPercent: 60

  2. 新しいポリシーを適用します。

    kubectl apply -f backend-policy.yaml --context=$CLUSTER1_CONTEXT

処理中のリクエスト

インフライト バランシング モードを使用するには、各バックエンドが処理できるインフライト リクエストの数を推定し、容量値を明示的に構成します。

  1. 次の内容で backend-policy.yaml という名前のファイルを作成して、進行中のリクエスト数に基づくロード バランシングを有効にします。

    kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: my-backend-policy
spec:
  targetRef:
    group: "networking.gke.io"
    kind: GCPInferencePoolImport
    name: vllm-qwen3-32b
  default:
    balancingMode: IN_FLIGHT
    trafficDuration: LONG
    maxInFlightRequestsPerEndpoint: 1000
    dryRun: false

  2. 新しいポリシーを適用します。

    kubectl apply -f backend-policy.yaml --context=$CLUSTER1_CONTEXT

デプロイを確認する

内部ロードバランサはプライベート IP アドレスを使用するため、内部ロードバランサを検証するには、VPC ネットワーク内からリクエストを送信する必要があります。クラスタの 1 つに一時 Pod を実行して、VPC ネットワークからリクエストを送信し、内部ロードバランサを確認します。

  1. 新しいシェルから、Gateway の IP アドレスを取得します。

    GW_IP=$(kubectl get gateway/cross-region-gateway -n default --context=$CLUSTER1_CONTEXT -o jsonpath='{.status.addresses[0].value}')

  2. クラスタ内の一時 Pod からテスト リクエストを送信します。

    kubectl run -it --rm --image=curlimages/curl curly --context=$CLUSTER1_CONTEXT -- \
  curl -i -X POST ${GW_IP}:80/v1/completions -H 'Content-Type: application/json' -d '{
  "model": "Qwen/Qwen3-32B",
  "prompt": "What is the best pizza in the world?",
  "max_tokens": 100,
  "temperature": 0
  }'

次のステップ