Container Service for Kubernetes:ALB Ingress Overview

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.

Refer to the following diagram to understand the logical relationship between ALB instances and ALB Ingress:

ALB Ingress Usage Flow

To complete the above process, see Create and Use ALB Ingress to Expose Services.

Advantages of ALB Ingress

ALB Ingress is a fully managed service that provides powerful Ingress traffic management capabilities. NGINX Ingress is self-managed and is better suited for scenarios that require extensive gateway customization. NGINX Ingress and ALB Ingress differ in product positioning, architecture, performance, and security. For a detailed comparison, see Comparison between NGINX Ingress and ALB Ingress.

ALB Ingress has significant advantages over NGINX Ingress in the following scenarios:

• Scenarios requiring persistent connections

  Persistent connections are suitable for business scenarios with frequent interactions, such as the Internet of Things (IoT), online financial services, and online games. Configuration changes require NGINX Ingress to reload its processes, which interrupts persistent connections. In contrast, ALB Ingress supports hot updates to its configuration, ensuring persistent connections remain stable.

• High-concurrency scenarios

  The large number of terminal devices in IoT services often results in high concurrency. Built on the Luoshen cloud network platform, ALB Ingress can efficiently manage sessions. A single ALB instance supports tens of millions of connections. NGINX Ingress supports a limited number of sessions and requires self-maintenance. Scaling NGINX Ingress consumes cluster resources and requires manual intervention, resulting in high scaling costs.

• High-QPS scenarios

  Internet services are often characterized by high queries per second (QPS), such as during promotional events and sudden traffic spikes. ALB Ingress supports automatic scaling. To handle high QPS, more VIPs are automatically provisioned. A single ALB instance can support up to one million QPS, providing lower latency than NGINX Ingress. In contrast, NGINX Ingress relies on cluster resources and is more likely to encounter performance bottlenecks in high-QPS scenarios.

• Scenarios with traffic fluctuations

  ALB Ingress is more cost-effective for services with fluctuating traffic, such as e-commerce and gaming. ALB Ingress is pay-as-you-go. During off-peak hours, fewer load balancer capacity units (LCUs) are consumed, which reduces costs. Its automatic scaling eliminates the need for manual traffic monitoring and management. If you use NGINX Ingress, you must reserve cluster resources, which incurs costs for idle resources during off-peak hours and requires manual resource reservation.

• Active zone-redundancy and active geo-redundancy disaster recovery scenarios

  For industries and applications that have high requirements for business continuity and reliability, such as social networking platforms and streaming media services, you can create ALB multi-cluster gateways in Distributed Cloud Container Platform for Kubernetes (ACK One) and manage multi-cluster traffic with ALB Ingresses to implement active zone-redundancy and active geo-redundancy disaster recovery solutions.

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 you use Flannel, ALB Ingress can forward requests only to NodePort and LoadBalancer services. ClusterIP services are not supported.

ALB Ingress Controller Change Log

For ALB Ingress feature change logs, see ALB Ingress Controller.