Requests, limits e PodDisruptionBudget: como ler um manifest de Kubernetes sem se enganar

Quase todo incidente de upgrade e boa parte do desperdício de custo em Kubernetes passam por poucos campos do manifest: requests, limits, readinessProbe, replicas e o PodDisruptionBudget. Eles parecem simples, e é por isso que os erros ficam.

Requests: o campo que define o custo

O request é o que o scheduler reserva para o pod no nó. O nó é cobrado inteiro, então o custo do cluster segue os requests, e não o uso. Um pod que pede 2 CPUs e usa 200m ocupa o mesmo espaço de um que usa as 2.

Isso tem três efeitos:

• Requests inflados criam nós que parecem cheios e estão ociosos, e nenhum autoscaler resolve isso sozinho.
• Requests ausentes deixam o pod sem reserva. Ele cai na classe de QoS BestEffort ou Burstable e é um dos primeiros a ser removido quando o nó fica sem memória.
• Autoscalers, consolidação e o planejamento de Savings Plans dependem de requests corretos.

Para definir valores, parta do uso observado, por exemplo o percentil 95 mais uma folga, e não de um palpite. O rightsizing-check compara requests com o uso (arquivos ou Prometheus) e diz o que definir.

Limits: CPU e memória se comportam diferente

• Memória. Passou do limite, o container é encerrado por OOM. Sem limite, um vazamento pode consumir o nó inteiro. Por isso o ideal é ter um limite de memória, perto do request.
• CPU. Passou do limite, o container é limitado (throttling), não encerrado. Limites de CPU apertados podem aumentar a latência sem aparecer como erro. Muitos times usam request de CPU sem limite de CPU, e isso é uma decisão válida, desde que seja uma decisão.

Quando requests e limits são iguais em todos os containers, o pod é Guaranteed, a classe mais protegida. É um bom padrão para cargas críticas, ao custo de menos aproveitamento do nó.

readinessProbe: o que decide quem recebe tráfego

Sem readinessProbe, o pod é considerado pronto assim que o container sobe. Durante um deploy ou uma consolidação, o Service pode enviar tráfego para um pod que ainda está iniciando. A probe também importa para o PDB, porque ele conta pods prontos.

PodDisruptionBudget: o que ele protege e o que não protege

Um PDB limita quantos pods de um serviço podem ficar indisponíveis ao mesmo tempo durante disrupções voluntárias: drenagem de nós, upgrades e consolidação do Karpenter ou do Cluster Autoscaler.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: checkout
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: checkout

Os erros mais comuns:

• Seletor que não casa. Se matchLabels não corresponde aos labels do pod, o PDB não protege nada e nenhum erro aparece. Confira com kubectl get pdb e veja se ALLOWED DISRUPTIONS faz sentido.
• `minAvailable` igual ao número de réplicas (ou maxUnavailable: 0). Nenhum pod pode ser removido, e o upgrade de nós trava. Deixe sempre uma folga.
• Uma única réplica com `minAvailable: 1`. Mesmo problema: o pod nunca pode sair.
• Achar que o PDB cobre falha de nó. Ele não cobre. Em Spot, por exemplo, o aviso de dois minutos limita o que uma drenagem consegue fazer, e é por isso que réplicas e spread importam mais que o PDB.

Como checar tudo isso de uma vez

O checker de manifests lê seus YAMLs no navegador, sem enviar nada, e aponta requests ausentes, falta de limite de memória, falta de readiness, tag latest, réplica única, ausência de PDB e de spread, cruzando o seletor do PDB com os labels do pod. Para o cluster em si, o spot-readiness aplica regras parecidas e gera um plano do que pode ir para Spot.

Um roteiro curto

1. Rode o checker nos manifests do serviço mais crítico.
2. Corrija requests e memória primeiro: têm o maior efeito em custo e estabilidade.
3. Adicione readiness e, nos serviços com 2 ou mais réplicas, um PDB e topologySpreadConstraints.
4. Teste uma drenagem de nó em homologação e veja se o PDB deixa passar o que deve.

Para entender o efeito financeiro de corrigir requests, use a calculadora de economia. Se quiser uma revisão do seu cluster, o assessment de eficiência é o ponto de partida.