The Ingress-NGINX Controller maintained by the Kubernetes community (repository kubernetes/ingress-nginx) will officially reach its end of life in March 2026. After this date, there will be no more releases, bug fixes, or security patches. Existing installations won't "break" immediately, but they will continue uncontrolled: new CVEs, new Kubernetes versions, new incompatibilities – without upstream fixes.
Important: This does not affect NGINX as a web server. It concerns the Kubernetes controller from the community (ingress-nginx), not the NGINX project.
The good news: You don't have to switch to an entirely new configuration world in one step. There are migrations that feel like a "soft landing" – including the continued use of many classic Ingress-NGINX annotations.
Why This Topic Should Be on Your Agenda Now
Ingress is an edge and security component. Once there are no more patches, "it works" becomes a risk that becomes unpleasantly visible at the latest during:
- Security audits / ISO 27001 / SOC 2
- Customer requirements (Supply Chain, Patch Management)
- Regulations (depending on the industry)
- Kubernetes upgrades
Kubernetes itself puts it very directly: After March 2026, no further updates to address newly discovered security vulnerabilities.
What Exactly Is Ending – and What Is Not?
Ending: kubernetes/ingress-nginx
- Best-effort maintenance until March 2026
- After that: read-only, no releases, no fixes
Not Ending: Kubernetes Ingress as an API
You can continue to use Ingress resources – just not with the community controller if you want upstream maintenance. (And prospectively, the focus is shifting towards the Gateway API.)
Two Practical Migration Paths (Plus a Strategic Option)
At its core, you have three sensible directions:
- Traefik: Migration "on the side" – through annotation compatibility and parallel operation
- F5/NGINX Ingress Controller: "Close to the NGINX ecosystem", commercially driven, politically easy to sell for many enterprises
- Gateway API: Strategically cleaner target state – but rarely the fastest "EOL exit"
Decision Logic in a Table
| Target | When It Fits | Advantage | Typical Drawback |
|---|---|---|---|
| Traefik (Ingress-NGINX Provider) | If you want to get out quickly without rewriting manifests | Automatically translates NGINX annotations; Zero-downtime guide | Differences in behavior/edge cases need testing |
| F5/NGINX Ingress Controller | If "staying with NGINX" is politically/operationally important | Officially maintained controller; Annotations & ConfigMap extensions | Products/features partly tied to the F5/NGINX ecosystem |
| Gateway API | If you are already advancing platform standardization | Roles/delegation, better extensibility | Migration is usually not a drop-in, requires design decisions |
Traefik explicitly positions the migration so that existing Ingress resources continue to run without changes because the Kubernetes Ingress NGINX Provider translates NGINX annotations into Traefik configuration. F5 describes its own Ingress Controller as an NGINX-based implementation with annotation/ConfigMap extensions.
The "Soft" Path: Zero-Downtime Migration from Ingress-NGINX to Traefik
Traefik has prepared the topic very operationally: Install Traefik alongside NGINX, gradually shift traffic, remove NGINX – without downtime.
Prerequisite: Traefik Version and Provider
The Kubernetes Ingress NGINX Provider requires Traefik v3.6.2 or newer. The provider documentation also shows the key parameters (IngressClass, controllerClass, namespaces, etc.).
Migration Principle in One Sentence
You operate two controllers in parallel that "see" the same Ingress resources. Then you shift traffic in a controlled manner – via DNS or external load balancer – and remove NGINX.
Step-by-Step: Parallel Operation, Verification, Traffic Shift, Shutdown
1) Install Traefik in Parallel (Without Touching NGINX)
Traefik is rolled out additionally – the crucial switch is the provider:
helm repo add traefik https://traefik.github.io/charts helm repo update helm upgrade --install traefik traefik/traefik \ --namespace traefik --create-namespace \ --set providers.kubernetesIngressNginx.enabled=true
This exact activation (providers.kubernetesIngressNginx.enabled=true) is the core for Traefik to understand your existing NGINX Ingresses.
Best Practice: Use IngressClass control instead of scanning "everything in the cluster". The provider specifically supports ingressClass/controllerClass configuration.
2) Verify That Traefik Serves Your Ingresses Correctly
Before changing DNS, test Traefik directly via its load balancer address (without redirecting user traffic). Traefik recommends tests with curl --connect-to to maintain hostname/SNI.
Pay special attention to:
- Redirects (HTTP→HTTPS)
- CORS headers, timeouts, body size behavior
- Session affinity / cookie stickiness, if used
- gRPC/WebSockets, if in use
3) Gradually Shift Traffic (Two Practical Variants)
Option A: DNS-Based Migration (Simple, but Plan TTL Realistically)
Add Traefik to DNS (round-robin), observe behavior, then remove NGINX from DNS.
Traefik points out a real issue: Some providers/ISPs do not reliably respect TTL – so keep NGINX running for another 24–48 hours after removing it from DNS.
Option B: External Load Balancer with Weighting (Controlled Rollout)
If you already have a Global LB / Cloud LB / Traffic Steering in front, you can shift weighted (10% → 50% → 90% → 100%). Traefik outlines this as a more controlled alternative.
4) Cleanly Remove NGINX – But Retain IngressClass
A frequently underestimated point: If Traefik observes your existing Ingress resources via the NGINX IngressClass, the corresponding IngressClass must not simply disappear. Traefik explicitly describes this as a necessary step: Preserve IngressClass, then uninstall.
Additionally: Remove admission webhooks to prevent Ingress changes from being blocked later (when NGINX is no longer there).
TLS During Migration: The Classic That Slows Down Teams
If Traefik is not yet "public" in DNS during the verification phase, Let's Encrypt HTTP-01 typically does not work. Traefik suggests pragmatic ways:
- Continue using existing certificates via
spec.tls.secretName(cert-manager, external PKI) - Alternatively, configure ACME DNS-01 Challenge for Traefik
- Do not "green test" with
curl -k– it masks real issues
Practical Tip: If you use cert-manager, this is the most pleasant path: Both controllers access the same TLS secrets.
What Does "Annotation Compatibility" Mean in Reality?
Traefik does not say "we are NGINX", but: We translate NGINX annotations into Traefik configuration. This is invaluable for migration, but you should be honest in the blog post:
- There is a list of supported annotations and behavioral differences.
- Certain "special tricks" from ingress-nginx (e.g., very individual snippets/template hacks) are naturally harder to map 1:1.
If you bring this transparency, the article does not seem like marketing, but like platform experience.
Alternative: Stay Within the NGINX Ecosystem – with the F5/NGINX Ingress Controller
For some organizations, "controller change" is politically difficult in itself. Then the obvious option is: move away from community ingress-nginx, to the officially maintained NGINX Ingress Controller from F5/NGINX.
NGINX documents the controller as an Ingress implementation with extensions via annotations and ConfigMap and promotes it as a long-term alternative after retirement.
Typical Positioning for Decision Makers:
- less "tooling culture change" (NGINX remains in the stack narrative)
- clear vendor owner for lifecycle & support
- but: product/license questions should be clarified early
Strategic Target State: Gateway API (Modernize, but Not as an EOL Emergency Project)
The Gateway API is for many platform teams the cleaner long-term abstraction (role model, delegation, standardization). But: EOL migration ≠ architecture modernization in one sprint.
A proven approach in companies:
- Remove EOL risk (change controller, stabilize operation)
- Observe & standardize (dashboards, logs, SLOs, policies)
- Gradually switch to Gateway API, where it adds value (e.g., delegate teams/namespaces, central policy, multi-tenant)
This keeps the migration deliverable without turning it into a "platform revolution".
Migration Checklist for Production
| Area | What You Should Check | Why It Is Important |
|---|---|---|
| HTTP Routing | Paths, pathType, host-based rules |
Small semantic details have big effects |
| Redirects | HTTP→HTTPS, HSTS | Otherwise breaks login flows and API clients |
| CORS | Headers, origins, credentials | Frontends notice immediately |
| Timeouts/Body Size | Uploads, APIs, webhooks | Common error source after cutover |
| Sticky Sessions | Cookie affinity | Especially relevant for legacy apps |
| gRPC/WebSockets | Upgrade/HTTP2 behavior | Monitoring often shows it only under load |
| Observability | Access logs, metrics, tracing | Without baseline, no safe transition |
| Rollback | DNS back / weighting back | Must be practiced, not just thought |
Conclusion: Migration Is Less a Tool Problem Than a Risk and Operations Problem
Ingress-NGINX ends in March 2026 – this is not a drama, but a clear lifecycle cut. If you want to get out quickly and pragmatically, Traefik with the Ingress-NGINX Provider is a very attractive path because it largely carries over existing Ingress manifests and annotations and describes the parallel operation cleanly. If you need to stay in the NGINX narrative (organization, compliance, support), the F5/NGINX Ingress Controller is the obvious alternative.
The real success curve does not come from "installing a new controller", but from:
- controlled traffic shift
- reproducible tests
- clean TLS strategy
- observability before the transition