Kubernetes API Gateway: The 2026 Guide to Gateway API

Ingress-NGINX, the most widely deployed Ingress controller in Kubernetes history, has been retired. Best-effort maintenance ended in March 2026, and the project now gets no further releases, bugfixes, or security patches. Clusters still running it keep working, but from here on any newly discovered vulnerability goes unpatched. The Ingress API itself isn't affected. It stays in place as a stable, frozen part of Kubernetes, alongside Gateway API. What's gone is Ingress-NGINX specifically, one implementation of that API, not the API standard or the underlying NGINX web server.

Kubernetes SIG Network and the project's Security Response Committee made the call, and their recommendation is direct: migrate to Gateway API, the project's own replacement for Ingress.

For teams that built their edge traffic layer on Ingress-NGINX, that recommendation lands as an actual deadline, not a suggestion to read about someday. This guide covers where Gateway API stands today and what has changed since the project's early days. It explains how to plan a migration off Ingress. It also shows how a Kubernetes API gateway fits into the broader job of managing APIs once traffic flows through it.

Does Kubernetes replace the API gateway?​

No. Kubernetes gives you a way to describe how traffic should be routed at the network layer, first through Ingress and now through Gateway API. Neither one replaces full lifecycle API management: versioning APIs, enforcing subscription and rate-limit policies per consumer, publishing a developer portal, and tracking usage across teams and environments. Gateway API standardizes how a gateway is configured. What you do with that gateway, and how you govern APIs running through it, is a separate and still-open question.

Where Gateway API stands today​

Gateway API has moved a long way past the experimental project it was a few years ago. As of the current release, GatewayClass, Gateway, ListenerSet, HTTPRoute, GRPCRoute, TLSRoute, TCPRoute, UDPRoute, BackendTLSPolicy, and ReferenceGrant all carry GA-level support under the stable v1 API version, at the specification level. Which of these an installed controller actually supports still varies by implementation and version, a distinction covered in more detail below.

That list grew as recently as this year: TCPRoute and UDPRoute, which handle raw layer-4 traffic for things like databases, DNS, and IoT telemetry, graduated from experimental status to Standard in Gateway API v1.6. Before that release, teams routing non-HTTP protocols through a Gateway had two options. They fell back to a plain Kubernetes Service, or they used an implementation-specific custom resource that didn't work across gateway controllers.

A rough timeline of how the project got here:

• 2015: Kubernetes Ingress introduced as the original way to route external traffic into a cluster
• 2019: The Gateway API project (first called Service APIs) starts inside SIG Network as Ingress's planned successor
• 2020: Ingress reaches general availability
• 2023: Gateway API v1.0 reaches general availability
• 2025: Gateway API sees wide production adoption across cloud and self-managed clusters
• March 2026: Ingress-NGINX best-effort maintenance ends
• 2026: TCPRoute and UDPRoute graduate to Standard, closing most of the remaining gap with Ingress annotation-based use cases

Is the Kubernetes Gateway API stable?​

Yes, for its core resources. The routing objects most teams need, including Gateway, GatewayClass, HTTPRoute, GRPCRoute, TLSRoute, TCPRoute, and UDPRoute, all sit in the Standard release channel under the stable v1 API version, alongside BackendTLSPolicy and ReferenceGrant. Stability here refers to the API surface and its conformance guarantees, not to any specific vendor's implementation, so the maturity of your actual gateway still depends on which controller you deploy.

Structurally, Gateway API also solves a problem Ingress never addressed well. Ingress bundled routing, infrastructure, and security concerns into one resource type, which worked poorly once multiple teams shared a cluster. Gateway API splits that up. A GatewayClass describes what kind of proxy or load balancer an implementation provides. A Gateway is a concrete instance of that class listening for traffic. Route resources like HTTPRoute attach to a Gateway and describe how specific traffic gets matched and forwarded. Platform teams own the Gateway. Application teams own the routes that attach to it. That separation isn't automatic across namespace boundaries. A Gateway only accepts routes from other namespaces once its owner allows it through allowedRoutes. Any other cross-namespace reference needs an explicit ReferenceGrant from the namespace being referenced. An example is a route that points at a backend Service in another namespace. Nobody has to touch a shared resource just to change their own path rules, but nobody can reach into another team's namespace without that team granting it, either.

The evolution of gateways​

The role a gateway plays at the edge of a system didn't arrive fully formed with Kubernetes. It moved through several distinct stages, each one responding to how applications were being built at the time:

• Early gateways worked as protocol converters, letting different network architectures talk to each other.
• Proxy servers, including Apache HTTP Server and Squid, added caching, security, and access control on top of basic traffic management.
• Hardware load balancers, like F5's Big-IP line, showed up as applications and their traffic volumes grew more complex.
• Software load balancers such as HAProxy brought advanced algorithms, session persistence, and health checks without dedicated hardware.
• Application delivery controllers, including NGINX and Citrix ADC, added TLS termination and traffic management on top of load balancing.
• SOAP gateways handled protocol conversion and security enforcement as SOAP and early web services matured.
• API gateways emerged with REST and service-oriented architectures, taking on routing, authentication, rate limiting, and transformation as core jobs.
• Microgateways pushed processing closer to the edge to support microservices, IoT, and low-latency use cases.
• Cloud native gateways built for Kubernetes and container orchestration are the current stage, increasingly incorporating automation and traffic intelligence.

Kubernetes didn't invent the gateway. It gave the current stage of that evolution a common, versioned API to build on, first through Ingress and now through Gateway API.

What an API gateway actually does​

If you're new to the concept, what an API gateway is covers the fundamentals in more depth. In short: an API gateway sits at the entry point for API traffic and takes on the quality-of-service work that would otherwise sit inside every individual service. In practice, that means a handful of concrete jobs:

• Security: Authenticating and authorizing requests through mechanisms like mutual TLS, OAuth 2.0 tokens, and API keys, with fine-grained scopes controlling what each caller can reach
• Rate limiting: Applying per-consumer policies so one noisy client can't degrade service for everyone else
• Caching: Cutting backend load and latency for responses that don't need to be recomputed on every call
• Request routing: Directing traffic to the right backend, including load balancing, failover, and traffic splitting for canary or A/B rollouts
• Observability: Collecting metrics and traces that let a platform team see what's actually happening to traffic, not just whether a route is technically valid

A gateway that runs on Kubernetes handles these same jobs. It also has to fit Kubernetes' own model. That means declarative configuration, controllers that reconcile actual state against desired state, and traffic patterns that shift as pods scale up and down.

Cloud native gateway architecture: control plane and data plane​

Kubernetes-native API management architecture separates two concerns. The control plane is where API management tasks happen: defining APIs, generating credentials, applying policies. The data plane is what actually terminates connections and moves traffic, exposing the APIs that were defined in the control plane to real callers.

That separation is what makes gateway federation possible. One control plane can govern several data planes at once. Those data planes can run in different clusters, in different clouds, or on different gateway implementations. It's also what lets the architecture lean on Kubernetes primitives like autoscaling and self-healing at the data plane layer without changing how policy gets authored at the control plane layer.

Who's building Gateway API implementations today​

Envoy creator Matt Klein introduced Envoy Gateway in 2022. It was one of the first projects to build a full gateway on the Gateway API spec. It adds a management layer around Envoy's existing proxy and xDS configuration model. That framing still holds, but the field around it has filled in considerably since.

kgateway, a CNCF sandbox project that Solo.io donated after building it as Gloo Gateway, is one of the more visible newer entrants, and it implements the same Gateway API spec on an Envoy data plane. Service mesh projects including Istio and Cilium ship their own Gateway API implementations, as do cloud providers through options like GKE Gateway and equivalents on other clouds. The practical result is that "Gateway API" now describes a specification with several credible, independently maintained implementations behind it, rather than a single reference project you either adapt or skip.

That plurality is exactly why the control-plane/data-plane split above matters more now than it did in 2023. A team standardizing on Gateway API isn't choosing one implementation forever. It's choosing a spec that several implementations speak, which changes how much a later switch actually costs.

Migrating from Ingress: what the tooling looks like​

Kubernetes itself now ships an official migration path. Ingress2Gateway reached a 1.0 release in March 2026, described by SIG Network as a stable, tested migration assistant. Releases 1.1 and 1.2 have since added a Traefik provider, more Ingress-NGINX annotations, and more output emitters.

The tool translates existing Ingress manifests, including implementation-specific annotations, into Gateway API resources, and flags anything it can't safely translate rather than guessing. Its 1.0 release covers more than 30 Ingress-NGINX annotations. Each supported translation is checked by integration tests that run real controllers in live clusters. The tests compare actual routing behavior, not just the resulting YAML.

That tooling exists partly because the alternative path failed. InGate, a from-scratch Ingress-NGINX successor, didn't get enough maintainer support to reach a usable state and was abandoned. Ingress2Gateway is a translation assistant, not a one-click cutover: it moves what it can and tells you clearly what needs a human decision.

