Don't let Kubernetes services stall a multi-cloud strategy
Despite the benefits of managed Kubernetes services from AWS, Microsoft and Google, these offerings can impede workload portability when tied closely to other provider-native tools.
One of the most appealing aspects of containers, along with Kubernetes for workload orchestration, is the promise of cloud portability. But there's a catch: Managed Kubernetes services from AWS, Microsoft and Google all have different configuration details and interfaces, which can hinder workload migration in a multi-cloud strategy.
As the control plane that manages cluster configurations and workload deployments, Kubernetes was the missing link in the container standards puzzle. The aim is to have a standard software control plane that makes it possible to move containerized applications between clouds without disruption. This concept is referred to as cluster federation, which Kubernetes supports via features and APIs.
Unfortunately, implementation isn't as simple in the real world -- but there are some workarounds.
Federation in a multi-cloud strategy
Multi-cloud federation has four main benefits:
- It allows workloads to synchronize across clouds.
- It enables workloads on different clusters to share back-end services.
- It provides high availability through workload redundancy on independent infrastructure.
- It prevents vendor lock-in by enabling workloads to easily migrate across clusters.
Enterprises can only achieve these benefits if each of their Kubernetes implementations runs a common configuration that they can centrally control with tools such as Kubefed and Kubernetes Anywhere. However, due to the learning curve that Kubernetes presents, many organizations choose to adopt managed Kubernetes services from a public cloud provider, and these services don't necessarily play well with others, particularly when they interact with provider-native features, such as databases and AI.
This makes it critical to understand the effects a managed Kubernetes service could have on your long-term container and multi-cloud strategy.
Kubernetes service landscape
Compared to rivals Microsoft and Google, AWS was the last to release a fully managed Kubernetes service. Its Elastic Container Service for Kubernetes (EKS) is still in preview with a limited number of users. Nevertheless, AWS' massive customer base ensures its eventual popularity.
Microsoft and Google have more established offerings in Azure Kubernetes Service (AKS) and Google Kubernetes Engine (GKE), respectively.
It's difficult to compare costs for these three services, as AWS hasn't provided pricing information for EKS yet. AKS and GKE use a similar pricing structure in which users pay for Kubernetes cluster nodes based on the cost of the underlying compute instances. To estimate your costs, use the Azure and Google Cloud pricing calculators.
Other noteworthy managed Kubernetes services include:
- Alibaba Cloud Container Service for Kubernetes;
- Oracle Cloud Container Engine for Kubernetes;
- StackPointCloud, a third-party tool that works with AWS, Google, Microsoft, Digital Ocean and Packet; and
- Red Hat OpenShift Online.
Roadblocks and workarounds for a multi-cloud strategy
As mentioned above, even when a container runtime and Kubernetes management environment are based on open source standards, it's possible to get locked into a particular cloud implementation due to reliance on native services. One way to mitigate these problems is through a cloud-agnostic Kubernetes manager, such as Platform9 or StackPointCloud.
Alternatively, you could use PaaS stacks, like Pivotal Cloud Foundry or OpenShift. These can run on any private or public cloud infrastructure and act as an abstraction layer that insulates developers and operations teams from the implementation details of each.
Google, for its part, offers the following guidance to achieve a heterogeneous Kubernetes environment:
- Create and expose Kubernetes services to enable traffic direction among multiple cluster implementations using the domain name system.
- Consider the use of third-party systems, such as Consul or Linkerd, to facilitate cross-cluster, multi-cloud service discovery.
- Use private, low-latency networks between clusters for shared services, such as databases.
Additionally, pay attention to the implementation details of any persistent storage used on containers, and stick with generic block device services.
In general, multi-cloud Kubernetes federation, especially without a third-party tool, such as those mentioned above, is still immature and requires a good deal of manual setup to get working.
