Autoscaling mais inteligente no GKE: vá além de CPU e memória com métricas customizadas

O autoscaling no Kubernetes geralmente depende do Horizontal Pod Autoscaler (HPA). Por padrão, o HPA escala workloads com base na utilização de recursos, como CPU ou memória. Isso funciona bem em muitos casos, mas nem sempre reflete a demanda real sobre a aplicação.

Por exemplo:

• Uma API web pode ter tráfego intenso de requisições sem alta utilização de CPU.
• Um serviço de processamento de filas pode precisar de mais workers conforme o backlog cresce.
• Workloads de inferência de IA podem depender mais do uso de GPU do que de CPU.
• Serviços de streaming podem precisar escalar com base em requisições por segundo.

Esses cenários exigem escalonamento baseado em métricas no nível da aplicação, e não em métricas de infraestrutura.

O Kubernetes oferece suporte a autoscaling baseado em métricas customizadas, mas, historicamente, isso exigia componentes adicionais, como:

• Adaptadores Prometheus — um deployment separado que faz a ponte entre as métricas do Prometheus e a API de métricas do Kubernetes
• Pipelines de métricas customizadas — camadas de ingestão, armazenamento e consulta entre a aplicação e o HPA
• Configuração complexa de IAM e service accounts — sobretudo em ambientes gerenciados como o GKE

Fonte: Gemini Nano Banana Pro

O custo operacional desses componentes era alto: as equipes precisavam manter a compatibilidade do adaptador entre versões do Kubernetes, depurar pipelines de métricas com vários saltos e lidar com a latência das camadas de infraestrutura. Esse atrito atrasou a adoção e fez muitos times voltarem ao escalonamento por CPU.

O GKE agora oferece integração nativa para expor métricas customizadas, simplificando a forma como as aplicações compartilham métricas com o sistema de autoscaling. Em vez de passar por adaptadores externos e sistemas de monitoramento, as métricas customizadas são coletadas diretamente dos pods e enviadas ao HPA.

Com isso, o sistema de autoscaling reage ao comportamento real da aplicação, como throughput de requisições ou utilização de recursos. Integrar métricas da aplicação às estratégias de escalonamento fica muito mais simples.

Fonte: Gemini Nano Banana Pro

O novo recurso funciona por meio de um objeto chamado AutoscalingMetric.

Esse objeto define:

• Quais pods expõem as métricas (via label selectors)
• Onde fica o endpoint de métricas (porta e path)
• Qual métrica específica deve ser coletada
• Como a métrica deve ser exportada para o sistema de autoscaling

Depois de definido, o GKE coleta essas métricas e as disponibiliza para componentes como o load balancer ou o autoscaler.

Os principais requisitos são:

• As métricas precisam estar disponíveis em um endpoint HTTP
• O formato deve seguir os padrões do Prometheus
• Apenas métricas do tipo gauge são suportadas.
• Limite de 20 métricas únicas expostas por cluster.

Gauge vs. outros tipos de métrica: um gauge representa um valor que pode subir ou descer a qualquer momento (ex.: tamanho atual da fila = 45). Já os counters só sobem (ex.: total de requisições processadas = 10.432) e não servem como alvo direto de autoscaling. Se sua aplicação expõe counters hoje, será preciso derivar um gauge (ex.: taxa de requisições derivada) antes de usá-lo com esse recurso.

Depois que a métrica é registrada, o GKE a lê continuamente e injeta o valor na lógica de escalonamento.

Vamos passar por um exemplo completo e autocontido.

Cenário: um serviço worker em background processa jobs de uma fila. Queremos escalar a quantidade de pods worker com base no tamanho atual da fila — e não no uso de CPU.

Passo 1: expor a métrica na aplicação

Faça o deploy da sua aplicação expondo uma métrica gauge em formato Prometheus no endpoint /metrics:

# HELP job_queue_length Current number of jobs waiting in the queue
# TYPE job_queue_length gauge
job_queue_length 45

Vamos supor que as métricas estejam disponíveis em http://worker-service:9090/metrics

Passo 2: criar um recurso AutoscalingMetric

Defina um recurso AutoscalingMetric que indique ao GKE onde encontrar a métrica e como exportá-la:

apiVersion: autoscaling.gke.io/v1beta1
kind: AutoscalingMetric
metadata:
  name: worker-queue-metric
  namespace: default
spec:
  selector:
    matchLabels:
      app: job-worker #Nome e valor do label que correspondem aos Pods
  endpoints:
  - port: 9090 #Número da porta de métricas
    path: /metrics #Path da métrica
    metrics:
    - gauge:
      name: job_queue_length #Nome da métrica que você está expondo.
      prometheusMetricName: job_queue_length #opcional: nome da métrica Prometheus exposta pelo Pod.

Após aplicado, a métrica fica disponível para o sistema de autoscaling.

Agora criamos um HPA que usa a métrica customizada.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: worker-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: job-worker
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: autoscaling.gke.io|worker-queue-metric|queue_utilization
      target:
        type: AverageValue
        averageValue: 20

Na prática, essa configuração significa:

• Se o tamanho médio da fila passar de 20 jobs por pod, o sistema escala para cima.
• Se a fila diminuir, o sistema escala para baixo.

Esse recurso traz várias vantagens importantes.

• Escalonamento orientado pela aplicação: as decisões refletem a demanda real, e não proxies de infraestrutura.
• Menos complexidade operacional: dispensa adaptadores externos e pipelines de métricas complicados.
• Mais desempenho: as aplicações escalam com mais precisão e respondem mais rápido a picos de workload.
• Uso melhor dos recursos: os custos de infraestrutura caem porque o escalonamento acompanha a demanda real.
• Estratégias de autoscaling flexíveis: os times podem montar políticas em torno de qualquer métrica gauge exposta pela aplicação, como profundidade de fila, sessões ativas, renderizações pendentes e muito mais.