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 GKE Inference Gateway.

Entenda e configure os seguintes recursos avançados:

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

O GKE Inference Gateway 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 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. Também é possível usar as proteções do NVIDIA NeMo para verificações de segurança.

O diagrama a seguir ilustra a integração do Model Armor com o GKE Inference Gateway em um cluster do GKE:

Integração doCloud de Confiance by S3NS 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 Cloud de Confiance by S3NS .

    2. Crie os modelos do Model Armor usando o console do Model Armor, a Google Cloud CLI 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. Execute os seguintes comandos para conceder os papéis necessários:

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

    Para aplicar as políticas do Model Armor ao 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 ao qual 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 em que 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 as configurações de extensionPolicy e 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 gateway, o Model Armor filtra automaticamente os comandos e as respostas com base nas regras definidas.

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

O GKE Inference Gateway se integra à Apigee para fornecer autenticação, autorização e gerenciamento de APIs 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 GKE Inference Gateway ao Apigee para melhorar o GKE Inference Gateway 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 da Apigee criada na mesma região do cluster do GKE.
  • O operador de APIM da Apigee e os CRDs dele 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 GKE Inference Gateway 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 estiver instalado com a flag 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 GKE Inference Gateway

Configure o GKE Inference Gateway para ativar o processador de extensão da 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 gateway.

  2. Aplique o manifesto ao cluster:

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

  3. Aguarde até que o status de GCPTrafficExtension mude para 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 GKE Inference Gateway, 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 recusada:

    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 APIs com o operador de APIM da Apigee para Kubernetes.

Configurar observabilidade

O GKE Inference Gateway 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 seus aplicativos.

OCloud de Confiance by S3NS oferece os seguintes painéis do Cloud Monitoring que oferecem observabilidade de inferência para o GKE Inference Gateway:

  • Painel do GKE Inference Gateway: fornece métricas de ouro para a veiculação de LLMs, como capacidade de processamento de solicitações e tokens, latência, erros e utilização de cache para o InferencePool. Para conferir a lista completa de métricas disponíveis do GKE Inference Gateway, consulte Métricas expostas.
  • Painéis de observabilidade de IA/ML: fornecem painéis para uso da infraestrutura, métricas do DCGM e métricas de performance do modelo vLLM.
  • Painel do servidor de modelo: fornece um painel para indicadores de ouro 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ção de ponta a ponta e identificar erros.
  • Métricas do Data Center GPU Manager (DCGM): fornece métricas do DCGM, como o desempenho e a utilização das GPUs NVIDIA. É possível configurar as métricas do DCGM no Cloud Monitoring. Para mais informações, consulte Coletar e visualizar métricas do DCGM.

Ver o painel do GKE Inference Gateway

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

  1. No console do Cloud de Confiance , acesse a página Monitoring.

    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 de monitoramento.

Acessar painéis de observabilidade de modelos de IA/ML

Para conferir os modelos implantados e os painéis das métricas de observabilidade de um modelo, siga estas etapas:

  1. No console do Cloud de Confiance , acesse a página Modelos implantados.

    Acessar "Modelos implantados"

  2. Para conferir detalhes sobre uma implantação específica, incluindo métricas, registros e painéis, clique no nome do modelo na lista.

  3. Na página de detalhes do modelo, clique na guia Observabilidade para conferir os painéis a seguir. Se solicitado, clique em Ativar para ativar o painel.

    • O painel Uso da infraestrutura mostra métricas de utilização.
    • O painel DCGM mostra as métricas do DCGM.
    • Se você estiver usando o vLLM, o painel Performance do modelo vai estar disponível e mostrará métricas de desempenho do modelo vLLM.

Configurar o painel de observabilidade do servidor de modelos

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

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

  1. No console do Cloud de Confiance , acesse a página Monitoring.

    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 mostrados.

    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 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. Você pode adicionar novos alertas ao manifesto usando outras métricas.

Para modificar os alertas de amostra, considere o seguinte exemplo:

  - 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 5 minutos exceder 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 da geração de registros 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 detalhe pode ajudar 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 exemplo ao cluster:

    kubectl apply -f logging-backend-policy.yaml

Depois de aplicar esse manifesto, o GKE Inference Gateway ativa 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, os cabeçalhos, o código de status da resposta e a latência.

Criar métricas com base em registros para ver detalhes de erros

É 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 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 com base 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 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 visualizar 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 com base 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 a 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 faz o escalonamento automático de pods com base em métricas do servidor de modelos, como KVCache Utilization. Essa abordagem ajuda a garantir que o serviço de inferência processe diferentes cargas de trabalho e volumes de consulta, além de gerenciar com eficiência o uso de recursos.

Para configurar as instâncias do InferencePool para que elas sejam escalonadas automaticamente 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 observabilidade.

  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
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. 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.s3ns.svc.id.goog/subject/ns/custom-metrics/sa/custom-metrics-stackdriver-adapter

    Substitua PROJECT_ID pelo ID do projeto Cloud de Confiance .

  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 da InferencePool (capacidade de referência). O HPA mantém esse número de réplicas quando o uso está abaixo do limite da meta 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 pod.
    • 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 forneça espaço suficiente para que a carga de trabalho possa ser escalonar verticalmente para manter as características de desempenho escolhidas.
    • TARGET_VALUE: o valor que representa a meta KV-Cache Utilization escolhida por servidor de modelo. Esse é um número entre 0 e 100 e depende muito do servidor de modelos, 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 processamento e latência no gráfico e use o valor KV-Cache Utilization correspondente como o destino do HPA. É necessário 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 do GKE Inference para determinar esse valor automaticamente.

A seguir