Kubernetes: End-to-end traffic on AWS EKS using ALB & Istio service mesh
In this article, we discover seamless end-to-end traffic management on AWS EKS using ALB and Istio. From setting up ALB as an Ingress Controller to leveraging Istio's powerful service mesh capabilities, we'll guide you through the entire process step-by-step. Whether you're a beginner or an experienced practitioner, this comprehensive guide will equip you with the knowledge to optimize traffic routing, apply security policies, and ensure smooth application deployment on your AWS EKS cluster.
At a high level, the traffic flow will be orchestrated as follows:
Client --(TLS)--> AWS ALB --(TLS)-->Istio Ingress Gateway --(mTLS)--> Microservice
What is AWS ALB Ingress Controller?
The AWS ALB Ingress Controller extends the functionality of standard Kubernetes Ingress by integrating with AWS ALB. It automatically provisions and configures ALBs in the AWS cloud based on the Ingress resources defined in the Kubernetes cluster. This allows you to utilize the advanced features of ALBs, such as path-based routing, SSL termination, and load balancing, for your Kubernetes applications.
Unlike Ingress Nginx where the traffic from Application Load Balancer will be redirected to the Ingress controller pod, the traffic from Application Load Balancer is routed to EKS node (node port type) and then go to the Kubernetes pods. In this case, the ALB ingress controller will connect to Kubernetes API server to create and update AWS LB resources based on the definition in ingress manifest.
Following the steps illustrate how ingress resources are created:
The controller actively monitors Ingress events from the Kubernetes API server. Upon identifying Ingress resources that meet its criteria, it initiates the automatic creation of corresponding AWS resources.
An ALB is created for the Ingress resource.
TargetGroups are created for each backend specified in the Ingress resource.
Listeners are created for every port specified as Ingress resource annotation. If no port is specified, sensible defaults (
443) are used.
For every path specified in your Ingress resource, individual rules are generated. These rules guarantee that traffic directed to a particular path is accurately routed to the corresponding TargetGroup that was created for that purpose.