Importante

Você está vendo a versão anterior da nova experiência da Alura que estamos preparando para você. Em breve, ela ganha uma identidade visual novinha totalmente pensada em potencializar seus estudos!

1
resposta

[Dúvida] O mistério do livenessProbe

Após aplicar o conceito explicado nesta aula, o meu cluster começou a se comportar de forma errônea. Após investigar o que estaria dando errado no meu .yaml, e não encontrar nada, fui investigar os logs e descobri que estava dando 404 ao tentar bater na rota /paciente, coisa que a aula fala pra fazer. Ao investigar mais, descobri que a rota existe, mas retorna uma mensagem "Não encontramos pacientes!" e um 404, como se a página não tivesse sido encontrada. Aí aprendi que o Kubernetes não lida bem com esse código de erro e começa a reiniciar a aplicação.

A minha dúvida é se o erro está aí de propósito pra que eu descubra ou se foi mesmo uma falha na hora de testar todo o contexto da aula, visto que dá pau em uma coisa que não está diretamente relacionado com o assunto em si, mas sim com a aplicação exemplo.

Espero ter conseguido me expressar. Obrigado!

1 resposta

Olá, Eduardo! Tudo certo?

Que bom que você foi fundo na investigação! Entender o comportamento do livenessProbe é exatamente o tipo de aprendizado que consolida o conceito explicado nesta aula. O que você descobriu faz todo sentido dentro da lógica do Kubernetes.

O comportamento que você está observando no cluster é esperado: quando o livenessProbe tenta bater na rota /paciente e recebe um 404 como resposta, o Kubernetes interpreta isso como sinal de que a aplicação não está saudável e inicia o ciclo de reinicialização do container. O detalhe importante aqui é que o livenessProbe considera apenas códigos HTTP entre 200 e 399 como indicadores de saúde. Qualquer coisa fora dessa faixa, incluindo o 404 que a aplicação está retornando, aciona o mecanismo de restart.

Para resolver essa situação, você pode considerar algumas abordagens práticas:

Ajustar a rota ou o código de resposta: verifique se a rota /paciente deveria mesmo retornar 404 quando não há pacientes cadastrados. Uma alternativa mais adequada seria retornar 200 com uma lista vazia, por exemplo. Isso resolveria o erro sem alterar a lógica central da aplicação.

Modificar o livenessProbe: se não for possível alterar a aplicação, configure o livenessProbe para verificar uma rota diferente que sempre retorne 200, como uma rota de health check dedicada.

Utilizar o readinessProbe: se a rota /paciente não é crítica para determinar se o container está vivo, o readinessProbe pode ser uma opção mais adequada. Ele não provoca reinicializações, apenas retira o pod do serviço temporariamente até que esteja pronto para receber tráfego.

Sobre a sua dúvida específica: tudo indica que se trata de uma inconsistência na aplicação de exemplo, e não um erro proposital do exercício. Mesmo assim, o resultado foi valioso, pois você investigou os logs, identificou o problema e aprendeu como o Kubernetes reage a esse tipo de situação.

Você já tentou criar uma rota de health check separada na sua aplicação para usar como base do livenessProbe?

Alura Conte com o apoio da comunidade Alura na sua jornada. Abraços e bons estudos!