AWS Elastic Kubernetes Service: running ALB Ingress controller

By | 04/21/2020

AWS ALB Ingress Controller for Kubernetes – is a Kubernetes controller which actually controls AWS Application Load Balancers (ALB) in an AWS account when an Ingress resource with the alb annotation is created in a Kubernetes cluster.

This Ingress resource in its turn describes an ALB Listeners configuration with SSL termination or traffic routing to the cluster’s WorkerNodes.

More in the documentation here:

Ingress controller types

AWS ALB Ingress controller supports two policy types for traffic routing –  the instance mode and the ip mode:

  • instance mode: traffic will be accepted on an ALB, then routed to a NodePort Service, then routed to pods inside of the cluster
  • ip mode: traffic will go to an ALB first, then is routed directly to pods in a cluster. The documentation states that it’s necessary to install the AWS CNI plugin for Kubernetes, but in AWS EKS it works out of the box

See more documentation here>>>.

eksctl – create a cluster

At first, let’s create a testing cluster:

eksctl create cluster --profile arseniy --region eu-north-1 --name eks-alb-testing
[ℹ]  eksctl version 0.15.0
[ℹ]  using region eu-north-1
[ℹ]  setting availability zones to [eu-north-1b eu-north-1c eu-north-1a]
[ℹ]  subnets for eu-north-1b - public: private:
[ℹ]  subnets for eu-north-1c - public: private:
[ℹ]  subnets for eu-north-1a - public: private:
[ℹ]  nodegroup "ng-c408bab3" will use "ami-0d40170cbe0b51e62" [AmazonLinux2/1.14]
[ℹ]  using Kubernetes version 1.14
[ℹ]  creating EKS cluster "eks-alb-testing" in "eu-north-1" region with un-managed nodes
[ℹ]  node "" is ready
[ℹ]  node "" is ready
[ℹ]  kubectl command should work with "/home/setevoy/.kube/config", try 'kubectl get nodes'
[✔]  EKS cluster "eks-alb-testing" in "eu-north-1" region is ready

IAM OIDC provider

Documentation –

The OIDC integration is necessary for the ServiceAccount used for the Controller, see more at

Create it:

eksctl --profile arseniy --region=eu-north-1 utils associate-iam-oidc-provider --cluster eks-alb-testing  --approve
[ℹ]  eksctl version 0.15.0
[ℹ]  using region eu-north-1
[ℹ]  will create IAM Open ID Connect provider for cluster "eks-alb-testing" in "eu-north-1"
[✔]  created IAM Open ID Connect provider for cluster "eks-alb-testing" in "eu-north-1"


aws --profile arseniy. --region=eu-north-1 eks describe-cluster --name eks-alb-testing --query "cluster.identity.oidc.issuer" --output text

Or via AWS UI > Identity providers:

ALB IAM policy

The next step is to add an IAM policy that will give access for a pod with the ALB Ingress Controller in an AWS Account to make an API-calls to the AWS Core to create and configure Application Load Balancers.

It can be created using AWS CLI with the following command:

aws --profile arseniy --region=eu-north-1 iam create-policy --policy-name ALBIngressControllerIAMPolicy --policy-document

Or can be added to a CloudFormation template using the AWS::IAM::Role resource.

In the command’s output you’ll have an ARN – “Arn”: “arn:aws:iam::534***385:policy/ALBIngressControllerIAMPolicy” – keep it, we will use it in the following step.

ALB Ingress IAM Role


1 iamserviceaccount (kube-system/alb-ingress-controller) was excluded

In the official documentation, the order is a bit different: first, it suggests to create an RBAC-role and RoleBinding, and after that – iamserviceaccount.

In my case, this led to the error during creating a new ServiceAccount “kube-system/alb-ingress-controller” – eksctl told that it is already present and skips it despite the --override-existing-serviceaccounts option:

[ℹ] eksctl version 0.15.0
[ℹ] using region eu-north-1
[ℹ] 1 iamserviceaccount(s) that already exist (kube-system/alb-ingress-controller) will be excluded
[ℹ] combined exclude rules: kube-system/alb-ingress-controller
[ℹ] 1 iamserviceaccount (kube-system/alb-ingress-controller) was excluded (based on the include/exclude rules)
[!] serviceaccounts that exists in Kubernetes will be excluded, use --override-existing-serviceaccounts to override
[ℹ] no tasks

After containing AWS SUpport (love these guys – the best support overall Cloud providers, in my opinion) we’ve changed the order: first, create the IAM-role, and after that – RBAC Role and binding.

But – let’s go ahead.

Check the currently configured cluster – just in case:

kubectl config current-context


Now create the IAM role using the eksctl, and using the ARN of the policy created above – attach it to this role (will create an additional CloudFormation stack):

eksctl --profile arseniy --region=eu-north-1 create iamserviceaccount --name alb-ingress-controller --namespace kube-system  --override-existing-serviceaccounts --approve --cluster eks-alb-testing --attach-policy-arn arn:aws:iam::534***385:policy/ALBIngressControllerIAMPolicy
[ℹ]  eksctl version 0.15.0
[ℹ]  using region eu-north-1
[ℹ]  1 task: { 2 sequential sub-tasks: { create IAM role for serviceaccount "kube-system/alb-ingress-controller", create serviceaccount "kube-system/alb-ingress-controller" } }
[ℹ]  building iamserviceaccount stack "eksctl-eks-alb-testing-addon-iamserviceaccount-kube-system-alb-ingress-controller"
[ℹ]  deploying stack "eksctl-eks-alb-testing-addon-iamserviceaccount-kube-system-alb-ingress-controller"
[ℹ]  created serviceaccount "kube-system/alb-ingress-controller"

