KubeAcademy by VMware
Networking on the Public Cloud
Next Lesson

Join 80,000+ fellow learners

Get hands-on practice with Kubernetes, track your progress, and more with a free KubeAcademy account.

Log In / Register

Running Kubernetes in the public cloud presents some interesting network considerations and constraints. In this lesson, we will discuss some of the things to keep in mind when running in AWS, GCP, or Azure both with your own cluster deployment and with their managed solutions.

Scott Lowe

Principal Field Engineer at Kong, Inc.

Focused on Kubernetes and related cloud-native technologies. Helps customers deploy and deliver applications with cloud-native and open source technologies.

View Profile

Hi. I'm Scott Lowe and I'm a staff Kubernetes Architect at VMware. In this lesson, Networking in the Public Cloud, we're going to continue our course on networking and Kubernetes by examining what networking and Kubernetes looks like when you're running Kubernetes in a public cloud provider. This course is heavy on, shall we say, lecture as opposed to demo. With a lot of concepts. So let's dig right in. So why is it that we need to talk about networking in the public cloud anyway? And why is this a topic? Why can't we just use the rest of the networking lessons? And why do we have to have a separate lesson on networking in the public cloud in general? That's because public cloud networking isn't necessarily like networking in your typical on-premises data center. Public clouds typically run their own software-defined networks or SDNs, and these SDNs don't necessarily behave or function like typical data center networks.

For example, some of the SDNs in public clouds don't support the address resolution protocol or ARP. And so the way that they match physical addresses like the Mac addresses and IP addresses is different. Public cloud networks also have additional constructs like regions and availability zones that introduce additional considerations. And there are other features and functionalities that are present in public clouds. Like the ability to spin up LoadBalancers on demand. As a result of all of these things, Kubernetes networking in the public cloud can be a bit different in some ways than Kubernetes networking in your typical on premises data center. And so the purpose of this lesson is to outline and discuss some of these additional considerations when you're running Kubernetes on a public cloud platform.

Now, before we get into the details of the two public cloud platforms that we're going to discuss in this lesson, which are going to be AWS and Azure, let's first review a few basics and talk about the two primary modes of handling networking. This is something that has been discussed in the other courses, the other lessons in this course, but I want to review it really quickly. And there are two primary modes for handling networking. You can route traffic without encapsulation, or you can route traffic with encapsulation. And here in capsulation are first of the use of a network protocol. Often called encapsulation protocol that could be considered something like VXLAN, IP-in-IP, GRE or others.

And the purpose of this encapsulation protocol is to serve as a means for isolating traffic from the underlying network fabric. Whether that network fabric is a set of switches and your typical on premises data center, or whether that network fabric is something like a VPC in AWS. In both cases, something, and I'm using something here in quotes, has to distribute routes. This could be any number of things, it could be a routing demon like what's used in Calico, and Eric covered that in the CNI lesson, in this course, or it could be some other mechanism. Some other CNIs don't use routing demons and they use other means to distribute routes among them so that they know how to direct traffic among the various nodes within a Kubernetes cluster.

Now, we're talking about routing without encapsulation. It's important to note here that when you do route traffic between Kubernetes nodes without encapsulation, and this is true, in on premises data center or in a public cloud, the underlying network fabric gets involved in the routing process. And as a result, the network fabric has to have knowledge of these routes. And you can accomplish that either via static routing configuration or the use of routing protocol like BGP. So if we consider Calico as an example, Calico uses a BGP routing demon to distribute routes among the Kubernetes nodes. And it has the capability to create a BGP peering relationship with the physical network. And through the use of that BGP peering relationship, it could distribute the routes that it knows about for the Kubernetes nodes. And this is one way that the underlying network fabric would have knowledge of the routes.

Now in your typical enterprise data centers, this is not really a problem. As I mentioned before, you can use something like a BGP peering relationship, or you can have your network operations team program, static routes in for what the Kubernetes clusters are using. And the public cloud, though, this gets a little more tricky, and we're going to dive into some details later on in this lesson, they're going to talk about how it is we can get routes into the underlying network fabric.

