Key Criteria for Leveraging Federated Kubernetes, Open and Closed

1. Summary

The Federated Kubernetes standard (now renamed Kubefed)^1&2 and architectural approach simplifies working with multiple clusters running on multiple clouds. This architecture is the result of utilizing the following two major building blocks:

• First is the capability of syncing resources across clusters. As you may expect, this would be the core challenge for those deploying multi-cloud Kubernetes. Mechanisms within Kubernetes can automatically sync deployments on plural clusters, running on many public clouds.
• Second is intercluster discovery. This is the capability of automatically configuring Domain Name System (DNS) servers and load balancers with backends, supporting all clusters running across many public clouds.

The benefits of leveraging multi-cloud/Kubefed, both the concept and the standard, include high availability, considering that you can replicate active clusters across multiple public clouds. This distributed availability means, if one has an outage, the other can pick up the processing without missing a beat.

Also, you avoid that dreaded provider lock-in. Since Kubernetes is the abstraction layer that is able to remove you from the complexities and native details of each public cloud provider, it thereby replaces both cloud services brokers (CSBs) and cloud management platforms (CMPs), at least in theory.

Moreover, both Kubernetes and Kubefed are open source standards, as are providers that support Kubefed, such as RedHat. This means that they are decoupled from some company that may or may not advance your business priorities.

Keep in mind that when we are discussing Federated Kubernetes, it is not only a standard that technology providers adopt, but it is an approach to distributing Kubernetes clusters that can be leveraged by cloud providers and technology providers, whether leveraging the Kubefed open standard or not.

Running workloads in federated Kubernetes technology, approaches, and architecture offers several core advantages:

• Ease of the configuration to the desired state – this means that once a ReplicaSet, or a StatefulSet, or a Deployment configures to execute a specific number of pods, the Kubernetes control plane (see Figure 1) ensures that all instances are available and exposed.
• Cluster federation, which in Kubernetes is able to bring high availability considering that customers can be geographically distributed – thus, you can place redundant processing at two or more regions, where one can failover to another (See Figure 1).
• The ability to abstract the applications from the underlying public cloud service – this allows one to leverage true multi-cloud architecture. It means that you can deploy a container on any number of federated clusters on any public cloud. Moreover, you can move containers between federated clusters with little or no changes in the containers themselves.

The essence of federated Kubernetes, both commercial, semi-open and open, is the ability to manage many clusters, using a single control plane, existing in widely distributed configurations (Figure 1).

Figure 1: Federated Kubernetes Enables Many Clusters to be Managed Using a Single Control Plane

Based on information gathering for this report, and current state-of-the-art in the implementation of federated Kubernetes, we’re making the following recommendations:

• Understand the use case for leveraging Kubefeds before picking this approach, standard, or technology as the primary platform. Leveraging this technology pattern can also mean twice the amount of development costs from design to deployment. This is because more time needs to be spent on design, development, and deployment in contrast to non-federated deployments.
• Understand the benefits and be prepared to value the benefits. Distribution is typically leveraged for scaling and for BC/DR purposes. If those are the reasons(s) you are moving to Kubefeds, you need to define the value of choosing that solution over other federation mechanisms. In many cases, traditional approaches to a federation, such as native cluster management found in most public cloud platforms, may be more cost-effective choices.
• Understand that the Kubefed standard is very much a work in progress at the time of this report. Thus do not place bets on standards that are not yet set. It could be a better approach to move forward with commercial semi-open source players, such as RedHat and its OpenShift platform.
• Understand that security and governance for federated Kubernetes solutions are still a work in progress. While the ecosystem around federated Kubernetes is growing, most security solutions have to be custom integrated. There are few canned solutions that one can put into production quickly.
• Understand that true performance results are still suspect, for Kubernetes federation. While taking a ‘divide and conquer’ approach may look good on paper, network latency and cluster syncing could end up being factors that make federated Kubernetes unviable for some enterprises.
  

  ---

  ¹_{https://blog.openshift.com/federation-v2-is-now-kubefed/}
  ²_{Note the federated Kubernetes if now called Kubefed. For the purposes of this report, we will use the term interchangeably.}