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

F5 Ecosystem | November 26, 2020
kubernetes1

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.

Share
Tags: 2021

About the Author

Related Blog Posts

Accelerate Kubernetes and AI workloads with F5 BIG-IP and AWS EKS
F5 Ecosystem | 11/17/2025

Accelerate Kubernetes and AI workloads with F5 BIG-IP and AWS EKS

The F5 BIG-IP Next for Kubernetes software will soon be available in AWS Marketplace to accelerate managed Kubernetes performance on AWS EKS.

The everywhere attack surface: EDR in the network is no longer optional
F5 Ecosystem | 11/12/2025

The everywhere attack surface: EDR in the network is no longer optional

All endpoints can become an attacker’s entry point. That’s why your network needs true endpoint detection and response (EDR), delivered by F5 and CrowdStrike.

F5 NGINX Gateway Fabric is a certified solution for Red Hat OpenShift
F5 Ecosystem | 11/11/2025

F5 NGINX Gateway Fabric is a certified solution for Red Hat OpenShift

F5 collaborates with Red Hat to deliver a solution that combines the high-performance app delivery of F5 NGINX with Red Hat OpenShift’s enterprise Kubernetes capabilities.

F5 accelerates and secures AI inference at scale with NVIDIA Cloud Partner reference architecture
F5 Ecosystem | 10/28/2025

F5 accelerates and secures AI inference at scale with NVIDIA Cloud Partner reference architecture

F5’s inclusion within the NVIDIA Cloud Partner (NCP) reference architecture enables secure, high-performance AI infrastructure that scales efficiently to support advanced AI workloads.

F5 Silverline Mitigates Record-Breaking DDoS Attacks
F5 Ecosystem | 08/26/2021

F5 Silverline Mitigates Record-Breaking DDoS Attacks

Malicious attacks are increasing in scale and complexity, threatening to overwhelm and breach the internal resources of businesses globally. Often, these attacks combine high-volume traffic with stealthy, low-and-slow, application-targeted attack techniques, powered by either automated botnets or human-driven tools.

Phishing Attacks Soar 220% During COVID-19 Peak as Cybercriminal Opportunism Intensifies
F5 Ecosystem | 12/08/2020

Phishing Attacks Soar 220% During COVID-19 Peak as Cybercriminal Opportunism Intensifies

David Warburton, author of the F5 Labs 2020 Phishing and Fraud Report, describes how fraudsters are adapting to the pandemic and maps out the trends ahead in this video, with summary comments.

Deliver and Secure Every App
F5 application delivery and security solutions are built to ensure that every app and API deployed anywhere is fast, available, and secure. Learn how we can partner to deliver exceptional experiences every time.
Connect With Us