Federation

Alright, let’s talk about the elephant in the room, the one wearing a “Kick Me” sign that says “DEPRECATED” on its back: KubeFed. You’ve heard the term “Kubernetes Federation” and your first Google search probably led you here. Buckle up, because this is a story of good intentions, architectural reality checks, and why the community ultimately decided to take a different path. We’ll cover what it was, why it’s being shelved, and what you should be looking at instead.

Alright, let’s talk about making GitOps actually work across the mess of clusters you’re now responsible for. You’ve got your shiny Argo CD installed in each one, and you’re manually creating Application resources. It works, but it feels like you’re just moving the manual kubectl apply step one level up. For every new cluster, you’re copy-pasting YAML and changing the cluster name. This is not the automated utopia we were promised.

Right, so you’ve got your clusters humming along nicely, isolated and secure in their own little worlds. Great. Now you need them to actually talk to each other. You can’t just wave a magic wand and expect ServiceA in cluster-a to ping ServiceB in cluster-b; the network overlords of each cluster have no idea the other exists. This is where Submariner swims in. It’s essentially a VPN and service discovery mechanism that stitches your clusters together across clouds, on-prem, or anywhere else. It doesn’t require you to expose every service with a public LoadBalancer, which is a security nightmare waiting to happen. Instead, it builds an encrypted overlay network between your worker nodes.

Alright, let’s get our hands dirty with multi-cluster federation. You’ve got a few Kubernetes clusters humming along nicely, and now you need them to actually talk to each other and share workloads without you manually playing switchboard operator. This is where tools like Liqo and Admiralty come in. They represent the modern, less-invasive approach to this problem, and frankly, they’re a lot more elegant than the old-school, hair-pulling methods. The core idea here is peer-to-peer service discovery. Instead of a clunky central control plane that becomes a single point of failure and a configuration nightmare, these tools let your clusters form a sort of mesh. They discover each other, establish secure tunnels, and then transparently extend their APIs. When you deploy a service in Cluster A, Cluster B just sees it, as if by magic. Well, not magic—just some very clever engineering.

Alright, let’s get our hands dirty. You’re not running a multi-cluster setup because it’s fun (though, admittedly, it kind of is). You’re doing it because you need resilience that a single cluster, even on the beefiest cloud hardware, can’t provide. You’re chasing zero-downtime deployments, surviving cloud region meltdowns, or wrangling data sovereignty laws. The pattern you choose isn’t just an architectural diagram; it’s a statement about what you value most: availability, simplicity, or not getting a 3 AM call.

Look, you don’t deploy your application across multiple Kubernetes clusters because it’s fashionable. You do it because you have a problem that a single cluster, no matter how beefy, simply cannot solve. Think of it this way: a single cluster is a magnificent castle. It’s defensible, it’s organized, and everything inside speaks the same language. But if the dragon burns it down, or the king in a neighboring land forbits trade, you’re toast. Multi-cluster is about building a kingdom. It’s messier, the communication is more formal, and the tax laws are different everywhere, but your reign is resilient.