Menyiapkan Inference Gateway multi-cluster GKE

Dokumen ini menjelaskan cara menyiapkan Inference Gateway multi-cluster Google Kubernetes Engine (GKE) untuk menyeimbangkan beban workload inferensi AI/ML Anda secara cerdas di beberapa cluster GKE, yang dapat mencakup berbagai region. Penyiapan ini menggunakan Gateway API, Multi Cluster Ingress, dan resource kustom seperti InferencePool dan InferenceObjective untuk meningkatkan skalabilitas, membantu memastikan ketersediaan tinggi, dan mengoptimalkan pemanfaatan resource untuk deployment penayangan model Anda.

Untuk memahami dokumen ini, pahami hal-hal berikut:

Dokumen ini ditujukan untuk persona berikut:

  • Engineer machine learning (ML), Admin dan operator platform, atau Spesialis Data dan AI yang ingin menggunakan kemampuan orkestrasi kontainer GKE untuk melayani beban kerja AI/ML.
  • Arsitek cloud atau spesialis Jaringan yang berinteraksi dengan jaringan GKE.

Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang dirujuk dalam kontenGoogle Cloud , lihat Peran dan tugas pengguna GKE Enterprise umum.

Sebelum memulai

Sebelum memulai, pastikan Anda telah melakukan tugas berikut:

  • Aktifkan Google Kubernetes Engine API.
  • Aktifkan Google Kubernetes Engine API
  • Jika ingin menggunakan Google Cloud CLI untuk tugas ini, instal lalu lakukan inisialisasi gcloud CLI. Jika sebelumnya Anda telah menginstal gcloud CLI, dapatkan versi terbaru dengan menjalankan perintah gcloud components update. gcloud CLI versi sebelumnya mungkin tidak mendukung menjalankan perintah dalam dokumen ini.
  • Aktifkan Compute Engine API, Google Kubernetes Engine API, Model Armor, dan Network Services API.

    Buka Aktifkan akses ke API dan ikuti petunjuknya.

  • Aktifkan Autoscaling API.

    Buka Autoscaling API dan ikuti petunjuknya.

  • Prasyarat Hugging Face:

    • Buat akun Hugging Face jika Anda belum memilikinya.
    • Minta dan dapatkan persetujuan untuk akses ke model Llama 3.1 di Hugging Face.
    • Tandatangani perjanjian izin lisensi di halaman model di Hugging Face.
    • Buat token akses Hugging Face dengan minimal izin Read.

Persyaratan

  • Pastikan project Anda memiliki kuota yang cukup untuk GPU H100. Untuk mengetahui informasi selengkapnya, lihat Merencanakan kuota GPU dan Kuota alokasi.
  • Gunakan GKE versi 1.34.1-gke.1127000 atau yang lebih baru.
  • Gunakan gcloud CLI versi 480.0.0 atau yang lebih baru.
  • Akun layanan node Anda harus memiliki izin untuk menulis metrik ke Autoscaling API.
  • Anda harus memiliki peran IAM berikut di project: roles/container.admin dan roles/iam.serviceAccountAdmin.

Menyiapkan Multi Cluster Inference Gateway

Untuk menyiapkan Inference Gateway multi-cluster GKE, ikuti langkah-langkah berikut:

Membuat cluster dan node pool

