Gateway API after ingress-nginx: don't turn one migration into two

Your ingress-nginx controller may still be routing traffic without a problem. That does not make it safe to leave it there.

‍

The Kubernetes project retired ingress-nginx in March 2026. Existing deployments continue to run, but there are no more releases, bug fixes or security patches. The official Kubernetes announcement recommends moving to Gateway API or another maintained Ingress controller.

‍

"It still works" is not a good reason to wait. Your ingress controller is the front door of your cluster: it handles every request that reaches your workloads from the internet. Every month without patches means any newly discovered vulnerability in that front door simply stays open.

‍

Gateway API is the logical destination for many teams. Moving there immediately is not always the safest route.

‍

We ran into that distinction while migrating a SaaS platform we manage. The plan was to replace ingress-nginx and adopt Gateway API in one move. A feature the platform already used in production stopped that plan.

‍

We separated the migrations instead.

‍

You are facing two migrations

Leaving ingress-nginx can involve two independent changes.

‍

First, you can replace the controller that serves your existing Ingress resources. Traefik and Contour are examples of other implementations.

‍

Second, you can replace the resource model itself. Your Ingress resources then become Gateway, HTTPRoute, TLSRoute or other Gateway API resources.

‍

Those changes solve different problems.

‍

Replacing ingress-nginx removes the retired controller from your platform. Moving to Gateway API changes how your routing is configured and how responsibilities are divided between teams.

‍

They do not have to happen during the same cutover.

‍

What Gateway API changes

Ingress started with a limited scope. Features outside its original design were added through controller-specific annotations.

‍

That works until you want to change implementations.

‍

Redirects are a simple example. The annotation you use with ingress-nginx may differ from the one another controller expects. Layer 4 traffic and gRPC require controller extensions too. Each extension creates more configuration that belongs to one implementation.

‍

Gateway API standardises more of that behaviour.

‍

It also splits responsibilities across different resources. Cluster operators work with Gateway resources. Application developers work with HTTPRoute or TLSRoute resources in their own namespaces.

‍

One of our engineers described Ingress as “a bit of a godlike resource”. Developers and cluster operators work on the same object. Developers need permission to change their routes, but that permission can also give them access to settings that belong to the cluster operator.

‍

Gateway API gives Kubernetes RBAC a clearer boundary. The Gateway determines which namespaces may attach routes. Teams can work on their own routing without receiving control over another team’s Gateway.

‍

That separation becomes valuable as the number of teams and workloads grows.

‍

It does not guarantee that every Gateway API implementation supports every feature you already use.

‍

What blocked Gateway API at a platform we manage

The platform used ingress-nginx with several implementation-specific annotations. One of them handled TLS client certificate validation.

‍

Our planned route looked straightforward:

‍

ingress-nginx → Traefik with Gateway API

‍

Traefik supported both Ingress and Gateway API. Its Gateway API implementation did not yet support the TLS frontend configuration this platform required.

‍

The missing functionality was tracked as tls.frontendValidation. The Traefik feature request had been open since August 2025 and was still unresolved when we assessed the migration.

‍

Moving to Gateway API would therefore mean waiting for the implementation to catch up. In the meantime, ingress-nginx would remain in production without security updates.

‍

We did not need to accept that trade-off.

‍

Traefik could also serve the platform’s existing ingress-nginx manifests. That gave us another route:

‍

ingress-nginx → Traefik serving Ingress → Traefik serving Gateway API

‍

The first step removes ingress-nginx. The existing Ingress resources remain in place.

‍

The second step moves the resource model to Gateway API when the implementation supports the features the platform needs.

‍

Why the staged route worked here

Changing the controller first reduced the number of moving parts during each cutover.

‍

We did not have to replace the controller, rewrite the routing resources and validate new TLS behaviour in one release. The team could move services to Traefik one by one and switch the traffic through DNS.

‍

At the time of our internal review, nine services had moved and twelve remained. Each service could be handled separately.

‍

The route also kept Gateway API on the roadmap. The second step is still a migration: you move from Traefik's Ingress setup to its Gateway API setup. But because both sides are Traefik, translating the configuration is a lot easier than switching vendors at the same time.

‍

This does not make Traefik the automatic answer for every environment. It was the right bridge for a platform with existing ingress-nginx manifests and a Gateway API requirement that Traefik did not yet support.

‍

The important decision was separating the urgent controller replacement from the broader API migration.

‍

When going straight to Gateway API can work

At another client, we already run Gateway API across development, acceptance and production. That environment did not hit the same blocker.

‍

A direct migration can work when the Gateway API implementation supports the behaviour your platform already depends on. Keep in mind that Gateway API is a specification, not a product. Not every feature is available everywhere, and what you can actually use depends heavily on how your provider has implemented it. Two implementations can both claim Gateway API support and still behave differently.

‍

The first platform had a specific TLS requirement that stopped the move. The second could proceed.

‍

That difference matters more than a general recommendation to adopt Gateway API immediately.

‍

Start with the configuration that is running today. Then check whether your chosen implementation can reproduce it.

‍

Start with the implementation-specific behaviour

Before choosing a migration route, map the behaviour that ties you to ingress-nginx.

‍

Start with:

• List the implementation-specific annotations used across your Ingress resources.
• Identify routing behaviour that depends on controller extensions, including redirects, layer 4 traffic and gRPC.
• Check which TLS and client-certificate requirements must survive the migration.
• Verify whether your chosen Gateway API implementation supports those requirements today.
• Decide whether you can migrate the controller and resource model separately.
• Plan the cutover service by service, with DNS as the final traffic switch.

‍

This gives you two realistic routes.

‍

You can go straight to Gateway API when your implementation supports what you need. You can replace the controller first when Gateway API would force you to wait for functionality that already exists in your current environment.

‍

The goal is not to reach Gateway API in the fewest possible steps. The goal is to remove ingress-nginx without combining more production changes than your team can safely manage.

‍

For us, that meant using Traefik as a bridge at one platform and running Gateway API directly at another.

‍

Same destination. Different route.

‍

If your implementation-specific behaviour is spread across years of annotations, a focused platform audit can help turn it into a concrete migration route.