이 문서에서는 Google Kubernetes Engine (GKE) 멀티 클러스터 추론 게이트웨이와 GKE 자동 확장 기능을 사용하여 AI 추론 워크로드의 탄력적인 교차 리전 고가용성을 구성하는 방법을 보여줍니다. 이 설정을 사용하면 서로 다른 리전의 여러 GKE 클러스터에서 워크로드를 지능적으로 부하 분산할 수 있습니다.
GKE 멀티 클러스터 추론 게이트웨이에 대한 자세한 내용은 GKE 멀티 클러스터 추론 게이트웨이 정보를 참고하세요.
시작하기 전에
Google Kubernetes Engine API를 사용 설정합니다.
이 작업에 Google Cloud CLI를 사용하려면 Google Cloud CLI를 설치하고 초기화합니다.
프로젝트에 H100 GPU 할당량이 충분한지 확인합니다. 자세한 내용은 GPU 할당량 및 리소스 할당을 참고하세요.
GKE 버전 1.34.1-gke.1127000 이상을 사용합니다.
gcloud CLI 버전 480.0.0 이상을 사용합니다.
노드에서 사용하는 서비스 계정에
roles/monitoring.metricWriter및roles/stackdriver.resourceMetadata.writer권한이 있는지 확인합니다.프로젝트에
roles/container.admin및roles/iam.serviceAccountAdminIdentity and Access Management (IAM) 역할이 있는지 확인합니다.다음 Hugging Face 기본 요건을 완료합니다.
- Hugging Face 계정을 만듭니다.
- Hugging Face에서 Llama 3.1 모델에 대한 액세스를 요청하고 승인을 받습니다.
- Hugging Face의 모델 페이지에서 라이선스 동의 계약에 서명합니다.
- 최소한 읽기 권한이 있는 Hugging Face 액세스 토큰을 생성합니다.
클러스터 및 노드 풀 만들기
서로 다른 리전에 GKE 클러스터 두 개를 만들고 노드 풀을 구성하려면 다음 단계를 따르세요.
첫 번째 클러스터를 만듭니다.
gcloud container clusters create gke-west --zone \ CLUSTER_1_ZONE \ --project=PROJECT_ID \ --gateway-api=standard \ --cluster-version=GKE_VERSION \ --machine-type="MACHINE_TYPE" \ --disk-type="DISK_TYPE" \ --enable-managed-prometheus --monitoring=SYSTEM,DCGM \ --hpa-profile=performance \ --workload-pool=PROJECT_ID.s3ns.svc.id.goog \ --async다음을 바꿉니다.
PROJECT_ID: 프로젝트 ID입니다.CLUSTER_1_ZONE: 첫 번째 클러스터의 영역(예:europe-west3-c)GKE_VERSION: 사용할 GKE 버전입니다(예:1.34.1-gke.1127000).MACHINE_TYPE: 클러스터 노드의 머신 유형(예:c2-standard-16)DISK_TYPE: 클러스터 노드의 디스크 유형입니다(예:pd-standard).
첫 번째 클러스터에서 H100 노드 풀을 만듭니다.
gcloud container node-pools create h100 \ --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 \ --min-nodes=MIN_NUM_NODES \ --max-nodes=MAX_NUM_NODES \ --enable-autoscaling \ --async다음을 바꿉니다.
PROJECT_ID: 프로젝트 ID입니다.CLUSTER_1_ZONE: 첫 번째 클러스터의 영역(예:europe-west3-c)CLUSTER_1_NAME: 첫 번째 클러스터의 이름입니다(예:gke-west).NODE_POOL_MACHINE_TYPE: 노드 풀의 머신 유형(예:a3-highgpu-2g)NUM_NODES: 노드 풀의 노드 수(예:3)MIN_NUM_NODES: 노드 풀의 자동 확장 최소 노드 수입니다(예:1).MAX_NUM_NODES: 노드 풀의 자동 확장 최대 노드 수입니다(예:10).
사용자 인증 정보를 가져오고 첫 번째 클러스터에서 Hugging Face 토큰 보안 비밀을 만듭니다.
gcloud container clusters get-credentials CLUSTER_1_NAME \ --location CLUSTER_1_ZONE \ --project=PROJECT_ID kubectl create secret generic hf-token \ --from-literal=token=HF_TOKEN다음을 바꿉니다.
PROJECT_ID: 프로젝트 ID입니다.CLUSTER_1_NAME: 첫 번째 클러스터의 이름입니다(예:gke-west).CLUSTER_1_ZONE: 첫 번째 클러스터의 영역(예:europe-west3-c)HF_TOKEN: Hugging Face 액세스 토큰
첫 번째 클러스터와 다른 리전에 두 번째 클러스터를 만듭니다.
gcloud container clusters create gke-east --zone CLUSTER_2_ZONE \ --project=PROJECT_ID \ --gateway-api=standard \ --cluster-version=GKE_VERSION \ --machine-type="MACHINE_TYPE" \ --disk-type="DISK_TYPE" \ --enable-managed-prometheus \ --monitoring=SYSTEM,DCGM \ --hpa-profile=performance \ --workload-pool=PROJECT_ID.s3ns.svc.id.goog \ --asyncCLUSTER_2_ZONE을 두 번째 클러스터의 영역으로 바꿉니다(예:us-east4-a).두 번째 클러스터의 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 \ --min-nodes=MIN_NUM_NODES \ --max-nodes=MAX_NUM_NODES \ --enable-autoscaling \ --async다음을 바꿉니다.
PROJECT_ID: 프로젝트 ID입니다.CLUSTER_2_ZONE: 두 번째 클러스터의 영역(예:us-east4-a)CLUSTER_2_NAME: 두 번째 클러스터의 이름입니다(예:gke-east).NODE_POOL_MACHINE_TYPE: 노드 풀의 머신 유형(예:a3-highgpu-2g)NUM_NODES: 노드 풀의 노드 수(예:3)MIN_NUM_NODES: 노드 풀의 자동 확장 최소 노드 수입니다(예:1).MAX_NUM_NODES: 노드 풀의 자동 확장 최대 노드 수입니다(예:10).
두 번째 클러스터에서 사용자 인증 정보를 가져오고 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다음을 바꿉니다. 다른 변수의 정의는 이전 단계를 참고하세요.
HF_TOKEN: Hugging Face 액세스 토큰
Fleet에 클러스터 등록
클러스터를 프로젝트의 Fleet에 등록합니다.
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_2_NAME: 두 번째 클러스터의 이름입니다(예:gke-east).
멀티 클러스터 인그레스 기능을 사용 설정하고 구성 클러스터를 지정합니다.
gcloud container fleet ingress enable \ --config-membership=projects/PROJECT_ID/locations/global/memberships/CLUSTER_1_NAME다음을 바꿉니다. 다른 변수의 정의는 이전 단계를 참고하세요.
PROJECT_ID: 프로젝트 ID입니다.CLUSTER_1_NAME: 첫 번째 클러스터의 이름입니다(예:gke-west).
프록시 전용 서브넷 만들기
경고: Cloud de Confiance by S3NS 를 사용하면 각 VPC 네트워크에 리전당 하나의 프록시 전용 서브넷만 있을 수 있습니다. 타겟 리전에 이미 purpose=REGIONAL_MANAGED_PROXY 설정이 있는 프록시 전용 서브넷이 포함되어 있으면 GLOBAL_MANAGED_PROXY 서브넷을 만들 수 없습니다. 먼저 기존 리전 프록시 전용 서브넷을 삭제해야 합니다. 리전 프록시 전용 서브넷을 삭제하면 해당 서브넷을 사용하는 리전 Envoy 기반 부하 분산기에 영향을 미치므로 이에 따라 변경사항을 계획하세요.
첫 번째 클러스터의 리전에 서브넷을 만듭니다.
gcloud compute networks subnets create CLUSTER_1_REGION-subnet \ --purpose=GLOBAL_MANAGED_PROXY \ --role=ACTIVE \ --region=CLUSTER_1_REGION \ --network=default \ --range=SUBNET_RANGE_1 \ --project=PROJECT_ID다음을 바꿉니다.
PROJECT_ID: 프로젝트 ID입니다.CLUSTER_1_REGION: 첫 번째 클러스터의 리전(예:europe-west3)SUBNET_RANGE_1: 첫 번째 클러스터 리전의 프록시 전용 서브넷의 서브넷 IP 범위입니다(예:10.0.0.0/23).
두 번째 클러스터의 리전에 서브넷을 만듭니다.
gcloud compute networks subnets create CLUSTER_2_REGION-subnet \ --purpose=GLOBAL_MANAGED_PROXY \ --role=ACTIVE \ --region=CLUSTER_2_REGION \ --network=default \ --range=SUBNET_RANGE_2 \ --project=PROJECT_ID다음을 바꿉니다.
PROJECT_ID: 프로젝트 ID입니다.CLUSTER_2_REGION: 두 번째 클러스터의 리전(예:us-east4)SUBNET_RANGE_2: 두 번째 클러스터 리전의 프록시 전용 서브넷의 서브넷 IP 범위(예:10.5.0.0/23)
필수 맞춤 리소스 설치
클러스터의 컨텍스트 변수를 정의합니다.
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: 두 번째 클러스터의 영역(예:us-east4-a)CLUSTER_2_NAME: 두 번째 클러스터의 이름입니다(예:gke-east).
두 클러스터 모두에 InferencePool 및 InferenceObjective 커스텀 리소스를 설치합니다.
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v1.0.1/manifests.yaml --context=$CLUSTER1_CONTEXT kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v1.0.1/manifests.yaml --context=$CLUSTER2_CONTEXT
대상 클러스터에 리소스 배포
두 클러스터에 모델 서버를 배포합니다.
kubectl apply -f \ https://raw.githubusercontent.com/kubernetes-sigs/gateway-api-inference-extension/release-1.0/config/manifests/vllm/gpu-deployment.yaml \ --context=$CLUSTER1_CONTEXT kubectl apply -f \ https://raw.githubusercontent.com/kubernetes-sigs/gateway-api-inference-extension/release-1.0/config/manifests/vllm/gpu-deployment.yaml \ --context=$CLUSTER2_CONTEXT다음 매니페스트를
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"두 클러스터에 모두 매니페스트를 적용합니다.
kubectl apply -f inference-objective.yaml --context=$CLUSTER1_CONTEXT kubectl apply -f inference-objective.yaml --context=$CLUSTER2_CONTEXTHelm을 사용하여 두 클러스터에 InferencePool 리소스를 배포합니다.
helm install vllm-llama3-8b-instruct \ --kube-context $CLUSTER1_CONTEXT \ --set inferencePool.modelServers.matchLabels.app=vllm-llama3-8b-instruct \ --set provider.name=gke \ --set inferenceExtension.monitoring.gke.enabled=true \ --version v1.0.1 \ 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.0.1 \ oci://registry.k8s.io/gateway-api-inference-extension/charts/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
리전 간 추론 게이트웨이 배포
다음 매니페스트를
mygateway.yaml로 저장합니다.--- kind: Gateway apiVersion: gateway.networking.k8s.io/v1beta1 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 allowedRoutes: kinds: - kind: HTTPRoute namespaces: from: All --- apiVersion: gateway.networking.k8s.io/v1beta1 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 --- kind: HealthCheckPolicy apiVersion: networking.gke.io/v1 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매니페스트를 구성 클러스터에 적용합니다.
kubectl apply -f mygateway.yaml --context=CLUSTER1_CONTEXT다음을 바꿉니다.
CLUSTER1_CONTEXT: 첫 번째 클러스터의 컨텍스트입니다(예:gke_my-project_europe-west3-c_gke-west).
맞춤 측정항목 보고 사용 설정
다음 콘텐츠로
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 exportName: kv-cache - name: vllm:gpu_cache_usage_perc exportName: kv-cache-old각 클러스터에 측정항목 구성을 적용합니다.
kubectl apply -f metrics.yaml --context=CLUSTER1_CONTEXT kubectl apply -f metrics.yaml --context=CLUSTER2_CONTEXTCLUSTER1_CONTEXT및CLUSTER2_CONTEXT정의는 필수 맞춤 리소스 설치를 참고하세요.
부하 분산 정책 구성
이 섹션에서는 부하 분산 정책을 구성하는 방법을 설명합니다. 이 정책은 맞춤 측정항목과 지역 설정을 기반으로 추론 풀에 트래픽이 분산되는 방식을 정의합니다. 다음 구성은 us-east4를 기본 리전으로 설정합니다. us-east4 리전의 gke.named_metrics.kv-cache 맞춤 측정항목이 사용률 80% 에 도달한 경우에만 트래픽이 다른 리전으로 유출됩니다.
- vLLM 버전 v0.10.2 이상에서는
gke.named_metrics.kv-cache측정항목을 사용합니다. - 이전 버전에서는
gke.named_metrics.kv-cache-old측정항목을 사용합니다.
다음 콘텐츠로
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: timeoutSec: 600 balancingMode: CUSTOM_METRICS trafficDuration: LONG customMetrics: - name: gke.named_metrics.kv-cache maxUtilizationPercent: 80 dryRun: false scopes: - selector: gke.io/region: "us-east4" backendPreference: PREFERRED새 정책을 적용합니다.
kubectl apply -f backend-policy.yaml --context=CLUSTER1_CONTEXTCLUSTER1_CONTEXT을 첫 번째 클러스터의 컨텍스트로 바꿉니다(예:gke_my-project_europe-west3-c_gke-west).
자동 확장 구성
트래픽이 다른 리전으로 유출되기 전에 각 클러스터가 증가하는 부하를 처리할 수 있도록 모델 서버 배포에 수평형 포드 자동 확장 처리 (HPA)를 구성해야 합니다.
주요 구성 원칙
동일한 맞춤 측정항목 사용: HPA는 다중 클러스터 추론 게이트웨이의
GCPBackendPolicy에서 사용하는 것과 동일한 맞춤 측정항목 (예:vllm:kv_cache_usage_perc)을 기반으로 확장되도록 구성해야 합니다. 이 접근 방식을 사용하면 부하 분산과 확장 결정이 모두 추론 서버의 동일한 신호에 의해 이루어집니다. 선택한 측정항목의 값은 사용률을 나타내기 위해 0과 1 사이여야 합니다. 측정항목 값이 1보다 크면 로드 밸런서의 사용률이 100% 로 해석되어 예기치 않은 라우팅 동작이 발생할 수 있습니다.HPA 타겟 낮게 설정: HPA 구성의 측정항목 타겟 값은
GCPBackendPolicy에 정의된maxUtilizationPercent설정보다 낮게 설정해야 합니다. HPA의 목표 사용률을 낮게 설정하면 (예: 평균 사용률이 50% 일 때 HPA가 확장됨) 부하 분산기의 임계값 (예: 사용률 80%)에 도달하기 전에 클러스터에서 복제본을 더 추가할 수 있습니다. 이 접근 방식은 선호하는 리전 내에서 용량을 최대화하는 데 도움이 됩니다. 또한 낮은 사용률 타겟은 현재 리전이 한계에 도달할 때 탄력적인 교차 리전 고가용성을 예약하여 조기 트래픽 오버플로를 방지하는 데 도움이 됩니다.
사용자에게 필수 승인 역할을 만들 수 있는 권한을 부여합니다.
kubectl create clusterrolebinding cluster-admin-binding \ --clusterrole cluster-admin --user "$(gcloud config get-value account)" --context=CLUSTER1_CONTEXT kubectl create clusterrolebinding cluster-admin-binding \ --clusterrole cluster-admin --user "$(gcloud config get-value account)" --context=CLUSTER2_CONTEXTCLUSTER1_CONTEXT및CLUSTER2_CONTEXT변수는 필수 맞춤 리소스 설치 섹션에 정의되어 있습니다.각 클러스터에 매니페스트를 적용합니다.
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter_new_resource_model.yaml --context=CLUSTER1_CONTEXT kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter_new_resource_model.yaml --context=CLUSTER2_CONTEXTcustom-metrics-stackdriver-adapter서비스 계정이 Cloud Monitoring 측정항목을 읽도록 허용합니다.PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format="value(projectNumber)") gcloud projects add-iam-policy-binding projects/PROJECT_ID \ --role roles/monitoring.viewer \ --member=principal://iam.googleapis.com/projects/$PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.s3ns.svc.id.goog/subject/ns/custom-metrics/sa/custom-metrics-stackdriver-adapterPROJECT_ID를 프로젝트 ID로 바꿉니다.다음 매니페스트를
pod-monitoring.yaml이라는 파일에 저장합니다.apiVersion: monitoring.googleapis.com/v1 kind: PodMonitoring metadata: name: inference-server-podmon spec: selector: matchLabels: app: vllm-llama3-8b-instruct endpoints: - port: 8000 path: /metrics interval: 5s두 클러스터에 모두 매니페스트를 적용합니다.
kubectl apply -f pod-monitoring.yaml --context=CLUSTER1_CONTEXT kubectl apply -f pod-monitoring.yaml --context=CLUSTER2_CONTEXT다음 매니페스트를
hpa.yaml이라는 파일에 저장합니다.apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: inference-server-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: vllm-llama3-8b-instruct minReplicas: 1 maxReplicas: 10 metrics: - type: Pods pods: metric: name: prometheus.googleapis.com|vllm:gpu_cache_usage_perc|gauge target: type: AverageValue averageValue: "0.5"두 클러스터에 모두 매니페스트를 적용합니다.
kubectl apply -f hpa.yaml --context=CLUSTER1_CONTEXT kubectl apply -f hpa.yaml --context=CLUSTER2_CONTEXT
배포를 확인합니다.
게이트웨이 IP 주소를 가져옵니다.
export GW_IP=$(kubectl get gateway/cross-region-gateway -n default --context=CLUSTER1_CONTEXT -o jsonpath='{.status.addresses[0].value}') echo ${GW_IP}CLUSTER1_CONTEXT변수는 필수 맞춤 리소스 설치 섹션에 정의되어 있습니다.임시 포드에서 대화형
sh세션을 시작합니다.kubectl run -it --rm --image=curlimages/curl curly --context=CLUSTER1_CONTEXT -- /bin/shCLUSTER1_CONTEXT변수는 필수 맞춤 리소스 설치 섹션에 정의되어 있습니다.curly포드 내부에서 테스트 요청을 보냅니다.curl -i -X POST <var>GW_IP</var>: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 }'GW_IP를 이전 단계의 게이트웨이 IP 주소로 바꿉니다.
게이트웨이 부하 테스트
동일한 VPC 네트워크 내에서 부하 생성기를 사용하여 게이트웨이 IP 주소에 지속적인 부하를 적용합니다.
기본 리전 (
us-east4)에서 처리할 수 있을 것으로 예상되는 적당한 부하로 시작합니다.부하 테스트의 요청 속도 또는 동시성을 점진적으로 늘립니다.
부하 테스트가 실행되는 동안 Cloud de Confiance 콘솔에서 또는
kubectl를 사용하여 시스템을 모니터링합니다.- 포드 확장 (HPA): 두 클러스터의
vllm-llama3-8b-instruct배포에 있는 포드 수를 확인합니다. - 노드 확장 (클러스터 자동 확장 처리): 두 클러스터의
h100노드 풀에 있는 노드 수를 모니터링합니다. - 맞춤 측정항목: 두 클러스터의 모델 서버 배포에 대해 Monitoring에서
vllm:kv_cache_usage_perc측정항목 (vllm 버전 v0.10.2 이상) 또는vllm:gpu_cache_usage_perc측정항목 (vllm 버전 v.0.10.2 미만)을 확인합니다. - 부하 분산기 측정항목: Monitoring에서
cross-region-gateway와 연결된 부하 분산기의 측정항목을 검사합니다.
- 포드 확장 (HPA): 두 클러스터의
부하를 늘리면 us-east4의 사용률이 증가합니다. gke-east 클러스터의 HPA가 스케일 아웃되고 평균 사용률이 GCPBackendPolicy에 정의된 maxUtilization 값 (80%)에 접근하면 부하 분산기가 europe-west3의 gke-west 클러스터로 요청을 라우팅하기 시작합니다.
다음 단계
- GKE Gateway API에 대해 자세히 알아보세요.
- GKE 멀티 클러스터 추론 게이트웨이에 대해 자세히 알아보세요.
- 멀티 클러스터 인그레스에 대해 자세히 알아보세요.