×
Community Blog In Response to the Retirement of Nginx Ingress, It’s Time to Clarify These Confusing Concepts

In Response to the Retirement of Nginx Ingress, It’s Time to Clarify These Confusing Concepts

This article aims to provide a simpler way to understand these easily confusing technical concepts: Nginx, Ingress, Ingress Controller, Ingress API, Nginx Ingress, Higress, Gateway API.

By Wang Chen

This article aims to provide a simpler way to understand these easily confusing technical concepts: Nginx, Ingress, Ingress Controller, Ingress API, Nginx Ingress, Higress, Gateway API.

1. Nginx and Kubernetes

We first categorize them into two types based on their relevance to Kubernetes:

Nginx is the de facto standard for traffic entry from the era before Kubernetes, functioning as a web server running independently on any Linux/Windows server. It provides the following main functionalities:

  • Receiving requests
  • Forwarding requests
  • Load balancing
  • Simple traffic management, such as rate limiting, caching, and rewrites

Ingress API, Ingress Controller, Nginx Ingress, Higress, and Gateway API all rely on Kubernetes, and these concepts emerged after the advent of Kubernetes. Among them, Ingress API is the specification for Kubernetes traffic management, Ingress Controller is the implementing component of the specification, Nginx Ingress and Higress are both complete implementations and functional extensions of the specification, while Gateway API is an upgrade and next generation of Ingress API.

It is important to note that Ingress often appears alone and needs to be judged based on context; it may refer to either Ingress API or the Ingress resource, which is the specific configuration object (YAML) written by the user, adhering to the Ingress API.

2. Ingress API and Ingress Controller

Ingress API and Ingress Controller are the specifications and executors of Kubernetes traffic management, respectively.

Ingress API: describes how external traffic enters the Services within the cluster in a declarative manner, including:

  • How to access services via domain names
  • How to route to different backend services based on URL paths
  • Who the backend services are
  • Whether to enable HTTPS encryption

Figuratively speaking, the Ingress API can be understood as the manual for managing traffic in Kubernetes.

Ingress Controller: is the implementing component of Ingress API, that is the executor, including

  • Listening for changes to Ingress resources
  • Translating Ingress rules into actual reverse proxy configurations
  • Receiving external traffic and routing it according to rules
  • Handling TLS termination (HTTPS decryption)
  • Providing capabilities for health checks, load balancing, retries, and other traffic management

Through these capabilities, the Ingress Controller realizes management of entrance traffic in Kubernetes.

3. Nginx Ingress and Higress

Nginx Ingress and Higress are both complete implementations and functional extensions of the Ingress API.

Nginx Ingress: uses Nginx as the underlying implementation of Ingress API, coupling the control plane and data plane within the same process/container. The advantages are simplicity, ease of use, and a broad community.

The disadvantages are:

  • It is not a native Ingress API; the semantics of Ingress API are relatively weak
  • Extensions rely on Annotations (engineering nightmares)
  • Generates nginx.conf + reload, with weak dynamic configuration capability (frequent reloads affect performance)

It is suitable for simple, stable, small-scale scenarios.

Higress: the data plane is based on Envoy, and the control plane is based on Istio, making it a native Ingress API.

The advantages are:

  • The control plane and data plane are decoupled, allowing for independent scaling.
  • Based on xDS protocol, it achieves true dynamic configuration (no reload, zero downtime).
  • Native support for plugin extensions: Wasm, Lua, and Go plugins are uniformly managed and distributed by the control plane.
  • Compatible with multiple protocols & standards: supports both Ingress API and Gateway API.

The disadvantage, compared to the extensive community foundation of Nginx, is that Higress, as a representative of the native Ingress API, has a learning cost in terms of deployment and maintenance.

It is suitable for high-performance, high-scalability, enterprise-level scenarios.

4. Retirement of Nginx Ingress

In November, the Kubernetes SIG Network and Security Response Committee announced the retirement of Ingress NGINX. (⚠️ NGINX has not been retired)

It means:

  • Ingress NGINX will maintain services until March 2026
  • No new versions will be released
  • No vulnerabilities will be fixed
  • No updates will be made for any security vulnerabilities that may be discovered
  • GitHub code repository will be set to read-only for reference only
  • Existing Ingress NGINX deployments will continue to run, and installation files will remain available

The fundamental reason for retirement:

  • For years, the project has only one or two people working part-time on development.
  • Efforts to collaborate with the Gateway API community to develop an alternative controller did not succeed in engaging more people in maintaining Ingress NGINX.

5. Higress: A Preferred Alternative Plan for the Retirement of Nginx Ingress

  • Officially recommended by Kubernetes, as stated in the official community documentation.
  • Highest compatibility with annotations of Nginx Ingress, supporting 51 types, covering 90% of user scenarios, which means existing K8s Ingress YAML files can be migrated without extensive modification.
  • Long-term investment and provision of enterprise-level services, namely Alibaba Cloud API Gateway.
  • Provides listening for K8s Ingress (Ingress mode), suitable for teams that wish to maintain K8s native workflows (such as GitOps); and console configuration API (API management mode), suitable for scenarios requiring centralized governance and fine management.

6. Gateway API and Ingress API

Gateway API is a superset and next generation of the Ingress API specification. Its emergence aims to address issues that Ingress API itself cannot manage. Among them, Higress already supports Gateway API standards, allowing users to smoothly migrate from Ingress API to Gateway API.

Problems existing in Ingress API are resolved by Gateway API as follows:

  • Unclear responsibilities lead to Ingress becoming “written by one person,” with no permission boundaries.

-> Gateway API resolves this through role separation, defining infrastructure providers, cluster administrators, and application developers.

  • Weak functional expression ability, relying on Controller-specific extensions; the consequence is non-standardization and high migration costs between different implementations.

-> Gateway API standardizes extension through Wasm, plugins, and service mesh integration.

  • Only supports HTTP/HTTPS, unable to handle protocols like TCP/UDP/gRPC.

-> Cloud-native applications are no longer just web services; Gateway API manages all north-south traffic through a unified API.

  • Inability to express complex routing logic; microservice governance needs far exceed Ingress capabilities.

-> Gateway API supports Wasm, plugins, and service mesh integration, addressing this through standardized advanced routing.

  • One Ingress Controller is globally shared, lacking multi-tenant isolation, which poses risks of security and configuration conflicts in multi-tenant scenarios.

-> Gateway API provides instances of independent Gateways.


If you want to learn more about Alibaba Cloud API Gateway (Higress), please click: https://higress.ai/en/

0 1 0
Share on

You may also like

Comments

Related Products