Untuk menghosting workload inferensi AI/ML dan mengaktifkan load balancing lintas region, buat dua cluster GKE di region yang berbeda, masing-masing dengan kumpulan node GPU H100.

  1. Buat cluster pertama:

    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
    

    Ganti kode berikut:

    • CLUSTER_1_NAME: nama cluster pertama, misalnya gke-west.
    • LOCATION: region untuk cluster pertama, misalnya europe-west3.
    • PROJECT_ID: project ID Anda.
    • GKE_VERSION: versi GKE yang akan digunakan, misalnya 1.34.1-gke.1127000.
    • MACHINE_TYPE: jenis mesin untuk node cluster, misalnya c2-standard-16.
    • DISK_TYPE: jenis disk untuk node cluster, misalnya pd-standard.
  2. Buat node pool H100 untuk cluster pertama:

    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
    

    Ganti kode berikut:

    • NODE_POOL_NAME: nama node pool, misalnya h100.
    • PROJECT_ID: project ID Anda.
    • CLUSTER_1_ZONE: zona untuk cluster pertama, misalnya europe-west3-c.
    • CLUSTER_1_NAME: nama cluster pertama, misalnya gke-west.
    • NODE_POOL_MACHINE_TYPE: jenis mesin untuk node pool, misalnya a3-highgpu-2g.
    • NUM_NODES: jumlah node dalam node pool, misalnya 3.
  3. Dapatkan kredensial:

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

    Ganti kode berikut:

    • PROJECT_ID: project ID Anda.
    • CLUSTER_1_NAME: nama cluster pertama, misalnya gke-west.
    • CLUSTER_1_ZONE: zona untuk cluster pertama, misalnya europe-west3-c.
  4. Di cluster pertama, buat secret untuk token Hugging Face:

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

    Ganti HF_TOKEN: token akses Hugging Face Anda.

  5. Buat cluster kedua di region yang berbeda dari cluster pertama:

    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.
    

    Ganti kode berikut:

    • LOCATION: region untuk cluster kedua. Region ini harus berbeda dengan cluster pertama. Contoh, us-east4.
    • PROJECT_ID: project ID Anda.
    • GKE_VERSION: versi GKE yang akan digunakan, misalnya 1.34.1-gke.1127000.
    • MACHINE_TYPE: jenis mesin untuk node cluster, misalnya c2-standard-16.
    • DISK_TYPE: jenis disk untuk node cluster, misalnya pd-standard.
  6. Buat node pool H100 untuk cluster kedua:

    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
    

    Ganti kode berikut:

    • PROJECT_ID: project ID Anda.
    • CLUSTER_2_ZONE: zona untuk cluster kedua, misalnya us-east4-a.
    • CLUSTER_2_NAME: nama cluster kedua, misalnya gke-east.
    • NODE_POOL_MACHINE_TYPE: jenis mesin untuk node pool, misalnya a3-highgpu-2g.
    • NUM_NODES: jumlah node dalam node pool, misalnya 3.
  7. Untuk cluster kedua, dapatkan kredensial dan buat secret untuk token 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
    

    Ganti kode berikut:

    • CLUSTER_2_NAME: nama cluster kedua, misalnya gke-east.
    • CLUSTER_2_ZONE: zona untuk cluster kedua, misalnya us-east4-a.
    • PROJECT_ID: project ID Anda.
    • HF_TOKEN: token akses Hugging Face Anda.

Mendaftarkan cluster ke fleet

Untuk mengaktifkan kemampuan multi-cluster, seperti GKE Multi-cluster Inference Gateway, daftarkan cluster Anda ke fleet.

  1. Daftarkan kedua cluster ke fleet project Anda:

    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
    

    Ganti kode berikut:

    • CLUSTER_1_NAME: nama cluster pertama, misalnya gke-west.
    • CLUSTER_1_ZONE: zona untuk cluster pertama, misalnya europe-west3-c.
    • PROJECT_ID: project ID Anda.
    • CLUSTER_2_NAME: nama cluster kedua, misalnya gke-east.
    • CLUSTER_2_ZONE: zona untuk cluster kedua, misalnya us-east4-a.
  2. Untuk mengizinkan satu Gateway mengelola traffic di beberapa cluster, aktifkan fitur Ingress multi-cluster dan tetapkan cluster konfigurasi:

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

    Ganti kode berikut:

    • PROJECT_ID: project ID Anda.
    • CLUSTER_1_NAME: nama cluster pertama, misalnya gke-west.

Buat subnet khusus proxy

Untuk gateway internal, buat subnet khusus proxy di setiap region. Proxy Envoy Gateway internal menggunakan subnet khusus ini untuk menangani traffic dalam jaringan VPC Anda.

  1. Buat subnet di region cluster pertama:

    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. Buat subnet di region cluster kedua:

    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
    

    Ganti kode berikut:

    • PROJECT_ID: project ID Anda.
    • CLUSTER_1_REGION: region untuk cluster pertama, misalnya europe-west3.
    • CLUSTER_2_REGION: region untuk cluster kedua, misalnya us-east4.

