Personaliza la configuración de GKE Inference Gateway

En esta página, se describe cómo personalizar la implementación de GKE Inference Gateway.

Esta página está dirigida a especialistas en redes que se encargan de administrar la infraestructura de GKE y a administradores de plataformas que administran cargas de trabajo de IA.

Para administrar y optimizar las cargas de trabajo de inferencia, configura las funciones avanzadas de GKE Inference Gateway.

Comprende y configura las siguientes funciones avanzadas:

Configura las verificaciones de seguridad de la IA

GKE Inference Gateway se integra en Model Armor para realizar verificaciones de seguridad en las instrucciones y respuestas de las aplicaciones que usan modelos de lenguaje grandes (LLM). Esta integración proporciona una capa adicional de aplicación de medidas de seguridad a nivel de la infraestructura que complementa las medidas de seguridad a nivel de la aplicación. Esto permite la aplicación centralizada de políticas en todo el tráfico de LLM. También puedes usar NVIDIA NeMo Guardrails para realizar verificaciones de seguridad.

En el siguiente diagrama, se ilustra la integración de Model Armor con GKE Inference Gateway en un clúster de GKE:

Integración de Model Armor deCloud de Confiance by S3NS en un clúster de GKE
Figura: Integración de Model Armor en un clúster de GKE

Para configurar las verificaciones de seguridad de la IA, sigue estos pasos:

  1. Requisitos previos

    1. Habilita el servicio de Model Armor en tu proyecto de Cloud de Confiance by S3NS .

    2. Crea las plantillas de Model Armor con la consola de Model Armor, Google Cloud CLI o la API. Con el siguiente comando, se crea una plantilla llamada llm que registra las operaciones y filtra el contenido dañino.

      # Set environment variables
PROJECT_ID=$(gcloud config get-value project)
# Replace <var>CLUSTER_LOCATION<var> with the location of your GKE cluster. For example, `us-central1`.
LOCATION="CLUSTER_LOCATION"
MODEL_ARMOR_TEMPLATE_NAME=llm

# Set the regional API endpoint
gcloud config set api_endpoint_overrides/modelarmor \
  "https://modelarmor.$LOCATION.rep.googleapis.com/"

# Create the template
gcloud model-armor templates create $MODEL_ARMOR_TEMPLATE_NAME \
  --location $LOCATION \
  --pi-and-jailbreak-filter-settings-enforcement=enabled \
  --pi-and-jailbreak-filter-settings-confidence-level=MEDIUM_AND_ABOVE \
  --rai-settings-filters='[{ "filterType": "HATE_SPEECH", "confidenceLevel": "MEDIUM_AND_ABOVE" },{ "filterType": "DANGEROUS", "confidenceLevel": "MEDIUM_AND_ABOVE" },{ "filterType": "HARASSMENT", "confidenceLevel": "MEDIUM_AND_ABOVE" },{ "filterType": "SEXUALLY_EXPLICIT", "confidenceLevel": "MEDIUM_AND_ABOVE" }]' \
  --template-metadata-log-sanitize-operations \
  --template-metadata-log-operations

  2. Otorga permisos de IAM

    La cuenta de servicio de Service Extensions requiere permisos para acceder a los recursos necesarios. Ejecuta los siguientes comandos para otorgar los roles necesarios:

    PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format 'get(projectNumber)')

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member=serviceAccount:service-$PROJECT_NUMBER@gcp-sa-dep.iam.s3ns-system.iam.gserviceaccount.com \
    --role=roles/container.admin

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member=serviceAccount:service-$PROJECT_NUMBER@gcp-sa-dep.iam.s3ns-system.iam.gserviceaccount.com \
    --role=roles/modelarmor.calloutUser

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member=serviceAccount:service-$PROJECT_NUMBER@gcp-sa-dep.iam.s3ns-system.iam.gserviceaccount.com \
    --role=roles/serviceusage.serviceUsageConsumer

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member=serviceAccount:service-$PROJECT_NUMBER@gcp-sa-dep.iam.s3ns-system.iam.gserviceaccount.com \
    --role=roles/modelarmor.user

  3. Configura el GCPTrafficExtension

    Para aplicar las políticas de Model Armor a tu puerta de enlace, crea un recurso GCPTrafficExtension con el formato de metadatos correcto.

    1. Guarda el siguiente manifiesto de muestra como gcp-traffic-extension.yaml:

      kind: GCPTrafficExtension
