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 capabilities for managing 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:
Feature | Description |
Install the ALB Ingress controller in the console | ACK Serverless clusters provide the managed ALB Ingress controller that uses Layer 7 forwarding rules based on ALB. Note
You can install the ALB Ingress controller when you create a cluster or on the Components page. For more information, see the following topics:
|
Grant permissions to the ALB Ingress controller | 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. |
Create an AlbConfig object and an IngressClass | After the permissions are granted to the ALB Ingress controller, you can create an AlbConfig object and an IngressClass, associate the IngressClass with the AlbConfig object, and then add annotations to the ALB Ingress to configure forwarding rules. This way, clients can access resources in Kubernetes by using the ALB Ingress. For more information, see the following topics: |
Create resources such as Ingresses, Services, and Deployments in Kubernetes | After you complete the preceding steps, you can create resources such as Ingresses, Services, and Deployments in Kubernetes. Clients can access the resources 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 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. ALB Ingresses are free of this issue.
High QPS
Internet services are expected to withstand high QPS in most scenarios, such as promotional activities and breaking events. ALB supports automatic scaling. Virtual IP addresses are added as the QPS value increases. ALB Ingresses respond faster than NGINX Ingresses because each ALB instance supports up to one million QPS. In addition, NGINX Ingresses do not use physical processing units (PPUs) when processing non-persistent connections. Compared with ALB Ingresses, NGINX Ingresses can handle less QPS per instance, and require more instances when handling the same amount of traffic as an ALB Ingress.
High concurrency
IoT services are expected to maintain a large number of concurrent connections initiated from terminal devices. ALB Ingresses integrate with Cloud Network Management to converge sessions. Each ALB instance supports up to tens of millions of connections. NGINX Ingresses require manual maintenance and support a smaller number of sessions per server. A large number of NGINX servers are required even if network-enhanced virtual machines (VMs) are used.
Large workload fluctuations
ALB provides 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 adjust the quantity and specifications of machines to keep up with workload fluctuations. In addition, NGINX also requires buffers to support disaster recovery. Buffers indirectly increase operational expenses.
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.