Kubernetes Load Balancers Guide
Civo Academy - Understanding Load Balancers in Kubernetes
Learn how to access your application through the LoadBalancer type in Kubernetes and the potential vulnerabilities of using it. Consider using an ingress or service mesh instead.
Introduction to load balancers
Welcome back to another Kubernetes service introduction video. In this video, we're going to look at the type load balancer. In the previous videos, we looked at why we need Kubernetes services, how they work, what they do, and the different types. The last one is the load balancer type that we will discuss now. Let's assume we have a Kubernetes cluster, K3s running on Civo. And we have here different nodes within our Kubernetes cluster.
So, now we have external traffic. It is the traffic through which we want to access our Kubernetes cluster. So, external traffic is coming to our Kubernetes cluster to allow us to access the application. The application, however, is here sitting and chilling within our different pods that are running within our nodes.
We can set up a cluster IP, for instance, a default type for our Kubernetes service. And we can then serve the traffic coming in here through additional rules, something like an ingress, something like external load balancers, and so on, to access our application running within our pods and our nodes.
Accessing an application through load balancer
So, if I now go ahead and I open. If I do localhost 3000, it won't do anything right now because I'm not forwarding it. So, it will just be stuck in loading here and fail. However, I now want to access through the external IP and remember that I'm not doing port forwarding. As discussed in previous videos, I'm just specifying the external IP and the port I'm using where my application runs. So, now I'm accessing it, and I can see here, again, my Hello World. So, the load balancer allows me to dynamically route the traffic through the service to my different pods here. So, I could be deleting my pods, and it would still work.
So, let's delete one of those pods. These pods have been spun up in addition to the others to serve my LoadBalancer. So, I can go ahead and use kubectl to delete my pods. I'm going to delete it by using
kubectl delete [POD_NAME] -n example, and I'm going to delete this pod in -n example. So, while this is deleting, I will still be able to access my application even though one of the pods has been deleted and spun up again because the load balancer type doesn't care. It doesn't care which pods I'm going to connect. It's just going to connect to any pods that are right now healthy and in a running state.
So, as you can see, they are running so that I can connect to them. Additionally, it sets up a DaemonSet, and this is the DaemonSet having all these different pods that serve my load balancer in this case. So, as you can see, I can now access my application from the outside world, from anywhere. Now, as you can see, this is not secure. This is nothing I want to leave open lying around. This is something I want to use in an instance. If I want to provide my application to the outside world, I will use an ingress service mesh to provide additional configuration and do it securely.