Kubernetes Gateway API: The Ingress Replacement That’s Ready for Production

Roughly half of all cloud-native environments run community ingress-nginx, a number cited by internal Datadog research and acknowledged by the Kubernetes Steering Committee itself. As of March 2026, the community ingress-nginx project is retired and no longer receiving upstream bug fixes or security updates. The final upstream release line ended with v1.15.x in March 2026, so any vulnerabilities discovered after that point become migration risk rather than normal patch-management work. If your clusters are in that 50%, you are not running a legacy ingress controller in the abstract sense. You are running software on an abandoned upstream, on your public-facing traffic path, with no fix pipeline for what comes next. The upstream maintainers, who were for several years one or two people working in their free time, have closed the door. The Kubernetes Gateway API is not just a better architectural choice. For a significant portion of the industry, it is now a security requirement.

The standard response to situations like this is to swap one Ingress controller for another and move on. Most teams will reach for a drop-in: NGINX Gateway Fabric, Traefik, or whichever controller their platform team has the most experience with. That instinct is not wrong, but it misses the more important architectural shift happening underneath. The Ingress API itself is feature-frozen. It was designed for a single-team cluster model and it shows: every feature beyond basic host/path routing lives in non-portable controller-specific annotations, cross-namespace routing is impossible without workarounds, and traffic splitting requires annotation gymnastics that differ between every controller you have ever used. Annotation-driven configuration is not an implementation detail. It is the core design constraint, and no amount of controller-swapping removes it.

Gateway API solves the problem at the API level, not the controller level. Its core resources (GatewayClass, Gateway, and HTTPRoute) graduated to GA in October 2023, and the February 2026 v1.5 release promoted TLSRoute, built-in CORS filtering, client certificate validation, and the ReferenceGrant security primitive to the stable channel. SAP is running it across hundreds of clusters on multiple cloud providers. The Trade Desk built a 20-million-QPS load balancing platform on it. The post below covers what the architecture actually looks like, which implementation to choose for your environment, what it costs, and how to know whether now is the right time to migrate or whether Ingress still serves you adequately.

Why Ingress Has Always Been a Workaround

The Kubernetes Ingress resource was added to the API in 2015. The design assumption was simple: one team, one cluster, one controller, basic routing. That assumption has not described most enterprise Kubernetes deployments for years.

The most visible symptom is annotations. Because the Ingress spec covers only host and path matching, every feature beyond that (SSL termination settings, rewrite rules, rate limiting, CORS, authentication, canary routing, header manipulation, connection timeouts) became a controller-specific annotation. nginx.ingress.kubernetes.io/rewrite-target, nginx.ingress.kubernetes.io/use-regex, nginx.ingress.kubernetes.io/configuration-snippet. When the ingress2gateway migration tool shipped its 1.0 release, it had to account for more than 30 ingress-nginx annotations to capture common production behaviours. Some of them, particularly the snippet and Lua injection annotations, have no portable equivalent in Gateway API at all, because they were essentially holes through which you injected arbitrary proxy configuration.

The non-portability problem is bad enough in a stable environment. It becomes acute when you change controllers. Moving from NGINX to Traefik or from AGIC to Cilium means auditing every annotation across every Ingress manifest, understanding what the annotation does, finding the equivalent in the new controller’s annotation dialect, and testing the result. Organisations that have gone through that process once are rarely enthusiastic about doing it again.

The single-actor model is the subtler problem. An Ingress resource conflates three distinct concerns: infrastructure configuration (which controller handles this), cluster-level routing (which listener, which port, which TLS certificate), and application routing (which path goes to which service). All three live in one object. That means the same RBAC scope covers all three, which means your application team either has no control over their own routing, or your platform team has handed them keys to the cluster-level listener configuration. Neither outcome is correct, and the workarounds (separate namespaces, admission webhooks, name-based conventions) add friction without solving the underlying model.

Cross-namespace routing is the third limitation. Ingress cannot reference a Service in a different namespace. In a multi-team cluster where a shared gateway serves traffic for multiple namespaces, every team either runs its own Ingress controller (expensive) or works through the platform team for every routing change (slow). Neither scales to more than a handful of teams.

The Gateway API Architecture Model

