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

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

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

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

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

Google Cloud のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な 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、Google Kubernetes Engine API、Model Armor、Network Services API を有効にします。

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

  • Autoscaling API を有効にします。

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

  • Hugging Face の前提条件:

    • Hugging Face アカウントを作成します（まだ作成していない場合）。
    • Hugging Face の Llama 3.1 モデルへのアクセス権をリクエストして承認を取得します。
    • 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 ロールが必要です。

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

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 マルチクラスタ推論 Gateway などのマルチクラスタ機能を有効にするには、クラスタをフリートに登録します。

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

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

  2. 単一の 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 ネットワーク内のトラフィックを処理します。

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

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

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

  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 CRD をインストールします。

    # Copyright 2025 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: restrict-toleration
spec:
  failurePolicy: Fail
  paramKind:
    apiVersion: v1
    kind: ConfigMap
  matchConstraints:
    # GKE will mutate any pod specifying a CC label in a nodeSelector
    # or in a nodeAffinity with a toleration for the CC node label.
    # Mutation hooks will always mutate the K8s object before validating
    # the admission request.  
    # Pods created by Jobs, CronJobs, Deployments, etc. will also be validated.
    # See https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#admission-control-phases for details
    resourceRules:
    - apiGroups:   [""]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["pods"]
  matchConditions:
    - name: 'match-tolerations'
      # Validate only if compute class toleration exists
      # and the CC label tolerated is listed in the configmap.
      expression: > 
        object.spec.tolerations.exists(t, has(t.key) &&
        t.key == 'cloud.google.com/compute-class' &&
        params.data.computeClasses.split('\\n').exists(cc, cc == t.value))
  validations:
    # ConfigMap with permitted namespace list referenced via `params`.
    - expression: "params.data.namespaces.split('\\n').exists(ns, ns == object.metadata.namespace)"
      messageExpression: "'Compute class toleration not permitted on workloads in namespace ' + object.metadata.namespace"

---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: restrict-toleration-binding
spec:
  policyName: restrict-toleration
  validationActions: ["Deny"]
  paramRef:
    name: allowed-ccc-namespaces
    namespace: default
    parameterNotFoundAction: Deny
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: allowed-ccc-namespaces
  namespace: default
data:
  # Replace example namespaces in line-separated list below.
  namespaces: |
    foo
    bar
    baz
  # ComputeClass names to monitor with this validation policy.
  # The 'autopilot' and 'autopilot-spot' CCs are present on
  # all NAP Standard and Autopilot clusters.
  computeClasses: |
    MY_COMPUTE_CLASS
    autopilot
    autopilot-spot


    kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api-inference-extension/v1.1.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.1.0/config/crd/bases/inference.networking.x-k8s.io_inferenceobjectives.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 など）。

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

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

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

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

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api-inference-extension/v1.1.0/config/manifests/vllm/gpu-deployment.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 など）。

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

    apiVersion: inference.networking.x-k8s.io/v1alpha2
kind: InferenceObjective
metadata:
  name: food-review
spec:
  priority: 10
  poolRef:
    name: llama3-8b-instruct
    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-llama3-8b-instruct \
  --kube-context CLUSTER1_CONTEXT \
  --set inferencePool.modelServers.matchLabels.app=vllm-llama3-8b-instruct \
  --set provider.name=gke \
  --version v1.1.0 \
  oci://registry.k8s.io/gateway-api-inference-extension/charts/inferencepool

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

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

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

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

    kubectl annotate inferencepool vllm-llama3-8b-instruct networking.gke.io/export="True" \
    --context=CLUSTER1_CONTEXT

    kubectl annotate inferencepool vllm-llama3-8b-instruct networking.gke.io/export="True" \
    --context=CLUSTER2_CONTEXT

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

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

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

登録されているすべてのクラスタの 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-llama3-8b-instruct-default
spec:
  parentRefs:
  - name: cross-region-gateway
    kind: Gateway
  rules:
  - backendRefs:
    - group: networking.gke.io
      kind: GCPInferencePoolImport
      name: vllm-llama3-8b-instruct
---
apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: health-check-policy
  namespace: default
spec:
  targetRef:
    group: "networking.gke.io"
    kind: GCPInferencePoolImport
    name: vllm-llama3-8b-instruct
  default:
    config:
      type: HTTP
      httpHealthCheck:
        requestPath: /health
        port: 8000

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

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

    CLUSTER1_CONTEXT は、最初のクラスタ（構成クラスタ）のコンテキスト（gke_my-project_europe-west3-c_gke-west など）に置き換えます。

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

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

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

    apiVersion: autoscaling.gke.io/v1beta1
kind: AutoscalingMetric
metadata:
  name: gpu-cache
  namespace: default
spec:
  selector:
    matchLabels:
      app: vllm-llama3-8b-instruct
  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

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

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

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

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-llama3-8b-instruct
  default:
    timeoutSec: 100
    balancingMode: CUSTOM_METRICS
    trafficDuration: LONG
    customMetrics:
    - name: gke.named_metrics.kv-cache
      dryRun: false

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

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

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

カスタム指標

ロード バランシングを最適化するには、まず目標使用率を 60% に設定します。このターゲットを達成するには、GCPBackendPolicy の customMetrics 構成で maxUtilization: 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-llama3-8b-instruct
  default:
    balancingMode: CUSTOM_METRICS
    trafficDuration: LONG
    customMetrics:
      - name: gke.named_metrics.kv-cache
        dryRun: false
        maxUtilization: 60

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

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

    CLUSTER1_CONTEXT は、最初のクラスタのコンテキスト（gke_my-project-europe-west3-c-gke-west など）に置き換えます。

処理中のリクエスト

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

  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-llama3-8b-instruct
  default:
    balancingMode: IN_FLIGHT
    trafficDuration: LONG
    maxInFlightRequestsPerEndpoint: 1000
    dryRun: false

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

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

    CLUSTER1_CONTEXT は、最初のクラスタのコンテキスト（gke_my-project_europe-west3-c_gke-west など）に置き換えます。

デプロイを確認する

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

  1. 一時 Pod でインタラクティブ シェル セッションを開始します。

    kubectl run -it --rm --image=curlimages/curl curly --context=CLUSTER1_CONTEXT -- /bin/sh

    CLUSTER1_CONTEXT は、最初のクラスタのコンテキスト（gke_my-project_europe-west3-c_gke-west など）に置き換えます。

  2. 新しいシェルから、Gateway の IP アドレスを取得してテスト リクエストを送信します。

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

curl -i -X POST ${GW_IP}:80/v1/completions -H 'Content-Type: application/json' -d '{
"model": "food-review-1",
"prompt": "What is the best pizza in the world?",
"max_tokens": 100,
"temperature": 0
}'

    成功したレスポンスの例を次に示します。

    {
  "id": "cmpl-...",
  "object": "text_completion",
  "created": 1704067200,
  "model": "food-review-1",
  "choices": [
    {
      "text": "The best pizza in the world is subjective, but many argue for Neapolitan pizza...",
      "index": 0,
      "logprobs": null,
      "finish_reason": "length"
    }
  ],
  "usage": {
    "prompt_tokens": 10,
    "completion_tokens": 100,
    "total_tokens": 110
  }
}

次のステップ