Kubernetes Gateway API in 2026: A Practical Ingress Migration Path

Kubernetes Gateway API is a mature, GA successor to the older Ingress API. The 2026 trigger is the retirement of the Ingress-NGINX controller project in March. Existing installations keep working, but receive no further releases, bug fixes, or security updates. This is not a deadline for the Ingress API. It is a reason to choose a supported controller and plan the move before the current controller becomes an incident risk.

Ingress puts most routing intent into one resource and often relies on controller-specific annotations. Gateway API separates ownership. GatewayClass selects the controller implementation, Gateway defines listeners and TLS, and HTTPRoute attaches application routing rules to a listener through parentRefs. That split lets a platform team own the Gateway while an application team owns its HTTPRoute. The trade-off is more objects to manage and a compatibility review for every annotation.

Install the Gateway API CRDs and the controller’s documented version first. The API release is independent of the Kubernetes version. In July 2026 the project listed v1.6.1 in the Standard channel, but a controller may support a narrower range of Gateway API features. Pin the CRD release and controller image in Git, then record the supported channel in the migration notes. Experimental or Extended features need a separate check; do not assume that a Standard resource supports every implementation-specific option.

A minimal HTTP listener and route can look like this:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: public
  namespace: edge
spec:
  gatewayClassName: example-controller
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    hostname: app.example.com
    tls:
      mode: Terminate
      certificateRefs:
      - name: app-tls
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app
  namespace: app
spec:
  parentRefs:
  - name: public
    namespace: edge
    sectionName: https
  hostnames: ["app.example.com"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: api
      port: 8080

Run SIG Network’s ingress2gateway v1.0 assistant against the existing manifests. Review its warnings instead of treating generated YAML as a finished migration. Rewrite annotations for rate limits, authentication, header manipulation, or snippets according to the new controller’s documentation. A rewrite that only checks 200 responses can miss TLS SNI errors, redirect loops, WebSocket handling, request-size limits, and cross-namespace ReferenceGrant requirements.

Run the new controller beside Ingress in a development cluster. Compare status conditions, certificate renewal, access logs, upstream timeouts, and metrics for the same test matrix. Use a canary hostname or weighted DNS/load-balancer target for the first production traffic. Shift gradually, watch error rate and latency, and keep the old route available for rollback. Delete Ingress resources and uninstall Ingress-NGINX only after the new Gateway path has served real traffic through one complete rollback window.

Sources: ingress2gateway v1.0 release, Ingress-NGINX retirement, Migrating from Ingress, Gateway API releases.