Gateway API replaces the single Ingress object with a layered set of resources that map to real organisational boundaries. Understanding which resource belongs to which persona is the key to understanding why the architecture works.

GatewayClass is owned by the infrastructure provider: the cloud vendor or your platform team. It defines which controller implements Gateways of this class. If you are running Envoy Gateway on AKS, your platform team creates a GatewayClass pointing at the Envoy Gateway controller. Application teams never touch this. It is the equivalent of a StorageClass: it abstracts the underlying implementation and gives the infrastructure team a single place to enforce configuration standards.

Gateway is owned by the cluster operator or platform team. It defines listeners: which ports, which protocols, which TLS certificates. If your platform team wants to expose HTTPS on port 443, they create a Gateway with an HTTPS listener and reference the TLS certificate. The Gateway also controls which namespaces and which Routes can attach to it. This is where multi-tenancy enforcement lives: a Gateway can specify that only Routes from the production namespace may attach, or that all namespaces may attach. The platform team controls this boundary without needing to review every Route change individually.

HTTPRoute (and GRPCRoute for gRPC traffic) is owned by application developers. It attaches to a Gateway via a parentRef and defines the actual routing rules: which hostnames, which paths, which headers to match, and which backend Service to forward to. Application teams can deploy and update their HTTPRoutes independently, within the constraints the Gateway defines, without raising a ticket to the platform team for every routing change.

This separation does not just improve governance. It removes a class of errors. When a routing misconfiguration happens in the Ingress model, the blast radius is unclear: was it a controller bug, a platform-level listener issue, or an application-level path conflict? With Gateway API, the layers are distinct objects with distinct status conditions. Each reports its own health independently, and the ownership is unambiguous.

HTTPRoute capabilities are where the gap with Ingress annotation behaviour closes in a portable way. Path matching supports Exact, PathPrefix, and RegularExpression. Header, query parameter, and HTTP method matching are first-class fields. Weighted traffic splitting across backendRefs is native and expressed in the spec itself, not in an annotation. A canary deployment that sends 5% of traffic to a new version looks like this:

rules:
- backendRefs:
  - name: api-stable
    port: 8080
    weight: 95
  - name: api-canary
    port: 8080
    weight: 5

rules:
- backendRefs:
  - name: api-stable
    port: 8080
    weight: 95
  - name: api-canary
    port: 8080
    weight: 5

Gateway API makes these behaviours portable at the API surface, but Core conformance should be treated as the baseline rather than a guarantee that every Extended feature behaves identically across controllers. Validate Extended features such as regular-expression path matching, rewrites, mirroring, retries, and timeouts against your chosen controller’s conformance report and compatibility documentation before committing. The request/response modifier filters (header injection, URL rewrite, redirect, request mirroring) are defined in the spec and tested by the conformance suite for Core-conformant implementations, but implementation-specific limits apply: NGINX Gateway Fabric, for instance, supports PathPrefix and Exact path matching but not RegularExpression, and applies only the first filter when multiple filters of the same type are configured on a rule.

ReferenceGrant, now promoted to v1 in the v1.5 release, is the cross-namespace security primitive. By default, an HTTPRoute cannot reference a Service in a different namespace. A ReferenceGrant, created by the owner of the target namespace, explicitly permits a named namespace to reference its Services or Secrets. This is a bidirectional trust model: you cannot reference something without the target namespace granting permission. It solves cross-namespace routing in a way that does not compromise the namespace boundary, and it keeps the permission visible as a resource rather than buried in RBAC rules.

GRPCRoute graduated to the standard channel in v1.1 (May 2024). It matches on gRPC service name and method rather than URI path, supports gRPC-specific retry conditions (CANCELLED, RESOURCE_EXHAUSTED), and requires the Gateway to support HTTP/2. For teams running gRPC-heavy microservices, this is a material improvement over Ingress, where gRPC routing required annotation-based workarounds and the results varied by controller.

Choosing Your Implementation

Gateway API is a specification, not a controller. The specification defines what resources exist and what they must do. The controller is what runs in your cluster and actually handles the traffic. Choosing the wrong controller for your environment is the most consequential decision in a Gateway API migration. The conformance levels are real but incomplete: Core conformance covers the portable features, and every implementation extends beyond that with proprietary policy CRDs. What those extensions cover differs significantly.

