Personalizar a configuração do GKE Inference Gateway

Nesta página, descrevemos como personalizar a implantação do GKE Inference Gateway.

Esta página é destinada a especialistas Rede responsáveis por gerenciar a infraestrutura do GKE e a administradores de plataforma que gerenciam cargas de trabalho de IA.

Para gerenciar e otimizar cargas de trabalho de inferência, configure recursos avançados do gateway de inferência do GKE.

Entenda e configure os seguintes recursos avançados:

Configurar verificações de segurança e proteção de IA

O gateway de inferência do GKE se integra ao Model Armor para realizar verificações de segurança em comandos e respostas de aplicativos que usam modelos de linguagem grandes (LLMs). Essa integração oferece uma camada extra de aplicação de segurança no nível da infraestrutura que complementa as medidas de segurança no nível do aplicativo. Isso permite a aplicação centralizada de políticas em todo o tráfego de LLM.

O diagrama a seguir ilustra a integração do Model Armor com o gateway de inferência do GKE em um cluster do GKE:

Google Cloud Integração do Model Armor em um cluster do GKE
Figura: integração do Model Armor em um cluster do GKE

Para configurar as verificações de segurança de IA, siga estas etapas:

  1. Pré-requisitos

    1. Ative o serviço Model Armor no seu projeto do Google Cloud .

    2. Crie os modelos do Model Armor usando o console do Model Armor, a CLI do Google Cloud ou a API. O comando a seguir cria um modelo chamado llm que registra operações e filtra conteúdo prejudicial.

      # 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 permissões do IAM

    A conta de serviço das extensões de serviço precisa de permissões para acessar os recursos necessários. Conceda os papéis necessários executando os seguintes comandos:

    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 o GCPTrafficExtension

    Para aplicar as políticas do Model Armor ao seu gateway, crie um recurso GCPTrafficExtension com o formato de metadados correto.

    1. Salve o seguinte manifesto de amostra 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}"}]'

      Substitua:

      • GATEWAY_NAME: o nome do gateway.
      • MODEL_ARMOR_TEMPLATE_NAME: o nome do seu modelo do Model Armor.

      O arquivo gcp-traffic-extension.yaml inclui as seguintes configurações:

      • targetRefs: especifica o gateway a que essa extensão se aplica.
      • extensionChains: define uma cadeia de extensões a serem aplicadas ao tráfego.
      • matchCondition: define as condições em que as extensões são aplicadas.
      • extensions: define as extensões a serem aplicadas.
      • supportedEvents: especifica os eventos durante os quais a extensão é invocada.
      • timeout: especifica o tempo limite da extensão.
      • googleAPIServiceName: especifica o nome do serviço para a extensão.
      • metadata: especifica os metadados da extensão, incluindo o extensionPolicy e as configurações de limpeza de comandos ou respostas.

    2. Aplique o manifesto de amostra ao cluster:

      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 -

Depois de configurar as verificações de segurança de IA e integrá-las ao seu gateway, o Model Armor filtra automaticamente comandos e respostas com base nas regras definidas.

Configurar o Apigee para autenticação e gerenciamento de APIs

O gateway de inferência do GKE se integra ao Apigee para fornecer autenticação, autorização e gerenciamento de API para suas cargas de trabalho de inferência. Para saber mais sobre os benefícios de usar a Apigee, consulte Principais benefícios de usar a Apigee.

É possível integrar o gateway de inferência do GKE ao Apigee para melhorar o gateway de inferência do GKE com recursos como segurança de API, limitação de taxa, cotas, análises e monetização.

Pré-requisitos

Antes de começar, verifique se você tem o seguinte:

  • Um cluster do GKE executando a versão 1.34.* ou mais recente.
  • Um cluster do GKE com o GKE Inference Gateway implantado.
  • Uma instância do Apigee criada na mesma região do cluster do GKE.
  • O operador da API Management da Apigee e os CRDs instalados no cluster do GKE. Para instruções, consulte Instalar o operador do APIM do Apigee.
  • kubectl configurado para se conectar ao cluster do GKE.
  • Google Cloud CLI instalado e autenticado.