The other primary means is routing with encapsulation. And so again, here we're using some sort of encapsulation protocol, like a VXLAN or IP-in-IP or GRE, Geneve. There's a number of them. And in cases like this, when we're routing with encapsulation, the underlying network fabric gets abstracted away. The underlying network fabric doesn't know about what's happening inside the encapsulation. In fact, that's the whole purpose of the encapsulation, is to isolate the traffic from the underlying network fabric. So to the network fabric, traffic between two Pods, actually it looks like traffic between two nodes. And the Pod IPS never actually gets seen by the network fabric because that traffic is wrapped in this encapsulation protocol.

Now this does have some advantages. It can be easier to implement an encapsulation protocol on top of existing network fabrics and not require changes or configuration on those network fabrics. But it does also have some disadvantages, the primary one being some added complexity. When we transition to running an encapsulation protocol on top of a public cloud provider. Depending on the public cloud provider, it may introduce some additional considerations. And so this is something we're going to discuss in this course.

So now that I've covered some basics of what we're going to discuss, I'd like to dive a little deeper on one particular public cloud platform and that's Amazon web services. So in the next couple of slides, we'll talk in more detail about what I've just discussed the basics, some of the considerations. We'll go into more detail about those with regards to AWS's specific implementation and talk about some considerations when running Kubernetes on AWS. First, let's discuss some of the core networking concepts that are used on AWS. And if you're very familiar with Amazon web services, you may already be familiar with these, but we want to make sure that we cover the basic building blocks of the SDN that AWS uses.

Networking on AWS has a number of different sort of core building blocks if you will. We mentioned earlier that public cloud platforms have this idea of a region and availability zone. And so in AWS, you have geographic regions and within each of those geographic regions, you have availability zones. And the number of availability zones will vary by region, within an availability zone latency may be consistent between availability zones latency may be a little more variable, but typically within a region, latency is typically very low.

Then you have this idea of a VPC or a virtual private cloud. And this is the basic networking concept. Everything in AWS these days involves a VPC. Now VPCs are tied to a region, but if VPC spans multiple availability zones or AZs within that region. So when you create a VPC, you'll create that VPC in a region like U.S West one or U.s East two, and then that VPC will span all of the availability zones that are available in that region. You then create subnets in AWS. Subnets are tied or associated to an availability zone. So you cannot have a subnet that spans multiple availability zones.

You also then have the idea of security groups. Security groups are associated with the VPC. You also have network access control lists or knuckles, that are also associated with the VPC. Both of these serve to allow you some control over what kinds of traffic are allowed between and among workloads running on AWS. And then finally, we have these idea of a route tables. Route tables are linked to subnets or associated to subnets, and also associated with gateways like internet gateways or net gateways. Both of which provide connectivity out of the VPC to the prodder internet. Now, without going too deep into the mechanics of AWSs, SDN, we do know and should point out that the VPC and the automation orchestration systems that AWS uses always know the IP address to Mac address mapping. That is how to take a given IP address and translate that to the physical address of a network interface of another instance or work load.

So there is no such thing as ARP. You don't have machines that will send out ARP a broadcast because our broadcasts don't actually get propagated by the underlying VPC because it knows what those mappings are and so the VPC responds directly, and this means that OS level ARP caches do show meaningful data. You will see actual Mac addresses in there. The other thing that's important to note is that, instances are only going to accept traffic destined for them. So if I send traffic to a node and it is routed to that node, because it is intended for a Pod running on that node, then by default when the source destination check is enabled, which it is by default, that traffic won't get passed up.

And this has began because the orchestration system, the STN that AWS uses, it knows how to send traffic to a particular IP address and it's not going to send traffic for an IP address that isn't intended or destined for that IP address. Now you can turn off this source of destination check and in some cases it is necessary to do so. And I'll talk about that more in just a moment.

