Kubernetes Gateway API v1.2: Replacing Ingress [2026]

The Lead

By April 2026, the interesting question is no longer whether Kubernetes Ingress still works. It does. The real question is whether it is still the right control surface for modern platform teams. The Kubernetes docs now state that the project recommends using Gateway instead of Ingress and that the Ingress API has been frozen. That one line changes the entire architectural conversation: Ingress is stable, but it is no longer where the platform evolves.

Gateway API is that new control surface. Version v1.2, released on October 3, 2024, was the point where the replacement story stopped sounding aspirational and started looking operational. The release moved HTTPRoute timeouts, Gateway infrastructure labels and annotations, and Service appProtocol handling for h2c, ws, and wss into the Standard channel, while cleaning up old API versions and expanding the experimental pipeline with retries, percentage-based mirroring, named rules, and backend TLS work.

That matters because Ingress always had an awkward split personality. The resource was intentionally minimal, but real production stacks needed richer traffic policy, backend protocol hints, cross-namespace delegation, and safer multi-team ownership. Controllers filled the gap with annotations, side CRDs, and implementation-specific defaults. Gateway API flips the model: the richer contract is part of the API design, not smuggled through controller-specific strings.

If you have spent years translating business intent into a wall of NGINX annotations, that difference is not cosmetic. It is the difference between an edge API that documents architecture and one that encodes tribal knowledge.

Architecture & Implementation

The core design move in Gateway API is role orientation. Ingress compressed entry-point ownership and app routing into one object. Gateway API decomposes that work into resources that map to how teams actually operate.

• GatewayClass selects the implementation and the infrastructure behavior.
• Gateway defines listeners, ports, TLS, and the entry surface the platform exposes.
• HTTPRoute lets application teams express host, path, match, filter, and backend policy.
• ReferenceGrant and policy attachments govern how cross-namespace references and shared controls work.

This decomposition is why Gateway API is a real Ingress successor instead of a syntax refresh. It gives cluster operators a clean contract for edge ownership, while letting application teams change routes without gaining the right to mutate the load balancer itself.

Here is the practical difference. A typical legacy Ingress often packs routing, TLS termination, rewrites, timeouts, and controller extensions into one manifest:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/proxy-read-timeout: "10"
spec:
  ingressClassName: nginx
  rules:
  - host: shop.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: shop-api
            port:
              number: 80

The Gateway API version is more verbose, but the extra objects are not overhead for its own sake. They separate responsibilities and make routing intent explicit:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: edge
spec:
  gatewayClassName: shared
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop
spec:
  parentRefs:
  - name: edge
  hostnames:
  - shop.example.com
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: shop-api
      port: 80
    timeouts:
      request: 10s

That timeouts block is exactly the kind of capability that used to live in annotations. In v1.2 it became Standard for HTTPRoute. The same release also standardized infrastructure propagation, which means the controller-generated data plane can inherit labels and annotations from the Gateway spec. That sounds small until you run shared platform stacks with service meshes, cost allocation labels, or organization-wide policy selectors. Suddenly the generated pieces of the gateway are first-class citizens in the rest of your platform.

The appProtocol work is equally important. Gateway API v1.2 standardized honoring kubernetes.io/h2c, kubernetes.io/ws, and kubernetes.io/wss on Services and EndpointSlices. In plain English, the backend can finally declare protocol expectations in a Kubernetes-native way, and the route can respect them without controller-specific hacks. For WebSocket-heavy apps and HTTP/2 cleartext backends, that is a real reduction in ambiguity.

Just as important are the breaking changes. v1.2 removed the old v1alpha2 forms of GRPCRoute and ReferenceGrant. That removal signaled maturity: the project was willing to clean up old surfaces rather than carry migration baggage forever. It also means upgrades require discipline. If your controller or CRDs still depended on the old version, an upgrade could fail even when your YAML already said v1.

One practical migration pattern is to convert in layers. First move the shared edge into Gateway. Then migrate application routing into HTTPRoute. Then attach policy and advanced filters. That sequencing preserves ownership boundaries and avoids the classic mistake of translating every annotation one-for-one without asking whether the old behavior should survive. During that cleanup phase, a small utility like TechBytes' Code Formatter is useful for keeping generated YAML readable before it lands in Git.

Benchmarks & Metrics

The most important benchmark caveat is this: Gateway API is not a data plane. Swapping Ingress for Gateway API does not automatically improve request latency or throughput. Your Envoy, Istio, Kong, Cilium, Traefik, or cloud controller still determines most of that behavior. What Gateway API changes is the quality of the control plane contract.

So the right benchmark is not just requests per second. It is whether the API gives you safer, more portable, more observable traffic management.

