Skip to main content

Wrapping it up

Understanding the AWS Load Balancer Controller​

Let's review what we learned about how the AWS Load Balancer Controller works with Application Load Balancers (ALBs). Understanding this architecture helps with future troubleshooting.

Core Components and Flow​

  1. Controller Operation

    • The controller continuously watches for ingress events from the Kubernetes API server
    • When it detects qualifying ingress resources, it begins creating corresponding AWS resources
    • The controller manages the full lifecycle of these AWS resources
  2. Application Load Balancer (ALB)

    • An ALB is created for each ingress resource
    • Can be configured as internet-facing or internal
    • Subnet placement is controlled through annotations
    • Requires proper IAM permissions for creation and management
  3. Target Groups

    • Created for each unique Kubernetes service defined in the ingress
    • Support IP-mode targeting for direct pod registration
    • Health checks are configurable via annotations
    • Multiple target groups can be used for different services
  4. Listeners

    • Created for each port specified in ingress annotations
    • Default to standard ports (80/443) when not specified
    • Support SSL/TLS certificate attachment
    • Can be configured for HTTP/HTTPS traffic
  5. Rules

    • Created based on path specifications in ingress resources
    • Direct traffic to appropriate target groups
    • Support path-based and host-based routing
    • Can be prioritized for complex routing scenarios

Common Troubleshooting Areas​

Through this module, we encountered and fixed several typical issues:

  1. Subnet Configuration

    • Public subnets require the kubernetes.io/role/elb=1 tag
    • Private subnets require the kubernetes.io/role/internal-elb=1 tag
    • Subnets must be properly associated with route tables
  2. IAM Permissions

    • Service account requires appropriate IAM role
    • Role must have necessary permissions for ALB operations
    • Common permissions include creating/modifying load balancers and target groups
  3. Service Configuration

    • Service selectors must match pod labels exactly
    • Service ports must align with container ports
    • Service name must match ingress backend configuration

Best Practices​

When working with the AWS Load Balancer Controller:

  • Always verify subnet tags before creating internet-facing ALBs
  • Use explicit annotations to control ALB behavior
  • Monitor controller logs for troubleshooting
  • Verify service endpoint registration
  • Use meaningful labels for services and pods
  • Document custom configurations
tip

The AWS Load Balancer Controller documentation is an excellent resource for advanced configurations and troubleshooting.