Expor métricas personalizadas para balanceadores de carga

Este documento descreve como enviar uma ou mais métricas de um pod ou carga de trabalho para o balanceador de carga.

Essas métricas vêm do serviço ou aplicativo que você está executando. Por exemplo, consulte as métricas expostas pelo mecanismo vLLM.

O balanceador de carga pode usar esses dados com o balanceamento de carga baseado na utilização para equilibrar as cargas de trabalho com mais eficiência. Por exemplo, é possível usar esse recurso para monitorar as regiões com maior uso de carga de trabalho e permitir que o balanceador de carga redirecione o tráfego para a região com mais recursos disponíveis. No exemplo do vLLM, uma métrica que pode ser útil para acompanhar a utilização é vllm:gpu_cache_usage_perc.

Requisitos

Os requisitos para os pods são os seguintes:

Os requisitos para as métricas são os seguintes.

  • As métricas precisam estar acessíveis em um endpoint HTTP nos pods que estão sendo balanceados pelo gateway. O caminho do endpoint padrão é /metrics.
  • As métricas precisam ser formatadas de acordo com o padrão do Prometheus.

  • Os balanceadores de carga têm restrições nos nomes das métricas. Por exemplo, o nome não pode exceder 64 caracteres. Para conferir a lista completa de restrições, consulte os detalhes sobre o campo backends[].customMetrics[].name na referência da API para BackendService.

    Se a métrica do serviço não estiver em conformidade com essas restrições, renomeie-a usando o campo exportName.

  • Somente métricas de medidor entre 0 e 1 são aceitas, com 1 representando a utilização de 100%.

  • Os nomes dos rótulos nos seletores de rótulos de pods não podem conter caracteres especiais. Somente letras de a a z (minúsculas ou maiúsculas), números, hifens e sublinhados são aceitos.

  • É possível expor no máximo 20 métricas exclusivas por cluster. Outros serviços têm limites próprios. Por exemplo, consulte os limites e requisitos dos balanceadores de carga. Um cluster pode usar mais de um balanceador de carga.

Balanceamento baseado na utilização (UBB, na sigla em inglês) do GKE com base em métricas personalizadas

É possível usar o balanceamento baseado na utilização (UBB) do GKE para permitir que o balanceador de carga distribua o tráfego com base na utilização dos pods de back-end. Em vez de depender de uma métrica genérica, como a CPU, é possível configurar o UBB para usar métricas personalizadas mais relevantes para o desempenho do aplicativo.

Quando você usa o UBB com métricas personalizadas no GKE, as seguintes limitações se aplicam:

  • Somente API Gateway:só é possível usar o UBB com métricas personalizadas com serviços expostos usando a API Gateway. O GKE usa o controlador do Gateway GKE para interagir com a API Gateway. As APIs Service e Ingress não oferecem suporte ao UBB com métricas personalizadas. As métricas personalizadas precisam se originar dos pods que são membros dos serviços.
  • Sem o Cloud Service Mesh:não é possível usar o UBB com métricas personalizadas com o Cloud Service Mesh.
  • Balanceadores de carga não aceitos:não é possível usar o UBB com métricas personalizadas com balanceadores de carga de rede de passagem externa e balanceador de carga de rede de proxy externo.

Expor métricas para balanceamento de carga

  1. Escolha uma métrica para expor. É possível escolher qualquer métrica exposta pelo servidor e que também atenda aos requisitos listados na seção anterior. Este exemplo usa uma métrica personalizada chamada queue_depth_util.

  2. Adicione o seguinte recurso personalizado, substituindo os detalhes específicos da métrica e do pod:

    apiVersion: autoscaling.gke.io/v1beta1
kind: AutoscalingMetric
metadata:
  name: NAME
  namespace:NAMESPACE
spec:
  metrics:
  - pod:
      selector:
        matchLabels:
          APP_LABEL_NAME: APP_LABEL_VALUE
      containers:
      - endpoint:
          port: METRIC_PORT
          path: METRIC_PATH
        metrics:
        - gauge:
          name: METRIC
          prometheusMetricName: METRIC_PROMETHEUS_NAME
          loadBalancing:
            enabled: true

    Substitua o seguinte para corresponder à carga de trabalho:

    • NAME: o nome do objeto AutoscalingMetric.
    • NAMESPACE: o namespace em que os pods estão.
    • APP_LABEL_NAME e APP_LABEL_VALUE: o nome e o valor do rótulo que correspondem aos pods que emitem a métrica.
    • METRIC_PORT: o número da porta.
    • METRIC_PATH: o caminho para a métrica. Verifique o caminho usado pelo serviço ou aplicativo. Esse caminho geralmente é /metrics.
    • METRIC: o nome da métrica que você está expondo. O nome precisa corresponder à expressão regular ^[a-z]([a-z0-9_-]*[a-z0-9])? e ter um comprimento de no máximo 63 caracteres. Isso significa que o primeiro caractere precisa ser uma letra minúscula, e todos os caracteres a seguir precisam ser hifens, sublinhados, letras minúsculas ou dígitos, exceto o último caractere, que precisa ser uma letra ou um dígito.

    • Opcional: METRIC_PROMETHEUS_NAME: o nome da métrica do Prometheus exposto pelo pod. É possível usar esse campo para renomear a métrica, por exemplo, porque o nome da métrica exposto pelo pod não está em conformidade com as restrições de nome definidas pelo balanceador de carga.

      Para conferir a lista completa de restrições, consulte os detalhes sobre o campo backends[].customMetrics[].name na referência da API para BackendService.

  3. Aplique o manifesto usando o seguinte comando:

    kubectl apply -f FILE_NAME.yaml

    Substitua FILE_NAME pelo nome do arquivo YAML.

    Quando você adiciona o recurso personalizado, a métrica é enviada por push para a API de escalonamento automático. A métrica é lida a cada poucos segundos e enviada ao balanceador de carga.

  4. Para usar esse sinal para fins de balanceamento de carga, forneça uma GCPBackendPolicy. Exemplo:

    kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: my-backend-policy
spec:
  targetRef:
    group: ""
    kind: Service
    name: store-v1
  default:
    balancingMode: CUSTOM_METRICS
    customMetrics:
    -   name: gke.named_metrics.queue_depth_util
        dryRun: false

Observe que as métricas informadas pelo Prometheus seguem um padrão de nomenclatura diferente. Quando as métricas são informadas para balanceamento de carga, o agente de métricas do GKE as anexa internamente com o prefixo gke.named_metrics. para seguir o requisito da API BackendService.

Para expor uma segunda métrica, siga as mesmas etapas para criar outro recurso personalizado.

Agora que você expôs as métricas ao balanceador de carga, é possível configurá-lo para usar essas métricas. Para mais detalhes, consulte Configurar o balanceador de carga para usar métricas personalizadas.

Para mais informações sobre como trabalhar com o balanceador de carga, consulte Configurar o balanceamento de carga baseado na utilização para serviços do GKE.

Resolver problemas de métricas expostas ao balanceador de carga

Para verificar se as métricas estão expostas corretamente ao balanceador de carga, faça o seguinte:

A seguir