Personalizar 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 gestionar la infraestructura de GKE y a administradores de plataformas que gestionan cargas de trabajo de IA.

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

Conocer y configurar las siguientes funciones avanzadas:

Configurar comprobaciones de seguridad de la IA

GKE Inference Gateway se integra con Model Armor para realizar comprobaciones de seguridad en las peticiones y respuestas de las aplicaciones que usan modelos de lenguaje extensos (LLMs). Esta integración proporciona una capa adicional de seguridad a nivel de infraestructura que complementa las medidas de seguridad a nivel de aplicación. De esta forma, se puede aplicar una política centralizada a todo el tráfico de LLMs.

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

Google Cloud Integración de Model Armor en un clúster de GKE
Ilustración: Integración de Model Armor en un clúster de GKE

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

  1. Requisitos previos

    1. Habilita el servicio Model Armor en tu Google Cloud proyecto.

    2. Crea las plantillas de Model Armor con la consola de Model Armor, Google Cloud CLI o la API. El siguiente comando crea una plantilla llamada llm que registra operaciones y filtra 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. Conceder permisos de gestión de identidades y accesos

    La cuenta de servicio de extensiones de servicio requiere permisos para acceder a los recursos necesarios. Ejecuta los siguientes comandos para conceder 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.gserviceaccount.com \
    --role=roles/container.admin

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

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

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

  3. Configurar el GCPTrafficExtension

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

    1. Guarda el siguiente archivo de manifiesto de ejemplo 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}"}]'

      Haz los cambios siguientes:

      • GATEWAY_NAME: el nombre de la pasarela.
      • MODEL_ARMOR_TEMPLATE_NAME: el nombre de tu plantilla de Model Armor.

      El archivo gcp-traffic-extension.yaml incluye los siguientes ajustes:

      • targetRefs: especifica la pasarela 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 van a aplicar.
      • 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 de la extensión.
      • metadata: especifica los metadatos de la extensión, incluidos los ajustes de extensionPolicy y de saneamiento de la petición o la respuesta.

    2. Aplica el manifiesto de ejemplo 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 -

Una vez que hayas configurado las comprobaciones de seguridad de la IA y las hayas integrado con tu pasarela, Model Armor filtrará automáticamente las peticiones y las respuestas en función de las reglas definidas.

Configurar Apigee para la autenticación y la gestión de APIs

GKE Inference Gateway se integra con Apigee para proporcionar autenticación, autorización y gestión de APIs a tus cargas de trabajo de inferencia. Para obtener más información sobre las ventajas de usar Apigee, consulta Ventajas principales de usar Apigee.

Puedes integrar GKE Inference Gateway con Apigee para mejorar tu GKE Inference Gateway con funciones como seguridad de APIs, limitación de frecuencia, cuotas, analíticas y monetización.

Requisitos previos

Antes de empezar, asegúrate de que tienes 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 desplegado.
  • Una instancia de Apigee creada en la misma región que tu clúster de GKE.
  • El operador de gestión de APIs de Apigee y sus CRDs instalados en tu clúster de GKE. Para obtener instrucciones, consulta Instalar el operador de gestión de APIs de Apigee.
  • kubectl configurado para conectarse a tu clúster de GKE.
  • Google Cloud CLI instalado y autenticado.

Crear un ApigeeBackendService

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

  1. Guarda el siguiente archivo de 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"

    Haz los cambios siguientes:

    • APIGEE_ENVIRONMENT_NAME: nombre de tu entorno de Apigee. Nota: No es necesario que defina este campo si apigee-apim-operator se instala con la marca generateEnv=TRUE. Si no es así, crea un entorno de Apigee siguiendo las instrucciones de Crear un entorno.
    • LOCATION: la ubicación de tu instancia de Apigee.
    • CLUSTER_NETWORK: la red de tu clúster de GKE.
    • CLUSTER_SUBNETWORK: la subred de tu clúster de GKE.

  2. Aplica el manifiesto a tu clúster:

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

  3. Comprueba que el estado sea CREATED:

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

Configurar GKE Inference Gateway

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

  1. Guarda el siguiente archivo de 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

    Sustituye GATEWAY_NAME por el nombre de tu pasarela.

  2. Aplica el manifiesto a tu clúster:

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

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

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