All right. So going back to our two primary ways of handling networking, we have routing without encapsulation and routing with encapsulation. And let's talk about how that works in an AWS environment. When you're routing without encapsulation, remember that the underlying network fabric, in this case, the VPC is involved in the routing process. And therefore the VPC does need to know the routes. So when a Kubernetes node comes online and it is given a subnet where all of its pot IPS are drawn from, the VPC needs to know what that subnet is. It needs to know the routing needs to know that 192, 168, 10/24 is available through node number one, so on and so forth. Now the AWS cloud provider can handle this by programming routes into the route tables. Recall that, the cloud provider provides a greater level of integration between Kubernetes and the underlying cloud platform AWS in this case, and Eric Shanks, did a great course on cloud providers and the AWS cloud provider in particular, so I encourage you to check out that course, if you need more details on the AWS cloud provider.

But if you do have the AWS cloud provider configured in your cluster, then you can optionally have the cloud provider automatically program routes into the route tables. And this has some concerns, we're going to talk about that in just a moment, there is a limit on the number of support routes and the time that it takes for those routes to appear and converge is variable. And I'm going to talk about that more in just a moment. The other thing that has to happen here is because we're sending Pod traffic to a node, right? And the VPC or the network fabric actually sees that we have to disable the source destination check, and that will allow nodes to accept traffic for Pods that are hosted on that node, even though that traffic doesn't have, it isn't destined for the IP address of the node. Right?

Now, Let's dig in a little more detail on this item number one here about having the VPC know the routes. So we have to have knowledge of the routes in the VPC when you aren't using an encapsulation protocol. So if you're just running straight up layer three routing, perhaps using Calico or some other CNI, then the VPC has to know the routes. It has to know how to send traffic between two different nodes, it's going to see the Pod-to-Pod traffic, it's going to see the Pod IPS. You can have the AWS cloud provider program routes into the route table automatically, but by default, the number of route entries in a route table is limited to 50. You can increase that, it can be increased up to 1000. AWS simply provides this vague warning. That, "network performance may be impacted."

Now, if you don't change this default route, that means your cluster size is also going to be limited to 50, because every node is earned require a route in the route table. You can program routes into the route table via the AWS APIs and that's handled by the cloud provider, but the latency on the convergence of adding those routes, in other words, how much time it takes for the route to be added, and for all the nodes to see that new route is variable. In other words, it isn't guaranteed. So you might have the AWS cloud provider program a new route, and then all the nodes in the cluster will see that route in just a couple of seconds. But the next time you do that, you might add a node and have the cloud provider program the route, and it might take 10 seconds before the route appears.

Now, the problem with this variable latency is that it can result in some connectivity issues. You might be trying to send traffic to Pods and the routes haven't yet propagated through the VPC and to all the nodes in the cluster. Now, this is really only an issue for clusters where you're adding and removing nodes, because that's when these routes have to be updated. So if you're talking about a stable cluster, you've sized it as large as it's going to go, then this may not be as much of a concern. There is, of course, still the concern about a node failing and having to be replaced. But that's not something necessarily that you can always address, right?

So these are some of the considerations when it comes to getting the VPC involved in the routing process, right? There's a default limit on the number of routes in a route table, and that in turn limits the number of nodes you can have in a cluster. And then there's this latency, that's variable latency when you're adding routes to the route tables via the AWS APIs, which is handled by the cloud provider that may introduce some odd connectivity issues. And so for this reason, you may not want to get the VPC involved in the routing process, it may not be the ideal solution for you. And if that's the case, then you're going to want to look at using encapsulation with your CNI.

So in a case like that, where you're using encapsulation, the underlying VPC does not get involved in the routing process. Recall that the purpose of the encapsulation protocol is to actually hide that traffic, that Pod-to-Pod traffic, so it just looks like, node-to-node traffic, right? And the underlying VPC already knows how to send traffic between two notes, right? It already knows what the physical address is of the node, what the associated IP addresses of the note, it knows how to get traffic from node A to node B or node B to node C, whatever the case may be.

