NOTE: This controller is in beta state as we attempt to move to our first 1.0 release. The current image version is 1.0-beta.7. Please file any issues you find and note the version used.
The AWS ALB Ingress Controller satisfies Kubernetes ingress resources by provisioning Application Load Balancers.
This project was originated by Ticketmaster and CoreOS as part of Ticketmaster's move to AWS and CoreOS Tectonic. Learn more about Ticketmaster's Kubernetes initiative from Justin Dean's video at Tectonic Summit.
This project was donated to Kubernetes SIG-AWS to allow AWS, CoreOS, Ticketmaster and other SIG-AWS contributors to officially maintain the project. SIG-AWS reached this consensus on June 1, 2018.
To get started with the controller, see our walkthrough.
The following diagram details the AWS components this controller creates. It also demonstrates the route ingress traffic takes from the ALB to the Kubernetes cluster.
This section describes each step (circle) above. This example demonstrates satisfying 1 ingress resource.
[1]: The controller watches for ingress events from the API server. When it finds ingress resources that satisfy its requirements, it begins the creation of AWS resources.
[2]: An ALB (ELBv2) is created in AWS for the new ingress resource. This ALB can be internet-facing or internal. You can also specify the subnets it's created in using annotations.
[3]: Target Groups are created in AWS for each unique Kubernetes service described in the ingress resource.
[4]: Listeners are created for every port detailed in your ingress resource annotations. When no port is specified, sensible defaults (80 or 443) are used. Certificates may also be attached via annotations.
[5]: Rules are created for each path specified in your ingress resource. This ensures traffic to a specific path is routed to the correct Kubernetes Service.
Along with the above, the controller also...
- deletes AWS components when ingress resources are removed from k8s.
- modifies AWS components when ingress resources change in k8s.
- assembles a list of existing ingress-related AWS components on start-up, allowing you to recover if the controller were to be restarted.
ALB Ingress controller supports two traffic modes:
- Instance mode
- IP mode
By default, Instance mode is used, users can explicitly select the mode via alb.ingress.kubernetes.io/target-type annotation.
Ingress traffic starts at the ALB and reaches the Kubernetes nodes through each service's NodePort. This means that services referenced from ingress resources must be exposed by type:NodePort in order to be reached by the ALB.
Ingress traffic starts at the ALB and reaches the Kubernetes pods directly. CNIs must support directly accessible POD ip via secondary IP addresses on ENI.
For details on how to setup the controller and external-dns (for managing Route 53), see setup.
You must have the Helm App Registry plugin installed for these instructions to work.
helm registry install quay.io/coreos/alb-ingress-controller-helm
Once the ALB Ingress Controller is running, you're ready to add ingress resources for it to satisfy. Examples can be found in the examples directory.
All ingress resources deployed must specify security groups and subnets for the provisioned ALB to use. See the Annotations section of the documentation to understand how this is configured.
Docs are being written. For now, we have:
Ingress Resources: Covers how ingress resources work in relation to The ALB Ingress Controller.
Configuration: Covers configuration of the ALB Ingress Controller.
For details on building this project, see BUILDING.md.
