Kubernetes Gateway API: The Ingress Replacement You Need Before Ingress-NGINX Hits End-of-Life

There is a deadline that a lot of Kubernetes teams are going to miss: Ingress-NGINX, the most widely deployed Kubernetes ingress controller, is scheduled for end-of-life on March 31, 2026. After that date: no security patches, no bug fixes, no compatibility guarantees with newer Kubernetes releases. If you are running Ingress-NGINX in production and have not started thinking about Gateway API, you are behind.

The good news is that Gateway API is not just a replacement for Ingress. It is a genuinely better model for managing cluster traffic. The architectural improvements are real enough that I would recommend migrating to it even without the EOL forcing function. But the EOL makes it urgent.

I have migrated several clusters from Ingress-based configurations to Gateway API over the past year. The migration is not trivial, but it is also not as painful as it sounds once you understand what is actually changing conceptually.

What Is Wrong with Kubernetes Ingress

The Ingress resource has been part of Kubernetes since version 1.1. It was designed to solve a specific problem: expose HTTP services inside a cluster to the outside world. It succeeded at that problem, but only barely.

The core issue is that Ingress is too thin. The specification defines a minimal HTTP routing model: route requests to backends based on hostname and path. That is it. Everything else, and there is a lot of everything else, gets pushed into controller-specific annotations.

Want to add rate limiting? That is an annotation, and the annotation syntax is different for every controller. Want to configure timeouts? Another annotation, different format. Want to do header-based routing, traffic splitting, circuit breaking, or any of the other things that production traffic management requires? All annotations. All controller-specific. All non-portable.

The result is that your Ingress manifests are not actually portable. A configuration that works with Ingress-NGINX will not work with HAProxy Ingress or Traefik. The annotations are different. Teams that switch controllers have to rewrite their routing configurations from scratch.

There is a governance problem too. Ingress was a single resource managed by a single team (platform engineers or SREs). Every time an application team needed a new routing rule, they had to go through the platform team to modify the Ingress resource. This is not a security model so much as an operational bottleneck dressed up as one.

Platform teams also had no good way to express what application teams were and were not allowed to configure. Ingress gave you one resource with one permission scope. Either you could modify routing for the entire cluster or you could not.

Gateway API: The Role-Oriented Model

Kubernetes Gateway API is the official successor to Ingress, developed by the SIG Network group and now generally available. The fundamental design change is role orientation: instead of one resource that everyone touches, Gateway API splits traffic management into multiple resources, each owned by a different persona.

GatewayClass is cluster-scoped and owned by the infrastructure team. It defines what implementation will handle traffic (Cilium, Istio, Envoy Gateway, Traefik, NGINX). Think of it as registering the available load balancer technology. In most clusters, there is one GatewayClass per implementation. Infrastructure teams create them; application teams never need to touch them.

Gateway is namespace-scoped (or cluster-scoped, depending on configuration) and owned by the platform team. It instantiates a specific load balancer with specific capabilities: which ports it listens on, which TLS certificates it uses, which namespaces are allowed to attach Routes to it. The platform team controls the Gateway. Application teams do not modify it.

HTTPRoute (and TCPRoute, TLSRoute, GRPCRoute) are namespace-scoped resources owned by the application team. An HTTPRoute says “for traffic arriving at the Gateway matching these hostnames and paths, send it to this service.” Application teams manage their own HTTPRoutes without touching the Gateway or GatewayClass. Multiple application teams can own their own HTTPRoutes that attach to the same Gateway.

This separation maps to how organizations actually work. Infrastructure teams care about which load balancer technology runs, what capacity it has, and which namespaces can use it. Platform teams care about what the Gateway exposes. Application teams care about routing their specific service. Each persona manages only the resources in their domain.

What Gateway API Actually Supports

Beyond the organizational model, Gateway API formalizes routing capabilities that Ingress left to annotations. These are first-class features of the spec, not controller-specific extensions.

Traffic splitting is built in. A single HTTPRoute can specify multiple backends with weights, enabling canary deployments and blue-green switches without annotations:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: payments-route
spec:
  parentRefs:
  - name: production-gateway
  hostnames:
  - "api.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /payments
    backendRefs:
    - name: payments-v2
      port: 8080
      weight: 90
    - name: payments-v1
      port: 8080
      weight: 10

This routes 90% of traffic to v2 and 10% to v1, directly in the manifest with no annotations. This is canonical, portable, and works the same across all Gateway API implementations. Compare this to the annotation gymnastics required to do canary deployments with Ingress-NGINX: multiple Ingress resources, nginx.ingress.kubernetes.io/canary: "true", nginx.ingress.kubernetes.io/canary-weight: "10". The Ingress approach works, but it is not standard and it does not translate to other controllers. For teams using feature flags alongside traffic splitting for progressive delivery, Gateway API’s weight-based routing is the right infrastructure primitive to pair with flag-controlled rollouts.

Header-based routing routes requests based on header values:

rules:
- matches:
  - headers:
    - name: "X-User-Beta"
      value: "true"
  backendRefs:
  - name: beta-backend
    port: 8080

URL rewriting and redirects are standard filters:

rules:
- filters:
  - type: URLRewrite
    urlRewrite:
      path:
        type: ReplacePrefixMatch
        replacePrefixMatch: /api/v2

gRPC routing via GRPCRoute handles the gRPC protocol natively without requiring the annotations that Ingress-NGINX needed for gRPC to work correctly with HTTP/2.

TCP and TLS routing via TCPRoute and TLSRoute handle non-HTTP traffic that Ingress simply could not handle.

The Migration Path from Ingress

Migrating an existing cluster from Ingress to Gateway API is not a flag day. You run both in parallel during the transition, migrating services incrementally.

