One control plane to rule them all
Imagine you manage 10 office branches. Instead of flying to each branch to update the employee handbook, you send one memo from headquarters and each branch applies it locally. Kubernetes Federation works the same way: a central "Host" cluster acts as headquarters, and "Member" clusters are the branches.
How KubeFed works
Kubernetes Federation v2 (KubeFed) introduced a set of custom resources that wrap standard Kubernetes objects. Instead of creating a Deployment, you create a FederatedDeployment. The Federation Controller running on the Host cluster reads this object and propagates standard Deployment objects to every registered Member cluster.
A FederatedDeployment wraps a normal Deployment template, a placement field naming which clusters should receive it, and an overrides section for per-cluster customization — the placement field controls which clusters receive the object, while overrides lets you customize per-cluster, such as giving one region fewer replicas than the others because its traffic is lower.
Propagation flow:
1. You kubectl apply the FederatedDeployment to the Host cluster.
2. The Federation Controller detects the new object.
3. It creates a standard Deployment in each Member cluster listed under placement.
4. Overrides are applied before propagation — the Asia cluster receives a modified copy.
The reality check
KubeFed's concept is sound, but the implementation proved operationally complex. Debugging propagation failures across clusters is difficult. The custom resource layer adds cognitive overhead. As a result, the industry has largely moved toward GitOps-based fleet management (ArgoCD, Flux) and purpose-built tools like Karmada (a CNCF project that evolved from KubeFed's ideas) and Red Hat Advanced Cluster Management (RHACM). Understanding KubeFed is valuable because it establishes the vocabulary — propagation, placement, overrides — that newer tools also use.