Enviar solicitudes autenticadas mediante claves de API

  1. Para encontrar la dirección IP de tu pasarela de inferencia de GKE, inspecciona el estado de la pasarela:

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

    Sustituye GATEWAY_NAME por el nombre de tu pasarela.

  2. Prueba una solicitud sin autenticación. Esta solicitud debe rechazarse:

    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á 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 interfaz de usuario de Apigee y crea una clave de API. Para obtener instrucciones, consulta el artículo Crear 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
}'

    Sustituye API_KEY por tu clave de API.

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

Configurar la observabilidad

GKE Inference Gateway proporciona información valiosa sobre el estado, el rendimiento y el comportamiento de tus cargas de trabajo de inferencia. De esta forma, puede identificar y resolver problemas, optimizar el uso de los recursos y asegurar la fiabilidad de sus aplicaciones.

Google Cloud proporciona los siguientes paneles de Cloud Monitoring, que ofrecen observabilidad de inferencia para GKE Inference Gateway:

  • Panel de control de GKE Inference Gateway: proporciona métricas de oro para el servicio de LLMs, como el rendimiento de las solicitudes y los tokens, la latencia, los errores y la utilización de la caché de InferencePool. Para ver la lista completa de métricas de GKE Inference Gateway disponibles, consulte Métricas expuestas.
  • Panel de control del servidor de modelos: proporciona un panel de control con las señales de oro del servidor de modelos. Esto le permite monitorizar la carga y el rendimiento de los servidores de modelos, como KVCache Utilization y Queue length.
  • Panel de control del balanceador de carga: muestra métricas del balanceador de carga, como las solicitudes por segundo, la latencia de servicio de las solicitudes de extremo a extremo y los códigos de estado de las solicitudes y respuestas. Estas métricas le ayudan a comprender el rendimiento del servicio de solicitudes de extremo a extremo e identificar errores.
  • Métricas de Data Center GPU Manager (DCGM): proporciona métricas de las GPUs de NVIDIA, como el rendimiento y la utilización de las GPUs de NVIDIA. Puede configurar las métricas de NVIDIA Data Center GPU Manager (DCGM) en Cloud Monitoring. Para obtener más información, consulta Recoger y ver métricas de DCGM.

Ver el panel de GKE Inference Gateway

Para ver el panel de control de GKE Inference Gateway, sigue estos pasos:

  1. En la Google Cloud consola, ve a la página Monitorización.

    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 control de Cloud Monitoring, busca "Gateway".

  5. Consulta el panel de control de GKE Inference Gateway.

También puedes seguir las instrucciones que se indican en el artículo Panel de control de monitorización.

Configurar el panel de control de observabilidad del servidor de modelos

Para recoger señales de oro de cada servidor de modelos y saber qué contribuye al rendimiento de GKE Inference Gateway, puedes configurar la monitorización automática de tus servidores de modelos. Esto incluye servidores de modelos como los siguientes:

Para ver los paneles de control de integración, primero debe asegurarse de que está recogiendo métricas de su servidor de modelos. A continuación, sigue estos pasos:

  1. En la Google Cloud consola, ve a la página Monitorización.

    Ir a Monitoring

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

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

    Vista de los paneles de control de integración
    Imagen: Paneles de control de integraciones

Para obtener más información, consulta Personalizar la monitorización de aplicaciones.

Configurar las alertas de Cloud Monitoring

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

  1. Guarda el siguiente archivo de manifiesto de ejemplo 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 alpha monitoring policies migrate --policies-from-prometheus-alert-rules-yaml=alerts.yaml

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

Modificar alertas

Puedes consultar la lista completa de las métricas más recientes disponibles en el repositorio de GitHub kubernetes-sigs/gateway-api-inference-extension y añadir nuevas alertas al manifiesto usando otras métricas.

Para modificar las alertas de muestra, consulta 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 las solicitudes durante 5 minutos supera los 10 segundos. Puedes modificar la sección expr de la alerta para ajustar el umbral según tus requisitos.

Configurar el registro de GKE Inference Gateway

Configurar el registro de Inference Gateway de GKE proporciona información detallada sobre las solicitudes y las respuestas, lo que resulta útil para solucionar problemas, auditar y analizar el rendimiento. Los registros de acceso HTTP registran todas las solicitudes y respuestas, 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 archivo de manifiesto de ejemplo 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

    Haz los cambios siguientes:

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

  2. Aplica el manifiesto de ejemplo 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

