Kubernetes Federation

Kubernetes Federation was an early attempt to manage workloads across clusters from a federation control plane. Federation v1 was deprecated, and its CRD-based successor, commonly called KubeFed or Federation v2, is no longer an active Kubernetes project. It should be treated as historical technology rather than the basis for a new platform.

What Federation Tried to Solve #

The model registered member clusters and propagated selected resources to them. It aimed to centralize placement, replica distribution, service discovery, and configuration while retaining independent clusters. The hard parts were conflict handling, cluster failure, networking, identity, version skew, and the fact that a single global API could become another availability dependency.

The original implementation used a separate federation API server. Later work moved federation behavior into custom resources and controllers, which made it easier to extend but did not remove the operational complexity of cross-cluster state.

Use Current Alternatives #

Choose an alternative according to the problem:

• GitOps fleets: Argo CD ApplicationSet and Flux can render and reconcile an application to many registered clusters.
• Workload scheduling: Karmada provides multi-cluster scheduling and propagation APIs.
• Fleet management: Open Cluster Management provides managed-cluster registration, policy, and placement primitives.
• Cross-cluster networking: Cilium Cluster Mesh, Submariner, and service-mesh multi-cluster features address connectivity; they do not replace deployment orchestration.

These tools have different control planes and failure modes. Do not assume that choosing a multi-cluster deployment manager also provides global service discovery, network reachability, or shared identity.

Design for Independent Clusters #

Treat each cluster as an independently operable failure domain. Define how credentials are rotated, how applications behave during control-plane disconnection, and whether a workload is active in one cluster or several. Prefer per-cluster persistent data unless the datastore has its own tested replication and failover design. A central management plane should improve consistency and visibility without making local recovery impossible.