NOTE: This controller is in alpha state as we attempt to move to our first 1.0 release. The current image version is 1.0-alpha.3. Please file any issues you find and note the version used.
The 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.
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.
This section details how traffic reaches the cluster.
As seen above, the ingress traffic for controller-managed resources starts at the ALB and reaches the Kubernetes nodes through each service's NodePort. This means that services referenced from ingress resource must be exposed on a node port in order to be reached by the ALB.
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.
Visit the docs directory for documentation on usage and configuration of the ALB Ingress Controller.
For details on building this project, see BUILDING.md.