APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
As probes Kubernetes têm finalidades distintas. Readiness indica se o container está pronto para receber tráfego dos Services correspondentes; falhar não é, por si, uma ordem para reiniciar. Liveness pode causar restart quando a falha ultrapassa a tolerância configurada. Uma startup probe permite tratar inicialização demorada e impede liveness e readiness até ter sucesso. Confirma tempos e condições apropriados ao processo. Uma aplicação que precisa de dois minutos para carregar dados não deve ser reiniciada repetidamente antes de terminar esse trabalho. Tornar liveness muito lenta durante toda a vida do container pode esconder deadlocks posteriores; separar o arranque permite preservar deteção útil em operação.
Aplicação guiada
Num exemplo fictício, todas as réplicas dependem de um backend lento. Uma liveness que falha por essa dependência reinicia réplicas saudáveis, reduz capacidade e aumenta carga nas restantes. Retrying indiscriminado agrava o ciclo. Define erros elegíveis, limites e backoff com jitter, e observa retries já feitos por outras camadas. Se três camadas fazem três tentativas totais cada e todas falham, o modelo pode produzir 27 chamadas à dependência final. Para operações que alteram dados, timeout não prova ausência de efeito: valida idempotência ou reconcilia o resultado. Jitter distribui tentativas no tempo mas não elimina duplicações de negócio. A recuperação deve ser medida em resultados sustentados do serviço, não apenas numa probe que passou uma vez.
Três camadas com três tentativas totais podem amplificar um pedido para 3 × 3 × 3 = 27.
Armadilhas comuns
Readiness como restart; liveness dependente de qualquer atraso; retries ilimitados; jitter como idempotência.
Tópicos relacionados: Objetivos e impacto no serviço · Domínios de falha e capacidade residual · Quorum e isolamento de escritores
Separa prontidão e recuperação e limita a carga adicional durante falhas.
Referência: Kubernetes startup, readiness and liveness probes · DR HA 2026-09; Pacemaker 3.0, etcd 3.6, PostgreSQL 18 and selected Kubernetes/AWS behavior