Confused by the Ingress-NGINX deprecation? You’re probably fine. This guide clarifies which controller is affected and outlines your real options before you panic-migrate to the Gateway API.

Wait, Which Ingress-NGINX is Deprecated? A Guide for the Trenches

I got a PagerDuty alert at 2 AM. The message was from a junior engineer, frantic: “URGENT: Core ingress controller is deprecated, need to migrate prod ASAP!” I stumbled to my laptop, my heart pounding, picturing our entire production environment about to go dark. After a quick check, I saw the truth: he’d read the Kubernetes announcement, panicked, and was about to rip out a perfectly stable, non-deprecated Ingress controller. We’ve all been there. A scary-looking announcement drops, and the impulse is to act immediately. But in this case, the real problem isn’t the code—it’s the name.

The Root of the Panic: Two Ingresses, One Name

This whole mess comes down to a simple, frustrating fact: there are two major projects called “Ingress-NGINX,” and they are not the same. One is a community project maintained by Kubernetes contributors, and that’s the one being deprecated. The other is maintained by F5/NGINX, and it’s alive and well. Most production setups I’ve seen are using the F5/NGINX version.

Here’s the breakdown so you can tell them apart:

The Kubernetes project is shifting its focus to the new, more powerful Gateway API, which is the right move for the ecosystem. But the poor naming choice has caused a lot of unnecessary fire drills.

Solution 1: The “Are You Sure?” Sanity Check

Before you do anything else, you need to verify which controller is actually running in your cluster. Don’t trust the Helm chart name or old documentation. Check the running pod directly. This is your five-minute fix to prevent a five-hour outage.

Run this command, replacing ingress-nginx with the namespace your controller is running in:

kubectl get pods -n ingress-nginx -o jsonpath='{.items[0].spec.containers[0].image}'

Now, look at the output:

• If you see something like registry.k8s.io/ingress-nginx/controller:..., then yes, you are running the deprecated community version. Don’t panic, but proceed to the next solutions.
• If you see nginx/nginx-ingress:... or something from your company’s private registry, you are likely using the F5/NGINX version. You can breathe a sigh of relief. The deprecation notice does not apply to you.

Pro Tip: I’ve seen teams get tripped up by this. The pod might be named `ingress-nginx-controller-xyz`, but the image source is the only ground truth. Always check the image tag!

Solution 2: The Proactive Path – Start Learning the Gateway API

Okay, so let’s say you’re safe for now—you’re running the F5/NGINX version. My advice? Don’t just close the ticket. The Gateway API is the future of ingress in Kubernetes, and it’s worth getting familiar with now.

Unlike the old Ingress object, which crammed everything into one resource, the Gateway API splits responsibilities in a way that actually makes sense for teams:

• GatewayClass: Defined by the cluster admin (that’s us!). It says, “We have an NGINX-based gateway available for use.”
• Gateway: Also managed by us. It requests a load balancer from the cloud provider and opens ports (e.g., “Open port 443 for the `prod-web-gateway`”).
• HTTPRoute: Managed by developers. They can attach their services to a Gateway without needing cluster-level permissions (e.g., “Route traffic for `api.myapp.com/v1` to the `api-v1-service`”).

This role-based approach is a massive improvement. It means developers can manage their own routing without us having to review every single path change. Start reading the docs, maybe even spin up a test implementation in a dev cluster. This is the way forward.

Solution 3: The “Okay, I’m Actually Affected” Migration Plan

If your sanity check revealed you *are* running the deprecated `k8s.io/ingress-nginx`, it’s time to plan a migration. This is not a “rip and replace” job for a Tuesday morning; it’s a project. You’re moving from a simple Ingress object to a Gateway API implementation.

Here’s the high-level battle plan:

1. Install a Gateway API Provider: The Gateway API is just a set of standards. You need a controller that implements them. Options include NGINX Gateway Fabric, Istio, Cilium, Traefik, etc.
2. Deploy a Gateway Resource: The infrastructure team creates a `Gateway` resource that defines the entry point, like your old controller service.
3. Translate Ingress to HTTPRoute: This is the bulk of the work. You need to convert your existing `Ingress` rules into `HTTPRoute` rules.

For example, this old Ingress rule:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
spec:
  rules:
  - host: "example.com"
    http:
      paths:
      - path: /foo
        pathType: Prefix
        backend:
          service:
            name: my-foo-service
            port:
              number: 8080

Becomes something like this new `HTTPRoute`:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: my-app-httproute
spec:
  parentRefs:
  - name: prod-web-gateway # This attaches to the Gateway we made
    namespace: networking
  hostnames: ["example.com"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /foo
    backendRefs:
    - name: my-foo-service
      port: 8080

Once you’ve translated your rules, you test them using a temporary hostname or by editing your local hosts file. When you’re confident everything works, you make the final DNS switch to point to the new Gateway’s load balancer IP. Done.

Warning: Treat this like any other infrastructure migration. Do it in a staging environment first. Test everything: TLS, redirects, headers, and path routing. Have a rollback plan that involves simply pointing the DNS back to the old Ingress controller’s IP.

Conclusion

So, before you wake up your lead engineer in a panic, take a deep breath. Check your image tags. Most of you reading this will discover you’re fine and can go back to your regularly scheduled work. For those who are affected, don’t see it as a crisis. See it as a planned opportunity to adopt a more robust, scalable, and secure API for managing traffic into your cluster. The future is here, it just requires a map and a bit of planning.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions