Choosing the Right Cloud‑Native Ingress Gateway: Nginx, ALB, and MSE Compared

Service Exposure in Kubernetes

Kubernetes Service objects provide internal discovery via a stable VIP or DNS name. To expose a service externally, NodePort allocates a port on every node, requiring clients to know the node IP and port; availability depends on node health. LoadBalancer builds on NodePort but delegates an external IP and load‑balancing to the cloud provider, eliminating single‑node failure risk. When many HTTP/HTTPS services need layer‑7 routing, creating a separate LoadBalancer per service is costly; an Ingress controller offers a unified entry point.

Application Gateway Requirements

Unified authentication, access control, and SSL termination to avoid redundant configuration across micro‑services.

Rate‑limiting for stability.

Observability: response‑time trends, status‑code statistics.

Detailed access logging for troubleshooting.

Nginx Ingress Overview

The default community Ingress controller is deployed as a Deployment with a LoadBalancer Service. It consists of a manager process and an Nginx worker. The manager watches Ingress resources, translates annotations and the spec into an nginx.conf, and triggers a reload of the Nginx process. The controller also watches Service back‑ends; when Pods are added or removed, the manager updates the Nginx upstream list without a full reload. Prometheus metrics are exposed for monitoring.

Custom Location Snippet Example

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/configuration-snippet: |
      if ($http_user = "gray") {
        rewrite ^/(.*)$ /traffic;
      }
spec:
  rules:
  - host: test.domain.com
    http:
      paths:
      - path: /test
        backend:
          service:
            name: test-svc
            port:
              number: 80

The generated Nginx configuration contains the injected snippet:

server {
  server_name test.domain.com;
  location /test {
    if ($http_user = "gray") {
      rewrite ^/(.*)$ /traffic;
    }
    ...
  }
}

Limitations and Operational Considerations

Performance depends on Pod resources and host node; co‑located workloads can cause contention.

High traffic typically requires dedicated nodes with taints/tolerations and Horizontal Pod Autoscaling (HPA).

Reloads replace the worker process and can disrupt long‑lived connections (e.g., WebSocket) if they exceed worker_shutdown_timeout.

Health checks use the manager’s /healthz endpoint on port 10254. Under load the endpoint may become unresponsive, causing repeated restarts.

Typical probe configuration:

livenessProbe:
  failureThreshold: 5
  httpGet:
    path: /healthz
    port: 10254
    scheme: HTTP
  initialDelaySeconds: 10
  periodSeconds: 10
  timeoutSeconds: 1
readinessProbe:
  failureThreshold: 3
  httpGet:
    path: /healthz
    port: 10254
    scheme: HTTP
  initialDelaySeconds: 10
  periodSeconds: 10
  timeoutSeconds: 1

To reduce reload impact, operators can add a custom annotation (e.g., reload-trigger: true) that the manager checks before performing a reload, or decouple configuration generation from the actual reload.

Dynamic routing can be achieved with Lua plugins that load rules from a database into Nginx shared memory, avoiding frequent reloads.

ALB Ingress

Alibaba Cloud ALB Ingress separates the data plane (the ALB instance) from the control plane (the controller). It provides hot‑loading, high elasticity, and a fully managed operation, making it suitable for high‑QPS scenarios. It supports many Nginx annotations, but custom configuration snippets and Lua plugins are not fully compatible.

MSE Ingress (Cloud‑Native Gateway)

MSE Ingress is built on Alibaba Cloud’s Managed Service for Edge. It offers data‑plane/control‑plane separation, hot‑loading, and full micro‑service gateway features such as rate‑limiting, circuit‑breaking, and traffic protection. It supports Wasm plugins and is adding Lua plugin support. The implementation is open‑source:

https://github.com/alibaba/higress

Scenario Summary

Nginx Ingress : Open‑source, highly customizable, suitable for migrations from self‑managed Nginx. Requires dedicated ops and carries stability risk.

ALB Ingress : Fully managed, ideal for extreme QPS and high‑concurrency workloads on Alibaba Cloud with minimal operational overhead.

MSE Ingress : Cloud‑native gateway that also serves as a micro‑service API gateway; best when both Ingress and service‑mesh capabilities are needed, with extensibility via Wasm.

All three providers rely on the standard Ingress API (host and path rules). Vendors extend functionality through custom annotations, which increases configuration complexity. The Kubernetes community’s Gateway API aims to standardize and extend gateway models, and many Ingress controllers are adding support for it.