NGINX Ingress vs Gateway API

The retiring default vs its successor. API model, traffic features, multi-team ownership, and the migration path.

Feature Matrix	NGINX Ingress The long-time default Kubernetes ingress controller, now in maintenance mode.	Gateway API The official, role-oriented successor to Ingress — portable across implementations.
API Model Gateway API replaces annotation sprawl with first-class fields.	Ingress resource + controller-specific annotations	GatewayClass, Gateway, HTTPRoute — typed, role-oriented resources
Project Status The retirement of ingress-nginx is the forcing function for most migrations.	ingress-nginx in maintenance mode; retirement announced for March 2026	GA since v1.0; the upstream successor to Ingress
Traffic Capabilities Things that needed annotations or snippets become spec fields.	Host/path routing; rewrites and canary via annotations	Header/query matching, weighted splits, mirroring, gRPC routes natively
Role Separation Gateway API was designed around multi-team ownership.	One resource — app teams and platform fight over it	Infra owns Gateway, app teams own HTTPRoutes in their namespaces
Cross-Namespace Shared gateways with delegated routes are a core pattern.	Not supported without controller hacks	Routes attach to Gateways across namespaces via ReferenceGrant
Controller Choice Same manifests work across conformant implementations.	Locked to nginx semantics and its annotation dialect	Portable spec — NGINX Gateway Fabric, Envoy Gateway, Cilium, cloud LBs
Migration Effort Plain Ingress converts cleanly; snippet-heavy configs are the hard part.	Stay = adopting an unmaintained data plane	ingress2gateway tool converts most resources; annotations need manual review
When to Choose In 2026 the question is when to migrate, not whether.	Short-lived clusters that won't outlive the deprecation window	Everything else — new clusters should start here

Kubernetes Ingress vs Gateway API: What Changes and Why

A deeper walkthrough of the resource model, controller landscape, and a staged migration plan off ingress-nginx.

Read the Blog Post

NGINX Ingress vs Gateway API: how to choose

This comparison is between an implementation and a specification, which is the first thing to be clear about. NGINX Ingress Controller implements the Ingress API. Gateway API is a newer Kubernetes API with several implementations — including NGINX's own. The real question is whether to keep writing Ingress resources or move to Gateway API resources.

Ingress became the standard by being simple, and then hit its ceiling. It expresses host and path routing and little else, so everything beyond that arrived as controller-specific annotations. A production Ingress is typically a small spec wrapped in a dozen annotations that only one controller understands, which is portability in name only.

Gateway API moves that into typed resources with a deliberate split of responsibility: cluster operators define Gateways and listeners, application teams attach Routes. Traffic splitting, header matching and request modification are first-class fields rather than annotations. Ingress is not being removed, but it is effectively feature-frozen — new capability lands in Gateway API.

The role split is the point

Ingress has one resource, so whoever writes it controls both the listener and the routing. In a shared cluster that means either giving application teams the ability to affect TLS and ports, or routing every change through the platform team.

Gateway API separates GatewayClass and Gateway, owned by the platform, from HTTPRoute, owned by the application team, with explicit rules about which namespaces may attach. A team can add a route to their service without touching TLS configuration, and the platform can change the listener without editing every application's resource. On a single-team cluster this is overhead; on a shared platform it is the reason to migrate.

Decision matrix: which one fits your situation

Your situation	Use	Why
Existing Ingress that works, single team	Stay on Ingress	It is not deprecated. Migrate for a capability you need, not for novelty.
New cluster being designed now	Gateway API	Start where the ecosystem is going; avoid a migration later.
Multi-tenant cluster, many teams	Gateway API	The role split is exactly what shared clusters need.
Need traffic splitting or header-based routing	Gateway API	First-class fields instead of controller-specific annotations.
Heavy investment in NGINX annotations and snippets	Stay, then plan	Migration means re-expressing that logic. Do it deliberately, not under pressure.
Non-HTTP protocols	Gateway API	TCPRoute, UDPRoute and TLSRoute exist; Ingress is HTTP-only.

Frequently asked questions

Is Ingress deprecated?

No. It is stable, supported, and running most production traffic on Kubernetes today. It is effectively feature-frozen — new routing capability is landing in Gateway API instead. Treat it as a mature API you can keep using, while assuming anything new you need will arrive on the other side.

Can both run in the same cluster?

Yes, and that is the sane migration path. Keep existing Ingress resources serving traffic, stand up a Gateway alongside, and move applications one at a time with DNS or a load balancer as the cutover point. There is no requirement to convert everything at once.

What happens to my NGINX annotations?

Some map to Gateway API fields — rewrites, timeouts and header manipulation have equivalents. Others, particularly raw configuration snippets, do not, and become implementation-specific policy attachments or disappear. Inventory your annotations before committing to a date; that inventory is usually the accurate scope of the migration.

Which implementation should I pick?

The one you already operate, if it has a conformant Gateway API implementation — NGINX, Envoy-based controllers, Istio, Cilium and the cloud providers' own all do. Check the conformance profile for the features you need rather than assuming they are equivalent, because partial implementations are common and the gaps are where migrations stall.