However, you want to be sure that you allow the encapsulation protocol through all your security groups or your network access control lists, right? So if you are using encapsulation protocol, you have to make sure that you allow that encapsulation protocol through any sort of AWS based firewalls, right? Security groups or network access control lists. If you're using IP-in-IP, which is common in Calico environments, please note that it can be detected as either protocol number 4 or protocol number 94. And so you'll want to make sure that both of those are allowed through your security groups. VXLAN is a UDP based encapsulation protocol and the default port is 4789. Geneve, which is a newer UDP based encapsulation protocol, and it is used by the Antrea CNI, as an example. Uses port 6081.

And because the CNI is handling the encapsulation, the wrapping and unwrapping of traffic, you do not need to disable the source destination check. To the VPC, the traffic looks like node-to-node traffic. And the traffic is destined for a node. So when node A sends traffic to node B, it wraps into the encapsulation protocol and sends it to node B. So you do not need to enable or disable these sources at destination check. One other consideration for both of networking with and without encapsulation, is that if there is a routing demon involved that is distributing routes via some sort of network protocol, you do need to make sure to allow that routing protocol to be passed through any of your security groups and your network access control lists. So if you're using BGP, for example, that runs on TCP port 179. And so you'd want to make sure that you allow that through your security groups or network access control list.

Now some CNIs also support a so-called hybrid operation, right? That uses both unencapsulated and encapsulated traffic. One example of this is in Calico, where we have this thing called cross subnet mode. And in the cross subnet mode, configuration, traffic within a given subnet is unencapsulated, so it is routed directly. Pod IP is exposed, all of that. And traffic between subnets is encapsulated. So when you go to move from subnet one to subnet two, then the CNI would wrap it encapsulation protocol around that. This can be useful in some cases, but when configured operate in hybrid mode, basically what you're getting here is that all of the considerations for both modes of operation are going to apply. Right? And so you have to think about both of the issues or all of the issues that are involved in with encapsulation and without encapsulation and address all of them when running a hybrid mode.

All right. Now, AWS does offer their own CNI plugin. It's called AWS VPC CNI plugin. And this is an AWS optimized and AWS specific CNI plugin that users can choose to leverage. And it is used by default in the AWS managed Kubernetes offering EKS. Now, this does have some advantages because of the way that it is structured. It can offer excellent integration into the rest of the AWS ecosystem. One example of this is for, let's say you wanted to use a VPC flow logs, which are a way of capturing network traffic flows within a VPC. And you wanted to use VPC flow logs with your Pod-to-Pod traffic, for example, right? You wanted to be able to analyze and look at network traffic flows between Pods. This CNI would allow you to do that because the way that it's structure., It does allow you to still continue to use something like Calico for network policy enforcement.

And Eric, did a great couple of lessons on network policy earlier in this course. So refer to those for more details on how never policy works. So you do get sort of best of both worlds, if you will, excellent integration to the ecosystem and the ability to continue to use things like Calico for policy enforcement, but there are some disadvantages. There are some potential limitations on Pod density, the way that the VPC CNI plugin works, it uses elastic network interfaces or ENIs to carry Pod IPS and there's limit on how many IPS and ENIs that can be used. And I'll talk about that in more detail in just a moment.

There's also a variable latency on the release and reuse of Pod IPS when you have churn in your workloads, when workloads shut down and then restart again. So let's look at both of these concerns in a little more detail. So regarding the Pod density concerns, you're going to be running Kubernetes on a particular instance type, t3.large, m5.large, whatever the case may be, right? Each of these instance types has a limit on how many ENIs are supported for that instance type. And not only a limit on how many ENIs are supportive of that instance type, but how many IP addresses can be associated with ENI. Right? And so, depending on the instance type that you're using, you may run into a limit on how many Pods you can host on a particular node, even if you have more resources available on that node. So the example that I use here is the m5.large, the m5.large per the AWS documentation supports three ENIs. And they have a maximum limit of 10 IP addresses per ENI.

