Your platform team of five spends nearly all its capacity upgrading control planes across 38 Kubernetes clusters. How did this happen and how do you fix it?

How it happened

There is no split axis, only history. Clusters were created per project, per experiment, per team, per acquisition — each for a reason that was locally sensible — and none were retired. Creating a cluster is a self-service action; retiring one is a negotiation with whoever might still be using it.

The cost is quadratic in attention: every cluster needs control plane upgrades, node image patching, add-on version compatibility, certificate rotation and policy distribution. Five people cannot do that for thirty eight and build anything.

Fix: declare the axis, then consolidate onto it

Step 1 — declare the split axis explicitly. Every cluster boundary must be justified by one of a small number of reasons:

• Environment. Production separate from non-production. Nearly always correct.
• Region. Forced by latency and data residency.
• Compliance boundary. Where scope reduction is worth real money, as with cardholder data.
• Blast radius, for a genuinely critical workload that must not share fate.

Team, project and experiment are not on the list. That typically implies six to ten clusters, not thirty eight.

Step 2 — inventory and map. For each existing cluster: workloads, owners, last deployment, and which target it maps to. Expect a third to be running nothing that matters — abandoned experiments and superseded projects. Those are deletions, not migrations, and they are the fastest wins.

Step 3 — consolidate in waves. Empty and near-empty clusters first, to build the runbook cheaply. Then the straightforward ones. The genuinely awkward ones — old versions, unusual add-ons, nervous owners — last, when the process is proven.

Step 4 — close the tap. Cluster creation becomes a decision that names its axis, with an owner and a review date. Otherwise you will be back here in two years.

What consolidation requires you to get right

Fewer, larger clusters concentrate risk, so the multi-tenancy has to be real: namespace quotas, default-deny network policy, priority classes and pod disruption budgets, and API server rate limits so one team's tight reconciliation loop cannot degrade the control plane for everyone. Upgrades also become more disruptive — which argues for a rehearsal cluster and a staged upgrade order rather than for keeping thirty eight.

What to tell leadership

This is not a platform improvement project competing with feature work. It is the release of most of a five-person team's capacity, currently consumed by maintenance that produces nothing. Frame it in those terms, with the inventory as evidence, and it funds itself.