The v1.2 conformance matrix shows how that portability was maturing by the ecosystem level. In the Gateway Profile HTTPRoute table, implementations are compared across 20 standard features and 1 experimental feature. As of the current v1.2 implementations page, Istio 1.24 reports 20/20 standard and 1/1 experimental, Cilium v1.17 reports 19/20 and 1/1, and Envoy Gateway reports 18/20 and 1/1. On the mesh side, Istio 1.24 shows 17/18 standard and 1/1 experimental support, while Cilium v1.17 shows 16/18 and 1/1.

Those are not vanity metrics. They tell you how much controller-specific behavior you will still need to carry. In the Ingress era, feature support was often buried in annotations and blog posts. In the Gateway era, conformance coverage is becoming part of the buying decision.

There is another number worth remembering. In the Kubernetes security response on the March 24, 2025 ingress-nginx vulnerabilities, the project noted that over 40% of Kubernetes administrators were using ingress-nginx. That is a reminder that architectural replacement is not just about elegance. It is also about shrinking the amount of critical behavior hidden inside one highly privileged implementation surface.

For platform teams evaluating a migration, measure these four things instead of looking for a magical latency win:

1. Config portability: Count how many controller-specific annotations remain after translation.
2. Conformance coverage: Compare required Gateway API features to your chosen implementation's score.
3. Behavior parity: Test redirects, rewrites, TLS, headers, and timeout handling with golden-route suites.
4. Operational blast radius: Measure how many teams need write access to shared edge resources before and after migration.

If you still want request-path metrics, keep the test honest. Run p50, p95, and p99 latency under the same data plane, once with the old Ingress configuration and once with the Gateway configuration. Then compare route correctness, retry behavior, WebSocket upgrade success, and reload stability. The outcome you are looking for is usually not dramatic speedup. It is lower configuration ambiguity and fewer controller surprises.

Strategic Impact

The strategic value of Gateway API is that it is becoming a common networking language across ingress, east-west routing, and higher-level extensions. That is a much bigger prize than replacing a single resource kind.

First, it gives organizations a better multi-tenant edge model. Platform teams can own the listeners, addresses, certificates, and gateway class. Application teams can own routes. Security teams can reason about policy attachment and cross-namespace references without parsing opaque annotations. This is closer to how real enterprises divide responsibility, which means fewer exceptions and cleaner RBAC.

Second, it makes implementation switching less painful. No API can erase all provider differences, but Gateway API moves feature negotiation into a typed, documented surface. Conformance tables, supported features, and status reporting are not abstract governance work. They are what let a team compare products without reverse-engineering every controller quirk.

Third, Gateway API is now clearly where new Kubernetes networking ideas land. v1.3, announced on June 2, 2025, pushed percentage-based request mirroring into the Standard channel and added experimental CORS filters, XListenerSet, and retry budgets. v1.4, announced on November 6, 2025 for the October 6, 2025 release, moved BackendTLSPolicy, supportedFeatures in GatewayClass status, and named rules into the Standard channel. That sequence matters. It shows the project is steadily absorbing the features teams once modeled through bespoke annotations and sidecars.

There is also a broader platform story. In June 2025, Kubernetes introduced the Gateway API Inference Extension to support model-aware routing for AI workloads. Whether that particular extension becomes universal is almost secondary. The bigger point is that the community is building new routing domains on top of Gateway primitives, not on top of Ingress.

Road Ahead

From the vantage point of April 5, 2026, the case for Gateway API replacing Ingress is strong, but the replacement is still a program, not a flip of a switch.

The good news is that the migration story has improved materially. On March 20, 2026, Kubernetes SIG Network announced Ingress2Gateway 1.0, positioning it as a stable migration assistant. The project notes support for 30+ common ingress-nginx annotations, including CORS, backend TLS, regex matching, and path rewrites, plus integration tests intended to validate behavioral equivalence. That is exactly the kind of tooling the ecosystem needed: not just YAML conversion, but a disciplined attempt to map runtime behavior.

Still, no serious team should read that as permission for blind translation. The hard part is not generating manifests. The hard part is deciding which historical behaviors are still desirable. Gateway API gives you a better contract, but it also forces you to make architecture decisions you may have deferred for years.

• Keep the behaviors that are clearly tied to product requirements.
• Re-test anything previously implemented through controller snippets or undocumented defaults.
• Drop legacy annotation patterns that only existed because Ingress had no native concept for the feature.

That is why Gateway API v1.2 matters so much in hindsight. It was the release where the successor stopped being theoretical. It standardized the primitives teams were actually missing, enforced some overdue cleanup, and set up a release process that kept the API moving. The later v1.3 and v1.4 releases only reinforced the trend.

Ingress is not disappearing from Kubernetes. The project has been explicit about that. But if you are choosing the API surface you want to bet your next three years of traffic policy on, the answer is no longer ambiguous. Gateway API is where Kubernetes networking is going.