O que e uma readiness probe? Controlando o trafego ate estar pronto
Uma readiness probe e uma verificacao que o Kubernetes executa para decidir se um pod deve receber trafego - se ela falha, o pod e retirado do load balancer ate passar.
Um continer pode estar rodando, mas ainda nao pronto para servir - ainda aquecendo um cache, conectando a um banco de dados ou carregando config. Uma readiness probe captura essa distincao. O Kubernetes so roteia trafego para pods cuja readiness probe passa, o que e o que torna os rolling updates fluidos.
O que ela verifica
Voce define uma probe - uma requisicao HTTP, uma conexao TCP ou um comando - que o Kubernetes executa periodicamente. Sucesso significa "pronto para trafego"; falha remove o pod dos endpoints do seu Service ate que ele se recupere.
Readiness vs liveness
Uma readiness probe que falha interrompe o trafego, mas nao reinicia o pod. Uma liveness probe que falha reinicia o continer. A readiness diz "nao pronto agora mesmo"; a liveness diz "quebrado, reinicie-me".
Por que torna os deploys seguros
Durante um rolling update, novos pods sao mantidos fora da rotacao ate que sua readiness probe passe. Assim, os usuarios nunca sao roteados para um pod que nao terminou de iniciar - sem erros no meio do deploy.
Uma configuracao tipica
- Um HTTP GET em
/healthzretornando 200 quando pronto. - Um atraso inicial para que o app tenha tempo de iniciar.
- Um periodo e um limite de falhas ajustados ao app.
A conexao com CI/CD
Readiness probes sao o que permite que o CD implante uma nova imagem com zero downtime. A mesma ideia se aplica a service containers de CI: aguarde a prontidao antes de rodar os testes para evitar flakiness de connection-refused.
Principais conclusões
- Uma readiness probe decide se um pod deve receber trafego.
- Ela retira um pod nao pronto da rotacao sem reinicia-lo.
- Readiness probes sao o que torna os rolling deploys zero-downtime.