Multi-Cluster without a new ops silo: what teams get wrong
Platform teams rarely fail due to Karmada or OCM, but rather due to the operating model.
Multi-cluster Kubernetes is a reality in most platform teams, but it’s rarely organized cleanly. Three, four, sometimes seven clusters are spread across cloud regions, edge locations, and a dedicated on-prem piece. What starts as a resilience argument often ends in a second ops silo: federated policies here, manual drift repair there. The question is not whether to use multi-cluster, but how much platform romance the operation can handle.
Key Takeaways
- Multi-cluster is an operating model, not a tooling choice: Introducing Argo CD, Cluster API, or Karmada without first defining ownership, on-call, and policy source creates a second ops silo alongside the first. The order matters, not the stack.
- Federation scales, central control planes bind personnel: Karmada and vCluster handle drift differently. Federation distributes complexity, while centralization concentrates it. Both approaches work, but only one fits the respective team size.
- GitOps is the only scalable policy source: Once three clusters are exceeded, every manual kubectl action is a potential audit finding. Argo CD or Flux with the App-of-Apps pattern makes the drift problem visible before it becomes costly.
RelatedHonest Platform Engineering / Multi-Cloud without Detours
Why one cluster becomes three without anyone deciding
The story is the same in almost every platform team. It starts with a productive cluster per environment, plus a DR setup in a second region. Then comes an edge location with strict latency requirements, a regulatorily isolated tenant for the finance sector, a dedicated GPU pool for AI workloads. Nobody declared multi-cluster. It just happened.
The break usually occurs at two points: ingress configuration and RBAC. Both are defined per cluster, and both drift faster than they can be patched. Platform teams consistently report the same pattern in recent quarters – the effort doesn’t increase linearly with the number of clusters, but rather by a factor of 1.7 per additional cluster, because permutations grow faster than workloads.
Hybrid Cloud is not an architecture pattern, but the consequence of two teams not talking to each other in time. Multi-cluster is the next stage of this.
The Milestones: How a Typical Multi-Cluster Stack Evolves
To gauge the maturity of your multi-cluster journey, you can refer to this timeline. It’s not a one-size-fits-all prescription, but it describes the path most platform teams take over two to three years.
Maturity Axis Multi-Cluster
- Month 0–6: Cluster Sprawl. Each application gets its own cluster because it’s convenient. RBAC and Ingress are copy-paste. Drift occurs but isn’t measured.
- Month 6–12: GitOps Enforces Order. Argo CD or Flux is introduced, usually reactively after the first serious configuration incident. Manifests move to a mono-repo, and drift becomes visible at least.
- Month 12–18: Policy-as-Code. OPA Gatekeeper or Kyverno join the stack, initially as warnings, later as blocking admission webhooks. Many teams fail here at the first auditing workshop because no one can explain the policies.
- Month 18+: Federation or Central Control Plane. Karmada, Cluster API, vCluster, or Open Cluster Management are evaluated. The choice is less technical than organizational – it defines where ownership lies.
Federation, Central Control Plane, or vCluster: The Honest Trade-off Table
Three architectural paths compete for multi-cluster operations. They aren’t mutually exclusive, but they scale on different dimensions. Choosing the wrong path creates the very Ops silo you’re trying to avoid.
| Path | Strength | Breaks First At | Suitable For |
|---|---|---|---|
| Karmada (Federation) | Workload distribution across real clusters, no single point of failure. | CRD diversity, operator incompatibilities, networking mesh latency. | 3–15 clusters, mixed cloud providers, clear tenant separation. |
| OCM / RHACM (Central CP) | Single pane of glass, strong policy reporting, vendor support available. | Lock-in to the hub, hub as a bottleneck, difficult in mixed distro setups. | Regulated environments, OpenShift houses, defined compliance path. |
| vCluster (Virtual Clusters) | Tenant isolation without hardware, very fast provisioning. | Persistence, GPU sharing, audit proof chains across host kernel. | Dev platforms, ephemeral stages, inner-source playgrounds. |
The table reflects reality, not marketing promises. Karmada is solid, but the operator zoo in DACH companies is large enough that federation can fail due to a single uncooperative CRD. OCM and RHACM bring vendor support, which counts in audits but also means in everyday engineering: you ask Red Hat before patching. vCluster is elegant but not a replacement for real clusters – ignoring this lesson is learned at the latest with the first persistent volume problem.
The three numbers every platform team needs to know
In multi-cluster operations, there are three metrics that make discussions about the operating model more than just theoretical. They may seem inconvenient at first glance, as they appear to be cost drivers. In reality, they are the only factors that make operations manageable.
Operational Reality
1.7×
Effort per additional cluster. Permutations grow faster than workloads. Linear thinking breaks down after cluster four.
3
Cluster threshold for GitOps. With three clusters, every manual kubectl action is an audit risk. At this point, Argo CD or Flux becomes mandatory.
~ 22 %
Drift ratio in untracked clusters. Order of magnitude from platform teams that introduced GitOps retrospectively.
These numbers are based on practical experience from platform teams, not on a study. Without measuring them in your own setup, you lack a basis for discussion with the CFO when justifying platform investments.
Who owns the platform when it’s distributed?
The organizational question is the most uncomfortable one. In a single-cluster setup, the platform owner is obvious; in a multi-cluster setup, ownership becomes a matter of negotiation. Tenant teams want local sovereignty, the platform team wants central policies, and the security department wants a single auditing point. These three expectations are not contradictory, but they are rarely articulated.
A robust operating model requires three decisions before choosing any stack. First: Who decides which workload goes into which cluster? Second: Who is pageable to which clusters, and who bears the consequences of a Sev-1? Third: Which policies are negotiable per tenant, and which are not? These questions cannot be answered by a tool, but only by a decision.
The difference between a functioning multi-cluster platform and a second ops silo is not the choice between Karmada and OCM. It’s the question of whether these three decisions exist in writing and whether the team still recognizes them a year later.
What a realistic 90-day path looks like
Platform teams that currently manage three or more clusters and want to consolidate their multi-cluster operating model usually find a viable answer within these 90 days. It’s not about the finished stack, but about the decisions that follow.
The first 30 days are spent on an honest inventory. How many clusters really exist, who has authorized kubeconfigs, how old is the oldest Helm release that’s been unchanged for months? This inventory reveals more than any architecture workshop. The next 30 days are spent on GitOps consolidation, ideally with Argo CD App-of-Apps or Flux Kustomization trees. Those who don’t succeed here shouldn’t think about federation yet. The last 30 days are spent on the operating model question: hub-and-spoke or true federation, and above all – which team will still be there in two years to maintain the stack.
This is not an elegant program. It’s what works when you understand a multi-cluster platform not as an architectural art, but as an operational commitment.
Frequently Asked Questions
When does Karmada or OCM become more worthwhile than a simple Argo CD federation?
In practice, it’s from five productive clusters or at the latest when faced with strict multi-tenancy requirements. Argo CD alone can roll out workloads to multiple clusters, but it doesn’t offer workload distribution logic. Karmada allows for declarative spreading policies, and OCM brings policy reporting in audit format. With fewer than five clusters, the operating overhead of both tools is rarely justified.
What is the most common source of drift in multi-cluster operation?
Emergency interventions using kubectl that aren’t backported to the Git repository. When a Sev-1 issue needs to be resolved quickly, direct cluster access takes priority. If these cases aren’t systematically backlogged, drift accumulates, becoming visible only during the next disaster. One solution is to provide read-only kubeconfigs for most engineers and a targeted break-glass procedure for Sev-1 cases.
Can vCluster replace real clusters?
No. vCluster provides tenant isolation at the API level but shares the host kernel, networking, and persistent storage. They’re very efficient for dev and stage environments. For regulated production or true multi-region resilience, separate clusters remain mandatory.
How do Policy-as-Code tools like OPA Gatekeeper and Kyverno fit into multi-cluster setups?
Both work per cluster, but the policy bundle must be deployed from a single source; otherwise, the inconsistency the stack is meant to solve arises. Ideally, GitOps deploys policy manifests to every cluster, and a central reporting tool like Policy Report API aggregates violations. Manually maintaining policies per cluster reintroduces the audit problem you’re trying to avoid.
What is the biggest hidden cost trap in multi-cluster setups?
Inter-cluster networking and observability egress. Cross-region traffic from a service mesh or a central Loki backend can burden the cloud bill faster than the cluster footprints themselves. A rough networking analysis before deciding on federation can save painful re-architecting rounds later.
Image source: AI-generated (Juli 2026)
