AWS Load Balancer Controller for Kubernetes

This study guide covers the implementation and management of the AWS Load Balancer Controller within Amazon EKS environments, a critical component for exposing Kubernetes applications via AWS Elastic Load Balancing (ELB) services.

Learning Objectives

Explain the role of the AWS Load Balancer Controller in an EKS cluster.
Differentiate between Kubernetes Ingress (ALB) and Service type: LoadBalancer (NLB) implementations.
Identify the two primary target types: Instance and IP.
Configure advanced features like ACM integration for TLS termination and multi-namespace support.
Understand the requirements for Fargate-based pod load balancing.

Key Terms & Glossary

AWS Load Balancer Controller: An open-source controller that manages AWS Elastic Load Balancers for a Kubernetes cluster.
Ingress Resource: A Kubernetes API object that manages external access to services in a cluster, typically HTTP/HTTPS.
TargetGroupBinding: A Custom Resource Definition (CRD) used by the controller to expose Kubernetes pods to an AWS Target Group.
OIDC Provider: OpenID Connect provider used by EKS to grant Kubernetes service accounts permissions to AWS resources via IAM roles.
Instance Mode: A routing mode where traffic is sent to the EC2 instances at a specific NodePort.
IP Mode: A routing mode where traffic is sent directly to the pod IP addresses (required for Fargate).

The "Big Idea"

The AWS Load Balancer Controller acts as a bridge between the Kubernetes Control Plane and the AWS Networking Stack. Instead of manually provisioning ELBs, developers define their requirements in standard Kubernetes manifests (Ingress or Services). The controller watches these manifests and automatically provisions, updates, or deletes the corresponding ALBs and NLBs in the AWS account, ensuring the network infrastructure scales alongside the application.

Formula / Concept Box

Kubernetes Resource	AWS Resource Provisioned	OSI Layer
`Ingress`	Application Load Balancer (ALB)	Layer 7
`Service (type: LoadBalancer)`	Network Load Balancer (NLB)	Layer 4
`Annotations`	Configuration Metadata	N/A

Hierarchical Outline

I. Controller Overview
- Formerly known as the ALB Ingress Controller.
- Software add-on installed via Helm or as an EKS add-on.
- Requires IAM Roles for Service Accounts (IRSA) for security.
II. Application Load Balancers (ALB)
- Triggered by Ingress resources.
- Supports path-based and host-based routing.
- ACM Integration: Automated TLS termination at the ALB level.
III. Network Load Balancers (NLB)
- Triggered by Service type: LoadBalancer.
- Handles ultra-high throughput and static IP requirements.
IV. Target Types
- Instance Type: Traffic routes to NodePort -> Kube-proxy -> Pod.
- IP Type: Traffic routes directly to Pod IP; requires Amazon VPC CNI.

Visual Anchors

Controller Logic Flow

Loading Diagram...

Routing: Instance vs. IP Mode

\begin{tikzpicture}[node distance=2cm] \draw[thick, fill=blue!10] (0,4) rectangle (3,5) node[pos=.5] {Load Balancer};

code

% Instance Mode
\draw[->, thick] (0.5,4) -- (0.5,2);
\draw[thick, fill=green!10] (-0.5,1) rectangle (1.5,2) node[pos=.5] {EC2 Node};
\draw[->, dashed] (0.5,1) -- (0.5,0);
\node at (0.5,-0.3) {Pod (Instance Mode)};

% IP Mode
\draw[->, thick] (2.5,4) -- (2.5,0);
\node at (2.5,-0.3) {Pod (IP Mode)};

\node at (1.5,5.5) {Traffic Distribution Path};

\end{tikzpicture}

Definition-Example Pairs

Annotation: A key-value pair in a Kubernetes manifest used to configure the AWS-specific settings of a load balancer.
- Example: alb.ingress.kubernetes.io/scheme: internet-facing tells the controller to create a public ALB instead of an internal one.
Fargate Pod: A serverless Kubernetes pod that does not run on a managed EC2 instance.
- Example: When deploying to Fargate, you must use alb.ingress.kubernetes.io/target-type: ip because Fargate pods do not have a host EC2 instance or NodePort.

Worked Examples

Example 1: Exposing a Web App via ALB

To expose a deployment named web-app using an ALB with TLS termination:

Request a Certificate: Use AWS Certificate Manager (ACM) to get an ARN for example.com.
Define Ingress:

yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-west-2:12345:certificate/abc
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-app
                port:
                  number: 80

Checkpoint Questions

Which Kubernetes resource type triggers the creation of an AWS Application Load Balancer?
Why is "IP mode" required for pods running on AWS Fargate?
Does the AWS Load Balancer Controller support the Classic Load Balancer (CLB)?
How does the controller authenticate with the AWS API to create resources?

Muddy Points & Cross-Refs

Cross-AZ Subnets: A common failure point is not having subnets in at least two Availability Zones tagged with kubernetes.io/role/elb: 1 (for public) or kubernetes.io/role/internal-elb: 1 (for private).
Security Groups: By default, the controller manages security groups for the ALB, but complex environments may require shared security group settings.
Deep Dive: For networking performance, refer to the VPC CNI documentation to understand how pod IPs are allocated within the VPC CIDR.

Comparison Tables

ALB vs. NLB via Controller

Feature	ALB (Ingress)	NLB (Service)
OSI Layer	Layer 7 (Application)	Layer 4 (Network)
Traffic Types	HTTP, HTTPS, gRPC	TCP, UDP, TLS
Routing	Path/Host-based	IP/Port-based
Target Types	Instance, IP	Instance, IP
Termination	SSL/TLS at ALB	SSL/TLS at NLB or Backend
Performance	High	Ultra-High (Millions of RPS)

AWS Load Balancer Controller for Kubernetes clusters