Container Service for Kubernetes:ALB Ingress overview

Before you begin

To better learn the features of ALB Ingresses, we recommend that you read this topic before using ALB Ingresses.

Before you read this topic, we recommend that you read the official Ingress documentation and learn terms related to Ingresses and IngressClasses.

How an ALB Ingress works

Terms related to ALB Ingresses:

• ALB Ingress controller: a component that manages Ingress resources. The ALB Ingress controller uses the API server to dynamically obtain changes in Ingress and AlbConfig resources and then updates the ALB instance. Unlike the NGINX Ingress controller, the ALB Ingress controller is a control plane of the ALB instance. It manages the ALB instance but does not distribute traffic. Traffic is distributed by the ALB instance. The ALB Ingress controller uses the API server in the cluster to dynamically obtain changes in Ingress resources and updates the ALB instance based on the Ingress routing rules.

• AlbConfig: An AlbConfig is a CustomResourceDefinition (CRD) created by the ALB Ingress controller. The parameters in the AlbConfig define the configuration of the ALB instance. Each AlbConfig corresponds to one ALB instance. The ALB instance serves as an ingress to distribute traffic to backend Services. The ALB instance is fully hosted by ALB. Compared with the NGINX Ingress controller, ALB Ingresses are O&M-free and extremely elastic.

• IngressClass: An IngressClass defines the association between an Ingress and an AlbConfig.

• Ingress: Ingresses are resource objects that define external traffic routing rules and access control rules. The ALB Ingress controller monitors changes in Ingress resources and updates the ALB instance to distribute traffic.

• Service: In Kubernetes, pod are varying temporary resources. A Service is a unified ingress to pods that serve the same feature. Other applications or Services can communicate the pods through the virtual IP address and port of the Service without worrying about any changes in the pods. For more information about Services, see Getting started.

The following figure shows the logical relationship between an ALB instance and an ALB Ingress.

How to use ALB Ingresses

ALB Ingresses are deeply integrated with cloud native services. ALB Ingresses support a wide range of features and can be used out-of-the-box. The following procedure demonstrates how to use ALB Ingresses in an ACK or ACK Serverless cluster:

Refer to Create an ALB Ingress and complete the workflow in the preceding figure.

Benefits

ALB Ingresses are fully managed by Alibaba Cloud and provide ultra-high processing capabilities. In comparison, NGINX Ingresses are highly customizable, but require manual management. NGINX Ingresses and ALB Ingresses provide different service scopes, architectures, and processing and security capabilities. For more information about the differences between an NGINX Ingress and an ALB Ingress, see Comparison between an NGINX Ingress and an ALB Ingress.

ALB Ingresses outperform NGINX Ingresses in the following scenarios:

• Persistent connections

  Persistent connections are ideal for scenarios in which frequent interaction is required, such as Internet of Things (IoT), Internet finance, and online gaming. When configurations are modified, NGINX Ingresses must reload processes and temporarily close persistent connections. This may cause service interruptions. To prevent this issue, ALB Ingresses use rolling updates to ensure the stability of persistent connections.

• High concurrency

  IoT services are expected to maintain a large number of concurrent connections initiated from terminal devices. ALB Ingresses run on the Cloud Network Management platform of Alibaba Cloud and can efficiently manage sessions. Each ALB instance supports tens of millions of connections. NGINX Ingresses support only a limited number of sessions, which require manual O&M. Scales-outs of NGINX Ingresses consume resources in clusters and require manual operations. The scale-out expense is relatively high.

• High QPS

  Internet services are expected to withstand high QPS in most scenarios, such as promotional activities and breaking events. ALB Ingresses support automatic scaling. Virtual IP addresses are automatically added as the QPS value increases. ALB Ingresses support lower network latency than NGINX Ingresses because each ALB instance supports up to one million QPS. In addition, NGINX Ingresses reply on resources in clusters and may experience performance bottlenecks in high QPS scenarios.

• Large workload fluctuations

  ALB provides more cost-effective pricing models that are ideal for services with large workload fluctuations, such as e-commerce and gaming services. ALB supports the pay-as-you-go billing method. Fewer Load Balancer Capacity Units (LCUs) are consumed during off-peak hours. In addition, ALB supports automatic scaling. You do not need to check traffic flows in real time. However, NGINX does not automatically release idle resources during off-peak hours. You must manually reserve a certain amount of resources in clusters to cope with workload fluctuations.

Regions and zones that support ALB Ingresses

For more information, see Regions and zones in which ALB is available.

ALB Ingress quotas

For more information, see Methods to calculate ALB quotas.

ALB Ingress controller release notes

For more information, see ALB Ingress Controller.