- Shipped
- September 4, 2026 at 8:39 PM UTC
- Author
- Kamo
- Commit
- 2862548
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. /healthz is answered by nginx itself rather than proxied to the sidecar: readiness decides whether this pod leaves the Service, and routing it through the sidecar would pull the whole meet UI out of rotation for a sidecar hiccup even though nginx is still serving every page. 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. The sidecar's orgConfigCache is a read-through TTL cache, so a second pod means a second cache, not divergent state.