Drain on SIGTERM, and run two pods

Featurekamo-marketing
Shipped
4 Septemba 2026, 20:39 UTC
Author
Kamo
Commit
f0edd01

Next handles SIGTERM with a bare process.exit(143), so every deploy severed whatever this pod had in flight — a form post, a server action, a streamed RSC payload, an upload. Invisible when a request lasted milliseconds; not invisible on a cluster that deploys on every push. scripts/standalone-entry.cjs wraps the standalone server: on SIGTERM it stops accepting, drops idle keep-alives at once so a pod with nothing in flight still exits in about a second, and lets running requests finish under a cap that sits below terminationGracePeriodSeconds. Ported from kamo-internal, which has run it in production for months. The wrapper starts server-nonce.js rather than server.js, through NEXT_SERVER_ENTRY — the CSP nonce server stays exactly where it was in the chain. 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.

All changes

Je, unaona nini kuhusu usafiri?

Kila moja ya hizi updates ardhi katika nafasi yako ya kazi moja kwa moja. Kuanza bure na kuangalia kukua wiki baada ya wiki.

Kuwa Huru MileleMtazamo wa bei