Probes e orçamento de partida

Uma JVM não responde no primeiro segundo. O chart trata isso com três probes em sequência, e o orçamento é o que decide se o pod é reiniciado ou apenas esperado.

As três probes

          startupProbe:
            httpGet: {path: /live, port: 8080}
            periodSeconds: 2
            timeoutSeconds: 2
            failureThreshold: 60
          livenessProbe:
            httpGet: {path: /live, port: 8080}
            periodSeconds: 10
            timeoutSeconds: 2
            failureThreshold: 3
          readinessProbe:
            httpGet: {path: /ready, port: 8080}
            periodSeconds: 5
            timeoutSeconds: 3
            failureThreshold: 3

probe	caminho	período	prazo	tentativas	o que significa
startupProbe	/live	2 s	2 s	60	a JVM está subindo; enquanto ela não passa, liveness e readiness não valem
livenessProbe	/live	10 s	2 s	3	o processo está vivo; falhar reinicia o container
readinessProbe	/ready	5 s	3 s	3	o pod pode receber tráfego

O orçamento de partida é 120 s (60 × 2 s). É folgado de propósito: uma partida medida com 1 CPU fica entre 7,4 s e 8,1 s, e o pod fica Ready em 11 s — mas sob throttling de CPU a partida passa dos 30 s que a liveness toleraria, e sem a startupProbe o pod entraria em laço de reinício. Não reduza o failureThreshold da startup pensando no caso feliz.

/live e /ready ficam na porta de serviço (8080), não na de management. Eles nunca passam pelo gateway: quem os chama é o kubelet, pela NetworkPolicy do pod.

O que cada um responde

• /live responde se o processo está vivo. Não olha dependência.
• /ready responde se o pod pode servir. Um check do /ready é um HealthIndicator comum, declarado como bean — o nome do bean é o nome do check. Os checks rodam em paralelo, 2 s cada. Um check que não termina no prazo deixa o pod unready.

NnsHealth.degraded(msg) e NnsHealth.unavailable(msg) levam a mensagem ao corpo da resposta — use quando o operador precisa saber o que está degradado, não só que está.

Regra dura do /ready: só dependência LOCAL. Banco fora do ar, ou schema em versão diferente da esperada, deixa o pod unready; dependência remota fora do ar não derruba o pod. O SDK já traz os checks db e schema quando o serviço declara banco.

Um efeito conhecido e aceito: o /ready sob carga direta estoura o prazo dos checks. Ele é alcançável só pelos probes (a NetworkPolicy não abre a 8080 para o resto do cluster) — não conte com ele como endpoint de diagnóstico público.

Em quanto tempo o pod fica pronto, na prática

momento	valor medido
partida da JVM (1 CPU, 768 Mi)	7,4–8,1 s
pod Ready	11 s
teto que a startupProbe dá	120 s
orçamento total de desligamento	30 s (terminationGracePeriodSeconds)

Os números são do laboratório com o módulo demo (2026-10-06), com o limite de 768 Mi e BPL_JVM_THREAD_COUNT=100. Se você subir as threads ou a memória, ou se o nó estiver saturado, a partida muda — meça de novo antes de apertar a startupProbe.

Quando o pod é reiniciado

• startupProbe estourou os 120 s → o container é morto e reinicia. É o sinal de que a partida está presa (configuração inválida, espera de recurso na inicialização).
• livenessProbe falhou 3 vezes depois da partida → reinício. Uma aplicação que trava a thread de aceitação é reiniciada aqui.
• readinessProbe falhou → o pod sai do balanceamento, sem reinício. É o comportamento certo para banco fora do ar.

Configuração inválida não chega a virar laço de reinício: o NnsApplication confere as NN_* antes de o Spring subir, escreve a mensagem de contrato no stderr e termina com código 1.

Onde isso mora

As três probes estão no Deployment do chart, que você não escreve à mão: elas fazem parte do esqueleto gerado. Se você mexer, o gate confere o manifesto renderizado:

./nnconsolew chart check --values nns/helm/testdata/injected-values.yaml --namespace <ns> \
  --runtime jvm --runtime-user 1002 nns/helm/chart