Amazon Elastic Kubernetes Service (EKS) is a powerful tool for deploying, managing, and scaling containerized applications using Kubernetes on AWS. One of the critical components of deploying scalable and highly available applications in EKS is the integration with Application Load Balancers (ALB). However, a common challenge faced by users is the ALB's inability to auto-discover subnets effectively. Understanding why this occurs and how to mitigate it is crucial for leveraging the full potential of EKS with ALBs.

Understanding EKS and ALB Integrations

Kubernetes and AWS

Kubernetes is an open-source platform designed to automate the deployment, scaling, and operation of application containers across clusters of hosts. Amazon EKS is a managed Kubernetes service that simplifies the process of running Kubernetes on AWS without needing to install and operate your Kubernetes control plane.

Application Load Balancer (ALB)

An Application Load Balancer is part of the AWS Elastic Load Balancing service that manages inbound traffic for applications across multiple targets, such as Amazon EC2 instances, in multiple Availability Zones. It offers advanced routing and routing-based on more flexible conditions, including path and host-based routing.

Integration Challenges

A significant challenge encountered during the integration of ALBs with EKS is the load balancer's inability to auto-discover subnets dynamically. This issue is crucial since correct subnet allocation ensures ALB spans multiple Availability Zones, contributing to the application's fault tolerance and availability.

Subnet Auto-discovery Mechanism

Subnets are subdivisions within VPCs (Virtual Private Clouds), and when deploying an ALB in conjunction with EKS, at least two subnets across different Availability Zones are required.

How Auto-Discovery is Supposed to Work

When an ALB is created, it should ideally query the availability of subnets tagged for load balancer usage, ensuring that the load balancer gets provisioned in each specified zone. The tag convention uses `kubernetes.io/role/elb` for load balancers and `kubernetes.io/role/internal-elb` for internal load balancers, enabling EKS to identify applicable subnets.

Common Auto-Discovery Issues

1. Improper Tagging: The most prevalent cause of failed auto-discovery is improper or missing subnet tags. Every subnet intended for ALB across zones must be appropriately tagged; otherwise, it isn't recognized during provisioning.
2. IAM Role and Permissions: The IAM Role associated with your EKS may lack necessary permissions to interact with EC2 subnets, resulting in failures to query or discover subnets.
3. Configuration Parameters: Incorrect security group associations or VPC configurations in launching services or clusters can also disrupt subnet auto-discovery.

Diagnosing and Mitigating Discovery Issues

Steps for Troubleshooting

1. Review Subnet Tags: Verify that each public subnet in the VPC has the required tags (`kubernetes.io/role/elb`). Ensure there are at least two such subnets in different Availability Zones.
2. Check IAM Permissions: Review IAM policies associated with your EKS and ensure necessary permissions (`ec2:DescribeSubnets`, `ec2:DescribeVpcs`, etc.) are included.
3. VPC and Security Group Configurations: Confirm that the VPC and security groups associated with your EKS cluster allow for necessary inbound and outbound traffic for ALB and backend instances.

Example IAM Policy Permissions

• Use Managed Node Groups: Managed node groups automatically handle subnet and security group configurations, minimizing manual errors.
• Automate via Infrastructure as Code (IAC): Tools like AWS CloudFormation or Terraform can ensure consistent subnet tagging and resource provisioning, reducing human error.