The comparison matrix below summarises the five implementations most likely to be relevant to enterprise teams:

Envoy Gateway is the CNCF-neutral choice and arguably the fastest-moving implementation in the space. It reached 1.0 GA in March 2024 and has shipped close to major Gateway API releases since. SAP adopted it before GA, now runs it across hundreds of clusters on multiple cloud providers, and co-designed the EnvoyExtensionPolicy resource to support its use cases. The Trade Desk used it to build a 20-million-QPS on-premises load balancing platform, contributing Zone Aware Routing and circuit breaker improvements back upstream. The extension model is deliberate: EnvoyPatchPolicy gives you direct access to Envoy’s xDS configuration for cases where the Gateway API spec does not yet cover what you need, without requiring a fork. The trade-off is operational: you are running and managing your own Envoy control plane. Independent benchmarking has flagged a memory pressure concern under sustained route-churn conditions, which warrants evaluation at large route counts.

Istio in ingress mode is the right choice if you are already running Istio for service mesh and want a single control plane. A minimal Istio installation without the mesh components provides a fully conformant Gateway API ingress implementation. Istio’s intended direction is Gateway API as the default traffic management API, which means its Gateway API support will track the spec closely. Independent benchmarks have measured Istio’s control-plane propagation as the fastest among the implementations tested. The complexity cost is the Istio operational surface area if you are not already running it. If you are, it is the obvious consolidation move.

Cilium is compelling in clusters where it is already the CNI, because the Gateway API implementation is embedded in the Cilium operator rather than being a separate deployment. Its eBPF data plane delivers unmatched L4 throughput and can apply CiliumNetworkPolicy to ingress traffic, which no other implementation on this list supports natively. Zynga adopted Cilium’s Gateway API implementation as part of a broader platform rebuild and found it addressed ingress limitations that had constrained their multi-team cluster model. The caveats from independent benchmarking are significant: Cilium consumed approximately 7.5 times the control-plane CPU of Istio under test conditions, and one test scenario found it failing silently to update proxies beyond a certain total configuration size, reporting routes as ready when they were not. Validate these specific behaviours at your expected route count before committing. Cilium as CNI is a prerequisite.

NGINX Gateway Fabric is a separate project from the retired community ingress-nginx. It was built from scratch on the Gateway API, uses the NGINX data plane, and released version 2.5.0 with full Gateway API v1.5 conformance including TLSRoute v1 and ReferenceGrant v1. For teams that want the NGINX data plane but cannot use the now-archived community controller, NGF is the natural landing point. Its 2.5 release added native OIDC support, mTLS, and a SnippetsFilter for cases where the spec does not cover a needed NGINX directive. One confirmed limitation: when multiple filters of the same type are configured on a rule, NGF applies the first and silently ignores the rest. Verify this does not affect your routing patterns before deploying.

Azure Application Gateway for Containers is Microsoft’s recommended path for AKS-hosted workloads. It is native Gateway API: an in-cluster ALB Controller translates Gateway API resources to an AGC ARM resource outside the cluster. Configuration propagates in seconds rather than minutes, traffic splitting and weighted round-robin are first-class, and mTLS is supported. Microsoft explicitly recommends migrating from the older AGIC (Application Gateway Ingress Controller) to AGC. Two material checks remain at the time of writing. Private/internal frontends are still not supported per current Microsoft documentation. WAF is now supported for Application Gateway for Containers through WAF policies attached using SecurityPolicy and WebApplicationFirewallPolicy resources, so the decision point is no longer whether AGC has WAF at all; it is whether AGC’s WAF model covers the specific Application Gateway v2 WAF behaviours your environment depends on. As discussed below, AGC also introduces a different billing model from AGIC.

Real-World Case Studies

Company Name and Industry: SAP, Enterprise Software

Scale Context: Hundreds of Kubernetes clusters across multiple cloud providers

Challenge: SAP needed a portable, Gateway API-native ingress solution for a multi-cloud platform serving its cloud product portfolio, without committing to a controller tied to a single provider’s infrastructure.

Solution Implemented: Envoy Gateway, adopted prior to its 1.0 GA release. SAP co-designed the EnvoyExtensionPolicy resource to support its integration requirements, contributing the capability upstream rather than maintaining a private fork.

