Kubernetes Gateway API: Goodbye Ingress, Hello Gateway

Ingress served Kubernetes well for nearly a decade. But in November 2025, Kubernetes officially stopped providing security patches for Ingress NGINX. No new features, no bug fixes. For teams running Ingress NGINX in production, this is a wake-up call.

Gateway API was designed to address exactly these limitations — not by replacing annotations with more annotations, but with dedicated, standardized resources.

Ingress is dead, long live Ingress

The core problem with Ingress is not NGINX. It is the API itself. Ingress is a simple resource, designed for an era when HTTP routing only needed host + path matching. As requirements outgrew the spec, annotations became the only escape hatch.

Each controller added its own annotations. The result: 200-line Ingress files, half NGINX-specific annotations, half workarounds. Not portable across controllers. No native support for header-based routing, traffic splitting, or mTLS.

Gateway API solves this by decoupling routing from implementation. Three primary resources:

• GatewayClass — selects the controller (Envoy, Istio, Traefik...)
• Gateway — declares listeners (HTTP, HTTPS)
• HTTPRoute — defines routing rules (path, header, method, weight...)

The same HTTPRoute can run on Envoy Gateway today and Istio tomorrow — zero changes needed.

Which Gateway API controller to pick?

Not all controllers are equal. A recent benchmark compared the main options:

• Envoy Gateway — CNCF project, run by the CNCF on its own infrastructure. Full mTLS and request buffering support. Currently the most considered choice among teams evaluating migration.
• Istio — most feature-complete, but comes with service mesh complexity.
• Traefik / NGINX Gateway Fabric — outside CNCF, less favored for long-term infrastructure decisions.

For most teams, Envoy Gateway is the right starting point: powerful enough, lightweight, with a rapidly growing community.

Zero-downtime migration: the real challenge

What holds many teams back is the fear of downtime during cutover. But a proven strategy exists: weighted DNS.

Instead of flipping all traffic at once:

1. Deploy Envoy Gateway alongside Ingress NGINX
2. Use weighted DNS to route 5-10% of traffic to the new Gateway
3. Monitor error rates and latency for several hours
4. Gradually increase the percentage until hitting 100%
5. Remove Ingress NGINX after 24 hours of stable confirmation

This approach enables instant rollback — simply set the DNS weight back to zero.

Another useful tool is ing-switch, which scans existing clusters, maps annotations to Gateway API equivalents, and generates migration manifests.

Bottom line

Ingress NGINX has served its historical role. Gateway API is no longer a "nice to have" — it is the official direction of Kubernetes networking. Start evaluating today, before you are forced to rush it tomorrow.