Introduces Ingress basics, how the ALB Ingress controller works, and usage notes for ALB Ingress on ACK.
Key terms
| Term | Description |
|---|---|
| Ingress | Defines rules for routing external HTTP/HTTPS traffic to cluster Services. |
| Service | Provides a stable network identity for a group of replicated pods. |
| ALB Ingress controller | Translates Ingress resources into ALB configuration — creating instances, listeners, and routing rules automatically. |
| AlbConfig | A custom resource definition (CRD) that configures an ALB instance and its listeners. Each AlbConfig maps to one ALB instance. |
How it works
When an Ingress resource changes, the controller detects it via the Kubernetes API server and performs these operations:
-
Creates an ALB instance.
-
Configures listeners on the instance.
-
Creates Ingress rules.
-
Configures backend server groups.
The three core resources:
-
Service — Defines a stable network endpoint that Ingresses route traffic to, abstracting an application across replicated pods.
-
Ingress — Defines reverse proxy rules that route HTTP/HTTPS requests to Services by host name and URL path.
-
AlbConfig — Configures the underlying ALB instance. The controller generates one AlbConfig per managed ALB instance.
Key capabilities
The controller supports:
| Capability | Description |
|---|---|
| Complex routing | Route traffic by host name and URL path. |
| Automatic certificate discovery | Retrieve and apply TLS certificates for HTTPS listeners automatically. |
| Multiple protocols | HTTP, HTTPS, and QUIC. |
| NGINX Ingress compatibility | Compatible with existing NGINX Ingress configurations. |
| Layer 7 elasticity | Handle high-volume traffic with ALB's built-in scaling and load balancing. |
Usage notes
ALB instances that serve Ingresses are fully managed by the ALB Ingress controller. Do not modify them in the ALB console. Manual changes may conflict with controller state and cause service interruptions.
For ALB quotas, see Functions and features.