Why Cloud Kubernetes Is Not as Vendor-Agnostic as It Seems – and What to Do about It

Kubernetes is an open source platform. You might think, then, that it's a vendor-agnostic platform, meaning that you can easily move from one Kubernetes implementation to another.

But you'd be wrong. The reality is that many Kubernetes solutions – in particular, those that are tied to a specific public cloud – are much less vendor-agnostic than you might think.

Fortunately, this doesn't mean that you can't take advantage of the public cloud as a Kubernetes hosting solution if you want to avoid lock-in. You can, but you have to design your Kubernetes strategy in a way that frees you from being locked into a particular cloud provider's Kubernetes service while still enabling you to enjoy the advantages of cloud-based Kubernetes.

Cloud-Based Kubernetes Options

Today, all of the major public clouds offer hosted Kubernetes services via an SaaS architecture. Amazon has Elastic Kubernetes Service. Azure provides Azure Kubernetes Service. Google offers Google Kubernetes Engine. IBM has IBM Cloud Kubernetes Service.

Because these services couple cloud-based infrastructure with software that helps to automate Kubernetes deployment and management, they are an attractive solution for organizations looking to get up and running quickly with Kubernetes.

Lock-In Risks of Cloud Kubernetes

The fact that these cloud Kubernetes services appear agnostic also increases their appeal. On the surface, it may seem that it would be easy enough to move from one Kubernetes SaaS platform to another. All of these platforms are based on standard, open source Kubernetes. They provide access to the same Kubernetes tooling (like kubectl) and generally support the same types of storage and networking configurations. In this light, they look quite vendor-agnostic.

However, when you dig deeper, you realize that the public clouds that offer Kubernetes as a hosted service aren't quite as flexible and generic as they may appear. They integrate and depend in various ways on other services running in the public clouds that host them. You have to create IAM policies on whichever cloud you use to manage your Kubernetes clusters. You may end up using vendor-specific services, like Azure Active Directory in the case of Azure Kubernetes Service, for authentication. And in many cases, there are add-on or replacement tools that Kubernetes services prefer that you use, even if they don't strictly require them. Google Kubernetes Engine wants you to use gke-deploy instead of kubectl, for example, while Elastic Kubernetes Service is designed for use with eksctl, Amazon's proprietary tool.

So, while the underlying Kubernetes code may be the same no matter which cloud you use to host Kubernetes, and while you could technically stick with generic tools if you really tried, the tooling and configurations you will most likely end up using are not vendor-agnostic. They are specific to whichever Kubernetes service you use.

That creates a major barrier if you want to move from, say, Azure Kubernetes Service to Google Kubernetes Engine. Even if you can lift and shift your Kubernetes workloads, you can't do the same with the tool chains and configuration files that support them.

Avoid Cloud Kubernetes Lock-In

If you want to take advantage of the public cloud's convenience and scalability when deploying Kubernetes clusters but don't want the lock-in, there are two basic solutions.

One is to set up your own clusters manually using cloud-based virtual machines and then manage them yourself. With this approach, you don't get the automation and integrations that come with the cloud providers' SaaS Kubernetes offerings, but you still get the infrastructure. Because you're not using specialized tooling, it's easier to migrate your clusters from one cloud host to another without rebuilding everything. Of course, the downside here is that there is a significant amount of manual effort required to set up and manage your clusters.

The other approach – one that is more automated and scalable – is to use a solution like Volterra's VoltStack® service to manage your clusters, no matter which clouds they happen to reside on. With this strategy, you essentially replace the cloud-specific tooling of each vendor's platform with a centralized command-and-control center that works with any public cloud, making it easy to migrate or replicate clusters between different public clouds. You get the same manageability as you would from services like Google Kubernetes Engine and Azure Kubernetes Engine without the lock-in to specific public clouds.

Conclusion

Don't make the mistake of assuming that Kubernetes is Kubernetes no matter where or how you run it. There are major differences between different cloud-based Kubernetes services, which can hinder the portability of Kubernetes clusters from one cloud to another (not to mention make it difficult to manage clusters on different clouds, because each one has a different set of tools).

The good news is that there is a solution: by using a cloud agnostic Kubernetes management solution like Volterra's VoltStack service to manage all of your clusters, you free yourself from dependence on a particular cloud provider while still taking advantage of the ease-of-use of cloud-based Kubernetes.