advanced 2 min answer

A platform must decide between one large cluster and many small ones. What are the trade-offs?

browserstackclustersisolationefficiencyblast-radius
Show the full answer Hide the answer

One large cluster

Buys: higher utilisation through bin-packing, one thing to operate and upgrade, simpler networking, and easier resource sharing between workloads with complementary profiles.

Costs: a single failure domain, a single upgrade blast radius, control-plane scaling limits, and noisy neighbours that must be managed through quotas rather than through separation.

Many small clusters

Buys: blast-radius containment — an upgrade, a misconfiguration or a control-plane failure affects one cluster — plus per-cluster tuning for different workload classes, and independent upgrade cadences.

Costs: lower utilisation, since each cluster needs headroom · operational surface multiplied by cluster count, which is the dominant cost and grows linearly · cross-cluster networking and service discovery complexity · and fragmentation, where capacity exists in the wrong cluster.

What usually decides it

The failure history and the workload heterogeneity. An organisation whose outages come from upgrades and configuration benefits enormously from separation; one whose workloads are homogeneous and whose failures are elsewhere does not.

And whether cluster creation and configuration is automated. Many clusters is unmanageable without it and straightforward with it — which makes the automation the actual prerequisite decision.

The middle position that is usually right

Clusters per workload class and per environment, not per team. Request-serving, batch, builds and anything untrusted have genuinely different characteristics — resource profiles, security requirements, upgrade tolerance — and separating them is justified on those grounds rather than on organisational ones.

Separating by team produces many clusters with the same characteristics, which is operational cost with no isolation benefit that quotas could not provide.

The specific case for untrusted workloads

Customer code must not share a kernel with the control plane or with other customers' work where the isolation guarantee matters. That argues for separate clusters or stronger isolation primitives regardless of the efficiency cost, and it is one of the few cases where the decision is not a trade-off.