- Shipped
- 4 de setembro de 2026 às 20:39 UTC
- Author
- Kamo
- Commit
- 7ea8f7f
Em seguida, lida com o SIGTERM com um process.exit nu(143), então cada implantação cortou o que quer que este pod tinha em vôo — uma postagem de formulário, uma ação do servidor, uma carga útil RSC transmitida, um upload. Invisível quando uma a requisição durou milissegundos; não invisível em um cluster que é implantado em cada push. scripts/standalone-entry.cjs envolve o servidor standalone: no SIGTERM ele pára de aceitar, deixa inativo manter-vivos de uma vez para que uma cápsula sem nada em vôo ainda sai em cerca de um segundo, e vamos correr Os pedidos terminam sob uma tampa que fica abaixo da terminaçãoGracePeriodSeconds. Portados de Kamo-internal, que a tem executado em produção há meses. 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. Já em duas réplicas; isto é o que faz o segundo realmente cobrir o primeiro durante um rollout em vez de ambos serem substituídos cegos.