Puede usar métricas basadas en registros para analizar los registros de balanceo de carga y extraer detalles de los errores. Cada clase de Gateway de GKE, como las clases gke-l7-global-external-managed y gke-l7-regional-internal-managed de Gateway, se basa en un balanceador de carga diferente. Para obtener más información, consulta las funciones de GatewayClass.

Cada balanceador de carga tiene un recurso monitorizado diferente que debe usar al crear una métrica basada en registros. Para obtener más información sobre el recurso monitorizado de cada balanceador de carga, consulte lo siguiente:

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

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

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

    Sustituye MONITORED_RESOURCE por el recurso monitorizado de tu balanceador de carga.

  2. Abre Cloud Shell o tu terminal local donde esté instalada la CLI de gcloud.

  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

Una vez creada la métrica, puedes usarla en Cloud Monitoring para ver la distribución de los errores que ha notificado el balanceador de carga. Para obtener más información, consulta Crear 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 Crear una política de alertas en una métrica de contador.

.

Configurar autoescalado

El autoescalado ajusta la asignación de recursos en respuesta a las variaciones de carga, lo que mantiene el rendimiento y la eficiencia de los recursos añadiendo o eliminando pods de forma dinámica en función de la demanda. En el caso de GKE Inference Gateway, esto implica el autoescalado horizontal de los pods de cada InferencePool. La herramienta de autoescalado horizontal de pods (HPA) de GKE autoescala los pods en función de las métricas del servidor de modelos, como KVCache Utilization. De esta forma, el servicio de inferencia puede gestionar diferentes cargas de trabajo y volúmenes de consultas, al tiempo que gestiona de forma eficiente el uso de los recursos.

Para configurar instancias InferencePool de forma que se escalen automáticamente en función de las métricas producidas por GKE Inference Gateway, sigue estos pasos:

  1. Despliega un objeto PodMonitoring en el clúster para recoger las métricas generadas por GKE Inference Gateway. Para obtener más información, consulta Configurar la observabilidad.

  2. Implementa el adaptador de Stackdriver de métricas personalizadas para que HPA pueda acceder a las métricas:

    1. Guarda el siguiente archivo de manifiesto de ejemplo 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
  namespace: custom-metrics
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:
  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 ejemplo a tu clúster:

      kubectl apply -f adapter_new_resource_model.yaml

  3. Para dar permisos al adaptador para leer 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.svc.id.goog/subject/ns/custom-metrics/sa/custom-metrics-stackdriver-adapter

    Sustituye PROJECT_ID por el ID de tu proyecto. Google Cloud

  4. Por 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

    Haz los cambios siguientes:

    • INFERENCE_POOL_NAME: el nombre del InferencePool.
    • INFERENCE_POOL_NAMESPACE: el espacio de nombres de InferencePool.
    • CLUSTER_NAME: el nombre del clúster.
    • MIN_REPLICAS: la disponibilidad mínima del InferencePool (capacidad de referencia). HPA mantiene este número de réplicas cuando el uso está por debajo del umbral objetivo de HPA. Las cargas de trabajo de alta disponibilidad deben asignar a este campo un valor superior a 1 para asegurar que la disponibilidad se mantenga durante las interrupciones de los pods.
    • MAX_REPLICAS: el valor que limita el número de aceleradores que se deben asignar a las cargas de trabajo alojadas en InferencePool. HPA no aumentará el número de réplicas más allá de este valor. Durante las horas de mayor tráfico, monitoriza el número de réplicas para asegurarte de que el valor del campo MAX_REPLICAS proporciona suficiente margen para que la carga de trabajo pueda aumentar y mantener las características de rendimiento elegidas.
    • TARGET_VALUE: el valor que representa el objetivo elegido KV-Cache Utilization por servidor de modelo. 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 mediante pruebas de carga y trazando un gráfico de rendimiento frente a latencia. Selecciona una combinación de latencia y rendimiento del gráfico y usa el valor KV-Cache Utilization correspondiente como destino del HPA. Debes ajustar y monitorizar este valor con atención para conseguir los resultados de rendimiento y precio que hayas elegido. Puedes usar GKE Inference Quickstart para determinar este valor automáticamente.

Siguientes pasos