- Shipped
- September 4, 2026 at 8:39 PM UTC
- Author
- Kamo
- Commit
- 4fdff18
This deployment had no readiness probe, so a pod counted as Ready the instant its container process started. With maxUnavailable 0 Kubernetes reads that as "the new pod is serving" and retires the old one — while Next is still initialising and has not bound its port. Requests landed on a port nothing was listening on, which is where the intermittent 502s on deploy came from. /api/health answers only for this pod and deliberately touches no backend: a readiness probe decides whether this pod leaves the Service, and wiring it to a backend turns a backend blip into a rolling restart of every pod here. The drain and the 660s grace period were already here; the missing probe is what stopped them counting. Kubernetes was retiring the draining pod before the replacement could serve. replicas 1 -> 2. Server-side state lives in Redis, not in the pod, and there is no scheduled work to duplicate, so a second replica changes nothing except that losing one pod stops being an outage. At one replica an OOM kill, a failed liveness probe or a node drain took the whole thing down for as long as it takes to boot. topologySpreadConstraints (added earlier, inert until now) keep the two on different nodes where the cluster can manage it, and a PodDisruptionBudget in KlusterServices makes a drain wait.