apiVersion: networking.gke.io/v1
metadata:
name: my-model-armor-extension
spec:
targetRefs:
- group: "gateway.networking.k8s.io"
  kind: Gateway
  name: GATEWAY_NAME
extensionChains:
- name: my-model-armor-chain1
  matchCondition:
    celExpressions:
      - celMatcher: request.path.startsWith("/")
  extensions:
  - name: my-model-armor-service
    supportedEvents:
    - RequestHeaders
    - RequestBody
    - RequestTrailers
    - ResponseHeaders
    - ResponseBody
    - ResponseTrailers
    timeout: 1s
    failOpen: false
    googleAPIServiceName: "modelarmor.${LOCATION}.rep.googleapis.com"
    metadata:
      model_armor_settings: '[{"model": "${MODEL}","model_response_template_id": "projects/${PROJECT_ID}/locations/${LOCATION}/templates/${MODEL_ARMOR_TEMPLATE_NAME}","user_prompt_template_id": "projects/${PROJECT_ID}/locations/${LOCATION}/templates/${MODEL_ARMOR_TEMPLATE_NAME}"}]'

      Reemplaza lo siguiente:

      • GATEWAY_NAME: Es el nombre de la puerta de enlace.
      • MODEL_ARMOR_TEMPLATE_NAME: Es el nombre de tu plantilla de Model Armor.

      El archivo gcp-traffic-extension.yaml incluye los siguientes parámetros de configuración:

      • targetRefs: Especifica la puerta de enlace a la que se aplica esta extensión.
      • extensionChains: Define una cadena de extensiones que se aplicará al tráfico.
      • matchCondition: Define las condiciones en las que se aplican las extensiones.
      • extensions: Define las extensiones que se aplicarán.
      • supportedEvents: Especifica los eventos durante los cuales se invoca la extensión.
      • timeout: Especifica el tiempo de espera de la extensión.
      • googleAPIServiceName: Especifica el nombre del servicio para la extensión.
      • metadata: especifica los metadatos de la extensión, incluidos los parámetros de configuración de limpieza de extensionPolicy y de instrucciones o respuestas.

    2. Aplica el manifiesto de muestra a tu clúster:

      export GATEWAY_NAME="your-gateway-name"
export MODEL="google/gemma-3-1b-it" # Or your specific model
envsubst < gcp-traffic-extension.yaml | kubectl apply -f -

Después de configurar las verificaciones de seguridad de la IA y de integrarlas en tu puerta de enlace, Model Armor filtra automáticamente las instrucciones y las respuestas según las reglas definidas.

Configura Apigee para la autenticación y la gestión de API

GKE Inference Gateway se integra en Apigee para proporcionar autenticación, autorización y gestión de API para tus cargas de trabajo de inferencia. Para obtener más información sobre los beneficios de usar Apigee, consulta Beneficios clave de usar Apigee.

Puedes integrar GKE Inference Gateway con Apigee para mejorar tu GKE Inference Gateway con funciones como seguridad de APIs, límite de frecuencia, cuotas, estadísticas y monetización.

Requisitos previos

Antes de comenzar, asegúrate de tener lo siguiente:

  • Un clúster de GKE que ejecute la versión 1.34.* o una posterior.
  • Un clúster de GKE con GKE Inference Gateway implementado
  • Una instancia de Apigee creada en la misma región que tu clúster de GKE.
  • El operador de APIM de Apigee y sus CRD instalados en tu clúster de GKE. Para obtener instrucciones, consulta Instala el operador de APIM de Apigee.
  • kubectl configurado para conectarse a tu clúster de GKE.
  • Google Cloud CLI instalado y autenticado.

Crea un ApigeeBackendService

