- Navios
- 4 de setembro de 2026 às 19:50 UTC
- Autor
- Kamo
- Enviar
- aefbb92
Implantes substituiu o único pod de cada serviço com nada para pegar os pedidos em Voo. Três configurações, aplicadas em toda a frota: - preStop dorme 10s antes do processo ver SIGTERM. Kubernetes remove a cápsula da sua EndpointSlice e sinaliza-o no mesmo momento, e Traefik só aprende da remoção por watch — assim, por um momento, continua a enviar novos pedidos para uma cápsula que já começou recusando-os. Essa lacuna é de onde vieram os 502s de um lançamento limpo. - rescisãoGracePeriodSegundos levantados acima do sono preStop, então o gancho não é em si O trabalho em voo tem espaço para terminar. É um teto, não uma espera: uma cápsula ociosa Ainda sai dentro de um segundo. - minReadySegundos 15, então uma cápsula que passa pronto uma vez e depois cai não pode aposentar o Pod saudável ele substituído depois de IC já chamou a implantação bom. topologiaSpreadConstraints são adicionados prontos para uma segunda réplica; eles são inertes em um. Auditado a partir do cluster ao vivo: 63 de 65 implantações em `kamo` executado uma única réplica, 1 de 65 tinha um gancho preStop, e nenhum tinha minReadySegundos. MediaService enviado com `estratégia: Recriar` em uma réplica com um período de graça 5s, então cada implante o pod que serve chat, anexos, o chat e notificação WebSockets, presença e empurrar, e só então começou a substituição — cujos próprios logs colocar sua inicialização em 59 segundos. Isso. é uma janela ~65s na qual o serviço não existia, e um upload no fio foi cortado no Ponto 5s. Um membro perdeu um documento para carregar exatamente isso. Não há PersistentVolumeClaim aqui e nunca foi — os volumes são um ConfigMap, dois Segredos e duas Dirs vazias — para que nada nunca precisou Recriar. Foi deixado para trás. RollingUpdate com maxIndisponível 0 / maxSurge 1; grace 660s to match kamo-internal, que carrega os mesmos 3 anexos GiB; **************************** 5s -> 600s, que foi o limite realmente corta uploads fora; IC's rollout timeout aumentado para 900s para sentar-se acima da graça. réplicas permanece em 1: MediaService não pode servir duas cápsulas corretamente ainda. Seu corretor STOMP é in-heap e sua per-conversation JetStream consumidor é um duráveis exclusivo nomeado em sessão GUID, para que um segundo pod não recebesse silenciosamente nada para conversas o primeiro pod Atado. Isso é corrigido separadamente, antes que a contagem de réplicas se mova.