PodDisruptionBudget no Node.js

O PodDisruptionBudget no Node.js limita quantos Pods de uma aplicação podem ser removidos simultaneamente durante interrupções voluntárias, como drain de nó, upgrade do cluster e manutenção planejada. O recurso ajuda a preservar capacidade enquanto administradores movem workloads.

Um PDB não protege contra falha de hardware, OOM, crash da aplicação ou indisponibilidade de zona. Ele controla apenas evictions voluntárias que respeitam a API do Kubernetes. Para funcionar, a aplicação precisa de réplicas, readiness correta, distribuição entre nós e capacidade para suportar uma réplica a menos.

Neste guia, você aprenderá minAvailable, maxUnavailable, selectors, rounding, unhealthy pod eviction policy, drain, HPA e práticas para evitar PDBs que bloqueiam a manutenção.

O que é uma interrupção voluntária?

A documentação oficial sobre PodDisruptionBudget inclui como exemplos:

• drain de um nó;
• upgrade controlado;
• remoção de nó pelo autoscaler;
• eviction iniciada por administrador;
• mudanças de infraestrutura que usam a Eviction API.

Uma pane do nó é involuntária e pode reduzir réplicas abaixo do orçamento.

Pré-requisito: múltiplas réplicas

Uma API com uma réplica não ganha alta disponibilidade ao receber um PDB. Se maxUnavailable: 0, o drain pode ficar bloqueado. Se permitir uma interrupção, a aplicação fica totalmente indisponível.

Use Deployment com réplicas suficientes. Veja Kubernetes Deployment no Node.js.

Exemplo com maxUnavailable

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: orders-api
  namespace: production
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: orders-api
      app.kubernetes.io/instance: production

Se o Deployment possui três réplicas, apenas uma pode estar indisponível por eviction voluntária. Duas devem permanecer Ready.

Exemplo com minAvailable

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: orders-api
  namespace: production
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: orders-api

Com três réplicas, o resultado é semelhante. Porém, maxUnavailable acompanha melhor alterações de escala, enquanto um inteiro fixo em minAvailable pode ficar desatualizado.

Use apenas um campo

Um PDB aceita minAvailable ou maxUnavailable, nunca ambos. A escolha deve refletir como o workload escala.

Percentuais

maxUnavailable: "25%"

Percentuais são arredondados para cima. Com três réplicas, 25% ainda pode permitir uma interrupção, equivalente a 33%. Teste a matemática para escalas pequenas.

Selector correto

O selector precisa corresponder aos Pods do controlador. Um selector vazio em policy/v1 pode selecionar todos os Pods do namespace, criando impacto muito maior que o planejado.

kubectl get pods -n production \
  -l app.kubernetes.io/name=orders-api

Confira o resultado antes de aplicar.

Status do PDB

kubectl get pdb orders-api -n production
kubectl get pdb orders-api -n production -o yaml

Campos importantes:

• currentHealthy: Pods Ready atuais.
• desiredHealthy: quantidade exigida.
• disruptionsAllowed: evictions permitidas no momento.
• expectedPods: réplicas esperadas pelo controller.

Readiness define saúde

O PDB considera saudável um Pod com condição Ready verdadeira. Uma readiness permissiva contabiliza Pods que não atendem corretamente. Uma readiness instável reduz disruptionsAllowed e pode bloquear drains.

Consulte Probes Kubernetes em Node.js.

Drain de nó

kubectl drain worker-3 \
  --ignore-daemonsets \
  --delete-emptydir-data

O drain usa eviction e respeita PDB. Se o orçamento não permite remover um Pod, o comando espera. Não use --disable-eviction como rotina, pois isso ignora o orçamento.

Por que o drain pode bloquear?

• réplicas insuficientes;
• um Pod não está Ready;
• novos Pods estão Pending;
• selector incorreto;
• maxUnavailable: 0;
• falta de capacidade em outros nós;
• affinity impede novo scheduling;
• imagem não pode ser baixada.

Zero interrupções

maxUnavailable: 0

Isso bloqueia toda eviction voluntária. Pode ser útil por um período curto para workload especial, mas impede drain enquanto o PDB existir. Mantenha um procedimento para alterar ou remover a proteção.

HPA e PDB

Com HPA, o número de réplicas varia. maxUnavailable: 1 ou percentual geralmente acompanha a escala melhor que minAvailable fixo.

Veja Kubernetes HPA no Node.js.

Capacidade após eviction

Três réplicas não significam que duas suportam o tráfego. Faça teste de carga com uma réplica indisponível e deixe margem de CPU, memória e conexões.

Rolling update e PDB

O controlador de Deployment possui sua própria estratégia maxUnavailable e não depende diretamente do PDB para todas as ações. Não trate PDB como configuração de rollout. Configure ambos de forma coerente.

