As Kubernetes gains popularity as the go-to container orchestration platform, managing traffic and load balancing for applications running on Kubernetes clusters becomes crucial. Kubernetes Ingress provides a convenient way to expose services to external users, but it lacks advanced routing capabilities and native integration with cloud provider load balancers; This is where the Application Load Balancer (ALB) Ingress Controller comes into play.

This technical blog will explore the ALB Ingress Controller, its benefits, and how it simplifies the management of Kubernetes Ingress resources. You will dive into its architecture, deployment considerations, and configuration options. By the end of this blog, you will have a solid understanding of how to leverage the ALB Ingress Controller to streamline Kubernetes application traffic management.

Table of Contents

1. Overview of Kubernetes Ingress
2. Introduction to ALB Ingress Controller
3. Benefits of ALB Ingress Controller
4. ALB Ingress Controller Architecture
5. Deploying the ALB Ingress Controller
6. Configuring and Managing Ingress Resources
7. Advanced Routing and Traffic Management
8. Integration with AWS Services
9. Conclusion

 

1. Overview of Kubernetes Ingress

Before diving into the ALB Ingress Controller, let’s briefly understand the concept of Kubernetes Ingress. Kubernetes Ingress is an API object that provides an entry point for external traffic to access services within a Kubernetes cluster. It acts as a layer 7 (application layer) load balancer, routing incoming requests to the appropriate services based on rules and configurations.

In a Kubernetes cluster, services are typically accessed through a Service object, which is a stable endpoint for internal communication. However, by default, services are not directly accessible outside the cluster; This is where the Ingress resource comes into play, providing an external access point and allowing traffic to be routed to different services based on various criteria.

Some Key Aspects of Kubernetes Ingress

1. Ingress Controller: An Ingress Controller is a Kubernetes component responsible for implementing the Ingress rules and managing the incoming traffic. It typically runs as a separate pod within the cluster and is responsible for configuring the underlying load balancer or as a reverse proxy to handle the external traffic.
2. Ingress Resource: The Ingress Resource is defined using a YAML or JSON file and specifies the routing rules for incoming requests. It describes the hostnames, paths, and associated back-end services for traffic routing.
3. Rules and Path Matching: Ingress rules define how incoming requests should be routed based on the specified hostnames and paths. Path matching can be based on exact matches, prefix matches, or regular expressions. Ingress rules can also be used to implement traffic splitting, SSL termination, or other advanced routing mechanisms.
4. TLS Termination: Ingress supports TLS termination, allowing secure communication using HTTPS. Certificates can be configured for specific hostnames or wildcard domains, enabling encryption and authentication for external traffic.
5. Annotations: Ingress resources can be further customized and extended using annotations. Annotations provide additional instructions to the Ingress Controller or other components involved in the routing process. They can be used for configuring timeouts, setting up redirects, enabling rate limiting, or implementing other custom behavior.
6. Ingress Controllers and Implementations: Various Ingress Controllers are available for Kubernetes, each using different load-balancing solutions or reverse proxies. Some popular options include NGINX Ingress Controller, ALB Ingress Controller, and Istio.

Overall, Kubernetes Ingress simplifies the management of external access to services within a cluster by providing a declarative way to define and manage routing rules. It allows for flexible and granular traffic routing, load balancing, and SSL termination, along with enabling the integration of external services with the Kubernetes ecosystem.

2. Introduction to ALB Ingress Controller

The ALB Ingress Controller is a Kubernetes controller that manages AWS ALB resources and integrates them with Kubernetes Ingress. It replaces the default Ingress controller in Kubernetes and provides enhanced functionality, including advanced routing, SSL termination, and integration with AWS services. It leverages the AWS Application Load Balancer, a highly available and scalable load-balancing solution.

The ALB Ingress Controller is a component in the Kubernetes ecosystem that enables the use of Application Load Balancers (ALBs) as ingress resources for the applications. In Kubernetes, an ingress is a collection of rules that define how incoming traffic should be routed to services within the cluster.

The ALB Ingress Controller specifically integrates with Amazon Web Services (AWS) Elastic Load Balancer (ELB) service, allowing you to leverage the advanced features and capabilities of ALBs for routing and load balancing traffic to Kubernetes services.

3. Benefits of ALB Ingress Controller

The ALB Ingress Controller offers several benefits over the default Ingress controller:

• Integration with AWS Services: ALB integrates seamlessly with other AWS services, such as AWS Certificate Manager, AWS WAF, and Amazon CloudWatch, for enhanced security and monitoring.
• Auto Scaling: ALB integrates with Kubernetes Horizontal Pod Autoscaler, automatically scaling back-end services based on the incoming traffic.

Some Key Benefits of ALB Ingress Controller

1. Purpose: The primary purpose of the ALB Ingress Controller is to create and manage ALBs, on your behalf, based on Kubernetes’ ingress resources. It automatically configures the ALB with the necessary routing rules, target groups, listeners, and other settings required to expose applications to external traffic.
2. Advanced Routing: ALBs provide advanced routing capabilities, such as path-based routing, host-based routing, and HTTP/HTTPS traffic termination with SSL certificates. Using the ALB Ingress Controller, you can take advantage of these features to create more complex routing configurations for applications.
3. Integration with Target Groups: The ALB Ingress Controller integrates with AWS Target Groups, which route requests to registered targets, such as EC2 instances or containers. Each Kubernetes service or pod can be associated with a specific target group, allowing the ALB to distribute traffic accordingly.
4. SSL/TLS Termination: The ALB Ingress Controller supports SSL/TLS termination, allowing you to offload the encryption and decryption of HTTPS traffic at the ALB level; This means that you can secure applications using SSL certificates without the need for individual certificates on each pod or service.
5. Scalability and High Availability: ALBs are designed to be highly scalable and fault-tolerant. As well as, the ALB Ingress Controller takes advantage of these capabilities, ensuring that the applications can handle increased traffic and providing high availability by automatically managing the underlying ALB infrastructure.
6. Annotations and Customization: The ALB Ingress Controller provides additional annotations that can be used to customize the behavior of the ALBs created for applications. These annotations enable defining routing rules, configuring SSL policies, setting up redirects, and more.

Overall, the ALB Ingress Controller simplifies exposing Kubernetes applications to external traffic by leveraging the power of ALBs. Also, it provides advanced routing capabilities, scalability, and high availability while reducing the operational complexity of managing load balancers manually.

4. ALB Ingress Controller Architecture

The ALB Ingress Controller architecture consists of several components, including the Ingress Controller pod, the Target Group Binding controller, and the AWS ALB Ingress Controller. Basically, this section will provide you an in-depth explanation of each component and their interactions.

Overview of the ALB Ingress Controller Architecture

1. Kubernetes Ingress Resources: Ingress resources are defined within Kubernetes to specify how incoming traffic should be routed to services. As well as, the ALB Ingress Controller watches for changes to these resources and manages the corresponding AWS ALB configurations accordingly.
2. Ingress Controller Pod: The ALB Ingress Controller runs as a pod within the Kubernetes cluster. Also, it communicates with the Kubernetes API server to watch for changes in Ingress resources.
3. AWS ALB API: The ALB Ingress Controller interacts with the AWS Application Load Balancer (ALB) API to create and manage ALB resources such as target groups, listeners, rules, and target instances.
4. ALB Configuration: When an Ingress resource is created or updated, the ALB Ingress Controller translates the Ingress rules into ALB-specific configurations. As well as, it creates or updates the necessary ALB resources based on the defined routing rules.
5. Target Groups and Targets: ALB Ingress Controller creates target groups in AWS ALB to represent back-end services in the Kubernetes cluster. Basically, it then registers target instances (such as pods or nodes) associated with those services as targets within the target groups.
6. Load Balancing: The ALB routes incoming traffic based on the defined rules, such as host-based routing, path-based routing, or SSL termination. As well as, it distributes the traffic across the registered target instances in the target groups using the configured load-balancing algorithm.
7. Ingress Controller Service: The ALB Ingress Controller exposes an Ingress Controller Service within the Kubernetes cluster. Also, this service provides an entry point for incoming traffic and acts as the endpoint for the ALB to forward requests.
8. ALB Health Checks: Basically, the ALB Ingress Controller periodically performs health checks on the registered target instances to ensure they are responsive. Unhealthy instances are automatically removed from the target group, and new healthy instances are registered.

Overall, the ALB Ingress Controller bridges the gap between Kubernetes Ingress resources and AWS ALB, providing seamless integration for routing traffic to Kubernetes services using ALB’s advanced load balancing features.

