Ingress NGINX Is Retiring — Here's How I'm Planning For It

The rug gets pulled

A fairly heavy announcement landed in the Kubernetes community recently. Ingress NGINX — the thing that's been the de facto front door on countless clusters for years — goes end-of-life in March 2026.

Honestly, you could see it coming. Security issues kept surfacing, and the pool of people willing to maintain it kept shrinking. Still, seeing an official date nailed down hits differently. The guy watching your cluster's front gate just handed in his resignation. The gate's still there. Nobody's manning it.

Anyone who's run infra knows why this is uncomfortable. The Ingress controller sits at the outermost edge of the cluster. When it wobbles, every service behind it wobbles with it. That's a rough position to be swapping parts in.

Why it's being retired

The biggest problem with Ingress NGINX was, ironically, that it was too flexible. Being able to inject arbitrary NGINX config through annotations was a genuine strength early on. Whatever weird requirement came in, you could config your way to it.

Over time that flexibility turned into a security hole. If users can inject arbitrary config, so can attackers. Cause and effect line up cleanly here. The flexibility was the cause. The CVEs were the effect.

Then structural problems piled on. Vulnerabilities kept getting found, the maintainer count was small, and the aging architecture had accumulated real technical debt. It couldn't keep pace with Kubernetes releases. The Kubernetes SIG Network folks appear to have concluded they couldn't keep it safe anymore. This wasn't a technical defect so much as people and structure giving out.

Looking at the alternatives

So what are the options? I went through the candidates one by one.

Gateway API (Contour/Envoy)

The forward-looking pick. It's settling in as the next-generation Kubernetes standard, so long-term it's the safest bet. The key shift: instead of cramming features into annotations the way Ingress did, routing rules live in their own separate resources. I like that the boundary between operator and developer responsibility is drawn at the spec level.

Being standards-based gives it stability, community support is strong, and new features land here first. The tradeoff is a steeper learning curve.

Traefik Proxy

Easily the winner on ergonomics. Configuration is intuitive, automatic service discovery actually works, and it just needs less babysitting. Setup and management are simple, the docs are good, and the community is active. Let's Encrypt integration comes built in.

Kong Ingress Controller

If you need more than routing — actual API gateway functionality — Kong enters the picture. The plugin ecosystem is rich enough to handle auth, rate limiting, and transformations at the controller layer. Having worked with company-wide OpenAPI, the question of whether features belong in the gateway or in the application was a constant argument. Kong pulls that center of gravity toward the gateway.

HAProxy Ingress

If raw performance is the top priority, HAProxy is worth a look. Its strength is stability and throughput proven over a long time. It fits the job of absorbing traffic quietly rather than doing anything flashy.

How to actually choose

You have to weigh several axes at once. Pick on a single metric and you'll regret it later.

Security

항목	중요도	평가 포인트
취약점 이력	높음	CVE 기록, CVSS 점수
대응 속도	높음	패치 릴리즈 속도
보안 기능	중간	mTLS, OIDC 지원 여부

Security is what caused this retirement in the first place, so it's the axis to look at first. Otherwise you're setting up to repeat the exact same mistake.

Operational complexity

Look at install and configuration difficulty, the learning curve for your existing team, how messy the CI/CD integration is, and the quality of the debugging tools. Day-one difficulty matters less than how fast you can find root cause when something breaks at 3am. Run things long enough and you learn that a tool's real cost shows up during incidents, not during normal operation.

Performance and scalability

Nothing beats running it yourself against something close to your real workload. Measure RPS capacity, latency, and resource usage together. Published benchmarks are a reference point, but a number that isn't from your traffic pattern is worth about half as much.

Migration plan

Do the switch in stages. I wouldn't recommend swapping the front door in one shot.

Step 1: Inventory what you have

Start by cataloging every Ingress resource currently running. What matters most is what's buried in the annotations. The custom config hiding there is what determines how hard the migration will be.

# 모든 Ingress 리소스 조회
kubectl get ingress --all-namespaces

# 특정 어노테이션 사용 현황 확인
kubectl get ingress -o yaml | grep -A 5 -B 5 "nginx.ingress"

Step 2: Validate the target

Beat on it in staging. Specifically, check whether the annotations you've been relying on have equivalents in the new solution. NGINX-only config rarely maps one-to-one. Whatever mismatches you don't find here, you'll find on cutover day.

Step 3: Roll out gradually

Blue-green or canary — slice the risk into small pieces.

1. 새 Ingress 컨트롤러 설치
2. 일부 서비스만 새 컨트롤러로 라우팅
3. 모니터링하면서 비중을 조금씩 확대
4. 모든 트래픽 이전 후 구 컨트롤러 제거

The point is staying in a state where you can always roll back. The moment you move all traffic at once, that card is gone.

Step 4: Monitor and verify

Confirm that metrics, logs, and alerts still work against the new controller. Prometheus metric formats can change, so dashboards and alert rules need updating too. Miss this and you finish the migration with no visibility into your own cluster front door. It looks fine, but you're driving with the instrument panel dark.

How much runway do you need

The deadline is March 2026, but I'd give yourself margin and aim to be done by the end of 2025.

Large clusters should move even earlier. Replacing a tool isn't just the technical work. Your team needs time to get comfortable with it and to re-learn incident response with the new thing in hand. If you barely finish by the deadline and then hit your first outage, you'll be fumbling around at 3am with a tool you don't know.

What I'd pick

Here's what I landed on after running these myself. Long-term stability first? Gateway API (Contour). Need to migrate fast? Traefik. High performance requirements? HAProxy. Need API gateway features? Kong. Already running a service mesh? Istio Gateway is the natural fit.

There's no single right answer. It comes down to what your team runs into most often.

Wrapping up

Retirements like this are normal in a tech ecosystem. Doesn't make it any less annoying when it's your cluster's front door on the line.

But treating it as nothing more than a forced swap is leaving value on the table. This is a chance to clear out the config debt you've been piling into annotations and rebuild your routing rules on top of a real standard. If I have to touch it anyway, I'd rather land somewhere that doesn't put me through this same exercise at the next retirement.