- Spegnimento
- 4 settembre 2026 alle ore 19:50 UTC
- Autore
- Kamo
- Impegno
- aefbb92
Deploys ha sostituito l'unico pod di ogni servizio con nulla per catturare le richieste in volo. Tre impostazioni, applicate attraverso la flotta: - preStop dorme 10s prima che il processo veda SIGTERM. Kubernetes rimuove il baccello dal suo EndpointSlice e lo segnala allo stesso momento, e Traefik impara solo della rimozione da guardare — così per un momento continua a inviare nuove richieste in una capsula che è già iniziata rifiutandoli. Quel divario è da dove sono arrivati i 502 su un rollout altrimenti pulito. - terminazioneGracePeriodSeconds sollevato sopra il sonno preStop, quindi il gancio non è di per sé SIGKILLed, e il lavoro in volo ha spazio per finire. È un soffitto, non un'attesa: un baccello inattivo esce ancora tra circa un secondo. - minReadySeconds 15, quindi un baccello che passa la prontezza una volta e poi cade sopra non può ritirare il pod sano sostituito dopo CI ha già chiamato il rollout buono. topologySpreadConstraints sono aggiunti pronti per una seconda replica; sono inerti ad uno. Audited dal cluster live: 63 di 65 distribuzioni in `kamo` ha eseguito una singola replica, 1 di 65 aveva un gancio preStop, e nessuno aveva minReadySeconds. MediaService spedito con `strategy: Recreate` ad una replica con un periodo di grazia di 5s, così ogni dispiegare cancellato il pod servire chat, allegati, chat e notifica WebSockets, presenza e spingere, e solo allora ha iniziato la sostituzione — i cui propri registri hanno messo il suo boot a 59 secondi. Che cosa? è una finestra ~65s in cui il servizio non esisteva, e un caricamento sul filo è stato sequestrato al Punto 5. Un membro ha perso un documento di caricamento esattamente in questo. Non c'è PersistentVolumeClaim qui e mai stato — i volumi sono un ConfigMap, due Segreti e due Dirs vuoti — così niente mai richiesto Recreate. E' stato lasciato qui. RollingUpdate con maxUndisponibile 0 / maxSurge 1; grazia 660s per abbinare kamo-internal, che trasporta gli stessi 3 allegati GiB; Non e' vero. 5s -> 600s, che era il limitare effettivamente tagliare i caricamenti off; il timeout rollout di CI sollevato a 900s per sedersi sopra la grazia. repliche rimane a 1: MediaService non può ancora servire due pod correttamente. Il suo broker STOMP è in-heap e la sua per-conversazione JetStream consumatore è un esclusivo durevole chiamato dopo GUID sessione, quindi un secondo pod non riceverà silenziosamente nulla per le conversazioni il primo pod legato. Questo è fissato separatamente, prima che il conteggio replica si muova.