tutorial_alb_eks_cluster

Posted on 1 June 2020, updated on 21 December 2023.

An EKS instance can manage many applications thanks to its pod’s resources. Therefore, it can be very useful to use an Application Load Balancer (ALB) for your cluster to avoid overloading the pods hosting your applications. This article deals with an ALB instance implementation for an EKS cluster.

What is an Application Load Balancer?

An Application Load Balancer or ALB is a bridge between inbound traffic and several targets (for example several pods for one application). The objective is to have applications with high availability.

Implementation of an ALB instance for an EKS cluster

Architecture


We will now go over how to deploy an Application Load Balancer thanks to 2 ingress controllers: the ALB ingress controller and the Nginx Ingress controller.

Why do we have to use 2 ingress controllers? Because if we use the nginx ingress controller, we can not connect it directly to an Application Load balancer. And if we only use the ALB ingress controller, you will have an Application Load Balancer (ALB) instance for every ingress resource in the cluster, therefore, for every application inside your kubernetes cluster.

It may be a good thing if you want one load balancer for one application. In the case in which we have both: it is important to know the nginx ingress controller will manage all ingress objects of your applications in your EKS cluster and the ALB ingress controller will manage the life cycle of the Application Load Balancer instance (you can see it the following picture).

alb-architecture

Creation of an IAM role with ID provider


To implement an ALB instance, we need to deploy it inside your EKS cluster the helm chart ALB ingress controller, whereas, it needs to have some permissions to create an AWS resource (in our case, the ALB instance). Our helm chart will need an AWS role to deploy an ALB instance. To do it, we have to create an identity provider in the AWS IAM service.

What is an AWS identity provider?

An identity provider lets an external user have some permissions inside AWS. In our case, this identity provider will give permission to the ALB ingress controller Service Account.

To create it, we need 3 elements: the identity provider type, the audience, and the provider Url. The type will be “OpenId Connect” and the audience will be “sts.amazonaws.com”.

And to know the provider URL you will need to execute the following command:

aws eks describe-cluster --name <CLUSTER_NAME> --query “cluster.identity.oidc.issuer” --output text

Of course, change <CLUSTER_NAME> to the right EKS cluster name. Normally, you will have an output similar to the following line:

https://oidc.eks.<region>.amazonaws.com/id/EXAMPLE86F27C29EF05B482628D9790EA7066.

This output is the provider URL. We now have all the necessary information to create the identity provider.

In the AWS console go to the IAM service, and click on the “Identity provider” section. In this section, you can create an Identity provider as shown below:

identity-provider

Interface for creating an Identity Provider.

The helm chart service account has to use an IAM role with this identity provider. So, go to create a new IAM role now.

iam-role

In the section Identity provider, choose the right identity provider. Then, you will have to enter the audience: “sts.amazonaws.com”.

And add the following policies for this role:

Now we have a role that is ready to be used by a service account inside your Amazon EKS cluster. Now, we will have to install, first, the helm chart Nginx Ingress Controller and, secondly, the helm chart Alb Ingress Controller.

Tags for your subnets


Before installing the Ingress Controllers, you are going to tag your subnets. The ALB ingress controller needs the following tags for creating the ALB instance in the right subnets:

Install the helm chart Nginx Ingress Controller


To install it, we will add a new helm repository to your kubernetes cluster: “http://storage.googleapis.com/kubernetes-charts-incubator” thanks to the command:

You can choose the repository name you want. Now, we can install the helm chart with the following command:

We set many variables in the helm chart but the most important thing to know is that the nginx ingress controller service will be a nodeport service and not a ClusterIp service.

Install the helm chart ALB ingress controller


First, add the right helm repo for this chart:

helm add repo <repo_name> http://storage.googleapis.com/kubernetes-charts-incubator

Now, we are going to install the following helm chart “Alb Ingress Controller”.

Now install the helm chart:

You have to change the following variables: <CLUSTER_NAME> (with your kubernetes cluster name), <AWS_REGION> (with the right AWS region), <VPC_ID> (with the right vpc id) and <ROLE_ARN> (with the IAM role you created).

You can check if the pod is created correctly with the command:

kubectl get pods -n kube-system

Connect the ALB to the Nginx Ingress controller


To connect the ALB to the nginx ingress controller, we need to create a Kubernetes ingress resource in the namespace kube-system with the following configuration:

In this file, change <CERTIFICATE_ARN>, <SUBNETS_LIST> and <NGINX_INGRESS_CONTROLLER_SERVICE_NAME>.

In this configuration, we suppose you already have a valid certificate, so, if you don’t have one, create one now.

Execute this command to create this resource:

kubectl apply -f <path_to_ingress>/<ingress_file_name>.yaml

We just deployed an ALB that watches over the ingress resource we defined earlier, thus forwarding traffic from the ALB to the nginx ingress controller.

After following these steps, you have a new ALB instance on your AWS infrastructure. And your ALB instance is ready to be used, so, go to test it!