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

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

このドキュメントの内容を理解するには、次の知識が必要です。

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

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

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

始める前に

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

  • 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 ロールが必要です。

マルチポートと NEG の上限

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

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

マルチクラスタ 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 トークンの Secret を作成します。

    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 トークンの Secret を作成します。

    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 の場合は、各リージョンにプロキシ専用サブネットを作成します。内部 Gateway の Envoy プロキシは、これらの専用サブネットを使用して VPC ネットワーク内のトラフィックを処理します。

  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 など）。

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

マルチクラスタ 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 カスタム リソースなどの必要なリソースをデプロイします。

  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

  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 倍以上に設定します。

たとえば、次のマニフェストでは、ロードバランサのタイムアウトを 100 秒に設定します。

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: 100
    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. kv-cache カスタム指標に基づいてロード バランシングを有効にするには、次の内容で backend-policy.yaml という名前のファイルを作成します。

    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

デプロイを確認する

内部ロードバランサを確認するには、VPC ネットワーク内からリクエストを送信する必要があります。これは、内部ロードバランサがプライベート IP アドレスを使用するためです。クラスタの 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
  }'

次のステップ