Kubernetes 1.36: PSI Metrics em GA – Antecipe Gargalos de Recursos com Overhead Menor que 3%

Enquanto suas métricas de CPU e memória mostram verde, suas aplicações podem estar sufocando em filas de espera. As PSI Metrics quebram esse engano — e agora chegam estáveis no Kubernetes 1.36.

O que a utilização esconde que a pressão revela?

Métricas clássicas de utilização indicam apenas o quanto um recurso está ocupado — não o quanto suas tarefas estão sofrendo. Um nó com 80% de CPU pode parecer saudável, mas se as threads estão esperando ciclos, a experiência real do usuário já está degradada.

Analogia rápida: Utilização é como saber quantos carros estão na estrada. PSI mede quantos estão parados no congestionamento.

As Pressure Stall Information (PSI), nativas do kernel Linux 4.20, medem exatamente isso: o tempo que as tarefas ficam bloqueadas por falta de CPU, memória ou I/O. São três tipos:

• CPU PSI — tarefas prontas para executar, mas sem CPU disponível.
• Memory PSI — tarefas esperando páginação ou swap.
• I/O PSI — tarefas aguardando disco.

Os dados são expostos como totais cumulativos e médias móveis (10s, 60s, 300s). Isso permite detectar picos e também acompanhar tendências.

PSI não é opinião — é evidência direta de contenção.

O que muda com o GA no Kubernetes 1.36?

A funcionalidade saiu do feature gate e agora é habilitada por padrão em todos os nós Linux com cgroup v2 e kernel ≥ 4.20. Mas a maior novidade é a detecção automática de suporte do SO.

O kubelet verifica se o kernel compilou com CONFIG_PSI=y. Se não houver suporte, as métricas simplesmente não aparecem — zero falso não é mais um problema.

Mais duas melhorias importantes

• API estável: sem mudanças quebradoras entre versões.
• Exposição dupla: /metrics/cadvisor (Prometheus) e Summary API.

"A PSI no GA não é apenas uma feature — é a porta de entrada para observabilidade preditiva."

Overhead real: abaixo de 3,125% mesmo com 80+ pods

Testes oficiais do SIG Node em hosts de 4 cores com 80 pods por nó mostraram números que acalmam qualquer engenheiro:

Conclusão prática: PSI pode ser ativada em produção sem impacto mensurável na carga de trabalho.Cuidado: ambientes com kernel < 4.20 ou sem cgroup v2 não conseguem usar PSI. Windows também não é suportado.

Como acessar e interpretar PSI no seu cluster

Duas interfaces padronizadas permitem consumir os dados:

• Endpoint Prometheus (/metrics/cadvisor) — ideal para dashboards e alertas existentes.
• Summary API — acesso direto via kubelet, exemplo:

"cpu": {
  "some": { "total": 1200000, "avg10": 0.5, "avg60": 0.3, "avg300": 0.1 },
  "full": { "total": 500000, "avg10": 0.2, "avg60": 0.1, "avg300": 0.05 }
}

O campo some indica tempo em que pelo menos uma tarefa sofreu pressão. full indica que todas as tarefas foram afetadas. O avg10 é o termômetro para alertas em tempo real.

"Um avg10 de CPU PSI subindo de 0,1 para 1,5 em dois minutos é sinal de que seus pods estão competindo por CPU — antes que o uso ultrapasse 90%."

Implicações para SREs e o ecossistema

Observabilidade preditiva

Com PSI, você não espera a lentidão chegar ao usuário. Um aumento no avg10 de memória pode gerar:

• Ajuste proativo de limites de recursos.
• Balanceamento preventivo de pods entre nós.
• Alertas baseados em pressão, não em thresholds arbitrários de utilização.

Mercado em movimento

Provedores de nuvem (EKS, GKE, AKS) devem integrar PSI em seus dashboards nativos. Ferramentas como Datadog, New Relic e Grafana precisam adotar os novos endpoints. Para equipes de SRE, isso reduz scripts customizados e complexidade.

Riscos e limitações

• Dependência de kernel moderno: ambientes legados podem exigir upgrade de SO.
• Acesso privilegiado: a Summary API exige permissões de cluster-admin.
• Curva de aprendizado: interpretar pressão exige treinamento — evite falsos positivos.

Visão Metatron

A graduação das PSI Metrics não é apenas mais uma feature. É um ponto de inflexão na maturidade da observabilidade de containers. Saímos de métricas superficiais que camuflam a dor real para indicadores que expõem a contenção com precisão cirúrgica.

Com overhead comprovadamente baixo e integração nativa com Prometheus, esse recurso capacita times a operar de forma preditiva — antecipando gargalos antes que eles impactem a experiência do usuário.

Resumo prático para sua equipe:
1. Verifique kernel ≥ 4.20 e cgroup v2 nos nós.
2. Ative a coleta de PSI via /metrics/cadvisor.
3. Crie alertas no avg10 de CPU, memória e I/O.
4. Treine o time para interpretar pressão em vez de utilização.A pressão está agora do seu lado. Comece a medir o que realmente importa.