[Bug] Problemas com o Liveness Probes / Retorno de requsição com erro

Bom dia Sheila, esse tipo de cenário costuma ser menos “comando desatualizado” e mais configuração desalinhada entre app, probe e rede. Vamos organizar isso com calma.

Primeiro ponto importante: se ao comentar a livenessProbe os pods ficam verdes e a aplicação volta a responder, é um sinal forte de que a probe está reiniciando o container, não necessariamente que o Kubernetes mudou algo “moderno”. A API de httpGet e tcpSocket não sofreu mudança recente que quebre comportamento básico.

Agora vamos por partes.

Se você trocou de httpGet para tcpSocket e o pod fica verde mas a requisição continua dando timeout (inclusive no Insomnia), isso indica que:

• O container está de pé (porta aberta → tcpSocket passa).
• Mas a aplicação pode não estar respondendo corretamente na rota que você está chamando.
• Ou o problema não é a probe, e sim rede (Service, porta, Istio, etc).

Sobre a livenessProbe:

Com httpGet, você precisa garantir:

• path realmente existe (ex: /health, /actuator/health, /)
• port é a porta interna do container, não do Service
• A aplicação responde rápido o suficiente para não estourar timeoutSeconds
• Se sua API exige autenticação, a probe não pode bater numa rota protegida

Se sua aplicação demora para subir, você deveria usar também:

• initialDelaySeconds
• failureThreshold
• periodSeconds

Sem isso, o Kubernetes pode começar a testar antes da aplicação estar pronta e entrar em ciclo de restart.

Exemplo típico que evita dor de cabeça:

livenessProbe:
  httpGet:
    path: /health
    port: 3000
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 2
  failureThreshold: 3

Agora sobre o erro 201 que você mencionou.

Liveness probe não espera 201. Ela espera qualquer código 200–399. Se você está testando uma rota de criação (POST) e esperando 201, isso é outro fluxo não tem relação direta com a probe.

Se no capítulo de backup o teste de requisição está dando timeout, pode ser:

1. Service apontando para porta errada.
2. TargetPort diferente da porta real do container.
3. Istio interferindo.

Sobre Istio: sim, pode influenciar. Se estiver usando sidecar injection:

• A probe HTTP pode estar sendo interceptada.
• Em alguns casos é necessário configurar rewriteAppHTTPProbers: true na annotation do pod.

Exemplo:

metadata:
  annotations:
    sidecar.istio.io/rewriteAppHTTPProbers: "true"

Se estiver com Istio habilitado e não configurar isso, a probe pode falhar mesmo com app saudável.

Eu faria essa sequência de diagnóstico:

1. kubectl describe pod <nome> → veja eventos. Está reiniciando? Por quê?
2. kubectl logs <pod> → a aplicação está crashando?
3. kubectl port-forward pod/<pod> 8080:3000 e testa localmente.
4. Confere se o Service está mapeando corretamente port e targetPort.
5. Se tiver Istio, verifica se há sidecar no pod (kubectl get pod -o wide).

Resumo honesto: não parece mudança “moderna” de livenessProbe. Parece desalinhamento entre rota/porta/probe ou interferência de mesh.

Se você quiser, me manda:

• Seu trecho de Deployment (parte das probes)
• Porta que sua aplicação sobe
• Trecho do Service
• Se está usando Istio ou não

A gente desmonta isso passo a passo e resolve.

Olá, tem as seguintes questões, você escreveu: """Esse tipo de cenário costuma ser menos “comando desatualizado” e mais configuração desalinhada entre app, probe e rede."""

Pode ser, mas para eu colocar tudo funcionando eu precisei não seguir os comandos das aulas. Acaso alguém siga as aulas á risca encontrará dificuldades e isso torna código aberto a divergências por estar diferente e ter incompatibilidades como as que encontrei para Istio Ingress Gateway e Mysql Database. Algumas coisas não rodam copiando os códigos yaml dados na transcrição das aulas, elas precisam ser modificadas.

você escreveu: """Primeiro ponto importante: se ao comentar a livenessProbe os pods ficam verdes e a aplicação volta a responder, é um sinal forte de que a probe está reiniciando o container, não necessariamente que o Kubernetes mudou algo “moderno”."""

Pode ser mas já tentei vários códigos (liveness probe) e não tive sucesso com nenhum, o fornecido na aula não faz nada rodar, então imaginei que estivesse desatualizado.

vou testar o que você escreveu: """Ou o problema não é a probe, e sim rede (Service, porta, Istio, etc)."""

vou testar esse código que você sugeriu:

livenessProbe:
httpGet:
path: /health
port: 3000
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 2
failureThreshold: 3

Você escreveu: """Agora sobre o erro 201 que você mencionou. Liveness probe não espera 201. Ela espera qualquer código 200–399. Se você está testando uma rota de criação (POST) e esperando 201"""

Em verdade eu escrevi errado no post * , o retorno deveria ser 200 com o GET para /pacientes, mas esse retorno que não ocorre.

Vou testar suas sugestões acima, gostaria de lhe agradecer,

Obrigada!

Olá, testei a sugestão e o que estava ocorrendo era problema no livenessProbe, o que você deu está correto e tudo roda, também alterei o mysql.yaml (coloquei standard), agora tudo ok!

volumeClaimTemplates:

• metadata:
  name: mysql-storage
  spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: standard
  resources:
  requests:
  storage: 8Gi

Acontece que paciente é a única rota aberta para teste (sem autenticações) e está vazio, e ao fazer get, retorna 404 not found e uma mensagem. O LivenessProbe exige entre 200-399, então os pods ficam reiniciando sem parar até crashar. Passei algumas horas tentando descobrir o porquê de não funcionar, até que encontrei.