Now the first address on each ENI is used by the VPC CNI plugin itself, and can't be assigned to a Pod. So the way this works out, as an example for an empire of large is you have three ENIs, 10 IPs each, but you take away one of those. So you take away three of those addresses because the first address on each ENI is used by the plugin, and that gives you a total of 27 IP addresses that that instance can support. Okay. And what that means then is because each Pod is assigned an IP address directly from the VPCs address space, right? Then your Pod density is limited to the number of IP addresses that the node can handle. In this case, you can get a maximum of 27 IP addresses and therefore you are limited to 27 Pods on that `m5.large node.

So even if you had plenty of CPU and plenty of memory capacity remaining on that node, as soon as you hit 27 Pods, that's it. All right? And it's also important to keep in mind, even if I didn't call it out right here on the slide, that when you're running demon set, that's going to consume an IP address and that's going to further reduce the number of Pods that users can schedule onto these nodes. So you have to be very careful. Now the limit of ENIs and the limit of IP addresses per ENI, scales up and it's variable based on different instance types. So there are ways to get around this and you can scale it up high enough that you should be fine, but you want to be sure that you go into this aware of that limitation and plan accordingly.

Regarding, or as for the IP release, reuse concerns. We mentioned already that the API latency to program routes into the route table is variable, right? It makes the API call and then the API call, you'll get an immediate return to the API call, but the amount of time that it takes for that to actually get processed in the background, it may be a second. It may be five seconds, maybe 15 seconds just depends. Right? And so there's no guaranteed sort of SLA in regards to when that happens. Same thing happens here, when the VPC CNI makes the API calls to release an IP address. So let's say you shut down a Pod, right? And then you're going to start a new one. So when that Pod is removed and API call is made to release the IP address of that Pod is using.

And then when you schedule a new Pod, then the CNI makes an API call to get a new IP address. In environments where there's a lot of churn, it's possible to run into IP address starvation issues, because IP addresses are not getting released quickly enough to be returned to the pool for other Pods to use. If your environment is low churn, your workloads are pretty stable, this may not be an issue for you. If however, you have a high turn environment, you could run into issues here. So just plan accordingly.

All right. So that's our discussion of Kubernetes networking on AWS. Let's turn our attention now to looking at Microsoft Azure. And we'll cover many of the same topics that we just discussed on AWS, some of the considerations, but as you'll see, Azure has its own set of considerations, aside from AWS that you'll want to consider if you are running self-managed Kubernetes on Azure VMs. So starting again by looking at the core and networking concepts, very much like AWS, we have these location-based region and availability zone concepts. So there are regions and availability zones within the Azure network and their SDN accounts for these things. You have this thing called VNet, and the VNet is the basic building block of Azure networking. This VNet like an AWS VPC is tied to a region and it does span multiple availability zones.

Within the VNet you will have one or more subnets. Key difference here from AWS is that the subnets are able to span multiple availability zones. And so you can't use subnets as a way to sort of limit workloads to a particular AZ. You also have network security groups or MSGs, these are ways of limiting network traffic or controlling network traffic so you can specifically allow or deny traffic using an industry. And NSG is associated with a subnet or with a network interface. And then finally you have route tables, route tables are linked to both again, subnets and gateways that control traffic out of the VNet.

Now like AWS, the SDN that Azure uses, does know about and control the IP address to Mac address mapping. And so there is no such thing as ARP broadcasts. In this case, however, OS level ARP caches do not show useful data, it appears that if you look at the ARP caches, it will look as if all traffic has to go through the VNet router, even traffic on the same subnet. And so you will never see sort of the Mac address for another instance or workload in the same subnet, you'll only see the Mac address for the VNet router. And then, so this doesn't really provide any sort of useful information.