Measurable Outcomes:

• Significantly lower CPU and memory consumption compared to their previous ingress approach
• Substantially larger configuration scale support
• Markedly faster configuration programming times
• Platform now runs across hundreds of clusters worldwide on multiple infrastructure providers

Source: https://gateway.envoyproxy.io/news/case-studies/sap/sap/

Company Name and Industry: The Trade Desk, Advertising Technology Scale Context: 20 million requests per second across on-premises infrastructure

Challenge: An existing bare-metal HAProxy Community Edition architecture needed replacement with a Kubernetes-native load balancing platform capable of handling the organisation’s traffic scale.

Solution Implemented: Envoy Gateway on Kubernetes, with custom contributions including Zone Aware Routing and Circuit Breaker support contributed back to the upstream project.

Measurable Outcomes:

• Platform handles 20 million QPS across the production traffic path
• Contributed Zone Aware Routing and Circuit Breaker patterns to the upstream Envoy Gateway project

Source: https://kccncna2025.sched.com/event/27FVe

(KubeCon NA 2025 session: “On-Prem Load Balancing Reimagined: Serving 20 Million QPS With Gateway API and Envoy Gateway”)

Company Name and Industry: Zynga, Gaming

Scale Context: Multi-team production clusters serving Zynga Poker and other titles

Challenge: Ingress limitations were constraining multi-team cluster operations and cross-namespace routing requirements.

Solution Implemented: Cilium with Gateway API, deployed as part of a broader platform rebuild replacing kube-proxy and legacy ingress.

Measurable Outcomes:

• Gateway API model resolved multi-team routing constraints that had required workarounds under the Ingress model
• Rollout across clusters with Zynga Poker already in production on the new platform

Source: https://www.cncf.io/case-studies/zynga/

Cost Analysis

The cost picture for Gateway API migration differs depending on which controller you choose and which cloud you are on. For most self-managed implementations (Envoy Gateway, Istio, Cilium, NGINX Gateway Fabric), the software is open source and the cost is operational: the engineering time to evaluate, deploy, and maintain the controller, plus the compute running the data plane. These costs are broadly comparable to running ingress-nginx, and in some configurations lower because a single Gateway API-aware controller replaces multiple ingress controllers that grew up to serve different teams.

The sharpest cost model change is on Azure, where migrating from AGIC to AGC introduces new billing line items. AGIC itself is a free in-cluster controller. You pay for the underlying Application Gateway v2 resource via a fixed hourly charge plus capacity-unit pricing (Standard_v2 roughly $0.008 per capacity-unit-hour; WAF_v2 roughly $0.0144). AGC introduces four separately billed items: the AGC parent resource, each Frontend, each Association (the binding between a Kubernetes cluster and the AGC resource), and capacity units. The Association charge is material. In East US 2 pricing, the Association runs at approximately $0.12 per hour. Model this carefully for multi-cluster deployments where you might have multiple Associations against a single AGC resource. The benefit is that Microsoft manages the underlying infrastructure, and configuration propagation moves from minutes to seconds, which reduces deployment risk. Whether that operational benefit justifies the billing model change depends on your cluster count and your platform team’s capacity.

From a TCO perspective, the most durable cost argument for Gateway API is the reduction in migration friction over time. An organisation that standardises on a conformant Gateway API implementation today will not repeat the annotation audit when it next changes controllers. The portable spec is the asset. Implementation-specific annotations are technical debt with an expiry date; Gateway API resources are not. Over a three to five year horizon, the avoided migration cost and the reduction in cross-team coordination overhead outweigh the initial investment in learning the new resource model.

When to Migrate and When to Wait

The decision to migrate is not binary, and it is not the same for every cluster. The factors that matter most are what controller you are currently running, what features you depend on, and how your teams are structured.

Migrate now if you are running community ingress-nginx. This is a security issue, not an architectural preference. Four HIGH-severity CVEs were disclosed in February 2026 with no fixes coming after the March retirement. Any internet-facing deployment is exposed. The migration path is well-defined: ingress2gateway 1.0 (released March 2026) converts manifests, flags untranslatable annotations, and produces a diff you can review before cutting over. Deploy the new controller alongside the existing one, shift traffic progressively, and decommission ingress-nginx once the switch is validated. As discussed in our container security best practices guide, unpatched components in the traffic path represent a category of risk that no other architectural improvement can offset.

