For years, routing traffic into a Kubernetes cluster meant reaching for one resource: the Ingress. It served the Kubernetes ecosystem well. But since 2023 it has had a successor with a fundamentally different design — the Gateway API — now widely considered the preferred choice for new Kubernetes networking deployments.
What is the Gateway API?
The Gateway API is an official Kubernetes project that defines a set of resources for modelling network traffic — a successor to Ingress, designed to be expressive, role-oriented, and portable across implementations.
Kubernetes ships no data plane for external traffic. It defines APIs — Ingress, and now the Gateway API — that describe how traffic should be routed; the implementation is delegated to third-party controllers that run as pods, watch those resources, and configure an underlying proxy to match. The Gateway API makes the API and the controller two separate decisions in a way Ingress never did.
GA since v1.0 (October 2023)
A standalone SIG-Network project with its own release cycle, shipped as CRDs you install separately — already at v1.6 (June 2026).
Role-oriented design
Separate resources for infrastructure providers, cluster operators, and application developers, each owning their own slice.
Protocol breadth
Native support for HTTP, HTTPS, gRPC, TCP, UDP, and TLS — TCP and UDP routing graduated to the standard channel in v1.6 (June 2026).
Portable config
A standardised spec with a defined extension model — no proprietary annotations that break when you switch controller.
One operational detail: from v1.1 onwards the CRDs require Kubernetes 1.26 or later, and releases support roughly the five most recent minor versions. The v1.5 release is the one to note — ListenerSet lets listeners be defined as independent resources and merged onto a shared Gateway, addressing the practical listener scaling limits present in earlier Gateway implementations and reinforcing the role-based design.
Why Ingress hit its limits
Ingress was a genuine step forward when it landed. But structural limits became apparent as clusters grew more complex.
- Annotations as configuration. Anything beyond simple host and path routing — rate limiting, authentication, traffic splitting — was bolted on through controller-specific annotations that differed by implementation, breaking portability.
- One resource for everything. A single Ingress object could not cleanly model L7 policies, traffic splitting, or cross-namespace routing. The data model was too thin.
- Awkward RBAC. Application teams owned either the whole Ingress or nothing. There was no clean line between who manages the infrastructure and who defines the routes.
Ingress vs Gateway API
| Aspect | Ingress | Gateway API |
|---|---|---|
| Spec standardisation | ✕Annotation-driven, per controller | ✓Standardised resource model |
| Role separation | ✕All or nothing | ✓Clean persona boundaries |
| Protocol support | ✕Mostly HTTP/HTTPS | ✓HTTP, gRPC, TCP, UDP, TLS |
| Traffic splitting | ✕Annotations only | ✓Native weighting |
| Header manipulation | ✕Controller-specific | ✓First-class filters |
| Multi-namespace routing | ✕Not supported | ✓ReferenceGrant model |
| Extensibility | ✕Annotations break portability | ✓Defined extension points |
Core components
Where Ingress packed everything into one resource, the Gateway API splits the model into a chain of resources, each owned by a different persona.
GatewayClass
- Defines which controller backs the Gateways
- Cluster-scoped, set up once
- Owned by the infrastructure provider
Gateway
- The entry point: listeners, ports, TLS
- References a GatewayClass
- Owned by the cluster operator
Route
Supported route types
- HTTPRoute
- GRPCRoute
- TCPRoute
- UDPRoute
- TLSRoute
This separation is the central win. The infrastructure layer decides the how, the operator manages the entry point, and application teams manage their own routes without owning the whole gateway. ListenerSet, added in v1.5, extends this even to the listener level: a platform team owns the Gateway while individual teams contribute their own listeners as separate resources.
Is Ingress dead?
No — and the nuance matters. SIG-Network maintains Ingress for the foreseeable future; it is not deprecated or removed in any current Kubernetes version. But it is feature-frozen: new features go only to the Gateway API. It is a legacy API, not a dead one.
The controllers are a separate story, and one that changes the urgency completely. The Kubernetes project retired the community Ingress-NGINX controller, with best-effort maintenance ending in March 2026 — no further releases, bug fixes, or CVE patches. Existing deployments keep running, but the project is end-of-life; a joint statement from the Kubernetes Steering and Security Response Committees cites Datadog research indicating that around half of all cloud-native environments relied on it.
Migration: when and how
The right horizon depends entirely on what you are migrating off.
- Community Ingress-NGINX users: urgent. With no CVE patches after March 2026, an unsupported ingress controller becomes a security risk. Migration to a maintained controller — the Gateway API or the F5 NIC product — should be prioritised.
- Maintained Ingress elsewhere: relaxed. There is generally no immediate urgency. Plan a Gateway API migration on a 12–24-month horizon; existing Ingress resources keep working.
- New clusters: default to the Gateway API. Starting there avoids a migration later.
If your controller supports both APIs — NGINX Gateway Fabric, Traefik v3, Cilium, Istio, Envoy Gateway, Kong — run them side by side and migrate routes incrementally. Audit annotations first: some controller-specific ones, particularly NGINX rate limiting and authentication, may not have a direct portable Gateway API equivalent. A typical path: install the CRDs and a compatible controller, translate Ingress routes into HTTPRoutes, point DNS at the new Gateway, watch metrics for 24–48 hours, then remove the old resources.
North-south and east-west
A useful mental model: the Gateway API was designed for north-south traffic — from outside the cluster in. Service meshes traditionally handle east-west traffic — pod to pod. That boundary has blurred: the GAMMA initiative extends Gateway API concepts into service mesh use cases, and modern service meshes such as Istio and Cilium increasingly support these APIs for east-west traffic. Routes attach directly to a Service; no new resources required — you can describe your whole traffic topology with one API.
Conclusion
The Gateway API is not an incremental upgrade to Ingress. It is a redesign that fixes the structural shortcomings directly: role-based, portable, and extensible by design. In 2026 it is the standard for new work, and the feature freeze on Ingress makes the direction unmistakable. The decision, in short: new cluster, choose the Gateway API; community Ingress-NGINX, migrate now; maintained Ingress elsewhere, plan for the next year or two.
Working on an Ingress-to-Gateway-API migration, or a Cilium or Istio setup? You will find more Kubernetes depth at The k8s Beacon.