Documentation
¶
Overview ¶
Command sandbox-sdk-loadgen measures the REAL create latency of the writable L3 aggregated apiserver by creating agents.x-k8s.io Sandboxes through a single persistent typed client — the same path the official agent-sandbox Go client uses. Unlike `kubectl create` in a loop (which re-runs discovery/OpenAPI on every invocation and inflated p50 to ~12s), the client here builds its RESTMapper once, so the histogram reflects the apiserver round-trip (warm claim), not client bootstrap cost.
Safety properties (hard, by construction):
- EXACTLY --total creates are issued, then the run stops. --total is REQUIRED and positive; there is no unbounded mode.
- With --cleanup (default true), each worker BLOCKS until its sandbox's release is confirmed before creating the next one, so live claims never exceed --concurrency. A delete that returns NotFound is NOT success — it means the read view has not published the object yet (vk lag, ~10s); the worker retries until the delete lands or --release-timeout expires, and an expiry is counted in sandbox_sdk_leaked_total and logged loudly.
Cycle mode (--wave-size > 0) replaces the single bounded run with a soak cycle: create --wave-size sandboxes at --concurrency, pause --wave-pause, repeat until --target creates have been issued this cycle; then delete every sandbox this loadgen owns (its namespace + name prefix) at --delete-concurrency with the same confirm-or-leak release semantics; then (with --loop) start the next cycle. Live claims stay bounded by --target: waves never issue past it and the delete phase empties the namespace before the next cycle begins.
Source Files