Multi-cluster anti-patterns — the most common mistakes

Multi-cluster anti-patterns are the most common mistakes that Kubernetes operators make when scaling beyond a single cluster. This lesson walks the anti-patterns, the fixes, and the operational discipline of avoiding them.

Anti-pattern 1: Clusters as tenants

flowchart LR
    A[Team A] --> B[Cluster A]
    C[Team B] --> D[Cluster B]
    E[Team C] --> F[Cluster C]

Each team gets its own cluster. The intent is isolation; the result is operational explosion — 10 teams, 10 clusters to upgrade, monitor, secure.

The fix is to use namespaces within a single cluster:

flowchart LR
    A[Team A] --> B[Namespace A in cluster 1]
    C[Team B] --> D[Namespace B in cluster 1]
    E[Team C] --> F[Namespace C in cluster 1]

Namespaces with NetworkPolicy, ResourceQuota, LimitRange, and RBAC provide the same isolation as separate clusters, at much lower operational cost. Reserve multi-cluster for actual multi-cluster drivers (DR, geography, compliance, scale).

Anti-pattern 2: Cluster-per-app

flowchart LR
    A[App A] --> B[Cluster A]
    C[App B] --> D[Cluster B]
    E[App C] --> F[Cluster C]
    G[App D] --> H[Cluster D]

Each application gets its own cluster. The intent is isolation; the result is dozens of clusters with the same configuration, the same upgrade cycle, and no shared capacity.

The fix is to consolidate: one cluster per environment (dev, staging, prod) with namespaces per app. Capacity is shared; isolation is per-namespace; operational cost is linear with the number of environments, not with the number of apps.

Anti-pattern 3: Premature active-active

flowchart LR
    A["Cluster A: primary"] -->|synchronous replication| B["Cluster B: secondary"]
    A -->|global LB| C[Users]
    B -->|global LB| C

Active-active with synchronous data replication is the most expensive multi-cluster topology. Most workloads do not justify it. The cost is double the infrastructure; the benefit is sub-minute RTO that most businesses do not need.

The fix is to start with primary-secondary (Tier 5) or even hot site (Tier 4) and only escalate to active-active if the business commits to sub-minute RTO.

Anti-pattern 4: Inconsistent policies

flowchart LR
    A["Cluster A: PSS restricted"] --> B[Workloads A]
    C["Cluster B: PSS baseline"] --> D[Workloads B]
    E["Cluster C: no PSS"] --> F[Workloads C]

Different clusters have different policies. Cluster A enforces restricted PSS; cluster B enforces baseline; cluster C has no PSS. The compliance gap is large: workloads in cluster C are not subject to the same security controls.

The fix is a fleet-wide policy framework: a single source of truth (e.g., Tanzu policies, Rancher projects) that enforces consistent PSS, NetworkPolicy, ResourceQuota, and RBAC across clusters.

Anti-pattern 5: Missing cross-cluster networking

flowchart LR
    A["Cluster A: pod 10.0.1.5"] -->|cannot reach| X["Cluster B: pod 10.0.2.5"]

A multi-cluster deployment without Submariner, service mesh federation, or VPC peering is a set of islands. Workloads in cluster A cannot reach workloads in cluster B; the multi-cluster value is lost.

The fix is to design cross-cluster connectivity explicitly: VPC peering for L3, Submariner for Pod-to-Pod, or service mesh federation for unified identity.

Anti-pattern 6: Missing cross-cluster observability

flowchart LR
    A[Cluster A metrics] --> B[Prometheus A]
    C[Cluster B metrics] --> D[Prometheus B]
    E[Cluster C metrics] --> F[Prometheus C]
    B -.->|no federation| X[Central visibility]
    D -.->|no federation| X
    F -.->|no federation| X

Each cluster has its own Prometheus; there is no federation. The operator cannot answer “is the fleet healthy?” because each cluster’s metrics are siloed.

The fix is cross-cluster observability: Thanos for metric aggregation, Loki for log aggregation, or a SaaS observability platform that ingests from every cluster.

The operational discipline

The multi-cluster anti-patterns’ operational discipline:

• Audit the cluster count. If the cluster count exceeds the drivers, consolidate.
• Audit the policies. Compare PSS, NetworkPolicy, and RBAC across clusters; gaps are compliance risks.
• Audit cross-cluster networking. Verify the tunnels, mesh identities, and route tables are functional.
• Audit cross-cluster observability. Verify metrics, logs, and traces are aggregated across clusters.
• Document the topology. The architecture diagram must show every cluster, every connection, every policy, and every observability path.

Quiz

Production discipline

• Audit the cluster count. If the cluster count exceeds the drivers, consolidate.
• Audit the policies. Compare PSS, NetworkPolicy, and RBAC across clusters; gaps are compliance risks.
• Audit cross-cluster networking. Verify the tunnels, mesh identities, and route tables are functional.
• Audit cross-cluster observability. Verify metrics, logs, and traces are aggregated across clusters.
• Document the topology. The architecture diagram must show every cluster, every connection, every policy, and every observability path.
• Review quarterly. Multi-cluster topologies drift; the review catches the drift.

Multi-cluster is a tool. The discipline is to use it only when the driver justifies the complexity, and to audit the topology regularly to ensure it still serves the drivers.