By default instances are only going to accept traffic destined for them. So when you spin up an Azure VM, then that Azure VM by default will only accept traffic destined for that particular VM. And the term on AWS, we used was source of destination check, here on Azure we just call that IP forwarding. Which in a sense does make sense, but it is a little bit confusing because we're talking about an Azure level configuration and not an OS level configuration, which is also often referred to as IP forwarding.

So when it comes to routing without encapsulation, so routing directly between nodes in Kubernetes, running on Azure, again, anytime you are routing without encapsulation, the underlying network fabric, in this case the VNet, is involved in the routing process. And again, therefore that means the VNet needs to know the routes, so it needs to know the route to every subnet that's involved, and you have to turn on IP forwarding on all of the nodes network interfaces. So for each Kubernetes node, then for that Azure network interface, you have to enable IP forwarding. And again, this isn't an Azure level configuration we're referring to here, not a iOS level configuration. Right?

Item number two here, configuring IP forwarding is pretty straightforward. It can be controlled programmatically by making API calls. It can be done using any number of your infrastructure as code tools like Terraform or others. So this is pretty straightforward. Item number one, the concerns here are very much like with on AWS. In this case, though, the limit on the number of routes and the number of route tables is much higher, so that's not the primary concern. Primary concern here is the variable latency on the manipulation of the route tables. So when you make an API call, which the Azure cloud provider can do, so if you're running your Kubernetes cluster with the Azure cloud provider enabled, then it can make these calls into Azure and program the routes, but the time that it takes for those routes to show up is variable and therefore can at times create odd and very difficult to troubleshoot issues.

When you're routing with encapsulation, as on AWS and a typical on premises data center network, the underlying network fabric, the VNet in this case is not involved in the routing process, so you do need to make sure that you allow your encapsulation protocol through all of the network security groups. If there is a routing protocol involved like BGP, you need to make sure that you allow that traffic through all the network security groups. Very important node right here, though, is you have to use a TCP or UDP based encapsulation protocol. This is because the Azure VNet router, which controls all traffic in the VNet, recall we just talked about how looking at the ARP caches only shows the address of the VNet router. That VNet router will only forward TCP, UDP and ICNP traffic. It does not forward any other IP protocols. So if you're trying to use a CNI that uses something like IP-in-IP, Calico is a good example here, it's not going to work on Azure. Period.

The Azure vignette router just won't forward the IP-in-IP traffic, your nodes will not be able to communicate and you'll have a problem, right? Both VXLAN and Geneve are UDP based so those are fine, but this would also apply to other encapsulations like GRE, which is an IP protocol, and so you couldn't use that as well. You do not have to enable IP forwarding on the nodes Azure network interface again, because when you're routing with encapsulation, it is node-to-node traffic, so the traffic coming in on a node is destined for that node and therefore Azure will pass it up.

But I just want to remind you that second bullet right there about using only TCP or UDP based encapsulation protocols, that's a big one. You really want to make sure that your CNI is using an encapsulation protocol that will be forwarded by the Azure VNet router. Otherwise, you're just going to be stuck. As with AWS, Azure also offers their own optimized and specific CNI plugin, they call it the Azure VNet CNI plugin, and this plugin assigns Pod IP addresses directly from the VNet's address space.

So in that regard is very much like the AWS VPC CNI plugin. One key difference between those two is that with the AWS CNI plugin, it appears that you can use secondary ciders. So IP addresses that are from a separate network space that can be associated with a subnet it does not appear to be possible with the VNet CNI plugin to do that. So Pod IPS will come from the same pool as node IPS directly from the VNet subnet. You can use network policies directly with the VNet CNI plugin, or you can connect it with something like Calico for network policy support. One advantage of this approach is that you do not need any Nat to connect to external systems or networks and external meaning external to the Kubernetes cluster.