Instal CRD yang diperlukan

GKE Multi-cluster Inference Gateway menggunakan resource kustom seperti InferencePool dan InferenceObjective. Pengontrol GKE Gateway API mengelola Definisi Resource Kustom (CRD) InferencePool. Namun, Anda harus menginstal CRD InferenceObjective secara manual, yang masih dalam versi alfa, di cluster Anda.

  1. Tentukan variabel konteks untuk cluster Anda:

    CLUSTER1_CONTEXT="gke_PROJECT_ID_CLUSTER_1_ZONE_CLUSTER_1_NAME"
    CLUSTER2_CONTEXT="gke_PROJECT_ID_CLUSTER_2_ZONE_CLUSTER_2_NAME"
    

    Ganti kode berikut:

    • PROJECT_ID: project ID Anda.
    • CLUSTER_1_ZONE: zona untuk cluster pertama, misalnya europe-west3-c.
    • CLUSTER_1_NAME: nama cluster pertama, misalnya gke-west.
    • CLUSTER_2_ZONE: zona untuk cluster kedua, misalnya us-east4-a.
    • CLUSTER_2_NAME: nama cluster kedua, misalnya gke-east.
  2. Instal CRD InferenceObjective di kedua cluster:

    # 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
    

    Ganti kode berikut:

    • CLUSTER1_CONTEXT: konteks untuk cluster pertama, misalnya gke_my-project_europe-west3-c_gke-west.
    • CLUSTER2_CONTEXT: konteks untuk cluster kedua, misalnya gke_my-project_us-east4-a_gke-east.

Men-deploy resource ke cluster target

Untuk membuat workload inferensi AI/ML Anda tersedia di setiap cluster, deploy resource yang diperlukan, seperti server model dan resource kustom InferenceObjective.

  1. Deploy server model ke kedua cluster:

    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
    

    Ganti kode berikut:

    • CLUSTER1_CONTEXT: konteks untuk cluster pertama, misalnya gke_my-project_europe-west3-c_gke-west.
    • CLUSTER2_CONTEXT: konteks untuk cluster kedua, misalnya gke_my-project_us-east4-a_gke-east.
  2. Deploy resource InferenceObjective ke kedua cluster. Simpan contoh manifes berikut ke file bernama 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. Terapkan manifes ke kedua cluster:

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

    Ganti kode berikut:

    • CLUSTER1_CONTEXT: konteks untuk cluster pertama, misalnya gke_my-project_europe-west3-c_gke-west.
    • CLUSTER2_CONTEXT: konteks untuk cluster kedua, misalnya gke_my-project_us-east4-a_gke-east.
  4. Deploy resource InferencePool ke kedua cluster menggunakan Helm:

    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
    

    Ganti kode berikut:

    • CLUSTER1_CONTEXT: konteks untuk cluster pertama, misalnya gke_my-project_europe-west3-c_gke-west.
    • CLUSTER2_CONTEXT: konteks untuk cluster kedua, misalnya gke_my-project_us-east4-a_gke-east.
  5. Tandai resource InferencePool sebagai diekspor di kedua cluster. Anotasi ini membuat InferencePool tersedia untuk diimpor oleh cluster config, yang merupakan langkah yang diperlukan untuk perutean multi-cluster.

    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
    

    Ganti kode berikut:

    • CLUSTER1_CONTEXT: konteks untuk cluster pertama, misalnya gke_my-project_europe-west3-c_gke-west.
    • CLUSTER2_CONTEXT: konteks untuk cluster kedua, misalnya gke_my-project_us-east4-a_gke-east.

Men-deploy resource ke cluster konfigurasi

Untuk menentukan cara traffic dirutekan dan di-load balance di seluruh resource InferencePool di semua cluster terdaftar, deploy resource Gateway, HTTPRoute, dan HealthCheckPolicy. Anda men-deploy resource ini hanya ke cluster config yang ditetapkan, yaitu gke-west dalam dokumen ini.

  1. Buat file bernama mcig.yaml dengan konten berikut:

    ---
    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. Terapkan manifes:

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

    Ganti CLUSTER1_CONTEXT dengan konteks untuk cluster pertama (cluster konfigurasi), misalnya gke_my-project_europe-west3-c_gke-west.

