Conceito e mecanismo
As probes respondem a perguntas diferentes. Startup acompanha inicialização; enquanto não tiver sucesso, adia liveness e readiness. Liveness identifica condições em que reiniciar pode ajudar, como um processo preso. Readiness indica capacidade de receber tráfego e pode retirar um Pod dos endpoints do serviço sem pedir reinício por esse motivo. Uma indisponibilidade comum da base de dados não implica que todos os processos tenham de ser reiniciados. Se liveness depende dessa base, a falha pode provocar ciclos de arranque e aumentar a carga precisamente quando a dependência está degradada. Escolhe critérios observáveis e leves, com tolerância adequada ao comportamento medido. Um Pod ativo não demonstra, por si só, prontidão funcional.
Aplicação guiada
Num batch fictício, a aplicação demora 90 segundos a inicializar e precisa de deteção rápida depois de arrancar. Uma startup probe pode dar a margem medida sem tornar a liveness lenta durante todo o ciclo de vida. Para HPA, distingue valores absolutos, percentagem de utilização e métricas externas. Um alvo de percentagem de CPU usa requests como denominador; confirma a configuração efetiva de cada container e disponibilidade das métricas. A escala calculada precisa de capacidade nas dependências. Trinta Pods com pools de quinze podem pedir 450 ligações, acima de 300 disponíveis. Coordena pools, admissão, backpressure e limites, preservando margem para outros consumidores. Mais réplicas não corrigem uma fuga de ligações nem uma base sem capacidade.
Um denominador em falta não é utilização zero; é informação insuficiente para aquele cálculo.
Armadilhas comuns
Readiness como pausa de liveness; falha externa como deadlock; HPA como escala automática da base.
Tópicos relacionados: Estado, cache e fluxos assíncronos · Credenciais, segredos e acesso · Build, artefactos e proveniência
Mede a condição certa e protege o percurso completo quando escalas.
Referência: Kubernetes probes · Current linked guide; edition date unconfirmed (2026-09-30 inspection)