Qual é a diferença entre uma liveness probe e uma readiness probe, e como as pessoas erram nisso?

Uma readiness probe controla se um pod recebe tráfego; uma liveness probe controla se o kubelet reinicia o container. O erro clássico é apontar a liveness para uma dependência abaixo, então um banco lento reinicia todos os pods em loop e transforma uma queda parcial numa queda total. A liveness deveria checar só que o processo está vivo e não travado. Use uma startup probe para aplicações que sobem devagar.

Readiness decide se o pod está nos endpoints do serviço, liveness decide se o kubelet mata e reinicia o container. A falha que eu vi de verdade foi um time que fez o endpoint de liveness checar o banco de dados. O banco ficou lento, todos os pods falharam a liveness mais ou menos ao mesmo tempo, o deployment inteiro entrou em loop de reinício, e agora, em vez de leituras degradadas, a gente não tinha nada, mais uma manada de conexões frias quando voltou. A liveness deveria ser quase entediante: o processo consegue servir um handler trivial, o event loop não está travado. Qualquer coisa sobre dependências pertence à readiness, porque tirar um pod de rotação é reversível e barato. A outra coisa que eu sempre checo é o tempo. Se a aplicação leva 45 segundos para aquecer caches, ou você usa uma startup probe ou ajusta initialDelaySeconds e failureThreshold para bater com isso, senão você construiu uma máquina que nunca consegue terminar de subir.