Primero, crea un recurso ApigeeBackendService. GKE Inference Gateway usa esto para crear un procesador de extensiones de Apigee.

  1. Guarda el siguiente manifiesto como my-apigee-backend-service.yaml:

    apiVersion: apim.googleapis.com/v1
kind: ApigeeBackendService
metadata:
  name: my-apigee-backend-service
spec:
  apigeeEnv: "APIGEE_ENVIRONMENT_NAME"  # optional field
  defaultSecurityEnabled: true # optional field
  locations:
    name: "LOCATION"
    network: "CLUSTER_NETWORK"
    subnetwork: "CLUSTER_SUBNETWORK"

    Reemplaza lo siguiente:

    • APIGEE_ENVIRONMENT_NAME: Es el nombre de tu entorno de Apigee. Nota: No es necesario que configures este campo si el apigee-apim-operator se instala con la marca generateEnv=TRUE. De lo contrario, crea un entorno de Apigee siguiendo las instrucciones que se indican en Crea un entorno.
    • LOCATION: Es la ubicación de tu instancia de Apigee.
    • CLUSTER_NETWORK: Es la red de tu clúster de GKE.
    • CLUSTER_SUBNETWORK: Es la subred de tu clúster de GKE.

  2. Aplica el manifiesto al clúster:

    kubectl apply -f my-apigee-backend-service.yaml

  3. Verifica que el estado haya cambiado a CREATED:

    kubectl wait --for=jsonpath='{.status.currentState}'="CREATED" -f my-apigee-backend-service.yaml --timeout=5m

Configura GKE Inference Gateway

Configura GKE Inference Gateway para habilitar el procesador de extensiones de Apigee como una extensión de tráfico del balanceador de cargas.

  1. Guarda el siguiente manifiesto como my-apigee-traffic-extension.yaml:

    kind: GCPTrafficExtension
apiVersion: networking.gke.io/v1
metadata:
  name: my-apigee-traffic-extension
spec:
  targetRefs:
  - group: "gateway.networking.k8s.io"
    kind: Gateway
    name: GATEWAY_NAME
  extensionChains:
  - name: my-traffic-extension-chain
    matchCondition:
      celExpressions:
        - celMatcher: request.path.startsWith("/")
    extensions:
    - name: my-apigee-extension
      metadata:
        # The value for `apigee-extension-processor` must match the name of the `ApigeeBackendService` resource that was applied earlier.
        apigee-extension-processor: my-apigee-backend-service
      failOpen: false
      timeout: 1s
      supportedEvents:
      - RequestHeaders
      - ResponseHeaders
      - ResponseBody
      backendRef:
        group: apim.googleapis.com
        kind: ApigeeBackendService
        name: my-apigee-backend-service
        port: 443

    Reemplaza GATEWAY_NAME por el nombre de tu puerta de enlace.

  2. Aplica el manifiesto al clúster:

    kubectl apply -f my-apigee-traffic-extension.yaml

  3. Espera a que el estado de GCPTrafficExtension cambie a Programmed:

    kubectl wait --for=jsonpath='{.status.ancestors[0].conditions[?(@.type=="Programmed")].status}'=True -f my-apigee-traffic-extension.yaml --timeout=5m

Envía solicitudes autenticadas con claves de API

  1. Para encontrar la dirección IP de tu GKE Inference Gateway, inspecciona el estado de la puerta de enlace:

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

    Reemplaza GATEWAY_NAME por el nombre de tu puerta de enlace.

  2. Prueba una solicitud sin autenticación. Esta solicitud se debe rechazar por los siguientes motivos:

    curl -i ${GW_IP}/v1/completions -H 'Content-Type: application/json' -d '{
"model": "food-review",
"prompt": "Write as if you were a critic: San Francisco",
"max_tokens": 100,
"temperature": 0
}'

    Verás una respuesta similar a la siguiente, que indica que la extensión de Apigee funciona:

    {"fault":{"faultstring":"Raising fault. Fault name : RF-insufficient-request-raise-fault","detail":{"errorcode":"steps.raisefault.RaiseFault"}}}

  3. Accede a la IU de Apigee y crea una clave de API. Para obtener instrucciones, consulta Crea una clave de API.

  4. Envía la clave de API en el encabezado de la solicitud HTTP:

    curl -i ${GW_IP}/v1/completions -H 'Content-Type: application/json' -H 'x-api-key: API_KEY' -d '{