Migrate now if you have multi-team clusters. The role separation model in Gateway API is the architectural solution to the problem multi-team clusters have been solving with workarounds for years. If your platform team spends meaningful time reviewing routing PRs from application teams, or if your application teams are blocked on routing changes because they lack Ingress permissions, Gateway API directly addresses both sides of that friction. The investment in migration pays back in reduced coordination overhead within the first quarter of operation.

Migrate now for greenfield clusters. There is no case for building on a feature-frozen API. New clusters should default to Gateway API from day one. The learning curve is upfront and contained; the operational model scales better from the start.

Defer migration if Ingress is working and your controller is maintained. Traefik, F5/NGINX commercial, HAProxy, and cloud-managed controllers all continue to support the Ingress API, which is feature-frozen but not deprecated. If you have a single-team cluster with basic host/path routing and no splitting requirements, your current setup is not broken. The Ingress API will continue to receive security fixes in Kubernetes itself. The right time to migrate is when you hit a capability limit or when a controller change is forced by something else.

Do not migrate to escape one problem if you will hit another. The NGINX Gateway Fabric silent filter-ignoring behaviour and Cilium’s configuration-scale ceiling are real issues at certain cluster sizes. If you depend on multiple filters of the same type per rule, or if you have thousands of routes, validate your specific scenario before committing. Running the Gateway API conformance suite against your candidate implementation is the minimum; running the independent benchmark at your route count is the due diligence step most teams skip and later regret.

Our Kubernetes cost optimisation guide covers the operational overhead trade-offs in more detail, including the controller resource footprint considerations that become relevant when evaluating Cilium’s higher control-plane CPU usage against its L4 throughput advantages.

Implementation Roadmap

Phase 1: Assess and choose (Months 1-3)

Begin with a cluster inventory. Identify every cluster running community ingress-nginx and prioritise them by internet exposure. For each cluster, export the Ingress manifests and run ingress2gateway in dry-run mode to identify untranslatable annotations. Any annotation flagged as untranslatable requires a decision: find the equivalent in the target implementation’s policy CRDs, rewrite the routing logic, or accept that the feature will not carry over. This step commonly uncovers reliance on configuration-snippet or Lua injection annotations that have been accumulating for years and were never formally documented.

Select your target implementation against the criteria in the decision framework above. If you are on AKS and considering AGC, model the Association billing at your cluster count before finalising. If you are considering Cilium, validate the route-count ceiling in a non-production environment that mirrors your production scale. Download the conformance reports for your shortlisted implementations from the Gateway API repository and check that the Extended features you depend on are covered.

Phase 2: Migrate and validate (Months 4-9)

Install Gateway API v1.5.x standard-channel CRDs into your target clusters. Deploy the new controller alongside the existing ingress controller. There is no requirement to cut over all at once: create HTTPRoutes for a subset of services, validate their behaviour under load, and extend progressively. Weighted DNS or load balancer configuration allows gradual traffic shifting between the old and new paths. The safe-upgrades admission policy introduced in v1.5 prevents accidental downgrades during this period.

Apply the new role model deliberately. Create GatewayClass resources as your infrastructure team. Create Gateways as your platform team. Grant application teams RBAC rights to create and update HTTPRoutes in their namespaces, with ReferenceGrant resources in place for any cross-namespace dependencies. The role separation will surface latent governance gaps, where application teams have been touching cluster-level configuration without anyone noticing.

Phase 3: Standardise and extend (Months 10-18)

By this phase, Ingress resources should be decommissioned from migrated clusters and the old controllers removed. Standardise on the implementation-specific policy CRDs your chosen controller provides for features beyond the spec: rate limiting, authentication, observability. Document the approved extension patterns so application teams are not reinventing them independently. This is also the phase where the network-level observability improvements that come with Gateway API’s richer status reporting start to pay operational dividends: typed conditions on GatewayClass, Gateway, and Route resources replace the ad-hoc logging analysis that was the only way to debug Ingress routing failures.

The Azure Kubernetes Service enterprise implementation guide covers the broader AKS platform governance patterns that apply here, including the namespace isolation and RBAC structures that align with the Gateway API role model.

