ALB Ingress is based on Alibaba Cloud's Application Load Balancer (ALB) service. It provides a unified entry point for services in a cluster. Compared to Nginx Ingress, ALB Ingress is a fully managed service. You do not need to perform maintenance. It automatically detects changes in Ingress resources in a Kubernetes cluster and distributes traffic to backend services based on predefined rules. Additionally, ALB Ingress features a robust elastic scaling mechanism. It automatically adapts to dynamic traffic changes, which ensures stable system operation.
Before You Read
To better understand ALB Ingress features, you can read this document before using ALB Ingress.
Before reading this document, you can read the official Kubernetes Ingress documentation to understand the basic concepts of Ingress and Ingress Class.
How ALB Ingress Works
ALB Ingress involves the following basic concepts:
ALB Ingress Controller: This component manages Ingress resources. It dynamically retrieves changes to Ingress and AlbConfig resources from the cluster API Server and updates ALB instances accordingly. Unlike the NGINX Ingress Controller, the ALB Ingress Controller serves as the control plane for ALB instances. It manages ALB instances but does not process user traffic directly. Instead, ALB instances forward user traffic. The ALB Ingress Controller dynamically retrieves changes to Ingress resources from the cluster API Server and updates ALB instances based on the forwarding rules defined in Ingress.
An AlbConfig is a cluster-level Custom Resource Definition (CRD) created by the ALB Ingress Controller. Each AlbConfig contains parameters that define the configuration for a single ALB instance. An ALB instance serves as the entry point for traffic and forwards requests to backend services. It is fully managed by Application Load Balancer (ALB). Unlike the Nginx Ingress Controller, ALB Ingress requires no operations and maintenance (O&M) and provides greater elasticity.
IngressClass: An IngressClass defines the association between an Ingress and an AlbConfig.
Ingress: In Kubernetes, Ingress is a resource object that defines external traffic routing and access rules. The ALB Ingress Controller monitors changes in Ingress resources and updates ALB instances to achieve traffic forwarding.
Service: In Kubernetes, pods are temporary and dynamic resources. A Service provides a stable, unified entry point for pods with the same functionality. Other applications or services can communicate with backend pods by accessing the Service's virtual IP address (VIP) and port, without needing to track potential pod changes. For more information about Service, see Service Management.
Manually modifying ALB instance configurations through the load balancing console may be overwritten by the ALB Ingress automatic synchronization mechanism. This can lead to configuration loss or even instance unavailability. Do not directly modify ALB instance configurations managed by ACK through the load balancing console without following official guidance.
Refer to the following diagram to understand the logical relationship between ALB instances and ALB Ingress:
ALB Ingress Usage Flow
ALB Ingress seamlessly integrates with cloud-native services, offering rich features and ease of use. The ALB Ingress usage flow is as follows:
To complete the above process, see Create and Use ALB Ingress to Expose Services.
When to use ALB Ingresses instead of NGINX Ingresses
ALB Ingresses are managed by Alibaba Cloud. Each ALB instance supports up to one million QPS, tens of millions of concurrent connections, automatic scaling, and 99.995% service uptime. NGINX Ingresses are self-managed and require manual scaling. For a detailed comparison, see Comparison between an NGINX Ingress and an ALB Ingress.
ALB Ingresses are a better fit in the following scenarios:
Persistent connections
Applications that require frequent interaction, such as IoT, Internet finance, and online gaming, rely on persistent connections. ALB Ingresses apply configuration changes through hot reloading without interrupting persistent connections. NGINX Ingresses must reload processes when configurations change, which temporarily closes persistent connections.
High concurrency
IoT services maintain a large number of concurrent connections from terminal devices. ALB Ingresses run on the Cloud Network Management platform and manage sessions at scale. Each ALB instance supports tens of millions of connections.
High QPS
Promotional activities and breaking events require high QPS capacity. ALB Ingresses support automatic scaling and automatically add virtual IP addresses as QPS increases. Each ALB instance supports up to one million QPS.
Workload fluctuations
E-commerce and gaming services experience large workload fluctuations. ALB supports the pay-as-you-go billing method and uses load balancer capacity units (LCUs). Fewer LCUs are consumed during off-peak hours, and ALB scales automatically without manual resource reservation.
Zone and geo-redundancy
For applications requiring high availability, such as social networking and streaming media, use Distributed Cloud Container Platform for Kubernetes (ACK One) to create ALB multi-cluster gateways and manage multi-cluster traffic with ALB Ingresses to implement active geo-redundancy and active zone-redundancy.
ALB Ingress Regions and Zones
For ALB Ingress supported regions and zones, see ALB Supported Regions and Zones.
Recommendations for ALB Ingress in Large-Scale Clusters
ALB Ingress drives configuration changes through Alibaba Cloud OpenAPI. In scenarios with large clusters, many ALB instances, and numerous Ingress rules, operations such as forwarding rule updates and backend server group synchronization may experience delays when you perform batch operations (such as batch creation or deletion of Ingress, large-scale pod rolling upgrades, or frequent Endpoint updates). The configuration effective time relates to the ALB OpenAPI response time. The number of configurable resources is subject to ALB quota limits.
If your business needs require large-scale changes, you must complete capacity assessment and stress testing in advance. Plan the change pace to avoid service interruption or access anomalies due to processing delays or exceeding quotas.
ALB Ingress Limits
For ALB Ingress quota limits, see ALB Quota Calculation Method.
When using Flannel, ALB Ingress only supports forwarding requests to NodePort and LoadBalancer type Services. It does not support ClusterIP type Services.
ALB Ingress Controller Change Log
For ALB Ingress feature change logs, see ALB Ingress Controller.