That last part matters for how a migration actually gets planned, because translating manifests is the easy half of the problem. The harder half is deciding which Gateway API implementation each environment should run, and how those choices stay governed once you have more than one running at the same time. This is where a control plane built to manage several gateway implementations changes the shape of the migration. Teams can bring different gateways into different clusters or environments on their own timeline. They keep a single place to see and govern all of them. Check which third-party gateways a control plane actually supports. WSO2's currently lists AWS, Azure, Kong, and Envoy.

What this means for your team​

A forced Ingress-NGINX migration is a reasonable moment to ask a broader question than "which controller do we swap in." A few signals suggest you should treat this as more than a like-for-like replacement:

• You're already running more than one gateway or ingress controller across clusters, clouds, or business units, and keeping their policies consistent has become a manual, error-prone process.
• Different teams need to move at different speeds. Some clusters can adopt a new Gateway API implementation this quarter, while others have compliance reviews or vendor contracts that push migration out further.
• You need to attribute API traffic and spend across teams or products, which gets harder, not easier, once traffic is spread across several ungoverned gateway implementations.
• Regulated or sensitive data flows through some of these APIs, and audit or compliance requirements need consistent policy enforcement regardless of which gateway happens to be handling a given route.

None of these are about hitting a specific traffic volume or request count. They're architectural and organizational signals, and any one of them is a reason to plan a control plane strategy alongside the technical migration, rather than treating this purely as a controller swap.

A single control plane for multiple gateways​

The most durable argument in this space goes back to when Gateway API itself was still pre-1.0. As the gateway itself gets commoditized by a shared spec, the real differentiator moves up a layer, to whatever governs and observes all of those gateways together. That argument holds up better now than it did then. The retirement of a widely deployed default like Ingress-NGINX is exactly the kind of forcing function that pushes teams toward more than one Gateway API implementation. Some get there by choice and some by necessity.

A control plane built around that assumption offers a few concrete advantages over standardizing on one gateway implementation everywhere:

• Deployment flexibility: Teams can pick the gateway deployment model that fits each environment, rather than making one big-bang bet across the whole organization.
• Consistent policy: Authentication, rate limiting, and observability get defined once and enforced the same way regardless of which data plane is handling the traffic.
• Lower migration risk: Moving off Ingress-NGINX doesn't require every cluster to land on the same target at the same time.

The WSO2 API Platform keeps gateway choice modular within its own product line. The same API Gateway runtime runs on VMs, in containers, or on Kubernetes, in standalone or operator mode. It can also run as an immutable gateway that loads its APIs from files at startup. An Event Gateway handles event-driven APIs, and the AI Gateway handles LLM and MCP traffic. All of them connect to the same control plane. A Kubernetes migration doesn't mean standing up a separate, disconnected way to manage policy for that one environment.

If you're weighing where to start, the WSO2 API Platform covers this federated approach in more depth. The API Gateway product page walks through how the Kubernetes-native option fits alongside the platform's other gateway types.

Conclusion​

Ingress-NGINX's retirement is a hard deadline, but the migration it forces is a reasonable moment to fix a harder problem: how your organization governs gateways once more than one of them is in play. Start by mapping which clusters run Ingress-NGINX today. Use Ingress2Gateway to see how much of that configuration translates automatically. Then decide up front whether each environment needs its own gateway or a shared one.

Whichever Gateway API implementations you land on, keeping them under one control plane is what keeps the migration from turning into a longer-term governance problem. The WSO2 API Platform is built around that federated model if you want a closer look at how it applies to a multi-gateway Kubernetes environment.

Frequently Asked Questions​

Does Kubernetes replace the API gateway?​

Kubernetes standardizes how a gateway is configured at the network layer through Gateway API. Full lifecycle API management, including versioning, subscriptions, and developer portals, still sits outside that scope.

Is the Gateway API replacing Ingress?​

In practice, yes, for new deployments. Ingress isn't formally deprecated, but the Kubernetes project's guidance points teams to Gateway API. The retirement of Ingress-NGINX also removed the most widely deployed Ingress implementation from active maintenance in March 2026.

Is the Kubernetes Gateway API stable?​

Its core resources are. GatewayClass, Gateway, ListenerSet, HTTPRoute, GRPCRoute, TLSRoute, TCPRoute, UDPRoute, BackendTLSPolicy, and ReferenceGrant all carry GA-level support under the stable v1 API version.

How do I install the Gateway API in Kubernetes?​

You install the Gateway API CRDs into your cluster, then deploy a conformant implementation, such as Envoy Gateway, kgateway, Istio, or a cloud provider's managed option, since the CRDs alone don't include a working gateway. If you're migrating existing Ingress resources, Ingress2Gateway can translate much of that configuration for you first.