Crie um ApigeeBackendService

Primeiro, crie um recurso ApigeeBackendService. O gateway de inferência do GKE usa isso para criar um processador de extensão do Apigee.

  1. Salve o seguinte manifesto 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"

    Substitua:

    • APIGEE_ENVIRONMENT_NAME: o nome do seu ambiente da Apigee. Observação: não é necessário definir esse campo se o apigee-apim-operator for instalado com a sinalização generateEnv=TRUE. Caso contrário, crie um ambiente da Apigee seguindo as instruções em Criar um ambiente.
    • LOCATION: o local da sua instância da Apigee.
    • CLUSTER_NETWORK: a rede do cluster do GKE.
    • CLUSTER_SUBNETWORK: a sub-rede do cluster do GKE.

  2. Aplique o manifesto ao cluster:

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

  3. Verifique se o status mudou para CREATED:

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

Configurar o gateway de inferência do GKE

Configure o gateway de inferência do GKE para ativar o processador de extensão do Apigee como uma extensão de tráfego do balanceador de carga.

  1. Salve o seguinte manifesto 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

    Substitua GATEWAY_NAME pelo nome do seu gateway.

  2. Aplique o manifesto ao cluster:

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

  3. Aguarde até que o status GCPTrafficExtension se torne Programmed:

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

Enviar solicitações autenticadas usando chaves de API

  1. Para encontrar o endereço IP do gateway de inferência do GKE, inspecione o status do gateway:

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

    Substitua GATEWAY_NAME pelo nome do seu gateway.

  2. Teste uma solicitação sem autenticação. Esta solicitação deve ser rejeitada:

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

    Você vai receber uma resposta semelhante a esta, indicando que a extensão do Apigee está funcionando:

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

  3. Acesse a interface da Apigee e crie uma chave de API. Para instruções, consulte Criar uma chave de API.

  4. Envie a chave de API no cabeçalho da solicitação 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
}'

    Substitua API_KEY pela sua chave de API.

Para mais informações sobre como configurar políticas da Apigee, consulte Usar políticas de gerenciamento de API com o operador APIM da Apigee para Kubernetes.

Configurar observabilidade

O gateway de inferência do GKE fornece insights sobre a integridade, o desempenho e o comportamento das suas cargas de trabalho de inferência. Isso ajuda a identificar e resolver problemas, otimizar a utilização de recursos e garantir a confiabilidade dos aplicativos.

Google Cloud fornece os seguintes painéis do Cloud Monitoring que oferecem observabilidade de inferência para o gateway de inferência do GKE:

  • Painel do gateway de inferência do GKE: fornece métricas de ouro para veiculação de LLM, como capacidade de processamento de solicitações e tokens, latência, erros e utilização do cache para o InferencePool. Para conferir a lista completa de métricas disponíveis do GKE Inference Gateway, consulte Métricas expostas.
  • Painel do servidor de modelo: fornece um painel para os sinais dourados do servidor de modelo. Isso permite monitorar a carga e o desempenho dos servidores de modelos, como KVCache Utilization e Queue length.
  • Painel do balanceador de carga: informa métricas do balanceador de carga, como solicitações por segundo, latência de atendimento de solicitações de ponta a ponta e códigos de status de solicitação-resposta. Essas métricas ajudam você a entender o desempenho do serviço de solicitações de ponta a ponta e identificar erros.
  • Métricas do Data Center GPU Manager (DCGM): fornecem métricas de GPUs NVIDIA, como o desempenho e a utilização delas. É possível configurar métricas do NVIDIA Data Center GPU Manager (DCGM) no Cloud Monitoring. Para mais informações, consulte Coletar e conferir métricas do DCGM.

Acessar o painel do GKE Inference Gateway