So this makes it potentially easier to to know where traffic is coming from. So if you have Pods in a Kubernetes cluster running on Azure, and they're connecting to an external database, for example, you'll be able to see the addresses directly and know where it's coming from. The challenge here is in terms of like firewalling that using network security groups or something of that nature, because the IP addresses assigned to Pods are going to be dynamic and Pods are going to come and go, right? So the Pod's IP is considered a femoral. And because they came from the same pool as the nodes, you don't necessarily have a good way of saying, I want to allow traffic from this range of not that range.

There are also some disadvantages. It does require more significant upfront planning of your IP address space and your subneting, because all of your Pods are going to consume addresses out of your subnets. You want to make sure that you size your subnets to accommodate the largest number of Pods that you think your cluster will ever host. Right? So if you think you're going to get up to a thousand Pods on your cluster, then you have to make sure that your subnet arrangement allows for a thousand IP addresses. Otherwise you'll run out of IP addresses and the IP addresses will become a constraint on the number workloads that you can run in your Kubernetes cluster.

The value in terms of like the number of IP addresses that can be assigned to a given node starts out very low. 30, right? And that's the default value. So if you don't change that, then by default, you're going to be limited to 30 Pods per node. Even if you're running very, very large nodes and have plenty of resources, you're going to cap out at 30 Pods per node. Fortunately, that's easy to change and it does go quite high. But the key value here is that if you want to change that value, you have to deploy new worker nodes, so you can't change that value on the fly for existing worker nodes in a cluster. You have to deploy a new worker nodes with the new values, migrate workloads over then retire the old worker nodes. So there's is a little more work required upfront and perhaps a little less flexibility on day two and continuing on.

All right, thanks for hanging in there. I know we've covered a lot of material. We only have a few more things to discuss, and then we'll be wrapping up this course. So let's take a look at our final considerations for running Kubernetes on the public cloud. So a few other things to keep in mind. Managed Kubernetes offerings. I mentioned this earlier, like EKS on Amazon or AKS on Azure, are typically going to use that cloud providers specific CNI plugin, and therefore will inherit all of the advantages and disadvantages of that cloud providers, specific CNI plugin. You'll also want to make sure that if you are going to go down that route and you want support for something like network policies, either their specific CNI plugin supports network policies, or that you're going to end up bringing in something like Calico to work in a policy only mode to enforce policies on that platform.

Also important to note here is that public clouds are the best place to use, or maybe not the best place, but an ideal place to use services of type of LoadBalancer. And what this means is that when the cloud provider is configured and enabled, so these are the AWS cloud provider or the Azure cloud provider. And again, I refer you to Eric Shanks course on cloud providers for more details on how that works. Then the cloud provider can automatically go and spin up a LoadBalancer in the public cloud and configure it automatically to expose any service objects in the Kubernetes cluster. So you can define a service and you can set the service type as LoadBalancer, and what'll happen is, it will create a LoadBalancer, it'll create the associated cluster IP and node port, and then it will forward automatically register instances or VMs into the LoadBalancer and then configure the appropriate forwarding so that as traffic comes into LoadBalancer, it gets directed to an instance on the backend where Pods may be running.

So this is super, super useful, sort of like real easy, right? All you have to do is to find the service of type LoadBalancer, and then you're good to go. But you do want to be aware that the public cloud platforms typically charge for those LoadBalancers and so you want to be aware of those additional costs, and again, know that this requires the appropriate card provider to be installed and working.

So if you did set up Kubernetes and you didn't enable the cloud provider, then you won't be able to use services of type LoadBalancer along with a bunch of other functionality, and unfortunately there's no way to sort of enable the cloud provider on the fly, this does require setting up a new cluster with a cloud provider installed and working from the very beginning and then migrating your workloads over. All right, and that wraps up this course, or this lesson rather on considerations for networking with Kubernetes in the public cloud. I do hope that you find the content useful and that it is informative. Thanks so much for watching.

Give Feedback

Help us improve by sharing your thoughts.

Links

Share