5. Deploying the ALB Ingress Controller

Basically, this section will guide you through the process of deploying the ALB Ingress Controller in your Kubernetes cluster. As well as, it will cover installation methods, prerequisites, and configuration options for different deployment scenarios. In addition, you are deploying the ALB Ingress Controller using Helm.

Prerequisites

• An existing Amazon EKS cluster
• An existing AWS Identity & Access Management (IAM) OpenID Connect (OIDC) provider for your cluster OR Deploy the IAM OIDC provider.
  The ALB Ingress Controller requires an IAM OIDC provider to authenticate and authorize itself with AWS.
  To deploy the OIDC provider, you can use the following command:
  $ eksctl utils associate-iam-oidc-provider --region --cluster --approve
• Latest version of AWS CLI v2.9.0 , KUBECTL v1.24 , Helm v3.0

Steps to Deploy AWS Load Balancer Controller to the EKS Cluster

1. You need an IAM policy for the load balance controller that allows it to call Amazon APIs.
2. Use the following command to download the IAM policy.
   curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.4.4/docs/install/iam_policy.json
3. Now you will create an IAM policy using the downloaded file
   iam_policy.json
aws iam create-policy \
--policy-name LoadBalancerControllerIAMPolicy \
--policy-document file://iam_policy.json

Steps to Get the Cluster’s OIDC Provider ID

That we use in creating policy for the role; you are attaching on AWS EKS Load Balancer Controller role.

Using the AWS CLI and kubectl

• Retrieve the cluster’s OIDC provider ID and store it in a variable using the below command, replacing with your own cluster name.
  oidc_id=$(aws eks describe-cluster --name --query "cluster.identity.oidc.issuer" --output text | cut -d '/' -f 5)
• Check if an IAM OIDC provider with the cluster’s ID is already in your account using the following command.
  aws iam list-open-id-connect-providers | grep $oidc_id | cut -d "/" -f4
• If the data arrives again, you already have an IAM OIDC provider for your cluster. If there is no result, you must make an IAM OIDC provider. In your case, if you get the output, use it in trusted entities of the EKSLoadBalancerControllerRole IAM role.
• Create a policy using the following content. Replace and with AWS account ID and AWS region, respectively. Also, replace with the output you get in the above step.
  cat >aws-load-balancer-role-trust-policy.json <<EOF
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated":"arn:aws:iam:::oidc-provider/oidc.eks..amazonaws.com/id/"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks..amazonaws.com/id/:aud": "sts.amazonaws.com",
"oidc.eks..amazonaws.com/id/:sub": "system:serviceaccount:kube-system:aws-load-balancer-controller"
}
}
}
}
}
EOF

Create the IAM role

aws iam create-role \
--role-name EKSLoadBalancerControllerRole \
--assume-role-policy-document file://"aws-load-balancer-role-trust-policy.json"

• Attach the IAM policy, you previously created in step 1, to the IAM role created above using AWS CLI. Replace with your account ID and execute the below command.
  aws iam attach-role-policy \
--policy-arn arn:aws:iam::11xxxxxx33:policy/LoadBalancerControllerIAMPolicy \
--role-name EKSLoadBalancerControllerRole
• Now you will create an aws-load-balancer-controller-service-account.yaml file. Replace with AWS account ID, then run the following commands.
  cat >aws-load-balancer-controller-service-account.yaml <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/name: aws-load-balancer-controller
name: aws-load-balancer-controller
namespace: kube-system
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam:::role/EKSLoadBalancerControllerRole
EOF
• Create a service account for AWS Load Balancer Controller pods using the yaml file created above using the following command.
  kubectl apply -f aws-load-balancer-controller-service-account.yaml
  The created service account is annotated with the IAM role you created named EKSLoadBalancerControllerRole.

Deploying the AWS Load Balancer Controller on the cluster using Helm

• You can add the eks-charts repository using the following command.
  helm repo add eks https://aws.github.io/eks-charts
• Update your local repo using the following command.
  helm repo update
• Use the following AWS load balancer controller image if you are deploying in us-east-1 and replace with us-east-1.
  602401143452.dkr.ecr..amazonaws.com/amazon/aws-load-balancer-controller:v2.4.4
