DEPLOYMENT GATE · READINESS · DRAIN
Deployment fixture gate: account for every invocation
Route twenty requests across two workers, send SIGTERM to one, and check that every invocation either commits or is rejected in a way a client can retry.
Your experiment
Two workers with two slots each serve 20 requests that arrive every 2 s from 1 s to 39 s; W1 is signalled at 30 s. Start with the opening settings, then remove the cold start, lengthen the grace period, add a replacement worker and try routing without readiness.
Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, Speed changes the pace and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.
Event trace
Computed data
Final metrics
Deterministic drill in whole seconds, not an ADK runtime or a container platform. The router sees readiness and worker exit instantly and picks the least-loaded worker; a result commits only when its invocation finishes; SIGKILL ends every invocation still running. Health-check intervals, load-balancer connection draining, client retries and autoscaling are omitted.
Twenty requests, one signal, one ledger
Two workers, W1 and W2, start at 0 s with two invocation slots each. Twenty requests arrive every 2 s from 1 s to 39 s; each runs for the Invocation duration, 7 s by default, and commits its result only when it finishes. W1 receives SIGTERM at 30 s. The gate accepts the drill only if every request is accounted for: committed, or rejected with a retryable 503 within the allowance, and never failed or killed in flight. With the opening settings the ledger reads 15 committed, 4 rejected, 0 failed and 1 killed: GATE FAILS.
Cold start and readiness
With a Worker startup time of 4 s, requests #1 and #2 arrive before any worker is ready. Route only to ready workers turns them into 503 rejections that a client can retry. Clear it and the router sends them to workers that are still initializing: 2 requests fail with 500, which no allowance excuses. Set the startup time to 0 and both early requests run normally; the remaining rejections and the kill come from the shutdown.
Drain for long enough
With startup 0, W1 is running #13, which ends at 32 s, and #15, which ends at 36 s, when the signal arrives. With W1 handles SIGTERM checked, W1 stops admission and lets in-flight work finish, but a Grace period before SIGKILL of 5 s sends SIGKILL at 35 s and #15 is killed one second before it would commit. A grace period of 6 s or more lets it finish: 18 committed, 2 rejected, 0 killed. Clear W1 handles SIGTERM and W1 exits at the signal, killing both invocations. The grace period must cover the longest remaining invocation, so it has to grow with the duration: at 12 s even a 10 s grace period kills one.
Capacity while one worker drains
Once W1 stops admitting, W2 alone has two slots for a 7 s job arriving every 2 s, so #17 and #19 are rejected. Setting Allowed 503 rejections to 10% accepts those two, 10% of 20, and the gate passes with 18 committed; this control is tested with startup 0 and a 10 s grace period, because a kill fails the gate at any allowance. Boot replacement W3 at the signal restores capacity: with startup 0 and a 10 s grace period all 20 commit. With a 4 s startup W3 is ready only at 34 s and #17 is still rejected. Shorter 4 s invocations pass without a replacement.
Reading the run and its limits
Play, Next event, Restart, Speed and Inspection time step through the setup, routing decisions, the signal, the drain, any kill and the ledger across sixty inspection seconds; the table lists every request with its worker, end time and status. The drill uses whole seconds, a least-loaded router that sees readiness instantly, fixed invocation times and one signal. Real platforms add health-check intervals, connection draining at the load balancer, client retries and autoscaling, which are omitted here.