How should compute clusters be structured for a platform running many teams' workloads with very different profiles?

The structure

Multiple clusters as isolation cells, with node pools by workload class inside each.

Why not one large cluster: the control plane is shared, so a misbehaving controller, an object explosion or a slow admission webhook degrades scheduling for every workload. Namespaces isolate naming and policy; they do not isolate the control plane. And a cluster upgrade becomes one event affecting everything.

Why not one cluster per team: operational cost per cluster is roughly constant and substantial, so the platform team's work scales with team count.

Cells sized to an acceptable blast radius, with traffic distributable across them, so losing one degrades a fraction of capacity and upgrades roll cell by cell with real traffic validating each step.

Inside a cluster

• Node pools by workload class, keeping latency-sensitive services off nodes running bursty batch work. This is bulkheading at the infrastructure layer and it is more reliable than tuning.
• Requests and limits mandatory, enforced by admission policy. A workload that does not declare its needs is one the scheduler cannot reason about, and it is the root of most noisy-neighbour incidents.
• Per-namespace quotas, so one team cannot occupy a cell.
• Priority classes with preemption, so a surge evicts batch work automatically rather than by human intervention.
• Disruption budgets, so upgrades and drains cannot take a service below its minimum availability.

The connection-heavy consideration

For workloads holding long-lived connections, the cluster design must account for the fact that draining a node disconnects its sessions. That makes routine operations — upgrades, rebalancing, node replacement — a reconnect event unless the application supports staggered draining and session resumption.

Capacity is also measured in connections rather than requests, so CPU-based autoscaling is the wrong signal and node sizing follows memory and file-descriptor limits.

The honest caveat

For a small organisation this is over-engineering. A single cluster with sensible limits is appropriate for a long time — the cell design earns its cost when the number of teams makes coordination expensive and a single failure domain becomes an unacceptable business risk.