Wait for its provision:

ALB Ingress ServiceAccount

Create a ServiceAccount named alb-ingress-controller in the kube-system namespace, add ClusterRoleBinding and ClusterRole named alb-ingress-controller with access rules:

kubectl apply -f created created
serviceaccount/alb-ingress-controller created


kubectl -n kube-system get serviceaccounts | grep alb
alb-ingress-controller               1         32s

Start ALB Ingress Controller

We can launch it using the deployment file from here –, which will spin up a pod using the Docker image.

Clone it to your workstation:


Open for edit and in the block:

        - name: alb-ingress-controller

Add the following arguments:

  • --cluster-name=eks-alb-testing
  • --aws-vpc-id=vpc-06a182dd0e5ef1b70
  • --aws-region=eu-north-1

VPC ID can be found in the Outputs of the root stack – eksctl-eks-alb-testing-cluster (check the AWS: CloudFormation – Nested Stacks and stacks parameters Import/Export post about how those stacks were created):

So the file has to look like the next:

Apply it to run ALB Ingress Controller:

kubectl apply -f alb-ingress-controller.yaml
deployment.apps/alb-ingress-controller created

Check its pod:

kubectl -n kube-system get pod
NAME                                     READY   STATUS    RESTARTS   AGE
alb-ingress-controller-c47448d84-49tsc   1/1     Running   0          36s

And the controller’s logs:

kubectl logs -n kube-system deployment.apps/alb-ingress-controller -f
AWS ALB Ingress controller
Release:    v1.1.4
I0325 14:18:03.203499       1 leaderelection.go:205] attempting to acquire leader lease  kube-system/ingress-controller-leader-alb...
I0325 14:18:03.211928       1 leaderelection.go:214] successfully acquired lease kube-system/ingress-controller-leader-alb
I0325 14:18:03.312309       1 controller.go:134] kubebuilder/controller "level"=0 "msg"="Starting Controller"  "controller"="alb-ingress-controller"
I0325 14:18:03.412486       1 controller.go:154] kubebuilder/controller "level"=0 "msg"="Starting workers"  "controller"="alb-ingress-controller" "worker count"=1

Well – it is started, looks like even works – nice!

But is it really working? Let’s test.

ALB Ingress controller Testing

For the test – let’s spin up an additional deployment which will run a pod with NGINX and the Kubernetes Ingress Service in front of it.

So, need to create:

  1. Kubernetes deployment for pods
  2. a NodePort Service to route traffic to pods
  3. and Ingress object with the internet-facing ALB annotation – this has to trigger our ALB Controller to create an AWS Application Load Balancer


kubectl apply -f nginx-testing-app.yml
deployment.apps/eks-alb-testing-deployment created
service/eks-alb-testing-web-service created
ingress.extensions/eks-alb-testing-web-ingress created

Check the controller logs:

E0325 14:24:06.627453       1 controller.go:217] kubebuilder/controller "msg"="Reconciler error" "error"="no object matching key \"default/eks-alb-testing-web-ingress\" in local store"  "controller"="alb-ingress-controller" "request"={"Namespace":"default","Name":"eks-alb-testing-web-ingress"}
I0325 14:24:09.257834       1 security_group.go:36] default/eks-alb-testing-web-ingress: creating securityGroup dbd770cc-default-eksalbtes-09fa:managed LoadBalancer securityGroup by ALB Ingress Controller
I0325 14:24:09.665207       1 loadbalancer.go:191] default/eks-alb-testing-web-ingress: creating LoadBalancer dbd770cc-default-eksalbtes-09fa
I0325 14:24:10.636180       1 targets.go:80] default/eks-alb-testing-web-ingress: Adding targets to arn:aws:elasticloadbalancing:eu-north-1:534***385:targetgroup/dbd770cc-fe1e32fc96596dcf2c1/ef783b9fead58965: i-0622ff000570f32c7:31095, i-062329ba6419ba845:31095
I0325 14:24:10.821148       1 listener.go:110] default/eks-alb-testing-web-ingress: creating listener 80
I0325 14:24:13.171590       1 rules.go:82] default/eks-alb-testing-web-ingress: modifying rule 1 on arn:aws:elasticloadbalancing:eu-north-1:534***385:listener/app/dbd770cc-default-eksalbtes-09fa/979c262ea2e12983/455a07658116adcd
I0325 14:24:13.192456       1 rules.go:98] default/eks-alb-testing-web-ingress: rule 1 modified with conditions [{    Field: "path-pattern",    Values: ["/*"]  }]

Check Ingress resources:

kubectl get ingress -o wide
NAME                          HOSTS   ADDRESS                                                                   PORTS   AGE
eks-alb-testing-web-ingress   *   80      114s

And try to connect to it:

curl -I
HTTP/1.1 200 OK
Date: Wed, 25 Mar 2020 14:26:27 GMT
Content-Type: text/html
Content-Length: 612
Connection: keep-alive
Server: nginx/1.17.9
Last-Modified: Tue, 03 Mar 2020 14:32:47 GMT
ETag: "5e5e6a8f-264"
Accept-Ranges: bytes


Also published on Medium.