- Navios
- 4 de setembro de 2026 às 20:39 UTC
- Autor
- Kamo
- Enviar
- 2862548
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. /healthz é respondido pelo nginx em vez de proxied ao sidecar: prontidão decide se Esta cápsula deixa o Serviço, e roteá-lo através do sidecar iria puxar toda a interface de encontro de rotação para um soluço sidecar mesmo que nginx ainda esteja servindo cada página. 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. O sidecar's orgConfigCache é um cache TTL lido, então um segundo pod significa Segundo cache, não estado divergente.