The ALB Ingress controller manages Layer 7 ingress traffic for Kubernetes clusters by integrating with Alibaba Cloud Application Load Balancer (ALB). This topic describes how the controller works, usage notes, and release notes.
How it works
When an Ingress resource changes, the controller detects the change from the API server and dynamically generates an AlbConfig object. It then performs the following operations in sequence:
Creates an ALB instance.
Configures listeners.
Creates routing rules.
Configures backend server groups.
The controller supports HTTP, HTTPS, and QUIC (Quick UDP Internet Connection) protocols, complex routing, and automatic certificate discovery. It is compatible with NGINX Ingresses and meets the requirements of cloud-native applications for ultra-high elasticity and balancing of heavy traffic loads at Layer 7.
To use ALB Ingresses to manage ingress traffic for an Alibaba Cloud Container Compute Service (ACS) cluster, deploy the ALB Ingress controller in the cluster.
Usage notes
For usage instructions, see ALB Ingress management.
Release notes
July 2025
| Version | Release date | Changes | Impact |
|---|---|---|---|
| v2.18.0-aliyun.1 | 2025-07-04 | Instance managed mode enabled by default; default certificate support; forwarding rule priority optimization; bug fixes | No impact on workloads |
v2.18.0-aliyun.1 — July 4, 2025
Enhancements:
Instance managed mode is now enabled by default. For ALB instances created via
AlbConfig, listeners and forwarding rules cannot be manually modified in the ALB console. This applies only to new ALB instances created after upgrading to this version. Existing and reused instances are unaffected.Default certificates can now be specified in
AlbConfigvia thedefaultCertificatefield.The priority sorting logic for forwarding rules is optimized, and the global uniqueness constraint on
orderis removed.A fixed waiting interval is implemented during
readinessGatechecks for unready pods.Validation logic for forwarding actions without termination types in admission webhooks is optimized.
Fixes:
Fixed a controller panic caused by flow control during asynchronous task queries.
Fixed an access control list (ACL) effectiveness conflict when HTTPS and QUIC listeners shared ports.
March 2025
| Version | Release date | Changes | Impact |
|---|---|---|---|
| v2.17.2-aliyun.1 | 2025-03-31 | Bug fixes for multi-namespace port conflicts and IPv4/IPv6 dual-stack | No impact on workloads |
| v2.17.1-aliyun.1 | 2025-03-18 | Gateway API v1.1.0 support | No impact on workloads |
| v2.16.0-aliyun.1 | 2025-03-04 | Breaking change: Persistent connections enabled by default for new server groups; canary release constraint change | No impact on workloads |
v2.17.2-aliyun.1 — March 31, 2025
Fixes:
Fixed a "port not found" error during server group reconciliation, which occurred when Ingress rules across multiple namespaces referenced Services with identical names but different ports.
Fixed incorrect parameter handling for IPv4 address queries in IPv4/IPv6 dual-stack cluster configurations.
Enhancements:
The maximum number of security groups processed per batch API call for add or remove operations is increased from 4 to 9.
API calls are now skipped when no new labels require configuration.
v2.17.1-aliyun.1 — March 18, 2025
Enhancements:
Gateway API v1.1.0 and later are now supported.
v2.16.0-aliyun.1 — March 4, 2025
Persistent connections are enabled by default for server groups created in this version. Existing server groups are not affected. Before upgrading, verify that this change does not impact your workloads.
Enhancements:
Persistent connections are enabled by default for new server groups.
Custom labels for listeners are now supported.
The cross-zone capability for server groups can now be disabled.
The overall tuning performance of Services is optimized.
ReadinessGate now updates pod status after all server groups are updated.
Canary release now requires two Ingresses or custom routing rules. Adding a canary annotation to an Ingress causes the system to report an error and retain the original forwarding rule.
January 2025
| Version | Release date | Changes | Impact |
|---|---|---|---|
| v2.15.2-aliyun.1 | 2025-01-24 | X-Forwarded-For and X-Forwarded-Host configuration; bug fixes | Not stated |
| v2.15.0-aliyun.1 | 2025-01-06 | ValidatingWebhook enabled by default; AScript support; security group creation for new ALB instances | No impact on workloads |
v2.15.2-aliyun.1 — January 24, 2025
Enhancements:
XForwardedForProcessingModecan now be set toX-Forwarded-For, and theX-Forwarded-Hostrequest header can be enabled viaXForwardedForHostEnabledin the listener'sXForwardedForConfig.FinalTypechecking in forwarding rule actions is now supported.clientTokencalculation is optimized during ALB instance creation.
Fixes:
Fixed a startup failure when
ValidatingWebhookConfigurationdoes not exist.Fixed a webhook verification failure when multiple values are specified for
alb.ingress.kubernetes.io/healthcheck-httpcode.
v2.15.0-aliyun.1 — January 6, 2025
Enhancements:
ValidatingWebhook is now enabled by default to precheck
AlbConfigand Ingresses.AScript is now supported.
Traffic throttling now supports fixed responses.
ssl-redirectand traffic throttling can now be used together.Session persistence for backend server groups now supports custom cookies.
Security groups can now be created for newly created ALB instances. This feature takes effect from 00:00:00 on February 25, 2025 (UTC+8).
Alerts for listener conflicts are improved.
Events are now generated when TLS certificate configuration is inconsistent with forwarding rules.
The validity of associated resources, such as bandwidth plans, can now be checked.
Certificates can now be configured in
AlbConfigfor gRPC authentication.
Fixes:
Fixed an issue where tags in
AlbConfigcould not be used aftercreatedbytags were enabled.Fixed continuous Service reconciliation errors in certain scenarios.
Fixed component crashes caused by
AlbConfigconfiguration errors.
May 2024
| Version | Release date | Changes | Impact |
|---|---|---|---|
| v2.13.1-aliyun.1 | 2024-05-10 | AlbConfig association event; server group creation bug fix | No impact on workloads |
v2.13.1-aliyun.1 — May 10, 2024
Enhancements:
A new event is generated when an
AlbConfigis not associated with an Ingress.
Fixes:
Fixed a server group creation failure when the namespace name starts with a number or when the namespace or Service name is excessively long.