How would you run and autoscale Selenium Grid on Kubernetes?

Running Grid on Kubernetes is attractive because browser demand is bursty: zero at night, hundreds of sessions when CI fires. Kubernetes can supply capacity on demand, but only if the Grid exposes the right signal and the nodes are sized correctly.

Topology

Selenium Grid 4 can run as hub and nodes (the hub bundles router, distributor, session map, session queue and event bus) or fully distributed, with each component as its own Deployment. For most teams, hub plus browser nodes is simpler and sufficient; distributed mode helps at large scale or when you need to scale the router independently.

Browser nodes run as pods (Chrome, Firefox, Edge), each registering with the Grid over the event bus. Clients connect to the router or hub Service URL, exactly as they would to any remote Grid.

Deployment with Helm

The SeleniumHQ docker-selenium project publishes an official Helm chart that deploys the Grid components, browser nodes and, optionally, KEDA-based autoscaling and video recording.

helm repo add docker-selenium https://www.selenium.dev/docker-selenium
helm repo update
helm install selenium-grid docker-selenium/selenium-grid \
  --namespace grid --create-namespace \
  --set autoscaling.enabled=true

Values names change between chart versions, so check the chart’s values.yaml for the release you install rather than copying flags from old blog posts.

Autoscaling with KEDA

CPU-based Horizontal Pod Autoscaling is a poor fit: an idle browser node uses little CPU, and the real demand signal is sessions waiting in the queue. KEDA has a Selenium Grid scaler that queries the Grid’s GraphQL endpoint for queued and active sessions per browser, and scales node Deployments (ScaledObject) or creates one Job per session (ScaledJob). Scale-to-zero is possible, at the price of a cold-start delay when the first test arrives.

Practical settings:

• One session per node pod (SE_NODE_MAX_SESSIONS=1) and drain after one session (SE_DRAIN_AFTER_SESSION_COUNT=1) with the ScaledJob strategy, so every test gets a fresh browser and scale-down never kills a running session.
• Session request timeout on the queue long enough to cover pod scheduling and image pulls, otherwise tests fail with session-not-created during scale-up.
• Pre-pulled images or a node pool with images cached to reduce cold starts.

Resource sizing

Browsers need memory and shared memory. Set CPU and memory requests honestly (an under-requested Chrome pod gets throttled and tests time out) and mount a memory-backed emptyDir at /dev/shm, because the container default is small and Chrome crashes with it. Isolate Grid nodes on a dedicated node pool so they do not compete with the system under test.

Operating it

• Monitor queue length, time-in-queue, session duration and node startup time; queue time is the earliest sign that capacity is the bottleneck.
• Collect video or logs only on failure to keep storage cost down.
• Set cluster autoscaler limits so a runaway CI job cannot scale the cluster indefinitely.
• Compare total cost and effort with a managed cloud grid; owning the Grid is justified by scale, data residency or network access to internal environments.

What interviewers look for

• Correct Grid 4 component knowledge and how clients connect.
• Queue-based autoscaling with KEDA instead of CPU-based HPA, and the cold-start trade-off.
• Browser resource sizing, /dev/shm, fresh node per session, and operational monitoring.