Feature | Description | References for ACK | References for ACK Serverless |
Forward requests based on domain names | You can create an Ingress with or without a domain name, and then use the Ingress to forward requests. | Forward requests based on domain names | Forward requests based on domain names |
Forward requests based on URL paths | ALB Ingresses can forward requests based on URL paths. You can use the pathType parameter to configure different URL match policies. The valid values of pathType are Exact, ImplementationSpecific, and Prefix. | Forward requests based on URL paths | Forward requests based on URL paths |
Custom forwarding rules | ALB Ingresses allow you to configure custom forwarding rules. A forwarding rule consists of match conditions and actions. ALB Ingresses support the following operations: Specify custom forwarding conditions, such as domain names, URLs, request headers, query strings, request methods, cookies, and source IP addresses by configuring the alb.ingress.kubernetes.io/conditions.<Service name> annotation. Specify custom forwarding actions to return fixed responses, redirect requests, insert request headers, mirror traffic, forward requests to multiple server groups, or rewrite requests by configuring the alb.ingress.kubernetes.io/actions.<Service name> annotation. Specify custom forwarding conditions in the ACK console, such as domain names, URLs, and HTTP headers. Specify custom forwarding actions in the ACK console to forward requests to specified server groups or return fixed responses.
| Create custom forwarding rules for ALB Ingresses | Create custom forwarding rules for ALB Ingresses |
Configure health checks | You can add annotations to ALB Ingresses to configure health checks. Health check parameters include path, protocol, method, httpcode, timeout, interval, and threshold. | Configure health checks | Configure health checks |
Configure automatic certificate discovery | The ALB Ingress controller supports automatic certificate discovery. You must first create a certificate in the Certificate Management Service console. Then, specify the domain name of the certificate in the TLS configurations of the Ingress. This way, the ALB Ingress controller can automatically discover and match the certificate based on the TLS configurations of the Ingress. | Use an ALB Ingress to configure certificates for an HTTPS listener | Use an ALB Ingress to configure certificates for an HTTPS listener |
Configure a redirect from HTTP requests to HTTPS requests | You can configure an ALB Ingress to redirect HTTP requests to HTTPS (port 443) by adding the alb.ingress.kubernetes.io/ssl-redirect: "true" annotation. | Redirect HTTP requests to HTTPS | Redirect HTTP requests to HTTPS |
Configure the HTTPS or gRPC protocol | ALB Ingresses support the HTTPS or gRPC protocol. To configure HTTPS or gRPC, add the alb.ingress.kubernetes.io/backend-protocol: "grpc" or alb.ingress.kubernetes.io/backend-protocol: "https" annotation. If you want to use an Ingress to distribute requests to a gRPC service, you must configure an SSL certificate for the gRPC service and use the TLS protocol to communicate with the gRPC service. Note You cannot change the backend protocol. If you need to change the protocol, delete and rebuild the Ingress. | Configure HTTPS or gRPC as the backend protocol | Configure HTTPS or gRPC as the backend protocol |
Configure rewrite rules | ALB Ingresses support rewrite rules. To configure rewrite rules, add the alb.ingress.kubernetes.io/rewrite-target: /path/${2} annotation. Note In the rewrite-target annotation, you must set the type of the path parameter to Prefix for a capturing group of the ${number} type. By default, the path parameter does not support characters that are supported by regular expressions, such as asterisks (*) and question marks (?). To specify characters that are supported by regular expressions in the path parameter, you must add the rewrite-target annotation. The value of the path parameter must start with a forward slash (/).
| Configure rewrite rules | Configure rewrite rules |
Configure custom listening ports | ALB Ingresses allow you to configure custom listening ports to expose multiple ports at the same time. You can use this method to expose both port 80 and port 443 of a Service to the internet. | Configure custom listening ports | Configure custom listening ports |
Configure forwarding rule priorities | You can add an annotation to the configuration of an Ingress to configure the priorities of the forwarding rules of the Ingress. Note The priority of each forwarding rule within a listener is unique. You can use the alb.ingress.kubernetes.io/order annotation to specify the priorities of the forwarding rules of an Ingress. Valid values: 1 to 1000. A lower value indicates a higher priority. | Configure forwarding rule priorities | Configure forwarding rule priorities |
Use annotations to perform canary releases | ALB allows you to configure canary releases based on request headers, cookies, and weights to handle complex traffic routing. You can add annotations to configure canary releases. You can add the alb.ingress.kubernetes.io/canary: "true" annotation to enable the canary release feature. Then, you can use different annotations to configure different canary release rules. | | |
Configure session persistence | You can configure session persistence for an ALB Ingress by adding the alb.ingress.kubernetes.io/sticky-session and alb.ingress.kubernetes.io/sticky-session-type annotations. | Configure session persistence by using annotations | Configure session persistence by using annotations |
Specify a load balancing algorithm for backend server groups | You can specify a load balancing algorithm for backend server groups by adding the alb.ingress.kubernetes.io/backend-scheduler annotation. | Specify the scheduling algorithm | Specify the scheduling algorithm |
Configure cross-origin resource sharing (CORS) | ALB Ingresses allow you to configure CORS by using annotations. | Configure CORS | Configure CORS |
Configure persistent TCP connections | Each time a traditional load balancer forwards a request to a backend server, it creates a short-lived connection. This action causes unnecessary load on the server and performance bottleneck issues. ALB provides the persistent TCP connection feature, which reduces the amount of resources consumed for establishing network connections and improves forwarding performance. You can add the alb.ingress.kubernetes.io/backend-keepalive annotation to the ALB Ingress to enable the persistent TCP connection feature. | Configure persistent TCP connections | Configure persistent TCP connections |
Configure QPS throttling | ALB supports QPS throttling based on forwarding rules. You can limit the QPS to a range of 1 to 100000. You can add the alb.ingress.kubernetes.io/traffic-limit-qps annotation to the ALB Ingress to enable the QPS throttling feature. | Configure QPS throttling | Configure QPS throttling |
Backend slow start | You can add the alb.ingress.kubernetes.io/slow-start-enabled annotation to enable slow start mode for an ALB Ingress. Add the alb.ingress.kubernetes.io/slow-start-duration annotation to configure the time it takes for the slow start to gradually increase traffic. Valid values range from 30 to 900 seconds. Note The longer the duration, the slower the increase in traffic. | Backend slow start | Backend slow start |
Connection draining | You can add the alb.ingress.kubernetes.io/connection-drain-enabled annotation to enable connection draining for an ALB Ingress. Add the alb.ingress.kubernetes.io/connection-drain-timeout annotation to configure the connection draining timeout period. Valid values range from 0 to 900 seconds. | Connection draining | Connection draining |
Specify both Kubernetes pods and Elastic Compute Service (ECS) instances as backend servers Use Cloud Enterprise Network (CEN) and transit routers to specify cross-region resources and data centers as backend servers
| ALB Ingresses allow you to use the alb.ingress.kubernetes.io/actions.<Service name> annotation to configure backend server groups for ALB instances. You can add both Kubernetes pods and ECS instances as backend servers for ALB instances by specifying Service names and server group IDs. You can attach ALB instances to CEN and transit routers to forward requests from ALB to servers in VPCs that are deployed in a different region than ALB and to data centers.
| Use ALB Ingresses to configure hybrid backend server groups, associate ECS instances with an ALB instance deployed in a different region, and associate on-premises servers with an ALB instance | Use ALB Ingresses to configure hybrid backend server groups, associate ECS instances with an ALB instance deployed in a different region, and associate on-premises servers with an ALB instance |
Elastic Compute Service (ECS)
Container Compute Service (ACS)