Cluster Autoscaler

O autoscaler pode deixar de remover um nó se o PDB impedir eviction. Muitos budgets rígidos reduzem eficiência e aumentam custo. Monitore nós não removíveis e o motivo.

Topology spread

Se todas as réplicas estiverem no mesmo nó, o PDB não protege contra a falha desse nó. Distribua Pods:

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: kubernetes.io/hostname
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        app.kubernetes.io/name: orders-api

Para clusters multi-zone, adicione regra por topology.kubernetes.io/zone.

Anti-affinity

Pod anti-affinity pode impedir concentração, mas regras obrigatórias tornam scheduling difícil em clusters pequenos. Compare com topology spread.

Unhealthy pod eviction policy

Versões atuais permitem controlar Pods Running mas não Ready:

spec:
  maxUnavailable: 1
  unhealthyPodEvictionPolicy: AlwaysAllow

AlwaysAllow permite remover Pods não saudáveis mesmo quando o budget já está interrompido. Isso evita drains presos por CrashLoopBackOff, mas reduz a chance de o Pod recuperar naquele nó.

IfHealthyBudget

O comportamento conservador permite eviction de Pod não saudável somente quando a aplicação não fica abaixo do budget. Protege workloads já degradados, mas pode bloquear manutenção.

Escolhendo a política

• Use AlwaysAllow quando Pods quebrados devem sair do caminho.
• Use comportamento conservador quando cada réplica potencial é importante e pode recuperar.
• Teste CrashLoop, readiness falha e drain.

Stateful workloads

Um StatefulSet de cinco membros com quorum três pode usar:

minAvailable: 3

Porém, o PDB não entende quorum, replicação ou estado do banco. O operador da aplicação precisa garantir que eviction é segura.

Jobs

Jobs reiniciáveis normalmente não precisam de PDB. O Job controller cria outro Pod. Um PDB pode bloquear manutenção sem benefício.

Graceful shutdown

Quando eviction é permitida, o Pod recebe SIGTERM. A aplicação Node.js deve parar de aceitar tráfego, concluir requisições e fechar recursos. Veja Graceful Shutdown no Node.js.

Termination grace period

terminationGracePeriodSeconds: 30

O valor deve ser maior que o tempo de draining e menor que o tolerável para manutenção. Requisições maiores precisam de desenho assíncrono ou timeouts menores.

preStop

lifecycle:
  preStop:
    exec:
      command: ["sh", "-c", "sleep 5"]

A espera ajuda a propagar remoção de endpoints, mas faz parte do mesmo período de terminação.

Helm

Valores:

podDisruptionBudget:
  enabled: true
  maxUnavailable: 1
  unhealthyPodEvictionPolicy: AlwaysAllow

Template deve exigir apenas um entre min e max. Consulte Helm para Node.js.

Kustomize

A base pode conter um PDB seguro e overlays ajustar percentuais por ambiente. Renderize todos os overlays no CI. Veja Kustomize para Node.js.

Observabilidade

Monitore:

• disruptionsAllowed;
• PDBs sem Pods selecionados;
• drains bloqueados;
• Pods não Ready;
• réplicas Pending;
• capacidade durante manutenção;
• nós não removíveis pelo autoscaler;
• tempo de graceful shutdown.

Alertas

Evite alertar apenas porque disruptionsAllowed é zero durante alguns segundos. Alerte quando permanece zero por muito tempo, existe manutenção planejada ou o workload já está abaixo do budget.

Teste em homologação

1. gere tráfego;
2. confirme todas as réplicas Ready;
3. execute drain;
4. observe eviction permitida;
5. meça erros e latência;
6. confirme novo Pod em outro nó;
7. verifique conclusão do drain;
8. teste com um Pod não saudável.

Erros comuns

• Uma réplica com maxUnavailable zero: manutenção fica bloqueada.
• Selector vazio: o budget pode selecionar o namespace inteiro.
• Readiness incorreta: Pods inúteis contam como saudáveis.
• Percentual sem calcular rounding: mais Pods são interrompidos que o esperado.
• Sem distribuição: falha de nó derruba todas as réplicas.
• PDB para Job: eviction é bloqueada sem preservar serviço.
• Ignorar capacidade: réplicas restantes saturam.
• Confundir com proteção contra falha: interrupções involuntárias continuam possíveis.

Conclusão

O PodDisruptionBudget no Node.js limita evictions voluntárias durante manutenção do cluster. maxUnavailable e minAvailable definem quantos Pods Ready precisam permanecer.

Use múltiplas réplicas, readiness correta e distribuição entre nós. Teste drain, HPA e Pods não saudáveis, sem criar budgets que impedem qualquer operação. Assim, o cluster consegue evoluir enquanto a aplicação mantém capacidade suficiente para atender usuários.