All Products
Search

This Product

    Container Service for Kubernetes:Comparison among NGINX Ingresses, ALB Ingresses, and MSE Ingresses

    Document Center

    Container Service for Kubernetes:Comparison among NGINX Ingresses, ALB Ingresses, and MSE Ingresses

    Last Updated:Jan 10, 2025

    ACK managed clusters and ACK Serverless clusters support NGINX Ingresses, Application Load Balancer (ALB) Ingresses, and Microservices Engine (MSE) Ingresses. NGINX Ingresses require manual maintenance. ALB Ingresses and MSE Ingresses are fully managed. This topic describes the differences among NGINX Ingresses, ALB Ingresses, and MSE Ingresses in terms of use scenarios, usage, and features. You can select suitable Ingress types for your business based on the comparison details described in this topic.

    Background information

    • NGINX Ingresses provide traffic management and advanced routing features at Layer 7 based on the open source Ingress NGINX Controller. NGINX Ingresses are compatible with the upstream community and support extensions. NGINX Ingresses require manual maintenance. No service-level agreement (SLA) guarantee is provided for NGINX Ingresses. If you want to customize gateways, you can choose NGINX Ingresses.

    • ALB Ingresses are developed based on ALB instances and are fully compatible with NGINX Ingresses. ALB Ingresses are fully managed and adopt an all-in-one architecture. ALB Ingresses support SSL hardware acceleration, auto scaling, low latency, and complex routing. Each ALB instance supports one million queries per second (QPS) and provides enhanced traffic routing capabilities for ALB Ingresses. For more information, see ALB Ingress management.

    • As Higress Enterprise Edition gateways, MSE Ingresses are compatible with NGINX Ingresses and are suitable for microservices scenarios. MSE Ingresses support multiple service discovery modes, various authentication methods, and plug-ins and extensions written in multiple languages. ALB Ingresses support canary releases, resource prefetching, and traffic throttling. Each MSE cloud-native gateway supports one million QPS and provides enhanced traffic routing capabilities for MSE Ingresses.

    Scenarios

    Type

    Scenario

    Nginx Ingress

    • Your cluster requires highly customized gateways.

    • Your cluster performs canary releases and blue-green deployments for cloud-native applications.

    ALB Ingress

    • Your cluster requires fully managed and O&M-free gateways and components.

    • Your cluster requires high-performance auto scaling for Internet applications at Layer 7.

    • Your cluster requires multi-level high availability in the service level agreement (SLA) that is up to 99.995%.

    • Your cluster performs canary releases and blue-green deployments for cloud-native applications.

    • Your cluster uses a single ALB instance to manage traffic for multiple cloud services.

    • Your cluster requires disaster recovery in multiple scenarios, such as hybrid cloud and cross-region cloud scenarios.

    • Your cluster requires high QPS and a large number of concurrent connections.

    MSE Ingress

    • Your cluster requires fully managed and O&M-free gateways.

    • You cluster adopts the microservices architecture, uses Nacos and ZooKeeper to implement service discovery, uses Sentinel to throttle traffic, has HTTP-to-Dubbo conversion enabled, or is integrated with OpenTelemetry.

    • Your cluster requires north-south traffic management and uses traditional registration centers such as Nacos, Kubernetes, DNS, or fixed IP addresses to discover backend services.

    • Your cluster requires east-west traffic management, internal communication within hybrid clouds, multiple data centers, and multiple business domains, and seamless integration with service meshes.

    • Your cluster uses a gateway that is shared among multiple clusters, multiple PaaS platforms, and multiple Elastic Compute Service (ECS) instances.

    • Your cluster requires internal communication within hybrid clouds, multiple data centers, and multiple business domains.

    • Your cluster requires authentication, flexible configuration, and enhanced security protection.

    • Your cluster requires high QPS and high concurrency.

    Implementation

    The following figures show how NGINX Ingresses, ALB Ingresses, and MSE Ingresses forward requests received by www.example.net/app to backend applications.

    NGINX Ingresses

    image

    The NGINX Ingress controller is an implementation that integrates both the control plane and the data plane. Each pod of the NGINX Ingress controller runs a controller process that serves as the control plane and other NGINX processes that serve as the data plane. Therefore, the pods of the NGINX Ingress controller process both the requests for configurations and the requests from users.

    ALB Ingresses

    image

    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 managed control plane of the ALB instance. It manages the ALB instance but does not process user requests. User requests are distributed by the ALB instance.

    MSE Ingresses

    image

    The MSE Ingress controller listens for Ingress resources defined by MseIngressConfigs in the cluster and coordinates MSE cloud-native gateways to implement the traffic management rules specified in the Ingress configurations. Unlike the NGINX Ingress controller, the MSE Ingress controller is used to manage MSE cloud-native gateways and their control planes. The pods of the MSE Ingress controller do not process requests from users. User requests are routed and forwarded by the MSE cloud-native gateway.

    Comparison of features

    Item

    Nginx Ingress

    ALB Ingress

    MSE Ingress

    Service positioning

    • Provides traffic management and advanced routing features at Layer 7.

    • A cluster component that can be customized based on your business requirements.

    • Provides traffic management and advanced routing features at Layer 7.

    • Runs at the application layer, provides deep integration with containers, and supports different release policies, such as canary release, A/B testing, blue-green deployment, and traffic distribution by ratio.

    • Provides ultra-large capacities and supports auto scaling and automated O&M.

    • Supports integration with multiple cloud services, such as Web Application Firewall (WAF), Function Compute, PrivateLink, and transit routers (TRs).

    • Integrates multiple network services to facilitate traffic routing across hybrid clouds, regions, and data centers.

    • Serves as traditional traffic gateways, microservices gateways, and security gateways. You can use features such as hardware acceleration, WAF local protection, and the plug-in marketplace to build high-performance, highly-scalable, and easy-to-integrate cloud-native gateways that support hot updates.

    • Provides traffic management and advanced routing features at Layer 7. Supports multiple service discovery modes and service canary release policies. The service canary release policies include canary release, A/B testing, blue-green deployment, and traffic distribution based on a custom traffic percentage.

    • Targets application-layer load balancing scenarios, and are deeply integrated with container services. MSE Ingresses are directly connected to the IP addresses of pods to forward requests.

    Service architecture

    Provides extended features based on NGINX and Lua.

    • Developed based on the Apsara Cloud Network Management platform.

    • Developed based on the CyberStar platform and supports auto scaling.

    • Developed based on the open source project Higress. Control planes are built based on Istiod and Envoy. For more information about Higress, visit Higress.

    • Exclusive to individual users.

    Basic routing

    • Supports routing based on content and source IP addresses.

    • Supports HTTP rewrites, redirects, overwrites, throttling, cross-origin resource sharing (CORS), and session persistence.

    • Supports inbound and outbound forwarding rules. Outbound forwarding rules can be configured by adding Snippet configurations.

    • Supports longest path matching for forwarding rules. When multiple paths are matched, the longest path is used.

    • Supports routing based on content and source IP addresses.

    • Supports HTTP rewrites, redirects, overwrites, throttling, CORS, and session persistence.

    • Supports inbound and outbound forwarding rules.

    • Requests are matched against forwarding rules in descending order of rule priority. When multiple paths are matched, the path whose forwarding rule number is the smallest has the highest priority for matching.

    • Supports load balancing modes such as standard polling, least connections, and consistent hashing based on source IP addresses and URLs.

    • Supports content-based routing.

    • Supports features such as HTTP header rewrites, redirects, rewrites, throttling, CORS, timeouts, and retries.

    • Supports load balancing modes such as standard polling, random, least connections, consistent hashing, and prefetching. In prefetching mode, the traffic that is forwarded to a backend server within the specified time window increases at a steady rate.

    • Supports thousands of Ingress rules.

    Protocol

    • Supports HTTP and HTTPS.

    • Supports WebSocket, WSS, and gRPC.

    • Supports HTTP and HTTPS.

    • Supports HTTP3.0, WebSocket, WSS, and gRPC.

    • Supports HTTP and HTTPS.

    • Supports HTTP 3.0, WebSocket, and gRPC.

    • Supports conversion from HTTP/HTTPS to Dubbo.

    Configuration change

    • Reloading is required when you update non-backend endpoints. This affects persistent connections.

    • Endpoint configuration changes are applied by using Lua hot updates.

    • Processes are reloaded when you change the configuration of the Lua plug-in.

    • Supports hot updates of configurations

    • Calls API operations to apply configurations changes in real time.

    • Supports hot updates of configurations, certificates, and plug-ins.

    • The List-Watch mechanism is used to update configurations in real time.

    Authentication

    • Supports Basic Auth-based authentication.

    • Supports the OAuth protocol.

    Supports TLS-based authentication.

    • Supports authentication based on Basic Auth, OAuth, JWT, and OIDC.

    • Supports integration with Alibaba Cloud IDaaS.

    • Supports custom authentication.

    Performance

    • Requires manual tuning to optimize system parameters and NGINX parameters.

    • Requires proper configurations on the number of replicated pods and the amount of resources. For more information, see Usage notes of the NGINX Ingress controller.

    • Support one million QPS per instance.

    • Supports tens of millions of connections per instance.

    • Uses SSL hardware for acceleration.

    • When the CPU utilization is 30% to 40%, the transactions per second (TPS) of MSE Ingresses is about 90% higher than the TPS of open source NGINX Ingresses.

    • Improves the performance of HTTPS by about 80% after hardware acceleration is enabled.

    Observability

    • Allows you to collect access logs.

    • Allows you to configure monitoring and alerting by using Managed Service for Prometheus (Prometheus).

    • Allows you to collect access logs by using Simple Log Service.

    • Allows you to collect metrics by using CloudMonitor.

    • Allows you to configure alerting based on CloudMonitor.

    • Supports Tracing Analysis and SkyWalking.

    • Allows you to collect access logs by using Simple Log Service and Prometheus.

    • Allows you to configure monitoring and alerting by using Prometheus.

    • Supports Tracing Analysis and SkyWalking.

    O&M

    • Requires manual O&M

    • Allows you to configure Horizontal Pod Autoscaler (HPA)-based scaling

    • Allows you to specify computing resource specifications for optimization.

    • Gateways and relevant components are fully managed and O&M-free.

    • Supports auto scaling and automated configuration and provides ultra-large capacities.

    • Supports auto scaling to handle traffic peaks,

    Gateways are fully managed and O&M-free.

    Security

    • Supports HTTPS.

    • Supports blacklists and whitelists.

    • Supports end-to-end data transfer over HTTPS, server Name Indication (SNI) for multiple certificates, Rivest-Shamir-Adleman (RSA) and elliptic-curve cryptography (ECC) certificates, TLS 1.3, and TLS cipher suites.

    • Supports WAF.

    • Supports Anti-DDoS.

    • Supports blacklists and whitelists.

    • Supports end-to-end encryption for data transfer over HTTPS, Server Name Indication (SNI) for multiple certificates, and custom TLS versions.

    • Supports WAF.

    • Supports blacklists and whitelists.

    Expense and costs

    • CLB instances: CLB billing.

    • The resource overheads of nginx-ingress-controller must be at least 0.2 vCores and 200 MiB of memory.

      Note

      You are charged for the resources and ECS nodes that are actually used. For more information about ECS billing, see Billing overview.

    • ALB instances: ALB billing.

    • alb-ingress-controller is managed by ACK and does not consume resources.

    For more information, see Manage the NGINX Ingress controller.

    For more information, see Manage the ALB Ingress controller.

    For more information, see Manage the MSE Ingress Controller component.

    Service governance

    • Supports service discovery in ACK clusters.

    • Supports canary releases and blue-green deployments.

    • Supports traffic throttling for high availability.

    • Supports service discovery in ACK clusters.

    • Supports canary releases and blue-green deployments.

    • Supports traffic throttling for high availability.

    • Supports service discovery based on Kubernetes, Nacos, ZooKeeper, Enterprise Distributed Application Service (EDAS), Serverless App Engine (SAE), DNS, and static IP addresses.

    • Allows you to use canary releases to release more than two application versions, supports tag-based routing, and supports end-to-end canary releases based on MSE service governance.

    • MSE Ingresses are integrated with Sentinel to support throttling, circuit breaking, and degradation.

    • Service testing supports service mocking.

    Scalability

    Supports Lua for configuring extended features.

    Supports AScript, which can be used to configure extended features. For more information, see AScript overview.

    • Uses the WebAssembly plug-in to support multiple programming languages.

    • Supports Lua for configuring extended features.

    Cloud-native support

    A component that requires manual maintenance and can be used in ACK clusters and ACK Serverless clusters. For more information, see Ingress overview.

    • Supports multiple cloud services, such as WAF, Function Compute, PrivateLink, and TRs.

    • A managed component that can be used in ACK clusters and ACK Serverless clusters.

    A user-side component that can be used in ACK clusters and ACK Serverless clusters and supports seamless integration with the key annotations of NGINX Ingresses. For more information about the annotations supported by MSE Ingresses, see Annotations supported by MSE Ingress gateways.

    References