In a previous post, we had a look at the different types of Load Balancers available in AWS. Today we focus on Kubernetes and how K8s can (or should) use Load Balancers in AWS.
When deploying Kubernetes (K8s) on AWS, the choice of load balancer depends on the specific requirements of our application. AWS provides multiple types of load balancers, and Kubernetes can integrate with them through its service types, such as
LoadBalancer. Here’s a guide on which AWS load balancers to use with Kubernetes:1. Application Load Balancer (ALB)
As we saw in that previous post, the ALB works at layer 7, and its ideal for HTTP/HTTPS traffic and applications that require advanced routing features.When it comes to its use in K8s, ALB is well-suited for Kubernetes applications that need layer 7 features, like path-based or host-based routing. This type of routing capabilities is perfect for an Ingress Controller. As a matter of fact, Kubernetes has an ALB Ingress Controller, which allows you to use ALB with Ingress resources. This controller enables us to configure routing rules, SSL/TLS termination, and WebSocket support directly from our Kubernetes manifests.
Also, ALB supports dynamic scaling, which is beneficial for handling varying traffic loads in Kubernetes environments.
In summary, the ALB ingress controller is the type of Load Balancer we would use when our application requires sophisticated routing, SSL termination at the load balancer, or WebSocket support.
2. Network Load Balancer (NLB)
The NLB is designed for high-performance and low-latency applications that need to handle a large volume of TCP or UDP traffic. NLB operates at layer 4, making it faster and capable of handling very high throughput and low-latency requirements. Operating at layer 4 means that routing rules cannot be based on HTTP content like paths or headers. It also means an NLB cannot be use for SSL termination. NLB routing is based on TCP/IP, that is, in information like source and destination IPs.That’s why an NLB is not a good fit for an ingress controller. However, when it comes to K8s, there’s another use case for routing besides the ingress controller. Our K8s cluster will have at least 2 Worker Nodes in a production environment, which means there has to be something on top of these worker nodes to distribute the incoming traffic among them.
This is when the NLB comes into play. The NLB will sit on top of our K8s cluster and will provide an external hostname for incoming traffic. This is how external traffic gets first to the NLB and the NLB will redirect the traffic to our Ingress controller. Once it gets to the K8s cluster the ingress will do its magic.
What if we wanted to use multiple ingress controllers? Does that mean we would need to create and configure an NLB for each ingress controller we set up in K8s? Fortunately, NLB is integrated with Kubernetes through the
LoadBalancer service type. When you create a Kubernetes service of the type LoadBalancer, AWS can provision an NLB to route traffic to your application. It provides static IP addresses and can preserve the client’s IP, which is useful for some applications. 3. Classic Load Balancer (CLB)
The CLB is an older generation load balancer that operates at both layer 4 (TCP/UDP) and layer 7 (HTTP/HTTPS). While Kubernetes can integrate with CLB using theLoadBalancer service type, it is generally not recommended for new deployments because ALB and NLB offer more modern features and better performance. CLB is simpler and may be sufficient for legacy applications or basic load balancing needs. We should use CLB only if we have legacy systems that specifically require it, or for very basic load balancing needs. It’s not recommended for new Kubernetes deployments.
Setting Up:
- ALB Ingress Controller: Deploy the AWS ALB Ingress Controller in your Kubernetes cluster to manage ALB resources via Kubernetes Ingress objects.
- Service Type
LoadBalancer: For NLB or CLB, create Kubernetes services with the typeLoadBalancer. Kubernetes will automatically provision the appropriate AWS load balancer and manage the backend configuration.
Summary:
- ALB: Best for HTTP/HTTPS workloads with advanced routing needs.
- NLB: Best for high-performance, TCP/UDP workloads with minimal latency. We will use it outside our K8s cluster to redirect external traffic to our ingress controller(s).
- CLB: In general, we should not use it for Kubernetes. It works with K8s but we should use it only for legacy or simple use cases, where we cannot use NLB or ALBs.