Para acessar o painel do GKE Inference Gateway, siga estas etapas:

  1. No console Google Cloud , acesse a página Recomendações.

    Acessar Monitoring

  2. No painel de navegação, selecione Painéis.

  3. Na seção Integrações, selecione GMP.

  4. Na página Modelos de painel do Cloud Monitoring, pesquise "Gateway".

  5. Acesse o painel do GKE Inference Gateway.

Como alternativa, siga as instruções em Painel do Monitoring.

Configurar o painel de observabilidade do servidor de modelo

Para coletar indicadores de ouro de cada servidor de modelo e entender o que contribui para o desempenho do GKE Inference Gateway, configure o monitoramento automático dos servidores de modelo. Isso inclui servidores de modelo como os seguintes:

Para acessar os painéis de integração, primeiro verifique se você está coletando métricas do servidor de modelo. Em seguida, realize as seguintes etapas:

  1. No console Google Cloud , acesse a página Recomendações.

    Acessar Monitoring

  2. No painel de navegação, selecione Painéis.

  3. Em Integrações, selecione GMP. Os painéis de integração correspondentes são exibidos.

    Uma visualização dos painéis de integração
    Figura: painéis de integração

Para mais informações, consulte Personalizar o monitoramento de aplicativos.

Configurar os alertas do Cloud Monitoring

Para configurar alertas do Cloud Monitoring para o GKE Inference Gateway, siga estas etapas:

  1. Salve o seguinte manifesto de amostra como alerts.yaml e modifique os limites conforme necessário:

    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 criar políticas de alertas, execute o seguinte comando:

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

    As novas políticas de alertas aparecem na página "Alertas".

Modificar alertas

A lista completa das métricas mais recentes está disponível no repositório do GitHub kubernetes-sigs/gateway-api-inference-extension, e é possível adicionar novos alertas ao manifesto usando outras métricas.

Para modificar os alertas de exemplo, considere o exemplo a seguir:

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

Esse alerta é acionado se o 99º percentil da duração da solicitação em cinco minutos ultrapassar 10 segundos. É possível modificar a seção expr do alerta para ajustar o limite com base nos seus requisitos.

Configurar a geração de registros para o GKE Inference Gateway

A configuração do registro em log para o GKE Inference Gateway fornece informações detalhadas sobre solicitações e respostas, o que é útil para solução de problemas, auditoria e análise de desempenho. Os registros de acesso HTTP registram todas as solicitações e respostas, incluindo cabeçalhos, códigos de status e carimbos de data/hora. Esse nível de detalhes pode ajudar você a identificar problemas, encontrar erros e entender o comportamento das cargas de trabalho de inferência.

Para configurar o registro em registros do GKE Inference Gateway, ative o registro de acesso HTTP para cada um dos seus objetos InferencePool.

  1. Salve o seguinte manifesto de amostra 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

    Substitua:

    • NAMESPACE_NAME: o nome do namespace em que seu InferencePool está implantado.
    • INFERENCE_POOL_NAME: o nome do InferencePool.

  2. Aplique o manifesto de amostra ao cluster:

    kubectl apply -f logging-backend-policy.yaml

Depois de aplicar esse manifesto, o GKE Inference Gateway vai ativar os registros de acesso HTTP para o InferencePool especificado. É possível conferir esses registros no Cloud Logging. Os registros incluem informações detalhadas sobre cada solicitação e resposta, como o URL da solicitação, cabeçalhos, código de status da resposta e latência.

Criar métricas com base em registros para ver detalhes do erro

É possível usar métricas com base em registros para analisar os registros de balanceamento de carga e extrair detalhes de erros. Cada classe de gateway do GKE, como as classes de gateway gke-l7-global-external-managed e gke-l7-regional-internal-managed, é apoiada por um balanceador de carga diferente. Para mais informações, consulte Recursos do GatewayClass.

Cada balanceador de carga tem um recurso monitorado diferente que você precisa usar ao criar uma métrica baseada em registros. Para mais informações sobre o recurso monitorado de cada balanceador de carga, consulte:

Para criar uma métrica com base em registros e ver os detalhes do erro, faça o seguinte:

  1. Crie um arquivo JSON chamado error_detail_metric.json com a seguinte definição de LogMetric. Essa configuração cria uma métrica que extrai o campo proxyStatus dos registros do 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)"
  }
}

    Substitua MONITORED_RESOURCE pelo recurso monitorado do balanceador de carga.

  2. Abra o Cloud Shell ou o terminal local em que a CLI gcloud está instalada.

  3. Para criar a métrica, execute o comando gcloud logging metrics create com a flag --config-from-file:

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

Depois que a métrica for criada, use-a no Cloud Monitoring para conferir a distribuição de erros informados pelo balanceador de carga. Para mais informações, consulte Criar uma métrica com base em registros.

Para mais informações sobre como criar alertas com base em métricas baseadas em registros, consulte Criar uma política de alertas em uma métrica de contador.

Configure o escalonamento automático

O escalonamento automático ajusta a alocação de recursos em resposta às variações de carga, mantendo a performance e a eficiência de recursos ao adicionar ou remover pods dinamicamente com base na demanda. Para o GKE Inference Gateway, isso envolve o escalonamento automático horizontal de pods em cada InferencePool. O escalonador automático horizontal de pods (HPA) do GKE escalona automaticamente os pods com base em métricas do servidor de modelos, como KVCache Utilization. Isso garante que o serviço de inferência processe diferentes cargas de trabalho e volumes de consultas, gerenciando o uso de recursos de maneira eficiente.

Para configurar instâncias InferencePool para que elas façam o escalonamento automático com base nas métricas produzidas pelo GKE Inference Gateway, siga estas etapas:

  1. Implante um objeto PodMonitoring no cluster para coletar métricas produzidas pelo GKE Inference Gateway. Para mais informações, consulte Configurar a capacidade de observação.

  2. Implante o adaptador de métricas personalizadas do Stackdriver para dar ao HPA acesso às métricas:

    1. Salve o seguinte manifesto de amostra 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. Aplique o manifesto de amostra ao cluster:

      kubectl apply -f adapter_new_resource_model.yaml

  3. Para conceder ao adaptador permissões de leitura de métricas do projeto, execute o seguinte 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

    Substitua PROJECT_ID pelo ID do projeto Google Cloud .

  4. Para cada InferencePool, implante um HPA semelhante ao seguinte:

    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

    Substitua:

    • INFERENCE_POOL_NAME: o nome do InferencePool.
    • INFERENCE_POOL_NAMESPACE: o namespace do InferencePool.
    • CLUSTER_NAME: o nome do cluster.
    • MIN_REPLICAS: a disponibilidade mínima do InferencePool (capacidade de valor de referência). O HPA mantém esse número de réplicas quando o uso está abaixo do limite de destino do HPA. As cargas de trabalho de alta disponibilidade precisam definir esse valor como maior que 1 para garantir a disponibilidade contínua durante interrupções de pods.
    • MAX_REPLICAS: o valor que restringe o número de aceleradores que precisam ser atribuídos às cargas de trabalho hospedadas no InferencePool. O HPA não vai aumentar o número de réplicas além desse valor. Durante os horários de pico de tráfego, monitore o número de réplicas para garantir que o valor do campo MAX_REPLICAS ofereça espaço suficiente para que a carga de trabalho possa ser escalonada e manter as características de desempenho escolhidas.
    • TARGET_VALUE: o valor que representa o KV-Cache Utilization de destino escolhido por servidor de modelo. Esse é um número entre 0 e 100 e depende muito do servidor, do modelo, do acelerador e das características do tráfego de entrada. É possível determinar esse valor de destino experimentalmente com testes de carga e criando um gráfico de capacidade de processamento versus latência. Selecione uma combinação de capacidade de transmissão e latência no gráfico e use o valor KV-Cache Utilization correspondente como a meta do HPA. É preciso ajustar e monitorar esse valor de perto para alcançar os resultados de preço-performance escolhidos. Use o guia de início rápido da inferência do GKE para determinar esse valor automaticamente.

A seguir