Measured startup is 4m45s from cell creation to Ready, of which roughly 3 minutes is cloning the 30 GiB root disk. Demand to usable capacity is 6m14s end to end (the pool notices demand on its resync, up to requeueSteady = 2 min).
So the remaining latency is storage, not software — baking already cut this from ~14 minutes. Options worth measuring:
- a smaller root disk in the reference image (30 GiB is generous for a node that runs containers on an overlay)
- a copy-on-write clone strategy instead of
copy, where the storage class supports it
- shortening the demand-detection lag by watching inner pods rather than relying on the resync
At ~5 minutes this sits exactly on the line the design drew for itself: reactive autoscaling stays worthwhile, but a latency-sensitive pool should keep minReplicas above zero rather than scaling to zero. Halving it would change that advice.
Measured startup is 4m45s from cell creation to Ready, of which roughly 3 minutes is cloning the 30 GiB root disk. Demand to usable capacity is 6m14s end to end (the pool notices demand on its resync, up to
requeueSteady= 2 min).So the remaining latency is storage, not software — baking already cut this from ~14 minutes. Options worth measuring:
copy, where the storage class supports itAt ~5 minutes this sits exactly on the line the design drew for itself: reactive autoscaling stays worthwhile, but a latency-sensitive pool should keep
minReplicasabove zero rather than scaling to zero. Halving it would change that advice.