Kubernetes Announces Retirement of ingress-nginx​

The Kubernetes team recently announced that the ingress-nginx project (one of the most widely used Kubernetes ingress controllers) is entering retirement and moving into maintenance-only mode: Kubernetes Post. The official post confirms that while critical security fixes will continue for now, the project is no longer taking new features and the community is clearly shifting toward the Gateway API as the long-term direction for Kubernetes traffic management. In short: nothing breaks today, but if you are running ingress-nginx in production, you should start thinking about your migration path before it becomes an urgent problem.

This announcement affects ingress-nginx, the community-managed NGINX ingress controller that lives under the Kubernetes GitHub organization. This does not affect nginx-ingress, the commercial and open-source NGINX Ingress Controller maintained by F5/NGINX. That one remains actively developed, with recent releases and features outlined through mid-2025 and beyond. NGINX Docs Unfortunately, the naming overlap is almost guaranteed to confuse people.

Retiring a controller doesn’t mean it stops working this minute. The blog emphasizes “best-effort maintenance” continues for some time. Kubernetes Post But the risk profile changes:

• No new features means if your business needs new traffic-routing capabilities you’ll be stuck.
• Over time security fixes may become less timely/robust.
• The longer you stay on it, the more technical debt you build.

So: treat this as a soon-plan migration, not an emergency fire-drill.

The retirement triggers a migration incentive chain. You should approach this like you would any other deprecation event: identify dependencies, map out annotations, understand traffic requirements, and evaluate candidate replacements. You’ll want to consider alternative ingress controllers (or gateway systems) that:

• Are actively maintained
• Support modern standards (especially the Gateway API) kgateway.dev
• Support your production traffic, features (e.g., canary, rate-limiting, multi-tenant routing)
• The blog from Traefik’s team puts it bluntly: “the ingress-nginx project will transition to maintenance mode, with no new features … you can’t wait years.” Traefik Labs

Even though the F5 nginx-ingress controller is unaffected, the branding collision means many teams will choose to migrate anyway. Some will do it by mistake. Others will do it to avoid confusion in training materials, onboarding docs, or compliance audits. Controllers that sound deprecated often get treated as deprecated, even if they aren’t. Engineers avoid ambiguity like the plague because ambiguity creates incidents.

If you are preparing for a migration, here are the controllers worth evaluating right now. All of them support Gateway API to varying degrees, which is important since Gateway API is the future of Kubernetes traffic management.kgateway.dev

Pros: Very lightweight, good performance footprint. Cons: Less functional and flexible compared to feature-rich controllers; Gateway API support may lag in certain advanced routing scenarios.

Pros: Lightweight, supports Gateway API, well-suited to simpler use-cases. Cons: Also less rich in the ecosystem of annotations/advanced features compared to some others; you may find missing features when you grow traffic patterns.

Pros: Very popular. Supports Gateway API. Their blog makes the migration path easy for ingress-nginx users (even supports many ingress-nginx annotations). Traefik Labs Cons: Performance (raw throughput / latency) may be lower than the heavier duty options (e.g., HAProxy or NGINX plus). If you’re doing very high-volume traffic, you’ll want to benchmark.

Pros: Built for complex traffic scenarios, security, multi-tenant teams, service-mesh style environments. If your architecture demands full control (east-west + north-south, canary, policy/injection) this is a strong play. Cons: Much heavier operational burden. More complex to configure. Higher resource footprint. Not as “drop-in” for simple ingress cases. Not appropriate if you only need basic ingress

The retirement highlights a real architectural shift Ingress was always a thin abstraction layer that required controller-specific extensions to do anything interesting. Over time we ended up with a constellation of annotations that drifted between clusters, vendors, and CI/CD toolchains. Gateway API exists precisely because the community outgrew that model. This retirement is the first major sign that the Gateway API is becoming the standardized future.

Security history played a role Ingress-nginx has had several significant CVEs in recent years, including issues with admission webhooks and request smuggling (e.g., CVE-2025-1974 that was flagged earlier this year: Kubernetes CVE Post). Less active maintenance plus high exposure equals rising operational risk.

Gateway API readiness The Gateway API ecosystem is still evolving. But it’s clearly the forward trajectory for Kubernetes networking.Kubernetes Gateway API. That means if you build for the future now you gain portability and avoid redoing work.

Migration timing and strategy For clusters where ingress-nginx is currently in use: you should plan out phases. Identify all ingress resources, understand annotation usage, map which features you rely on, pick a replacement candidate, run side-by-side tests, plan cut-over windows. If you start evaluating replacements now, you get to migrate on your terms, with a clear architecture and without late-stage fire drills.