The first step is installing a Gateway API implementation. Major options in 2026:

Cilium is my current default recommendation. Cilium’s eBPF-based networking provides Gateway API support alongside its CNI and network policy capabilities. If you are already running Cilium as your CNI, enabling Gateway API support adds minimal operational overhead. No additional controller to manage.

Istio includes Gateway API support as its primary ingress model. If you are already running a service mesh with Istio, using Istio’s Gateway API implementation is the natural path. The service mesh and ingress control plane are unified.

Envoy Gateway is the CNCF project building a production-grade Gateway API implementation on Envoy Proxy. Envoy is the same data plane used by Istio, Contour, and many cloud load balancers, so the performance and capability profile is excellent. Envoy Gateway is maturing fast and is a good choice for teams that want a clean, purpose-built implementation.

Traefik and NGINX (the Kubernetes NGINX project, distinct from Ingress-NGINX) also have Gateway API implementations.

Once you have an implementation running, creating a GatewayClass and a Gateway is the first step:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: cilium
spec:
  controllerName: io.cilium/gateway-controller
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: production-gateway
  namespace: networking
spec:
  gatewayClassName: cilium
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      certificateRefs:
      - name: wildcard-cert
        namespace: networking
    allowedRoutes:
      namespaces:
        from: All

Then, for each Ingress resource you migrate, create an equivalent HTTPRoute:

# Old Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  annotations:
    nginx.ingress.kubernetes.io/proxy-read-timeout: "60"
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 8080

# New HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
spec:
  parentRefs:
  - name: production-gateway
    namespace: networking
  hostnames:
  - "api.example.com"
  rules:
  - backendRefs:
    - name: api-service
      port: 8080

The timeout configuration that was an annotation is now a first-class field in the HTTPRoute’s retry and timeout policy. The Gateway API tools project includes converters that can generate HTTPRoute manifests from existing Ingress resources, which significantly reduces the manual migration work for large configurations.

Policy Attachment: The Extension Model Done Right

Ingress extended via annotations. Gateway API extends via Policy Attachment, a formal mechanism for attaching policy resources to Gateway API objects.

A BackendTLSPolicy attaches to a Service to configure TLS from the Gateway to the backend pod. A BackendLBPolicy controls load balancing behavior for individual backends. The SIG Network working group is standardizing policies for rate limiting, circuit breaking, and retry logic.

The critical difference from annotations is scope and inheritance. A policy can attach at the GatewayClass level (applies to everything), the Gateway level (applies to all Routes on this Gateway), or the HTTPRoute level (applies to this specific route). Policies inherit downward and can be overridden at more specific levels.

Platform teams can enforce policies at the Gateway level that application teams cannot override. Applications can set their own policies within the scope the platform allows. This is the governance model that Ingress annotations never had.

Multi-Tenant Configuration

Gateway API’s role separation solves the multi-tenancy problem that Ingress handled poorly. The pattern:

1. Infrastructure team creates GatewayClasses for each environment (production, staging)
2. Platform team creates Gateways in a shared networking namespace, configured to accept Routes from specific namespaces
3. Each application team creates HTTPRoutes in their own namespace, referencing the shared Gateway

The allowedRoutes field on Gateway listeners controls which namespaces can attach:

listeners:
- allowedRoutes:
    namespaces:
      from: Selector
      selector:
        matchLabels:
          environment: production

Only namespaces labeled environment: production can attach Routes to this Gateway. Platform teams can also use ReferenceGrants to explicitly permit cross-namespace references when needed.

This model scales to large organizations with many teams sharing a cluster, with each team self-managing their routing without platform team involvement in routine changes. Combined with Kubernetes network policies for east-west traffic control, you get complete traffic management across the cluster without centralized bottlenecks.

Operational Considerations

Monitoring and observability for Gateway API implementations varies by controller, but most expose standard metrics: request rate, error rate, latency by route. Cilium exposes these through Prometheus-compatible metrics. The layer 4 versus layer 7 metrics distinction matters here: your Gateway API implementation operates at layer 7 and can expose per-route metrics that a pure layer 4 load balancer cannot.

Certificate management integrates with cert-manager through the Gateway API listeners. The standard pattern is to use cert-manager to provision certificates and reference them from Gateway listeners, the same pattern that worked with Ingress but now with the cert-manager Gateway API integration providing better automation.

Health checking and circuit breaking are available through policy attachment in implementations that support them. Not all implementations support all policies yet. Check your chosen implementation’s documentation for which policies are currently supported before planning your configuration.

Migrating between Gateway API implementations is more tractable than migrating between Ingress controllers, because the core HTTPRoute, GatewayClass, and Gateway resources are standard. Implementation-specific extensions exist, but the baseline routing configuration is portable. This portability is one of the most significant operational improvements over the Ingress ecosystem.

The Timeline Reality

Ingress-NGINX EOL is March 31, 2026. If you are reading this after that date, you are already running unsupported infrastructure. The migration is not instant: evaluating implementations, testing configurations, migrating services incrementally, training your team on the new model. A realistic timeline for a medium-size cluster with dozens of services is two to three months of focused effort.

Start with non-production environments. Deploy a Gateway API implementation alongside your existing Ingress controller. Migrate one service at a time. Build familiarity with the new resource types and configuration model. By the time you are migrating production services, the operational patterns should be well-understood.

The migration is worth doing independently of the EOL pressure. The annotation sprawl in mature Ingress configurations is a maintenance burden that Gateway API’s structured model eliminates. The role-based ownership model reduces the coordination overhead between platform and application teams. The native support for traffic splitting, header routing, and gRPC makes production traffic management cleaner.

Gateway API is the right model for Kubernetes traffic management going forward. The EOL deadline just makes the conversation easier.