On November 11, 2025, the Kubernetes project officially announced the retirement of the Ingress NGINX controller (the kubernetes/ingress-nginx project).

The reaction across platform and infra teams has been predictable:

• Is Kubernetes removing Ingress?
• Does this break my existing clusters?
• What should I migrate to — and how urgent is it?
  

This post breaks everything down clearly:

1. What Ingress NGINX actually is
2. What the retirement announcement says
3. What it doesn’t mean
4. A real-world example (EKS with multiple NGINX controllers)
5. The two realistic migration paths
6. Practical guidance for teams that need to plan next steps

1. Ingress vs. Ingress NGINX vs. Gateway API — The Fast Primer

Ingress (the Kubernetes API)

• A stable Kubernetes API that defines HTTP(S) routing rules.
• It is configuration only — you still need a controller to implement the rules.
  

Ingress NGINX (the controller that’s being retired)

• A widely adopted Ingress controller maintained under kubernetes/ingress-nginx.
• Early, flexible, and cloud-agnostic — but hard to maintain and increasingly risky.
• Its flexibility (e.g., arbitrary NGINX snippets) is a major source of ongoing security debt.
  

Gateway API (the modern traffic API)

• The next evolution: more expressive, more secure, more structured.
• Defines GatewayClass, Gateway, HTTPRoute, TCPRoute, GRPCRoute, etc.
• Supported by most major vendors and the primary focus for new features.

Ingress NGINX is one implementation. The Ingress API and Gateway API are Kubernetes standards independent of this retirement.

2. What the Retirement Actually Says

From the Kubernetes SIG Network announcement:

• Ingress NGINX is being fully retired.
• Best-effort maintenance continues until March 2026. After that:
  • No new releases
  • No fixes
  • No security patches
• Existing deployments will keep running; images and charts remain available.
• Users should migrate to:
  • Gateway API, or
  • Another Ingress controller
    

Why it’s being retired

• Extremely high maintenance burden
• Too few long-term maintainers
• Security risks due to its configurability
• “InGate,” the attempted successor, is also being retired due to lack of support
  

This is not an early deprecation — it’s the end of the road.

3. What This Does Not Mean

Let’s clear up the confusion:

• Ingress itself is not being removed.
• It’s stable and supported, but not growing — future features land in Gateway API.
• Other Ingress controllers remain supported
• (AWS LBC in Ingress mode, NGINX Inc controller, Traefik, Kong, HAProxy, etc.).
• Your clusters won’t suddenly break in March 2026.
• But you will be running an unsupported, security-sensitive data plane component.
  

This retirement applies only to the kubernetes/ingress-nginx controller.

4. Real-World Example: EKS With Two Ingress NGINX Controllers

A common production pattern:

• You run EKS.
• You deploy two Ingress NGINX controllers:
  • nginx-public
  • nginx-internal
• Each listens on ports 80/443 but exposes its own AWS Load Balancer.
• Ingress resources reference whichever controller they belong to.
  

In this scenario:

• The controller pods (ingress-nginx) are the components being retired.
• All your Ingress pipelines — routing, TLS termination, config generation — flow through these controllers.
  

A migration plan is required.

5. Your Two Migration Paths

You have two viable strategies. The right answer depends on timing, scope, and appetite for change.

Option 1 — Move to Gateway API (future-proofing)

Adopt Gateway API with a supported controller — for EKS, that’s typically AWS Load Balancer Controller (LBC).

Why choose this path

Pros

• Aligns with Kubernetes’ long-term direction
• Much richer routing capabilities
• Strong multi-tenant and cross-namespace safety
• Clean separation between platform teams (Gateway) and app teams (HTTPRoute)
  

Cons

• Requires refactoring
• NGINX-specific features may not exist in ALB/Gateway
• Requires coordination with app teams

This is the “do it right” path.

Option 2 — Stay on Ingress, Switch Controllers (short-term stabilization)

Instead of refactoring everything now, keep using the Ingress API and replace Ingress NGINX with:

• AWS LBC in Ingress mode
• NGINX Inc’s commercial controller
• Traefik
• Kong
• HAProxy Ingress
  ‍

Why choose this path

Pros

• Minimal change for application teams
• Fastest route to getting off an unsupported controller
• Some controllers support both Ingress and Gateway API, easing the eventual transition
  

Cons

• Ingress API is feature-frozen — you will eventually migrate again
• Annotation differences can be significant
• Two-step journey:
  1. Ingress NGINX → another Ingress controller
  2. Ingress → Gateway API (later)

This is the “we need stability now” path.

Draftt’s Recommendation

Here’s how to evaluate your next step:

If you can take on a more significant migration now → Go straight to Gateway API.

This gives you the stable, modern foundation that Kubernetes is actively investing in.

If you need a fast, low-risk stabilization → Switch to another supported Ingress controller first.

Then migrate to Gateway API when the organization is ready.

What matters most

Ingress NGINX is retired after March 2026.

Any production cluster relying on it should have a migration plan on the roadmap.

This isn’t about panic or rushing to rebuild everything. it’s about making an informed, intentional transition, based on your specific use case.