Kubernetes and the Challenge of Federation
Wouldn’t it be handy if you could manage multiple Kubernetes clusters using a single tool and interface? Kubernetes would like to let you do this using a feature called federation.
The trouble is, federation has proved to be much more difficult for Kubernetes to implement than you might expect. Here’s why.
What is Kubernetes Federation?
The goal behind federation in Kubernetes is simple: to allow multiple clusters to be managed from a single Kubernetes instance.
Kubernetes developers envision federation as a way to solve several problems. It can increase availability by spreading workloads across multiple clusters. It can make application migration from one cluster to another easier. It simplifies the process of managing a multi-cluster Kubernetes deployment.
Kubernetes Federation V1
You might think federation would be a relatively easy feature to implement. After all, how hard could it be to get different clusters to respond to a single tool?
Kubernetes developers perhaps thought that this would be easy to accomplish, too—at least, originally. That’s why they added federation v1 to Kubernetes. The feature relied on the Kubernetes API to let users manage multiple clusters at once without having to learn any new tricks.
But federation v1 never came close to being ready for production-level use. Today, it’s considered deprecated, and Kubernetes recommends against using it.
Federation V2
The main reason why, as representatives of companies that contribute to Kubernetes development wrote last year, is that federation is actually more difficult to implement than it might first appear. It requires making decisions about things such as whether a workload can be shared between clusters of drastically different sizes without impacting performance, which actions users should be able to perform on multiple clusters at once, how to handle access control for multiple clusters and more.
Kubernetes developers are now working on a new federation solution, called federation v2, that aims to answer these questions and provide a more robust federation solution.
For now, federation v2 remains in development, and is not ready for prime-time use. Its developers call it an “in-progress prototype,” which is not language that suggests that it’s going to be production-grade anytime soon.
The good news for Kubernetes users seeking a federation feature, however, is that federation v2 is under heavy development, with lots of steady activity on GitHub over recent months.
Will running multiple clusters using a federated model prove to be the big innovation in Kubernetes architectures a year or two from now? It’s too early to say for sure, but if federation v2 works out, I see a lot of federated clusters in the future.