What Comes Next for Gateway API

The most significant development in the Gateway API roadmap is not in the core spec at all. The Gateway API Inference Extension, which promotes InferencePool to v1 (stable), adds AI-model-aware routing to the Gateway API surface. An Endpoint Picker service or extension routes requests based on signals such as KV-cache utilisation, request queue length, prefix-cache state, and LoRA adapter affinity across GPU and TPU backends. Google’s production evaluation showed this approach reduced Time to First Token latency by more than 35% for Qwen3-Coder and improved P95 TTFT by 52% for DeepSeek V3.1 on Vertex AI. Implementations including GKE, Istio, and NGINX Gateway Fabric already support InferencePool. If your clusters are running inference workloads today, this is worth tracking closely: the Gateway layer is becoming the right place to implement model-aware load balancing, and Gateway API is the portable API surface to do it on.

TCPRoute and UDPRoute remain in the experimental channel. They cover non-HTTP protocols that Ingress never addressed, and their graduation to stable would extend Gateway API’s scope to cover virtually every north-south traffic pattern. The release-train cadence introduced in v1.5 targets a four-month standard-channel cycle, which means the next batch of promotions is due in mid-2026.

The AI Gateway Working Group, announced in March 2026, is formalising the patterns for LLM traffic management at the API level. Rate limiting per token rather than per request, model versioning, and heterogeneous accelerator routing are all in scope. For teams building platforms that will serve AI workloads alongside conventional HTTP traffic, the direction is clear: Gateway API is the intended consolidation point.

This trajectory is why the implementation choice matters beyond the immediate migration. Envoy Gateway’s EnvoyExtensionPolicy design, Istio’s convergence on Gateway API as its default, and NGINX Gateway Fabric’s OIDC and mTLS additions are all positioning for a model where the Gateway API layer handles authentication, AI routing, observability, and security policy alongside basic HTTP routing. The teams that treat the current migration as a one-time controller swap will find themselves repeating the exercise in two years. The teams that treat it as an API surface standardisation will compound the investment.

Strategic Recommendations

The recommendation varies by your current situation, not by a single universal answer.

If you are running community ingress-nginx on any internet-facing cluster, treat this as a security incident in slow motion. The CVEs are known, the patches are not coming, and the exposure window grows with each day. Start the ingress2gateway annotation audit this week, pick an implementation, and set a hard decommission deadline. Six months is achievable; three is better.

If you are on a maintained Ingress controller and not yet hitting capability limits, prioritise greenfield clusters first. Get your team familiar with the Gateway API resource model on new infrastructure where there is no migration risk. When you next hit a capability wall (traffic splitting, cross-namespace routing, gRPC): the answer is already in production and your team knows how to use it.

The implementation choice matters most for teams with heterogeneous cluster environments. If you run both AKS and self-managed clusters, Envoy Gateway gives you a consistent control plane across both. If you are AKS-native and want Microsoft to manage the data plane, AGC is the correct path, but model the billing and confirm the WAF and private frontend gaps do not block you. If Cilium is already your CNI, its Gateway API implementation avoids an additional controller deployment, which matters at scale.

The parallel with the network security perimeter shift is instructive. As covered in our series on Azure Private Endpoints and zero-trust networking, the most durable security improvements come from building on the right abstraction layer rather than patching the wrong one. Gateway API is that layer for Kubernetes ingress traffic. The annotation workaround era is over.

Useful Links

1. Gateway API v1.5 release announcement, official SIG Network post covering the v1.5 stable promotions
2. Gateway API official documentation, spec, guides, and conformance reports
3. Gateway API implementations list, current conformance status for all implementations
4. ingress2gateway migration tool, converts Ingress manifests to Gateway API resources, flags untranslatable annotations
5. SAP Envoy Gateway case study, SAP’s production adoption across hundreds of clusters
6. The Trade Desk KubeCon NA 2025 session, 20M QPS platform built on Gateway API and Envoy Gateway
7. Zynga Cilium case study, Gateway API adoption for multi-team cluster model
8. NGINX Gateway Fabric documentation, conformance details and policy CRD reference
9. Azure Application Gateway for Containers pricing, Association and Frontend billing model detail
10. Gateway API Inference Extension, InferencePool v1 and AI-model-aware routing roadmap