Mengaktifkan pelaporan metrik kustom

Untuk mengaktifkan pelaporan metrik kustom dan meningkatkan load balancing lintas region, Anda mengekspor metrik penggunaan Cache KV dari semua cluster. Load balancer menggunakan data penggunaan KV Cache yang diekspor ini sebagai sinyal beban kustom. Dengan menggunakan sinyal beban kustom ini, keputusan load balancing yang lebih cerdas dapat dibuat berdasarkan beban kerja aktual setiap cluster.

  1. Buat file bernama metrics.yaml dengan konten berikut:

    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. Terapkan konfigurasi metrik ke kedua cluster:

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

    Ganti kode berikut:

    • CLUSTER1_CONTEXT: konteks untuk cluster pertama, misalnya gke_my-project_europe-west3-c_gke-west.
    • CLUSTER2_CONTEXT: konteks untuk cluster kedua, misalnya gke_my-project_us-east4-a_gke-east.

Mengonfigurasi kebijakan load balancing

Untuk mengoptimalkan cara permintaan inferensi AI/ML didistribusikan di seluruh cluster GKE, konfigurasi kebijakan load balancing. Memilih mode penyeimbangan yang tepat membantu memastikan pemanfaatan resource yang efisien, mencegah kelebihan beban pada setiap cluster, serta meningkatkan performa dan responsivitas keseluruhan layanan inferensi Anda.

Mengonfigurasi waktu tunggu

Jika permintaan Anda diperkirakan memiliki durasi yang lama, konfigurasi waktu tunggu yang lebih lama untuk load balancer. Di GCPBackendPolicy, tetapkan kolom timeoutSec ke setidaknya dua kali latensi permintaan P99 yang diperkirakan.

Misalnya, manifes berikut menetapkan waktu tunggu load balancer menjadi 100 detik.

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

Untuk mengetahui informasi selengkapnya, lihat batasan Gateway multi-cluster.

Karena mode load balancing Metrik kustom dan Permintaan dalam proses bersifat saling eksklusif, konfigurasikan hanya salah satu mode ini di GCPBackendPolicy.

Pilih mode load balancing untuk deployment Anda.

Metrik kustom

Untuk load balancing yang optimal, mulailah dengan pemakaian target sebesar 60%. Untuk mencapai target ini, tetapkan maxUtilization: 60 di konfigurasi customMetrics GCPBackendPolicy Anda.

  1. Buat file bernama backend-policy.yaml dengan konten berikut untuk mengaktifkan load balancing berdasarkan metrik kustom 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. Terapkan kebijakan baru:

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

    Ganti CLUSTER1_CONTEXT dengan konteks untuk cluster pertama, misalnya gke_my-project-europe-west3-c-gke-west.

Permintaan dalam proses

Untuk menggunakan mode penyeimbangan dalam proses, perkirakan jumlah permintaan dalam proses yang dapat ditangani setiap backend dan konfigurasikan nilai kapasitas secara eksplisit.

  1. Buat file bernama backend-policy.yaml dengan konten berikut untuk mengaktifkan load balancing berdasarkan jumlah permintaan dalam proses:

    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. Terapkan kebijakan baru:

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

    Ganti CLUSTER1_CONTEXT dengan konteks untuk cluster pertama, misalnya gke_my-project_europe-west3-c_gke-west.

Memverifikasi deployment

Untuk memverifikasi load balancer internal, Anda harus mengirim permintaan dari dalam jaringan VPC karena load balancer internal menggunakan alamat IP pribadi. Jalankan Pod sementara di dalam salah satu cluster untuk mengirim permintaan dari jaringan VPC Anda dan verifikasi load balancer internal:

  1. Mulai sesi shell interaktif di Pod sementara:

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

    Ganti CLUSTER1_CONTEXT dengan konteks untuk cluster pertama, misalnya gke_my-project_europe-west3-c_gke-west.

  2. Dari shell baru, dapatkan alamat IP Gateway dan kirim permintaan pengujian:

    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
    }'
    

    Berikut adalah contoh respons yang berhasil:

    {
      "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
      }
    }
    

Langkah berikutnya