"model": "food-review",
"prompt": "Write as if you were a critic: San Francisco",
"max_tokens": 100,
"temperature": 0
}'

    Reemplaza API_KEY por tu clave de API.

Para obtener información más detallada sobre cómo configurar las políticas de Apigee, consulta Usa políticas de gestión de API con el operador de APIM de Apigee para Kubernetes.

Configura la observabilidad

GKE Inference Gateway proporciona estadísticas sobre el estado, el rendimiento y el comportamiento de tus cargas de trabajo de inferencia. Esto te ayuda a identificar y resolver problemas, optimizar el uso de recursos y garantizar la confiabilidad de tus aplicaciones.

Cloud de Confiance by S3NS proporciona los siguientes paneles de Cloud Monitoring que ofrecen observabilidad de inferencia para GKE Inference Gateway:

  • Panel de GKE Inference Gateway: proporciona métricas de oro para la entrega de LLM, como la capacidad de procesamiento de solicitudes y tokens, la latencia, los errores y el uso de la caché para el InferencePool. Para ver la lista completa de las métricas disponibles de GKE Inference Gateway, consulta Métricas expuestas.
  • Paneles de observabilidad de IA/AA: Proporciona paneles para el uso de la infraestructura, las métricas de DCGM y las métricas de rendimiento del modelo de vLLM.
  • Panel del servidor de modelos: Proporciona un panel para los indicadores clave del servidor de modelos. Esto te permite supervisar la carga y el rendimiento de los servidores de modelos, como KVCache Utilization y Queue length.
  • Panel del balanceador de cargas: Informa las métricas del balanceador de cargas, como las solicitudes por segundo, la latencia de entrega de solicitudes de extremo a extremo y los códigos de estado de solicitud y respuesta. Estas métricas te ayudan a comprender el rendimiento de la entrega de solicitudes de extremo a extremo y a identificar errores.
  • Métricas del administrador de GPU del centro de datos (DCGM): Proporciona métricas de DCGM, como el rendimiento y el uso de las GPU de NVIDIA. Puedes configurar las métricas de DCGM en Cloud Monitoring. Para obtener más información, consulta Recopila y visualiza métricas de DCGM.

Visualiza el panel de GKE Inference Gateway

Para ver el panel unificado llm-d Overview de GKE Inference Gateway, sigue estos pasos:

  1. En la consola de Cloud de Confiance , dirígete a la página Monitoring.

    Ir a Monitoring

  2. En el panel de navegación, selecciona Paneles.

  3. En la sección Integraciones, selecciona GMP.

  4. En la página Plantillas de panel de Cloud Monitoring, busca "llm-d".

  5. Selecciona el panel llm-d Overview, que supervisa el balanceador de cargas de aplicaciones, las redes de GPU, el EPP de llm-d (llm_d_epp_*) y las métricas de vLLM en el modo independiente y el modo de puerta de enlace.

  6. Haz clic en Agregar panel a tu lista y completa los campos obligatorios. Luego, haz clic en Agregar a la lista de paneles.

Visualiza los paneles de observabilidad de los modelos de IA/AA

Para ver los modelos y los paneles implementados de las métricas de observabilidad de un modelo, sigue estos pasos:

  1. En la consola de Cloud de Confiance , ve a la página Modelos implementados.

    Ir a Modelos implementados

  2. Para ver detalles sobre una implementación específica, incluidas sus métricas, registros y paneles, haz clic en el nombre del modelo en la lista.

  3. En la página de detalles del modelo, haz clic en la pestaña Observabilidad para ver los siguientes paneles. Si se te solicita, haz clic en Habilitar para habilitar el panel.

    • En el panel Uso de infraestructura, se muestran las métricas de uso.
    • En el panel de DCGM, se muestran las métricas de DCGM.
    • Si usas vLLM, el panel Rendimiento del modelo está disponible y muestra las métricas del rendimiento del modelo de vLLM.

