- Navios
- 4 de setembro de 2026 às 20:39 UTC
- Autor
- Kamo
- Enviar
- 4fdff18
Esta implantação não tinha nenhuma sonda de prontidão, então uma cápsula contada como Pronto no instante em que o seu recipiente processo iniciado. Com maxIndisponível 0 Kubernetes lê que como "o novo pod está servindo" e retira-se o antigo — enquanto o Next ainda está a inicializar e não ligou o seu porto. Pedidos desembarcados em um porto nada estava ouvindo em, que é de onde os 502s intermitentes em implantação vieram. /api/saúde responde apenas para esta cápsula e deliberadamente não toca nenhuma infra-estrutura: uma sonda de prontidão decide se este pod deixa o Serviço, e fiação para uma infra- estrutura transforma um blip de infra- estrutura em uma A reiniciar cada cápsula aqui. O dreno e o período de graça 660 já estavam aqui; a sonda em falta foi o que os deteve Contagem. Kubernetes estava a retirar a cápsula de drenagem antes da substituição poder servir. réplicas 1 -> 2. O estado do servidor vive em Redis, não no pod, e não há trabalho agendado para duplicar, então uma segunda réplica não muda nada exceto que perder uma cápsula deixa de ser uma falha. Em uma réplica uma morte OOM, uma sonda de vida falhada ou um dreno de nó levou tudo para baixo para O tempo que for preciso para arrancar. topologiaSpreadConstraints (adicionado mais cedo, inerte até agora) manter os dois em nós diferentes onde o cluster pode gerenciá-lo, e um PodDisruptionBudget no KlusterServices faz um dreno esperar.