Federation vs independent clusters — when to federate

Federation vs independent clusters is one of the most debated multi-cluster architecture decisions. This lesson walks federation, independent clusters, the modern alternatives, and the operational discipline of choosing the right architecture for the use case.

Federation vs independent clusters

flowchart LR
    A[Multi-cluster architecture] --> B[Federation]
    A --> C[Independent clusters]
    B --> B1[Single API across clusters]
    B --> B2[Sync state across clusters]
    C --> C1[Each cluster managed separately]
    C --> C2[No shared state]

The two approaches:

• Federation. A single API that spans multiple clusters. The API can query, create, and update objects across clusters. State is synchronised.
• Independent clusters. Each cluster is managed separately. No shared state; no unified API.

Federation provides a unified view but adds complexity (synchronising state, handling failures, conflicts). Independent clusters are simpler but require explicit tooling for cross-cluster operations.

When federation makes sense

Federation makes sense for narrow use cases:

flowchart TD
    A[Federation use cases] --> B[Unified policy]
    A --> C[Cross-cluster service discovery]
    A --> D[Cross-cluster Ingress]
    B --> B1["Same PSS, same RBAC, same NetworkPolicy"]
    C --> C1[Service visible across clusters]
    D --> D1[Single Ingress for multi-cluster backend]

• Unified policy. A single policy (e.g., PSS restricted) is enforced across every cluster. The policy is a federation-wide object; each cluster applies it.
• Cross-cluster service discovery. A Service in cluster A is discoverable from cluster B. Federation maintains the service registry.
• Cross-cluster Ingress. A single Ingress points to backends across multiple clusters. Federation routes traffic based on cluster health.

These use cases are narrow. Most multi-cluster deployments do not need federation; they need explicit tooling for the specific cross-cluster requirement.

The modern alternatives

flowchart LR
    A[Modern alternatives] --> B[Submariner]
    A --> C[Istio multi-cluster]
    A --> D[Argo CD]
    A --> E["Rancher / TMC"]
    B --> B1[L3 cross-cluster Pod networking]
    C --> C1[Unified service identity and mTLS]
    D --> D1[GitOps across clusters]
    E --> E1["Fleet management UI/API"]

The modern alternatives:

• Submariner. L3 cross-cluster networking. Pods in cluster A can reach Pods in cluster B by IP. Service ClusterIPs can be exported.
• Istio multi-cluster. Unified service identity across clusters. mTLS between clusters is automatic. Traffic management across clusters.
• Argo CD. GitOps across clusters. A single Argo CD instance manages manifests across multiple clusters from Git.
• Rancher / Tanzu Mission Control. Fleet management UI/API. Centralised view of clusters, projects, RBAC.

Each tool addresses a specific cross-cluster requirement. Federation tried to do all of them at once; the modern alternatives do each separately, better.

The decision framework

The framework:

1. Identify the cross-cluster requirement (networking, service identity, GitOps, fleet UI, policy).
2. Choose the tool that addresses the requirement.
3. Combine tools as needed (e.g., Submariner + Argo CD).

Federation as a single architecture rarely makes sense; combination of purpose-built tools usually does.

The operational failure modes

Architecture choices fail for predictable reasons:

• Federation without need. A team deploys federation because it sounds unified; the operational complexity exceeds the benefit.
• KubeFed in production. KubeFed is deprecated; production deployments relying on it will face issues as upstream development stops.
• Tool sprawl. Multiple cross-cluster tools (Submariner + Istio + Argo CD + Rancher) without clear ownership produce configuration drift.
• Missing cross-cluster observability. Tools deployed without observability produce silent failures.
• Drift between clusters. Tools that should enforce consistency fail to do so; clusters drift in configuration.

Quiz

Production discipline

Federation vs independent clusters in production rests on five non-negotiable elements:

• Choose based on the requirement. Federation rarely makes sense; the modern alternatives are purpose-built.
• Avoid KubeFed in new deployments. It is deprecated; the upstream API server is EOL.
• Combine purpose-built tools. Submariner + Argo CD + Istio is simpler than federation.
• Document the architecture. The cross-cluster topology must be documented with the tools, the ownership, and the migration plan.
• Test cross-cluster functionality quarterly. The cross-cluster requirements must be validated regularly.

Federation is rarely the right answer. The discipline is to choose purpose-built tools based on the actual cross-cluster requirements, and to test them regularly.