- Shipped
- September 4, 2026 at 7:50 PM UTC
- Author
- Kamo
- Commit
- fdf6231
Deploys replaced the only pod of each service with nothing to catch the requests in flight. Three settings, applied across the fleet: - preStop sleeps 10s before the process sees SIGTERM. Kubernetes removes the pod from its EndpointSlice and signals it at the same moment, and Traefik only learns of the removal by watch — so for a moment it keeps dispatching new requests into a pod that has already begun refusing them. That gap is where the 502s on an otherwise clean rollout came from. - terminationGracePeriodSeconds raised above the preStop sleep, so the hook is not itself SIGKILLed, and in-flight work has room to finish. It is a ceiling, not a wait: an idle pod still exits in about a second. - minReadySeconds 15, so a pod that passes readiness once and then falls over cannot retire the healthy pod it replaced after CI has already called the rollout good. topologySpreadConstraints are added ready for a second replica; they are inert at one. Audited from the live cluster: 63 of 65 deployments in `kamo` ran a single replica, 1 of 65 had a preStop hook, and none had minReadySeconds. Graceful shutdown's own window **************** went from 5s to 30s in the ConfigMap. That inner limit was the binding one: no matter how generous the pod's grace period, Spring stopped waiting after five seconds and dropped whatever was still running. The ConfigMap is what runs — it is mounted over the image's application.yml as SPRING_CONFIG_LOCATION, a full replacement rather than an overlay.