Demystifying Nginx, Ingress, and Gateway API: A Simple Cloud‑Native Guide

Background: Nginx and Kubernetes

Nginx originated as a standalone web server and reverse‑proxy that runs on any Linux or Windows host. Its core functions are receiving HTTP requests, forwarding them to upstream services, performing load‑balancing, and providing basic traffic‑management features such as rate‑limiting, caching, and URL rewriting.

Ingress‑related concepts in Kubernetes

Ingress API – a declarative Kubernetes resource that specifies how external traffic should be routed to Services.

Ingress Controller – a controller that watches Ingress resources and translates them into concrete proxy configurations.

Nginx Ingress – an implementation of the Ingress API that uses Nginx as the data plane.

Higress – an implementation built on Envoy (data plane) with a control plane based on Istio, providing a native Ingress API.

Gateway API – a next‑generation superset of the Ingress API that adds richer routing, multi‑protocol support, and role‑based separation.

Ingress API

The Ingress API is a Kubernetes specification that describes external access to a Service. Typical fields include:

Host‑based routing (e.g., example.com).

Path‑based routing (e.g., /api → service‑a, /web → service‑b).

Backend Service reference (name and port).

Optional TLS configuration for HTTPS termination.

In practice the Ingress resource is a YAML manifest that follows this schema and serves as the “traffic‑management instruction manual” for the cluster.

Ingress Controller

An Ingress Controller implements the Ingress API. Its responsibilities are:

Watch for creation, update, or deletion of Ingress resources.

Convert each Ingress rule into a reverse‑proxy configuration (e.g., Nginx nginx.conf or Envoy xDS resources).

Expose an external entry point (LoadBalancer, NodePort, or HostPort) and route incoming traffic according to the rules.

Terminate TLS if a secret is referenced.

Provide health‑checking, load‑balancing, retries, and other traffic‑governance features.

Nginx Ingress vs Higress

Architecture

Nginx Ingress bundles control‑plane logic and the Nginx data plane in a single container. Configuration changes trigger a full Nginx reload.

Higress separates the control plane (Istio‑based) from the data plane (Envoy). Configuration is pushed via the xDS protocol, allowing zero‑downtime updates.

Advantages and drawbacks

Nginx Ingress

Simple deployment, widely adopted, strong community support.

Limited native Ingress API semantics; extensions rely on annotations.

Reload‑based configuration can impact performance under frequent changes.

Higress

Control‑plane and data‑plane can be scaled independently.

Dynamic configuration via xDS eliminates reloads, providing zero‑interrupt updates.

Native support for Ingress API and Gateway API.

Plugin extensibility through Wasm, Lua, or Go, managed centrally by the control plane.

Supports multiple protocols (HTTP, HTTPS, TCP, UDP, gRPC) and advanced routing.

Higher learning curve and smaller community compared with Nginx Ingress.

Retirement of the NGINX Ingress controller

The Kubernetes SIG Network announced that the NGINX Ingress controller will receive maintenance only until March 2026. After that date:

No new releases or security patches will be published.

The GitHub repository will be set to read‑only (reference only).

Existing deployments continue to run; installation manifests remain available.

The retirement is driven by limited maintainer resources and insufficient community interest in a successor.

Recommended replacement: Higress

Officially recommended by the Kubernetes community as the primary Ingress‑API‑compatible controller.

Supports 51 Nginx Ingress annotations, covering roughly 90 % of typical use‑cases, enabling migration with minimal YAML changes.

Backed by long‑term investment and an enterprise offering (Alibaba Cloud API Gateway).

Provides two operating modes:

Ingress mode – native Kubernetes workflow (GitOps‑friendly).

API‑management mode – centralized governance via a console.

Gateway API vs Ingress API

Gateway API is designed as a superset of the Ingress API to address its limitations:

Clear role separation : defines distinct roles for infrastructure providers, cluster administrators, and application developers, eliminating ambiguous responsibility.

Standardized extensions : uses Wasm, plugins, and service‑mesh integration instead of controller‑specific annotations.

Multi‑protocol support : manages HTTP, HTTPS, TCP, UDP, gRPC, and other protocols for both north‑south and east‑west traffic.

Advanced routing : supports complex match conditions, weighted routing, and traffic splitting required by modern micro‑service architectures.

Multi‑tenant isolation : each Gateway instance is independent, improving security and configuration safety.