KamoCRM

Drain on SIGTERM, and run two pods

Featurekamo-marketing
Ya
4 Septemba 2026, 20:39 UTC
Mwandishi
Kamo
Ahadi ya
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.

Mabadiliko yote

Je, unaona nini kuhusu usafiri?

Kila kitu kinaingia kwenye tovuti yako mwenyewe. Anza kwenye mpango wa bure na usome ukurasa huu tena katika mwezi mmoja.

Kuwa Huru MileleMtazamo wa bei