Gardener Proposed Traefik as Its ingress-nginx Replacement: What the Emerging Consensus Means for Your Fleet's Edge

Six months after the most-used ingress controller in Kubernetes was archived, the ecosystem's managed offerings have effectively voted on what replaces it. SAP's Gardener project put up GEP-57, proposing a Traefik extension as the official successor to its nginx-ingress shoot addon. SUSE made Traefik the default for new RKE2 clusters. K3s shipped Traefik all along. That is three significant platforms converging on one answer within half a year of the retirement.

Here is the verdict up front, before the evidence. Land Traefik's NGINX-compatibility provider as your drop-in edge now, and convert routes to Gateway API at your pace afterward — do not attempt a flag-day rewrite of every Ingress object as your first move. The destination is still Gateway API. But even Gardener, writing its replacement proposal with a blank sheet, explicitly scoped Gateway API migration out and chose the drop-in first. When the platforms with the most to lose all pick the two-stage crossing, that is the strongest signal your own ingress decision has had since March.

The retirement, then the votes​

The retirement facts, stated once so the rest of the post has a foundation. Kubernetes SIG Network and the Security Response Committee announced the end of ingress-nginx in November 2025, after years of warnings that the project was critically short of maintainers. A joint Steering and SRC statement in January 2026 called it "critical infrastructure for about half of cloud native environments."

Maintenance ended in March 2026 — the repositories moved to kubernetes-retired and went read-only, and there will be no more releases, bug fixes, or security patches of any kind. The warning shot had already been fired a year earlier: the March 2025 "IngressNightmare" CVE-2025-1974 was a CVSS 9.8 unauthenticated remote-code-execution flaw in the admission controller. The next one like it lands on an unpatched codebase forever.

Against that backdrop, here is the convergence — every major vote since the archive, in one table:

Two patterns jump out. First, every distribution that serves clusters it does not fully control — Gardener, RKE2, K3s — landed on Traefik-as-drop-in, not a forced Gateway API rewrite. Second, the one straight-to-Gateway-API jump came from a managed cloud that owns the whole stack and could ship a supported landing zone alongside the legacy controller. If you run your own fleet, you are in the first group, not the second — and the first group's answer is now unanimous.

Why drop-in-first won​

The convergence is not fashion; it is mechanics. Three facts about the post-retirement landscape all point the same way.

First, the Ingress API is frozen, not removed. Kubernetes has no plans to delete it, which means existing Ingress objects keep working and nothing forces a flag-day rewrite at the API level. A frozen API plus a maintained controller that speaks it is a perfectly stable place to stand while you plan stage two.

Second, two ingress classes can coexist in one cluster. Each Ingress object declares its controller via ingressClassName, so the old and new stacks run side by side while routes drain from one to the other. Our per-route migration playbook works through this mechanic in detail: both stacks live, traffic moves host by host, a misbehaving route flips back with a one-object change instead of a cluster-wide rollback. GEP-57 leans on exactly this property — Traefik registers under the nginx ingress class name in compat mode, so existing objects get picked up without modification.

Third, Traefik did the unglamorous work that makes the drop-in real. The KubernetesIngressNGINX provider reads your existing Ingress objects, NGINX annotations included, and translates them into Traefik configuration at runtime — you change the ingress class, not the objects. Proxy 3.7's GA marker (May 2026) put numbers on it: 85 supported annotations covering more than 90% of what real migration teams actually use. Note the honest denominator — not 90% of every annotation ever documented, but 90% of what shows up in real clusters. That is the number you audit your own fleet against, and it is why RKE2's official migration guide and Gardener's proposal both build on this provider rather than on hand rewrites.

What the consensus does NOT promise​

A consensus this tidy deserves a skeptical reading, and Gardener's own documents supply it. GEP-57 is a proposal with limits it states plainly, and each one matters for a fleet copying the shape.

There is no zero-downtime path on Gardener's migration. The operations docs spell out the order — remove the nginx-ingress addon, then install Traefik — because Traefik always creates its own wildcard DNSRecord for *.ingress.<shoot-domain>, which conflicts with the addon's. Plan a maintenance window; the "drop-in" label describes configuration compatibility, not hitless cutover.

Unsupported annotations are silently ignored. GEP-57 says it outright: only a subset of NGINX-specific annotations is translated, and the rest are dropped without error. The 90% coverage number cuts both ways — the remaining 10% fails quiet, not loud. Audit every annotation family in your fleet against Traefik's support list before you move traffic, especially server-snippet and configuration-snippet blocks, which embed raw NGINX config no translator can faithfully carry over.

The rollout is scoped to evaluation shoots. GEP-57's fifth goal restricts the extension to shoots with purpose: evaluation for a safe, incremental rollout. This is a proposal working its way toward production, not a finished migration — treat Gardener's pick as direction signal, not as a battle-tested runbook you can copy verbatim.

Gardener core is not moving to Gateway API in this proposal. Non-goal number one, stated explicitly: Traefik's Gateway API capabilities can be enabled by users independently, but migrating Gardener itself is tracked as separate work. And the follow-up proposal, GEP-68, suggests Envoy Gateway — not Traefik — as the first-class Gateway API extension for shoot clusters. Read that carefully: Gardener's long-term Gateway API story may run on a different data plane than its Ingress-API replacement. The two-stage crossing is real, but the second stage's vehicle is not settled even among the voters.

None of this weakens the verdict; it bounds it. The consensus says "land here first," not "this is the last move you will ever make."

Your fleet's decision​

Translate the convergence into action for the fleet you actually run:

Two timing notes make stage two cheaper than it looked in March. Gateway API v1.6 shipped June 30, 2026 with TCPRoute and UDPRoute graduated to the Standard channel as stable v1 resources — the same Gateway object that routes your HTTP apps can now route raw TCP and UDP, so the eventual migration absorbs your L4 sprawl too instead of leaving it on Services and implementation-specific CRDs (we covered what that unification means in detail). And the reason to finish stage two at all is structural, not cosmetic: Gateway API splits the flat annotation bag — where any tenant's routing edit could touch shared load-balancer config — into platform-owned Gateways, tenant-owned routes, and policy attachments, an RBAC boundary you can actually enforce on a multi-tenant edge.

For the mechanics of the crossing itself — the annotation-by-annotation fate table and the six-step per-route cutover — our migration playbook remains the companion piece to this post. This post is the why now, why Traefik; that one is the how, host by host.

The durable contract​

The post-ingress-nginx era now has a visible shape: a Traefik drop-in consensus for stage one, Gateway API as the agreed destination for stage two, and a managed-cloud exception that proves the rule by owning its whole stack. Gardener's proposal is the latest and most explicit vote, but the pattern was already there in RKE2's default flip and K3s's standing choice. Six months after the archive, "what serves Ingress now" finally has a default answer.

Defaults still need operating. Audit the annotations, plan the window Gardener warns you about, and treat the compat provider as the bridge it is — the far side of the crossing is Gateway API role separation, and v1.6 just made it wide enough for your TCP and UDP traffic too.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.