- Spegnimento
- 4 settembre 2026 alle ore 20:39 UTC
- Autore
- Kamo
- Impegno
- 2862548
Questa distribuzione non aveva sonda di prontezza, quindi un baccello ha contato come Ready l'istante il suo contenitore il processo è iniziato. Con maxUndisponibile 0 Kubernetes legge che come "il nuovo pod sta servendo" e ritira il vecchio — mentre Next sta ancora inizializzando e non ha limitato il suo porto. Richieste atterrate su un porto nulla stava ascoltando, che è dove gli intermittenti 502 su schiera provenivano. /api/health risponde solo per questo baccello e deliberatamente non tocca backend: una sonda di prontezza decide se questo baccello lascia il Servizio, e il cablaggio a un backend trasforma un blip backend in un riavviare ogni capsula qui. /healthz è risposto da nginx stesso piuttosto che proxied al sidecar: la disponibilità decide se questo baccello lascia il Servizio, e routing attraverso il sidecar avrebbe tirato l'intero incontro UI fuori rotazione per un singhiozzo sidecar anche se nginx sta ancora servendo ogni pagina. repliche 1 -> 2. Lo stato lato server vive in Redis, non nel pod, e non c'è lavoro programmato per duplicare, quindi una seconda replica non cambia nulla tranne che perdere un pod smette di essere un outage. In una replica un omicidio OOM, una sonda di liveness fallita o uno scarico del nodo hanno preso l'intera cosa per Finche' ci vorra' per iniziare. topologySpreadConstraints (aggiunto prima, inerte fino ad ora) tenere i due su nodi diversi dove il cluster può gestirlo, e un PodDisruptionBudget in KlusterServices fa un'attesa di scarico. Il sidecar's orgConfigCache è una cache TTL, quindi un secondo pod significa un seconda cache, non stato divergente.