Deploying Kubernetes Across Multiple Clouds

Last updated at Tue, 16 Jan 2024 15:21:08 GMT

What is Kubernetes?

Kubernetes is essentially a container orchestration platform. It is not a container runtime (software that executes containers and manages container images on a node), meaning it doesn’t replace Docker. Docker is what Kubernetes uses on each node (a worker machine that may be a VM or physical machine depending on the cluster) to run the containers. Kubernetes is in charge of deploying the containers to the specific nodes that have the capacity, or where they need to be based on labels or tagging. It can also handle dealing with the software-defined networking layer that allows the containers to talk to one another, and services like load balancing all inside the Kubernetes cluster.

What Kubernetes is not, as mentioned before, is a runtime. You still have Docker underneath the “covers” running a lot of these containers, though that may change in the future as Google begins to bring on more container runtimes like gVisor. But for now, Docker is still a required component.

Why cross-cloud?

Business: Avoid vendor lock-in and ensure the best price per resource

A lot of companies don’t want to be locked into a vendor.  We all played the data center game and know how painful it can be when you get locked into a long-term contract.  It doesn’t provide you the flexibility you need as an enterprise. Furthermore, you really can’t engage in optimal pricing negotiating if they know they’ve got you by the tail.  They know you can’t leave their environment, so avoiding vendor lock-in is just a good business practice for you to make the best business decisions.

Stability: Keep applications online, even during a catastrophic cloud outages

Cloud outages do happen, and the reality is that technology fails, but people fail way more often. We are likely to see more stability issues as systems become more and more complex. So, it’s important to spread yourself across multiple clouds to ensure that your application is still up and running and making money in the event one of the cloud providers goes down.

Best-in-class services: Take advantage of the best service cloud providers have to offer

Providers are beginning to commoditize, meaning the infrastructure layer is becoming the same across all providers. Servers, load balancers, etc., are all generally the same and operated the same. The differentiators are Google focusing on AI and machine learning, and Amazon has some excellent database service technologies like their Relational Database Service (RDS) and DynamoDB.

Security: Protect your data by replicating across multiple data storage systems

We are seeing a lot more ransomware out there, and companies being held hostage if their Amazon account is compromised. You need to make sure you spread yourself out so in the event you are compromised, you can protect yourself and isolate the area that has been compromised. This will allow you to maintain your running applications and deal with the situation in the other cloud provider.

Kubernetes makes all of this possible because it allows for effortless application portability.  You can move applications from one server to the other server—in fact, the Kubernetes cluster is going to be doing it all the time for you as part of the orchestration layer.

How do you deploy across multiple clouds?

Kubernetes believes in a multi-cloud environment, if not just because of Amazon and Google, but also because there are many enterprises that still run a lot of data center workloads and probably will be for some time to come. Public cloud is not always cheaper, and not always the best option, so you need to make sure you can create a Kubernetes cluster that works across multiple locations, whether it be in public or private clouds. This is very important to Kubernetes.

This is what our application looks like today. We’ve pre-configured an Amazon environment and a Google environment both with a VPC. Amazon has the “.200,” and Google has the “.201.”  They have DNS, internet connectivity, and everything you would need necessary to run.

This is what it would look like if you deployed Kubernetes Clusters in each one of those environments: You’d have independent load balancers, independent Kube apps, and Kubernetes clusters, independent databases, etc. However, you want to take the next step of linking these networks together so you can deploy a Kubernetes Cluster across both VPCs simultaneously.