To meet the requirements of cloud-native scenarios, Application Load Balancer (ALB) is deeply integrated with cloud-native services to support ALB Ingresses, which are a type of cloud-native Ingress. ALB Ingresses can be used to balance external traffic to Services in Container Service for Kubernetes (ACK) or Container Service for Kubernetes Serverless (ACK Serverless) clusters at Layer 7. This topic describes the concepts, benefits, and use scenarios of ALB Ingresses, and how to use ALB Ingresses.
Concepts
ALB Ingresses can be used to balance external traffic to ACK or ACK Serverless clusters at Layer 7. The ALB Ingress controller deployed in Kubernetes clusters can monitor changes in AlbConfigs, Ingresses, and Services on the API server and then dynamically update the existing AlbConfigs. For more information about the ALB Ingress controller, see ALB Ingress Controller.
Work with ALB Ingresses
Empowered by ALB, ALB Ingresses provide more powerful management capabilities for network traffic. ALB Ingresses are compatible with NGINX Ingresses. This allows ALB Ingresses to perform complex routing, automatically discover certificates, and support HTTP, HTTPS, and QUIC. ALB Ingresses are ideal for cloud native scenarios that require high scalability and large-scale traffic forwarding at Layer 7.
Procedure
ALB Ingresses are fully managed. Do not configure ALB Ingresses in the ALB console. Otherwise, Ingress errors may arise. For more information about the ALB quotas, see Limits.
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:
Operation | Description |
Install the ALB Ingress controller | You can install the ALB Ingress controller when you create a cluster or on the Components page. For more information, see the following topics:
Note
|
(Optional) Grant access permissions to ACK dedicated clusters | If you want to access Services by using an ALB Ingress in an ACK dedicated cluster, you must grant the required permissions to the ALB Ingress controller before you deploy the Services. For more information, see Authorize an ACK dedicated cluster to access the ALB Ingress controller. |
Deploy backend services such as Services and Deployments | You can deploy backend services such as Services and Deployments in Kubernetes to which the ALB Ingress forwards network traffic. For more information, see the following topics:
|
(Optional) Create an AlbConfig and an IngressClass | Important When you create the ALB Ingress controller, if you set Gateway Source to New or Existing, the controller automatically creates an AlbConfig named alb and an IngressClass named alb. In this case, you can skip this step. After you grant permissions to the ALB Ingress controller, you can create an AlbConfig and an IngressClass and associate them with each other. The AlbConfig is exclusive to the ALB instance and defines the configurations of the ALB instance. The IngressClass defines the association between the Ingress and AlbConfig. For more information, see the following topics:
|
Create an Ingress | After you complete the preceding operations, you can create an Ingress and configure the Ingress to forward requests to backend Services based on forwarding rules and associate the Ingress with the IngressClass and AlbConifg. This way, clients can access resources in Kubernetes by using the ALB Ingress. For more information, see the following topics:
|
In addition to forwarding rules, you can add annotations to ALB Ingresses to configure advanced features such as session persistence and canary releases. For more information about other features of ALB Ingresses, see the following topics:
ACK clusters: Advanced ALB Ingress configurations
ACK Serverless clusters: Advanced ALB Ingress configurations
How ALB Ingresses work
ALB Ingresses are compatible with Kubernetes features and allow you to use AlbConfig objects, which are CustomResourceDefinitions (CRDs) objects, and annotations to configure advanced settings.
AlbConfig CRD: AlbConfig CRDs are used to configure ALB instances and listeners. Each AlbConfig object corresponds to one ALB instance.
Annotations: You can add annotations to ALB Ingresses to configure forwarding rules. This way, HTTP and HTTPS requests can be forwarded to Services based on the forwarding rules.
A Service is an abstraction of a backend application that runs on a set of replicated pods.
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.
Scenarios
ALB Ingresses are open, programmable, and fully managed. ALB Ingresses provide ultra-high performance and support auto scaling.
Supports load balancing and scheduling at multiple levels and can process up to one million QPS.
Supports ultra-robust forwarding capabilities by combining software advantages with hardware advantages.
Supports auto scaling to simplify O&M and guarantees 99.995％ of service uptime.
Provides a customizable system to route complex workloads.
ALB Ingresses are applicable to multiple scenarios. The following figure shows some common scenarios.