Cluster Architecture

Definition

Cluster architecture decides how container workloads are grouped: one large cluster, many small ones, or something between, and where the boundaries fall.

The trade

Fewer, larger clusters give better bin-packing efficiency, less operational overhead, and simpler service discovery. They also mean a larger blast radius — a control-plane problem, a bad upgrade or a misconfigured admission policy affects everything.

More, smaller clusters give isolation, independent upgrade schedules and smaller blast radius, at the cost of duplicated overhead, harder cross-cluster networking and more to operate.

The boundaries that make sense

• Environment. Production separate from non-production, always. Sharing is how a test job takes down production.
• Region. Clusters do not span regions usefully; latency and partition behaviour make it a bad idea.
• Compliance boundary. Where a regulatory or residency requirement applies, a separate cluster makes the boundary demonstrable to an auditor rather than argued.
• Blast radius for critical workloads. A tier-one workload may justify its own cluster so nothing else can affect it.
• Team or tenant, only where isolation requirements genuinely demand it — namespace isolation with network policies and quotas is usually sufficient and far cheaper.

Multi-tenancy within a cluster

Namespaces are a naming boundary, not a security boundary. Isolating tenants within a cluster requires network policies (default deny, explicit allow), resource quotas and limit ranges, admission policy, separate service accounts with least privilege, and node pools where workload separation matters.

Whether that is sufficient depends on the threat model. For teams within one organisation, usually yes. For genuinely untrusted workloads, no — separate clusters, and possibly separate accounts.

The operational decisions that dominate

Upgrade strategy. Clusters must be upgraded regularly, and the version support window is short. A fleet of clusters needs an automated, tested upgrade path, or versions drift and fall out of support.

Address planning. Every pod consumes an IP address. A subnet sized for VM-era density exhausts at container density, and it presents as pods stuck pending rather than as an address problem.

Failure scenarios

• One cluster for everything, so a control-plane issue is a total outage.
• A cluster per team in an organisation that cannot operate the resulting fleet.
• Namespaces treated as a security boundary.
• No automated upgrade path, so clusters fall out of support.
• Address exhaustion, diagnosed as a capacity problem.

Interview question

"How many Kubernetes clusters should an organisation run, and what decides the boundaries?"