Configura el panel de observabilidad del servidor de modelos

Para recopilar indicadores de oro de cada servidor de modelos y comprender qué contribuye al rendimiento de GKE Inference Gateway, puedes configurar la supervisión automática para tus servidores de modelos. Esto incluye servidores de modelos como los siguientes:

Para ver los paneles de integración, primero asegúrate de recopilar métricas de tu servidor de modelos. Luego, realiza los pasos a continuación:

  1. En la consola de Cloud de Confiance , dirígete a la página Monitoring.

    Ir a Monitoring

  2. En el panel de navegación, selecciona Paneles.

  3. En Integraciones, selecciona GMP. Se muestran los paneles de integración correspondientes.

    Una vista de los paneles de integración
    Figura: Paneles de integración

Para obtener más información, consulta Personaliza la supervisión de las aplicaciones.

Configura las alertas de Cloud Monitoring

Para configurar alertas de Cloud Monitoring para GKE Inference Gateway, sigue estos pasos:

  1. Guarda el siguiente manifiesto de muestra como alerts.yaml y modifica los umbrales según sea necesario:

    groups:
- name: gateway-api-inference-extension
  rules:
  - alert: HighInferenceRequestLatencyP99
    annotations:
      title: 'High latency (P99) for model {{ $labels.model_name }}'
      description: 'The 99th percentile request duration for model {{ $labels.model_name }} and target model {{ $labels.target_model_name }} has been consistently above 10.0 seconds for 5 minutes.'
    expr: histogram_quantile(0.99, rate(inference_model_request_duration_seconds_bucket[5m])) > 10.0
    for: 5m
    labels:
      severity: 'warning'
  - alert: HighInferenceErrorRate
    annotations:
      title: 'High error rate for model {{ $labels.model_name }}'
      description: 'The error rate for model {{ $labels.model_name }} and target model {{ $labels.target_model_name }} has been consistently above 5% for 5 minutes.'
    expr: sum by (model_name) (rate(inference_model_request_error_total[5m])) / sum by (model_name) (rate(inference_model_request_total[5m])) > 0.05
    for: 5m
    labels:
      severity: 'critical'
      impact: 'availability'
  - alert: HighInferencePoolAvgQueueSize
    annotations:
      title: 'High average queue size for inference pool {{ $labels.name }}'
      description: 'The average number of requests pending in the queue for inference pool {{ $labels.name }} has been consistently above 50 for 5 minutes.'
    expr: inference_pool_average_queue_size > 50
    for: 5m
    labels:
      severity: 'critical'
      impact: 'performance'
  - alert: HighInferencePoolAvgKVCacheUtilization
    annotations:
      title: 'High KV cache utilization for inference pool {{ $labels.name }}'
      description: 'The average KV cache utilization for inference pool {{ $labels.name }} has been consistently above 90% for 5 minutes, indicating potential resource exhaustion.'
    expr: inference_pool_average_kv_cache_utilization > 0.9
    for: 5m
    labels:
      severity: 'critical'
      impact: 'resource_exhaustion'

  2. Para crear políticas de alertas, ejecuta el siguiente comando:

    gcloud monitoring policies migrate --policies-from-prometheus-alert-rules-yaml=alerts.yaml

    Verás las políticas de alertas nuevas en la página Alertas.

Modifica las alertas

Puedes encontrar la lista completa de las métricas más recientes disponibles en el repositorio de GitHub kubernetes-sigs/gateway-api-inference-extension y puedes agregar alertas nuevas al manifiesto con otras métricas.

Para modificar las alertas de muestra, considera el siguiente ejemplo:

  - alert: HighInferenceRequestLatencyP99
    annotations:
      title: 'High latency (P99) for model {{ $labels.model_name }}'
      description: 'The 99th percentile request duration for model {{ $labels.model_name }} and target model {{ $labels.target_model_name }} has been consistently above 10.0 seconds for 5 minutes.'
    expr: histogram_quantile(0.99, rate(inference_model_request_duration_seconds_bucket[5m])) > 10.0
    for: 5m
    labels:
      severity: 'warning'

