In docker-selenium's Helm chart, when is on-demand node scaling worth what it obliges you to run?

A container grid can be a fixed pool that somebody sized, or a pool that grows because something counted the work waiting. `docker-selenium`'s Helm chart supports both, and the interesting part of the question is not the switch but what the switch obliges you to own. ## What the chart actually ships The chart's `autoscaling.enabled` value defaults to **false**. A plain install is therefore a fixed set of node replicas that you chose; a queue that grows produces waiting, not nodes. Enabling autoscaling installs KEDA as part of the release, or `autoscaling.enableWithExistingKEDA` attaches to an installation you already operate — a distinction that matters the moment a platform team owns KEDA and does not want a test grid installing its own. ## Two scaling shapes, and the default is not the obvious one `autoscaling.scalingType` defaults to `job`. | | `scalingType: job` (default) | `scalingType: deployment` | |---|---|---| | KEDA object rendered | `ScaledJob` | `ScaledObject` | | What is scaled | Kubernetes Jobs | A node Deployment's replicas | | Lifetime of a node | Serves its work, then exits | Long-lived, reused | | Shutdown concern | The Job simply completes | Must be drained before termination | | Chart settings that apply | `scaledJobOptions` | `terminationGracePeriodSeconds`, `deregisterLifecycle` | The chart's `jobTargetRef` sets `parallelism: 1` and `completions: 1`, so a scaled unit in job mode is a Pod that does its work and finishes. That is the same disposable-per-session instinct a container grid has natively, expressed in Kubernetes objects. Deployment mode trades it for warm nodes that must be told to stop accepting work before they are killed, which is exactly what the grace period and the deregister lifecycle hook exist for. Note also that autoscaling and the drain-after-work setting solve adjacent problems: `SE_DRAIN_AFTER_SESSION_COUNT` detaches a node from the grid once it has served its allotted work, so a long-lived node can still be made replaceable. ## What enabling it obliges you to run - **A scaler, and its credentials.** Something has to read the grid's live state to know how much work is waiting, and it needs an address and, where the grid is protected, an authenticated way in. - **A metric that matches your grid.** The scaler's trigger metadata has to line up with the browser and platform the pool actually serves. Get it wrong and you scale the wrong pool, or nothing at all, while the queue looks perfectly healthy from the outside. - **Correct counting of work in progress.** The chart's own documentation records that combining a strategy which already deducts pending and running work with a metric that also counts ongoing sessions double-counts, and the result is unbounded node creation. A scaler that miscounts does not scale badly; it runs away. - **Cold start on the critical path.** A session arriving at an empty pool now waits for a Pod to be scheduled, an image to be present, and a node to register before anything happens. - **A blast radius in the cluster.** The grid can now consume cluster capacity in response to traffic, which makes it a neighbour of every other workload on those machines. ## When it is worth it Scale on demand when the load is **bursty and unpredictable** and idle capacity is genuinely wasted: a grid that sits untouched for most of the day and then absorbs a rush after a merge queue drains. Scale on demand when the peak is far above the median, because that is precisely the ratio a fixed pool has to pay for continuously. Keep the fixed pool when: - The load is a known nightly window of known width. You are not saving anything by discovering its size again every night. - Session start-up latency is already the dominant complaint. Adding a cold pool underneath it makes the worst case worse. - Nobody owns the cluster. An autoscaled grid is a running system with its own failure modes, and it needs someone whose job includes noticing them. - The grid is small enough that the whole pool costs less attention than the scaler would. ## How to decide, concretely 1. Measure the actual shape of demand over a fortnight — peak, median, and how long the peak lasts. 2. Price the fixed pool at the peak, and compare it with the median plus the operational cost of the scaler. 3. Decide whether cold start is acceptable for the slowest tolerable session, and set a floor of warm nodes if it is not. 4. Choose the scaling shape from how your nodes end: disposable work units, or long-lived nodes that must be drained. 5. Write down what happens when the scaler is wrong in both directions, because it will be. ## What an interviewer is listening for - That you know the chart ships autoscaling off, so "we use the chart" does not mean "we autoscale". - That growth is driven by counting waiting work, and that the counter is now a component you operate. - That you can argue for a fixed pool when the demand shape is known, instead of treating autoscaling as strictly better.