Kubernetes cluster consolidation: merging 20 clusters into 4 and what it saves

Quick answer

Every cluster carries fixed cost that does not shrink with workload: a control plane fee of about $73 per month, two to three nodes minimum for availability, a full set of system DaemonSets, and its own idle headroom. Consolidating 20 clusters into 4 typically removes $1,168 in control plane fees and 40 to 48 nodes of floor capacity, roughly $4,500 to $5,200 per month, plus better bin packing because workloads from different teams fill each other's gaps. Keep separate clusters only where you need a hard boundary: different compliance scope, different cloud region, different Kubernetes version cadence, or a blast radius you genuinely cannot share.

Nobody decides to run 20 Kubernetes clusters. It happens one reasonable request at a time: a team wants isolation, a project needs a different region, someone spins up a sandbox for a spike and it becomes load bearing. Two years later the fleet has 20 control planes, and nobody can say what the fleet costs as a fleet.

The fixed cost of existing

A cluster has a floor that has nothing to do with how much work it does.

Fixed item	Typical monthly cost	Why it is unavoidable
Control plane fee	$73	Charged per cluster-hour
Minimum 3 nodes for HA	$210 to $840	Quorum and zone spread
System DaemonSets	Included in node capacity	CNI, kube-proxy, agents per node
Ingress controller	$16 to $90	Its own load balancer
Monitoring and logging stack	$80 to $250	Collector, storage, retention
Idle headroom for burst	15 to 30 percent of nodes	Cannot share across clusters
Floor per cluster	$380 to $1,250

Twenty clusters at even the low end of that range is $7,600 per month, $91,200 per year, purely to exist. At the high end it is $25,000 per month. And the headroom line is the one people miss: each cluster keeps its own spare capacity for spikes, and that spare capacity cannot be lent to another cluster.

A worked consolidation

Take a fleet of 20 clusters: 8 team production clusters, 8 team staging clusters, 2 shared platform clusters, and 2 abandoned proof-of-concept clusters nobody deleted. Target topology: 4 clusters, one production per region pair and one shared non-production per region pair.

Line	Before, 20 clusters	After, 4 clusters	Saved
Control plane fees	$1,460	$292	$1,168
HA node floor	60 nodes, $16,800	12 nodes, $3,360	$13,440
Ingress load balancers	$440	$88	$352
Observability stacks	$2,400	$600	$1,800
Workload capacity	$22,000	$17,600	$4,400
Total	$43,100	$21,940	$21,160

The workload capacity line drops by 20 percent not because less work happens but because pooled headroom is smaller than the sum of separate headrooms, and becausebin packing improves when more pod shapes compete for the same nodes. Statistical multiplexing is the whole argument: 8 teams each keeping 25 percent spare need far less spare in total when they share.

What replaces cluster boundaries

Was provided by a separate cluster	Provided instead by
Resource isolation	ResourceQuota and LimitRange per namespace
Access isolation	RBAC scoped to namespace
Network isolation	NetworkPolicy, default deny
Cost attribution	Namespace labels and per-namespace reporting
Node isolation for noisy workloads	Taints, tolerations, dedicated node pools
Blast radius for deploys	PodDisruptionBudgets and progressive rollout

Namespaces are a softer boundary than a cluster, and that is the honest tradeoff. A cluster-wide incident, an API server outage, a bad CRD, a failed upgrade, now affects 8 teams instead of 1. That risk is real and it is why consolidation usually stops at 3 to 6 clusters rather than 1.

When to keep a cluster separate

Keep separate clusters for genuine compliance scope separation, where an auditor needs a hard boundary; for different regions, since a cluster cannot span them; for workloads that must run a different Kubernetes version or upgrade cadence; and for anything where a shared control plane failure would be unacceptable, such as a disaster recovery environment. Everything else is usually a namespace.

How to actually do it

Start with the clusters that cost the most and do the least: the abandoned proof of concept, the staging cluster for a deprecated service, the second cluster someone created because the first was full. Those deletions are free savings with no migration.

Then merge non-production first, because it is lower risk and it is where sprawl is worst. Stand up the target cluster with quotas, RBAC, and network policies already configured, migrate one team at a time, and delete the source cluster only after a full sprint of quiet. Production consolidation comes last and should be done region by region.

Track the number as you go. Cluster definitions live in Terraform, so removing a cluster module is a priceable change. Price the fleet against the resource catalog and each consolidation pull request carries its own savings figure, which is how a six-month platform project keeps its budget. Pair it withper-namespace cost reporting so teams still see their own spend after the merge.

FAQ

How much does Kubernetes cluster consolidation save?

Typically 40 to 55 percent of total fleet cost. A worked example merging 20 clusters into 4 saved $1,168 in control plane fees, $13,440 in HA node floors as 60 minimum nodes became 12, $1,800 in duplicated observability stacks, and $4,400 in workload capacity from better packing and pooled headroom, about $21,160 per month in total.

What is the fixed cost of running a Kubernetes cluster?

Roughly $380 to $1,250 per month before any workload: a $73 control plane fee, two to three nodes for high availability at $210 to $840, an ingress controller with its own load balancer at $16 to $90, a monitoring and logging stack at $80 to $250, and 15 to 30 percent idle headroom that cannot be shared with another cluster.

Why does consolidating clusters improve utilization?

Because headroom pools. Eight teams each keeping 25 percent spare capacity in separate clusters need far less spare in total when they share one, since their spikes rarely coincide. Packing also improves when more pod shapes compete for the same nodes, so fewer nodes sit half full. In practice workload capacity drops 15 to 25 percent for identical work.

When should I keep separate Kubernetes clusters?

Keep separate clusters for genuine compliance scope separation where an auditor needs a hard boundary, for different cloud regions since a cluster cannot span them, for workloads that require a different Kubernetes version or upgrade cadence, and for disaster recovery environments where a shared control plane failure would be unacceptable. Everything else is usually a namespace.

What replaces cluster isolation after consolidation?

ResourceQuota and LimitRange handle resource isolation, RBAC scoped to namespaces handles access, default-deny NetworkPolicy handles network isolation, namespace labels handle cost attribution, and taints with dedicated node pools isolate noisy workloads. The honest tradeoff is blast radius: a control plane incident now affects every team on the cluster, which is why consolidation usually stops at 3 to 6 clusters.

How does C3X help with cluster consolidation?

Cluster and node group definitions live in Terraform, so removing a cluster module is a priceable change. C3X prices the fleet against a live catalog, so each consolidation pull request carries its own monthly savings figure. That keeps a multi-month platform project accountable to a number rather than an assumption that merging must be cheaper.

What to do next

Put a number on every cluster you retire. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.