platform-notes

February 19, 2026 • 4 min read

The NGINX Ingress Cliff Is Here, and Maintenance Mode Is Not a Plan

Ingress NGINX reaches end-of-life in March 2026. Here is a practical migration view from teams that have to live with the blast radius.

kubernetes ingress gateway-api security devops

Ingress failures rarely look dramatic at first. Mine started with a Teams message:

“Did we mean to expose /metrics publicly?”

We did not. It was a routing mistake, not an exploit, and we fixed it quickly. But that incident forced a harder question: why are we still treating ingress as a solved problem when it sits on the public edge of everything we run?

That question matters more now. In March 2026, k8s/ingress-nginx stops getting releases, including security patches. That is not a lifecycle footnote; it is a deadline.

Why teams delay this decision

Most teams do not stay on Ingress NGINX because they are passionate about it. They stay because it is familiar, already deployed, and politically easy.

What feels “safe” in the short term:

  • Avoiding churn
  • Avoiding migration risk
  • Avoiding platform debates

What actually gets riskier over time:

  • Keeping an internet-facing component that no longer gets patches
  • Treating stability as a substitute for maintainership
  • Assuming “we have not had issues” means “we are fine”

The YAML is not the problem. The threat model is.

The most dangerous sentence: “We’ll monitor CVEs”

I keep hearing versions of the same plan:

  • “We will keep it until something breaks.”
  • “It has been stable for years.”
  • “We will pin the image and watch advisories.”

That sounds disciplined, but it misses the point. When releases stop, patch paths stop. At that moment, “monitoring CVEs” often means “watching known risk accumulate.”

For edge components, that is not operational prudence. It is deferred ownership.

Migration options, with the real trade-offs

There is no no-cost path. There is only choosing which cost you want to pay.

Option 1: Move toward Gateway API

This is not a drop-in swap. It is a model shift.

You get clearer boundaries between platform and app teams, stronger policy surfaces, and better long-term contracts. You also surface hidden complexity that used to live in annotations and tribal memory.

That disruption is real, and useful.

Option 2: Move to commercial NGINX

This is often the lowest-friction path for teams that depend on NGINX behavior. You buy continuity and support, and you accept a tighter vendor dependency.

That can be a rational trade. Just call it what it is.

Option 3: Move to another controller

Cilium, Traefik, HAProxy, Envoy Gateway, and cloud controllers can all work. None are magic replacements. You should expect behavior differences in defaults, observability, and edge-case handling.

The pain is rarely conversion syntax. It is operational surprise.

Option 4: Do nothing

This is easiest to defend in meetings and hardest to defend after an incident. Past stability does not reduce future exposure when patchability ends.

My recommendation

Treat March 2026 as a security deadline, not a roadmap suggestion. If you can, use this moment to move to Gateway API as your interface contract, even if your first controller choice is pragmatic.

If you cannot move to Gateway API immediately, move first to something maintained and supported, then set a near-term Gateway API plan with dates and owners.

Controllers change. Contracts should outlast controllers.

A migration shape that works in practice

You do not need a big-bang cutover. A safer pattern:

  • Run two controllers in parallel
  • Use IngressClass boundaries to migrate incrementally
  • Start with lower-risk services
  • Reserve time for annotation-heavy edge cases
  • Measure parity with real traffic and observability, not only status codes

This is not “changing ingress.” It is closing a known future vulnerability window.

Practical takeaways

  • Treat end-of-patch components like expired certs: still present, no longer trustworthy.
  • Inventory annotations early; they reveal your real migration scope.
  • Make migration progress visible with dashboards and SLOs.
  • If you choose a vendor, choose deliberately and budget for it explicitly.
  • Put dates and ownership on the plan, or it will slip behind “more urgent” work.

Closing thought

A lot of Kubernetes feels free until you need someone to own the hard parts. This is one of those moments.

If you are still on ingress-nginx, you can either carry unbounded edge risk or use this as a forcing function to build a cleaner, more defensible platform boundary.

“Maintenance mode” is not a plan. It is what a plan sounds like when nobody wants to pay the migration cost yet.

References

  1. Kubernetes Blog - Ingress NGINX Retirement Announcement
    https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/

  2. Kubernetes Blog - Steering and Security Response Committee Statement on Ingress NGINX
    https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/

  3. Reddit r/devops - “Ingress NGINX retires in March, no more CVE patches” (Feb 18, 2026 discussion thread)
    https://www.reddit.com/r/devops/comments/1qqkqzn/ingress_nginx_retires_in_march_no_more_cve/

Related posts