Hi, I'm Eric Shanks, a Senior Field Engineer at VMware. In this video, I'll discuss Kubernetes cloud providers. I'll start off by introducing what a cloud provider is, and then I'll move into the capabilities we can get from them and how they can provide higher availability for our applications.

First, let's discuss what a cloud provider is. Here we've got an example Kubernetes cluster. You can see we've got an SED node, we've got a control plane node, we've got several worker nodes and we've got an application deployed in its own namespace that consists of a service and a pod. But Kubernetes clusters don't live all by themselves, they live on some sort of infrastructure. In this case, let's assume that infrastructure is AWS. Now a Kubernetes cloud provider is the connection between the Kubernetes control plane and the underlying infrastructures control plane. So you can assume that the Kubernetes API controllers can talk to the AWS API.

And once we've got that connection nailed up, we can do some pretty interesting things. For example, we can apply a Kubernetes manifest against our Kubernetes API, and that API will then talk to the underlying AWS infrastructure to do things for us. For example here, we've asked the Kubernetes API to provision a service of type Load Balancer. Now, Kubernetes itself doesn't have any Load Balancers, but AWS does. So Kubernetes when it receives this manifest can request these resources from the underlying infrastructure. It makes that AWS API call and it spins up an elastic Load Balancer and connects it to the service that lives in Kubernetes. That's neat. What else can we do with these things?

Well, in a similar instance, we might need additional storage for one of our containers. We can do that by applying another manifest directly to the Kubernetes API and having the Kubernetes API talk to that infrastructure, request the EBS volume, and attach it to our pod. Now, the types of capabilities that you'll have will completely depend on the cloud provider you're using. A lot of them are similar, but you may have differences.

So what else can we do with the cloud provider? Well, we can also use it for availability. Now just for some background, when you apply a deployment or a replica set against the Kubernetes API, the scheduler in Kubernetes will try to take those pods that are part of the replica set and distribute them across multiple nodes and it does this so that there's higher availability if a node were to die, we have another node that's still running part of our application.

But what if Kubernetes is running on some sort of infrastructure that has availability zones like AWS? In AWS, they use availability zones, which are distinct data centers. And the guidance has always been you deploy your applications so that they're highly available across these AZs so that if you lose an entire data center, your application is still not interrupted.

Here you can see, we've got our Kubernetes nodes and they're deployed across those AZs. We deployed a replica set and Kubernetes API and the scheduler decided to place those pods on separate nodes as it should, but in this case, it didn't know about the availability zones and it scheduled both pods on different nodes in the same AZ. Now this can cause a problem because if there was some sort of an outage in the data center and the availability zone were to die, so would our application. There's no pod in the second availability zone. The Kubernetes cloud provider is zone aware, so if you set this up with a cloud provider and you have zones, Kubernetes will know about these zones and will instead distribute those pods across zones so that if you had an outage to one of these AZs, the other AZ is still available, and so is our application.

I hope you've learned a little bit about cloud providers today. Thank you for watching.