• If you’re deploying to any AWS Region other than us-east-1, add the following flag to the helm command, replacing 602401143452 and with the values for your AWS Region listed in Amazon container image registries. If you pulled the image and pushed it to your repository, replace the full registry and repository with your own.
  --set image.repository=602401143452.dkr.ecr..amazonaws.com/amazon/aws-load-balancer-controller
• Replace with your own cluster. In the following command, aws-load-balancer-controller is the Kubernetes service account you created in a previous step.
  helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
-n kube-system \
--set clusterName=my-eks-cluster \
--set serviceAccount.create=false \
--set serviceAccount.name=aws-load-balancer-controller
--set
image.repository=602401143452.dkr.ecr..amazonaws.com/amazon/aws-load-balancer-controller

For instance, you are using the following command:
helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
-n kube-system \
--set clusterName=dev-eks-cluster \
--set serviceAccount.create=false \
--set serviceAccount.name=aws-load-balancer-controller \
--set image.repository=602401143452.dkr.ecr.us-east-1.amazonaws.com/amazon/aws-load-balancer-controller

You can verify using the below command that the controller is deployed successfully
kubectl get deployment -n kube-system aws-load-balancer-controller

You will get the following output
NAME                             READY     UP-TO-DATE     AVAILABLE     AGE
aws-load-balancer-controller     2/2       2              2             80s


To uninstall the ALB ingress controller, use the following command
helm list -n kube-system
helm uninstall -n kube-system

6. Configuring and Managing Ingress Resources

After deploying the ALB Ingress Controller, you must configure and manage Ingress resources to define routing rules and expose services. Also, this section will help you understand how to create and manage Ingress resources, including various annotations and configuration options.

Create an Ingress Resource: Basically, define an Ingress resource in Kubernetes to configure the routing rules for your applications. As well as, an Ingress resource specifies the hostnames, paths, and back-end services to route incoming traffic. Here’s an example of an Ingress resource.

YAML:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example-ingress
annotations:
kubernetes.io/ingress.class: alb
alb.ingress.kubernetes.io/target-type: ip
alb.ingress.kubernetes.io/load-balancer-name: non-prod-alb
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/subnets: subnet-1,subnet-2
alb.ingress.kubernetes.io/security-groups: sg-example
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}]'
alb.ingress.kubernetes.io/ssl-redirect: '443'
spec:
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: example-service
port:
number: 80

7. Advanced Routing and Traffic Management

The ALB Ingress Controller provides advanced routing capabilities, such as host-based routing, path-based routing, URL rewrites, and redirect rules.

For example:

Path-based routing:
spec:
rules:
- host: example.com
http:
paths:
- path: /service-1
pathType: Prefix
backend:
service:
name: service-1
port:
number: 80
- host: example.com
http:
paths:
- path: /service-2
pathType: Prefix
backend:
service:
name: service-2
port:
number: 80

Host-based routing:
spec:
rules:
- host: example-1.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: service-1
port:
number: 80
- host: example-2.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: service-2
port:
number: 80

8. Integration with AWS Services

Basically, one of the key advantages of the ALB Ingress Controller is its seamless integration with AWS services. Also, this section will explore how to leverage features like AWS Certificate Manager, AWS WAF, and SSL certificate management, along with monitoring your Kubernetes applications.

You can add the following annotation to configure ACM:

annotations:
alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-east-1::99999999999:certificate/69daxxx58-bxxd-xxx9-b384-d4fxxxb6

Conclusion

In conclusion, the ALB Ingress Controller is a powerful tool that simplifies the management of Kubernetes Ingress resources while providing advanced routing and integration capabilities with AWS services. Adopting the ALB Ingress Controller can enhance the scalability, reliability, and security of your Kubernetes applications running on AWS. As well as, you can now leverage the ALB Ingress Controller and streamline your application traffic management in Kubernetes with the knowledge from this blog.

In addition, by implementing the ALB Ingress Controller, you can take full advantage of the powerful features and seamless integration provided by AWS, ensuring a smooth and efficient traffic management experience for your Kubernetes applications.

Gophers Lab specializes in DevOps Automation Services with one of the best DevOps Team which has deep expertise on all major cloud platforms, such as AWS, GCP, and Azure. You can contact us to outsource DevOps projects or hire dedicated DevOps engineers.

REFERENCES:
ALB ingress controller:
https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html

AWS CLI:
https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html

HELM:
https://docs.aws.amazon.com/eks/latest/userguide/helm.html

KUBECTL:
https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html