Mastering AWS Load Balancer Controller: Exploring Ingress Sharing and Target Group Binding (Part 2)

Published in

Hyand Blog

5 min readJul 15, 2024

In the first part, we deep dive into the concepts of Ingress Sharing and Target Group Binding, exploring how these cool features optimize load balancer efficiency and flexibility.

In this part, we will walk you through the practical aspects of deploying the cluster and using the AWS Load Balancer Controller to understand how you can leverage its capabilities to streamline load balancer management in your K8s cluster.

Architectural Overview

The above architectural diagram shows the working AWS Load Balancer Controller performs once installed. It evaluates the Kubernetes API server for updates to Ingress resources. If it detects changes, it automatically updates resources such as the Application Load Balancer, listeners, target groups, and listener rules.

Understanding Architecture Working

To demonstrate, we’ll deploy four web applications in two different namespaces (This will also help us to understand a diversified case study). Then, we’ll show how to group different ingresses that can be configured and grouped to share a single ALB. We’ll use group.name annotations to enable the grouping of multiple ingress resources.

To make it more accurate and understandable the four variants of a web application render a web page with different background colors. The blue and green apps run in the blue-green-ns namespace, and the orange and purple apps run in the orange-purple-ns namespace.

Once these apps are deployed it will create two ingresses named blue-green-ingress and orange-purple-ingress. Ingress rules configure the path-based routing.

In the above diagram, when ALB receives traffic, it routes requests to Pods based on the defined ingress rules. The blue-green-ingress has the routing rules to route traffic to blue and green web apps and deploys in the blue-green-ns namespace. Similarly, the orange-purple-ingress has the routing rules to route traffic to orange and purple web apps and deploys in namespace orange-purple-ns.

Let’s See Demo In Action

You’ll need the following things to follow along:

An Amazon Elastic Kubernetes Service (Amazon EKS) Cluster with an existing node group
AWS Load Balancer Controller installed in the cluster
Tools required on a machine with access to the AWS and Kubernetes API Server. AWS CLI, eksctl, kubectl, Helm, Docker

The code is available on GitHub. Start by cloning the code and deploy the sample application:

git clone https://github.com/bhanvendrasingh/AWS-Loadbalancer-Controller.git
kubectl apply -f AWS-Loadbalancer-Controller/ingress-grouping/

Once resources are created it's good to check the status of resources in namespace blue-green-ns.

kubectl -n blue-green-ns get all

The Pods should be running:

NAME                             READY   STATUS    RESTARTS   AGE
pod/blue-app-9b7bd7578-gjqrm     1/1     Running   0          1d00h
pod/blue-app-9b7bd7578-sgjvd     1/1     Running   0          1d00h
pod/green-app-695664547f-lmq4b   1/1     Running   0          1d00h
pod/green-app-695664547f-lrjh8   1/1     Running   0          1d00h

Similarly, verify that the application Pods are operational in the orange-purple-ns namespace.

We also have two Ingress resources:

kubectl get ingress -A

You can see that both Ingress resources have the same ADDRESS:

NAMESPACE          NAME                    CLASS   HOSTS   ADDRESS                                                            PORTS   AGE
blue-green-ns      blue-green-ingress      alb     *       k8s-appcolorlb-9527f4eb57-1779454964.us-west-2.elb.amazonaws.com   80      5m52s
orange-purple-ns   orange-purple-ingress   alb     *       k8s-appcolorlb-9527f4eb57-1779454964.us-west-2.elb.amazonaws.com   80      5m25s

Let's get the address assigned to the ALB:

kubectl get ingress blue-green-ingress -n blue-green-ns \
  -o=jsonpath="{'http://'}{.status.loadBalancer.ingress[].hostname}{'\n'}"

Navigate to the address of the application load balancer at /green path. you will notice a webpage with a green background indicating that the routing is working.

Similarly, the routing can be checked for different paths also using /blue, /orange, and /purple which will show their corresponding background color.

Let’s try to understand the point of having just one Application load balancer for both Ingresses. If you take a closer look at the ingresses you’ll notice that they include thealb.ingress.kubernetes.io/group.name annotation.

kubectl -n blue-green-ns describe ingress blue-green-ingress

annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/group.name: app-color-lb # This is used to group

The useful advantage of an IngressGroup is that you can assign Ingresses in multiple namespaces.

In the deployment, both blue-green-ingress and orange-purple-ingress use the same group app-color-lb.

Using the ALB controller reduces the number of ALBs which leads to cost savings.

Consider these points while working with IngressGroup

The first consideration when using IngressGroup in a multi-tenant environment is conflict resolution. When configuring ingress rules in ALB, the Controller uses the group.order field to specify the order of evaluation. If the user does not declare a value for group.order, the controller default value is 0.
The group.order field controls and sets the order in which rules are evaluated. Rules with lower order values are evaluated first. By default, the rule order between Ingresses within an IngressGroup is determined by the lexical order of the Ingress’s namespace.

Teams should use unambiguous values for group.name. The AWS Load Balancer Controller currently does not provide fine-grained control over access to an IngressGroup. So, don’t give your group a generic name like MyIngressGroup, because someone else in the cluster may create an Ingress with the same name and add it to your group.

Conclusion:

We covered the practical aspects of setting up an Amazon Elastic Kubernetes Service (Amazon EKS) cluster, setting up the AWS Load Balancer Controller, and using it to automate load balancing tasks in your Kubernetes cluster in this section. We showed how to optimize load balancer efficiency and resource utilization with Ingress Sharing and Target Group Binding by deploying web applications across multiple namespaces and configuring ingress resources.

Keep an eye out for the third installment of this blog series, where we will discuss how to use TargetGroupBinding to separate load balancers and Kubernetes resources, as we continue to examine load balancer efficiency and Kubernetes resource management. With your Kubernetes environment, this sophisticated feature gives you even more flexibility and control over load balancing.

We appreciate your participation as we explore the effectiveness of load balancers in AWS. In the next installment of this series, we’re excited to share even more best practices and insights. Keep checking back!