Esta alerta se activa si el percentil 99 de la duración de la solicitud durante 5 minutos supera los 10 segundos. Puedes modificar la sección expr de la alerta para ajustar el umbral según tus requisitos.

Configura el registro para GKE Inference Gateway

Configurar el registro para GKE Inference Gateway proporciona información detallada sobre las solicitudes y respuestas, lo que es útil para solucionar problemas, auditar y analizar el rendimiento. Los registros de acceso HTTP registran cada solicitud y respuesta, incluidos los encabezados, los códigos de estado y las marcas de tiempo. Este nivel de detalle puede ayudarte a identificar problemas, encontrar errores y comprender el comportamiento de tus cargas de trabajo de inferencia.

Para configurar el registro de GKE Inference Gateway, habilita el registro de acceso HTTP para cada uno de tus objetos InferencePool.

  1. Guarda el siguiente manifiesto de muestra como logging-backend-policy.yaml:

    apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: logging-backend-policy
  namespace: NAMESPACE_NAME
spec:
  default:
    logging:
      enabled: true
      sampleRate: 500000
  targetRef:
    group: inference.networking.x-k8s.io
    kind: InferencePool
    name: INFERENCE_POOL_NAME

    Reemplaza lo siguiente:

    • NAMESPACE_NAME: Es el nombre del espacio de nombres en el que se implementa tu InferencePool.
    • INFERENCE_POOL_NAME: el nombre de InferencePool.

  2. Aplica el manifiesto de muestra a tu clúster:

    kubectl apply -f logging-backend-policy.yaml

Después de aplicar este manifiesto, GKE Inference Gateway habilita los registros de acceso HTTP para el InferencePool especificado. Puedes ver estos registros en Cloud Logging. Los registros incluyen información detallada sobre cada solicitud y respuesta, como la URL de la solicitud, los encabezados, el código de estado de la respuesta y la latencia.

Crear métricas basadas en registros para ver los detalles de los errores

Puedes usar métricas basadas en registros para analizar tus registros de balanceo de cargas y extraer detalles de errores. Cada clase de GKE Gateway, como las clases de Gateway gke-l7-global-external-managed y gke-l7-regional-internal-managed, está respaldada por un balanceador de cargas diferente. Para obtener más información, consulta Funciones de GatewayClass.

Cada balanceador de cargas tiene un recurso supervisado diferente que debes usar cuando creas una métrica basada en registros. Para obtener más información sobre el recurso supervisado de cada balanceador de cargas, consulta los siguientes vínculos:

Para crear una métrica basada en registros y ver los detalles de los errores, haz lo siguiente:

  1. Crea un archivo JSON llamado error_detail_metric.json con la siguiente definición de LogMetric. Esta configuración crea una métrica que extrae el campo proxyStatus de los registros del balanceador de cargas.

    {
  "description": "Metric to extract error details from load balancer logs.",
  "filter": "resource.type=\"MONITORED_RESOURCE\"",
  "metricDescriptor": {
    "metricKind": "DELTA",
    "valueType": "INT64",
    "labels": [
      {
        "key": "error_detail",
        "valueType": "STRING",
        "description": "The detailed error string from the load balancer."
      }
    ]
  },
  "labelExtractors": {
    "error_detail": "EXTRACT(jsonPayload.proxyStatus)"
  }
}

    Reemplaza MONITORED_RESOURCE por el recurso supervisado de tu balanceador de cargas.

  2. Abre Cloud Shell o la terminal local en la que está instalada la gcloud CLI.

  3. Para crear la métrica, ejecuta el comando gcloud logging metrics create con la marca --config-from-file:

    gcloud logging metrics create error_detail_metric \
    --config-from-file=error_detail_metric.json

Después de crear la métrica, puedes usarla en Cloud Monitoring para ver la distribución de los errores que informa el balanceador de cargas. Para obtener más información, consulta Crea una métrica basada en registros.

Para obtener más información sobre cómo crear alertas a partir de métricas basadas en registros, consulta Crea una política de alertas en una métrica de contador.

Configurar ajuste de escala automático

