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 plan a supported controller migration.

The migration model replaces an Ingress with three resources: a GatewayClass, a Gateway, and HTTPRoutes. The GatewayClass pins the controller implementation you choose, the Gateway binds listeners and TLS certificates, and each HTTPRoute attaches routing rules to the Gateway through a parentRef. Host and path rules become HTTPRoute matches, TLS termination moves to the Gateway, and an HTTP-to-HTTPS redirect becomes a RequestRedirect filter. Gateway API is installed as CRDs, and its version is separate from the Kubernetes version, so check which Gateway API release your chosen implementation supports before you start.

Use the SIG Network ingress2gateway v1.0 assistant to generate the initial manifests and to flag Ingress-NGINX annotations that have no direct equivalent. Treat the output as a starting point: review the warnings, test in a development cluster, and run the new controller beside the existing Ingress. Shift traffic gradually through weighted DNS, a load balancer, or traffic splitting, and remove the old resources only after the new path is proven in production.

The API surface still moves — the project ships regular Standard-channel releases, with v1.6.1 in July 2026 — so pin the CRD version and controller release you have tested, and record them in your migration notes. A clean cutover sequence is: run a canary Gateway and HTTPRoute, verify routing and TLS, move DNS or traffic weight, and only then delete the Ingress resources and the old controller.

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