Managed Kubernetes services from public cloud providers offer resilient and highly available Kubernetes control...
plane deployments. These services integrate with the native features of their respective cloud provider, as well as with on-premises Kubernetes deployments. However, these services don't always integrate with other cloud providers' offerings -- at least not easily or well.
It's best to use managed Kubernetes services -- such as Amazon Elastic Container Service for Kubernetes (EKS), Azure Kubernetes Service (AKS) and Google Kubernetes Engine (GKE) -- when you commit to a single cloud provider and associate all your orchestration processes with deployments on that provider's platform. The more exceptions to this rule your application presents, the less likely a single managed Kubernetes service will work for you.
Organizations that choose to work with multiple cloud providers should expect the integration of container orchestration tasks across a multi-cloud deployment to become difficult.
To weigh the pros and cons of a managed Kubernetes service for your cloud deployment, follow these three steps.
1. Map out deployment
The step in any container orchestration strategy is to map out the hosting space -- meaning the complete resource set you'll use to host applications. This might include an on-premises data center and multiple public cloud providers. For each application, determine the scope of its deployment, including where you will host its components. This exercise will frame how diverse your Kubernetes deployment will be.
Strong candidates for managed Kubernetes services will have an orchestration map that shows two important things: first, they only plan to use one cloud provider and are prepared to rework their operations strategy if they change providers. Second, any applications with components hosted in the cloud and in the data center perform little to no failover or bursting across that boundary.
At the other extreme, poor candidates for managed Kubernetes services are those who plan to use several public cloud providers and move applications quickly between them. In addition, companies that plan to use all hosting resources, including an on-premises data center, as a large resource pool from which application components can draw are not a good fit for these managed services.
2. Determine multi-cloud goals
Most companies fall somewhere in the middle of these two extremes. If this is the case, the next step is to define your multi-cloud strategy. Determine whether you have a static multi-cloud model -- where you place application components into fixed cloud provider hosting groups -- or a dynamic multi-cloud model -- where components move freely across different cloud providers' platforms.
For those with the static model, using a managed Kubernetes service in each of your public clouds is most likely justified, but only if the cloud provider tightly integrates Kubernetes with a tool, such as Istio, that can distribute work and manage distributed processes. In this case, the use of each cloud provider's tools would likely improve your container hosting capabilities.
Those with a dynamic multi-cloud model, however, most likely won't benefit from cloud providers' managed Kubernetes services. Instead, they need an overarching orchestration approach that crosses cloud boundaries freely. These enterprises should look to deploy their own Kubernetes orchestration platform with cloud-agnostic tools.
3. Choose how you want to commit
Cloud-hosted managed Kubernetes services won't integrate with the native features of other cloud providers. This means, if you commit to these services in a multi-cloud model, you will, in most cases, also commit to separately orchestrating each of your public clouds.
If you select a software distribution of Kubernetes, such as Red Hat OpenShift, you'll have to deploy both your applications and Kubernetes in each of your cloud domains. You'll also have to manage the availability of Kubernetes elements and their control plane connectivity.
One common multi-cloud framework for Kubernetes is Stackpoint.io, and it supports the three major public cloud providers -- AWS, Azure and Google -- as well as on premises. With Stackpoint.io, enterprises can create a universal, multi-cloud Kubernetes control plane that can unify deployment. There are a number of commercial vendors, including DigitalOcean, Red Hat and VMware, that offer a version of Kubernetes and Stackpoint.io, bundled with support.
Lastly, consider your cloud provider's commitment to containers and Kubernetes. Google has demonstrated a strong commitment to both, but Google Cloud's recent leadership change might signal a change in direction. Microsoft, for its part, seems nearly as committed as Google, but AWS was slow out of the gate to improve its own container hosting and orchestration service -- and its Firecracker micro-virtual-machine offering could indicate more of a focus on VMs.