El ajuste de escala automático ajusta la asignación de recursos en respuesta a las variaciones de carga, lo que mantiene el rendimiento y la eficiencia de los recursos agregando o quitando Pods de forma dinámica según la demanda. Para GKE Inference Gateway, esto implica el ajuste de escala automático horizontal de los Pods en cada InferencePool. El Horizontal Pod Autoscaler (HPA) de GKE escala automáticamente los Pods según las métricas del servidor de modelos, como KVCache Utilization. Este enfoque ayuda a garantizar que el servicio de inferencia controle diferentes cargas de trabajo y volúmenes de consultas, a la vez que administra de forma eficiente el uso de recursos.

Para configurar las instancias de InferencePool de modo que se ajusten automáticamente en función de las métricas que produce GKE Inference Gateway, sigue estos pasos:

  1. Implementa un objeto PodMonitoring en el clúster para recopilar las métricas que produce GKE Inference Gateway. Para obtener más información, consulta Configura la observabilidad.

  2. Implementa el adaptador de Stackdriver para métricas personalizadas para otorgar acceso al HPA a las métricas:

    1. Guarda el siguiente manifiesto de muestra como adapter_new_resource_model.yaml:

      apiVersion: v1
kind: Namespace
metadata:
  name: custom-metrics
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: custom-metrics-stackdriver-adapter
  namespace: custom-metrics
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: custom-metrics:system:auth-delegator
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:auth-delegator
subjects:
- kind: ServiceAccount
  name: custom-metrics-stackdriver-adapter
  namespace: custom-metrics
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: custom-metrics-auth-reader
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: extension-apiserver-authentication-reader
subjects:
- kind: ServiceAccount
  name: custom-metrics-stackdriver-adapter
  namespace: custom-metrics
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: custom-metrics-resource-reader
rules:
- apiGroups:
  - ""
  resources:
  - pods
  - nodes
  - nodes/stats
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: custom-metrics-resource-reader
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: custom-metrics-resource-reader
subjects:
- kind: ServiceAccount
  name: custom-metrics-stackdriver-adapter
  namespace: custom-metrics
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: custom-metrics-stackdriver-adapter
  labels:
    run: custom-metrics-stackdriver-adapter
    k8s-app: custom-metrics-stackdriver-adapter
spec:
  replicas: 1
  selector:
    matchLabels:
      run: custom-metrics-stackdriver-adapter
      k8s-app: custom-metrics-stackdriver-adapter
  template:
    metadata:
      labels:
        run: custom-metrics-stackdriver-adapter
        k8s-app: custom-metrics-stackdriver-adapter
        kubernetes.io/cluster-service: "true"
    spec:
      serviceAccountName: custom-metrics-stackdriver-adapter
      containers:
      - image: gcr.io/gke-release/custom-metrics-stackdriver-adapter:v0.15.2-gke.1
        imagePullPolicy: Always
        name: pod-custom-metrics-stackdriver-adapter
        command:
        - /adapter
        - --use-new-resource-model=true
        - --fallback-for-container-metrics=true
        resources:
          limits:
            cpu: 250m
            memory: 200Mi
          requests:
            cpu: 250m
            memory: 200Mi
---
apiVersion: v1
kind: Service
metadata:
  labels:
    run: custom-metrics-stackdriver-adapter
    k8s-app: custom-metrics-stackdriver-adapter
    kubernetes.io/cluster-service: 'true'
    kubernetes.io/name: Adapter
  name: custom-metrics-stackdriver-adapter
  namespace: custom-metrics
spec:
  ports:
  - port: 443
    protocol: TCP
    targetPort: 443
  selector:
    run: custom-metrics-stackdriver-adapter
    k8s-app: custom-metrics-stackdriver-adapter
  type: ClusterIP
---
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  name: v1beta1.custom.metrics.k8s.io
spec:
  insecureSkipTLSVerify: true
  group: custom.metrics.k8s.io
  groupPriorityMinimum: 100
  versionPriority: 100
  service:
    name: custom-metrics-stackdriver-adapter
    namespace: custom-metrics
  version: v1beta1
---
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  name: v1beta2.custom.metrics.k8s.io
spec:
  insecureSkipTLSVerify: true
  group: custom.metrics.k8s.io
  groupPriorityMinimum: 100
  versionPriority: 200
  service:
    name: custom-metrics-stackdriver-adapter
    namespace: custom-metrics
  version: v1beta2
---
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  name: v1beta1.external.metrics.k8s.io
spec:
  insecureSkipTLSVerify: true
  group: external.metrics.k8s.io
  groupPriorityMinimum: 100
  versionPriority: 100
  service:
    name: custom-metrics-stackdriver-adapter
    namespace: custom-metrics
  version: v1beta1
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: external-metrics-reader
rules:
- apiGroups:
  - "external.metrics.k8s.io"
  resources:
  - "*"
  verbs:
  - list
  - get
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: external-metrics-reader
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: external-metrics-reader
subjects:
- kind: ServiceAccount
  name: horizontal-pod-autoscaler
  namespace: kube-system

    2. Aplica el manifiesto de muestra a tu clúster:

      kubectl apply -f adapter_new_resource_model.yaml

  3. Para otorgar permisos al adaptador para que lea las métricas del proyecto, ejecuta el siguiente comando:

    $ PROJECT_ID=PROJECT_ID
$ 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-adapter

    Reemplaza PROJECT_ID por el ID del proyecto de Cloud de Confiance .

  4. Para cada InferencePool, implementa un HPA similar al siguiente:

    apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: INFERENCE_POOL_NAME
  namespace: INFERENCE_POOL_NAMESPACE
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: INFERENCE_POOL_NAME
  minReplicas: MIN_REPLICAS
  maxReplicas: MAX_REPLICAS
  metrics:
  - type: External
    external:
      metric:
        name: prometheus.googleapis.com|inference_pool_average_kv_cache_utilization|gauge
        selector:
          matchLabels:
            metric.labels.name: INFERENCE_POOL_NAME
            resource.labels.cluster: CLUSTER_NAME
            resource.labels.namespace: INFERENCE_POOL_NAMESPACE
      target:
        type: AverageValue
        averageValue: TARGET_VALUE

    Reemplaza lo siguiente:

    • INFERENCE_POOL_NAME: el nombre de InferencePool.
    • INFERENCE_POOL_NAMESPACE: Es el espacio de nombres de InferencePool.
    • CLUSTER_NAME: el nombre del clúster
    • MIN_REPLICAS: Es la disponibilidad mínima de la InferencePool (capacidad de referencia). El HPA mantiene esta cantidad de réplicas activas cuando el uso está por debajo del umbral objetivo del HPA. Las cargas de trabajo con alta disponibilidad deben establecer este valor en un valor superior a 1 para garantizar la disponibilidad continua durante las interrupciones de los Pods.
    • MAX_REPLICAS: Es el valor que restringe la cantidad de aceleradores que se deben asignar a las cargas de trabajo alojadas en el InferencePool. El HPA no aumentará la cantidad de réplicas más allá de este valor. Durante los momentos de mayor tráfico, supervisa la cantidad de réplicas para asegurarte de que el valor del campo MAX_REPLICAS proporcione suficiente margen para que la carga de trabajo pueda aumentar verticalmente y mantener las características de rendimiento de la carga de trabajo elegidas.
    • TARGET_VALUE: Es el valor que representa el KV-Cache Utilization objetivo elegido por servidor de modelos. Este es un número entre 0 y 100, y depende en gran medida del servidor del modelo, el modelo, el acelerador y las características del tráfico entrante. Puedes determinar este valor objetivo de forma experimental a través de pruebas de carga y trazando un gráfico de capacidad de procesamiento en comparación con la latencia. Selecciona una combinación de capacidad de procesamiento y latencia elegida del gráfico y usa el valor KV-Cache Utilization correspondiente como el objetivo del HPA. Debes ajustar y supervisar este valor de cerca para lograr los resultados de precio-rendimiento elegidos. Puedes usar la guía de inicio rápido de inferencia de GKE para determinar este valor automáticamente.

¿Qué sigue?