Nginx Ingress vs Traefik vs Gateway API in 2026

Ingress-NGINX is retired. Compare Traefik and Gateway API controllers as replacements, plus a safe migration plan that avoids outages.

A platform team audits its dependencies and finds that the component routing every external request into every cluster is no longer maintained. No new releases, no security fixes, no one to report a CVE to. That is the situation for any team still running the community ingress-nginx controller after its retirement in March 2026.

This is really two decisions bundled into one deadline: which controller do you move to, and do you move to a new API model (Gateway API) at the same time? This post helps you answer both, then gives you a migration plan that avoids an outage.

Which NGINX ingress are you actually running?

Three similarly named things exist, and only one of them was retired. The retired one is the community project kubernetes/ingress-nginx. F5's NGINX Ingress Controller is a different, maintained project, and the Ingress API itself is still supported.

Name	Maintainer	Status
kubernetes/ingress-nginx	Kubernetes community	Retired
nginxinc/kubernetes-ingress	F5 NGINX	Maintained
Ingress API	Kubernetes	Frozen, not removed

Confirm what you run before you plan anything:

Bash

kubectl get pods -A \
  -l app.kubernetes.io/name=ingress-nginx
kubectl get ingressclass

If the first command returns pods, you are on the retired community controller. A chart or image named ingress-nginx almost always means the same.

Why was ingress-nginx retired?

It was retired because maintaining it safely was no longer sustainable. The Kubernetes Steering and Security Response Committees cited a shortage of maintainers and architectural limits as the reasons, and they warned that running it after end of life leaves you exposed to attack.

Its flexibility was also its weakness. The annotation model allowed raw NGINX configuration to be injected through Kubernetes objects, and that produced a long list of injection-style vulnerabilities. In March 2025, the IngressNightmare set of issues (including CVE-2025-1974) showed how serious that attack surface could be.

Any controller that is no longer patched becomes a permanent risk at the edge of your network, which is why this is a security migration first and a feature migration second. Check the official announcement for the current status and timeline.

What are your options as a replacement?

You have four realistic paths: another Ingress controller, a Gateway API controller, a cloud provider's managed option, or a vendor-supported bridge. The right one depends on your deadline and your appetite for change.

flowchart TD S([Retired
ingress-nginx]) --> Q{Ready for
Gateway API?} Q -->|Not yet| T[Traefik or F5 NGINX
Ingress-compatible] Q -->|Yes| G[Gateway API controller
Envoy Gateway, Istio,
Cilium, Kong] Q -->|Cloud native| C[Managed option
ALB, GKE, Azure] T --> M([Plan Gateway API
later]) G --> D([Done in one move]) classDef start fill:#EF4444,color:#FFFFFF classDef gate fill:#F59E0B,color:#111827 classDef ingress fill:#326CE5,color:#FFFFFF classDef gw fill:#10B981,color:#FFFFFF classDef cloud fill:#8B5CF6,color:#FFFFFF classDef end1 fill:#D1FAE5,color:#1E293B class S start class Q gate class T ingress class G gw class C cloud class M,D end1

Traefik (Ingress-compatible). Traefik reads your existing Ingress resources, updates routes dynamically instead of reloading a config file, and also supports Gateway API. Recent Traefik releases include compatibility for common ingress-nginx annotations, so check which ones are supported before you rely on it.
Gateway API controller. Envoy Gateway, Istio, Cilium, Kong, NGINX Gateway Fabric and Traefik itself all implement Gateway API, with Gateway and HTTPRoute resources from day one. It is a bigger change, but you only migrate once.
Managed cloud option. The AWS Load Balancer Controller, GKE's gateway and Azure's application gateway products remove the in-cluster proxy but tie you to one cloud.
Vendor-supported bridge. Some vendors offer extended support for NGINX-based ingress. This buys planning time, but it is a bridge, not a destination, so read the terms carefully.

How do you find out what you depend on?

Inventory your annotations first, because they are where migrations break. Every nginx.ingress.kubernetes.io/ annotation is behavior you must reproduce in the new controller.

Bash

kubectl get ingress -A -o json \
  | jq -r '.items[].metadata.annotations // {} | keys[]' \
  | grep nginx.ingress | sort | uniq -c | sort -rn

The most-used annotations are usually rewrites, redirects, body size limits, timeouts and IP allow lists. Any configuration-snippet or server-snippet is a red flag, since raw NGINX config has no portable equivalent.

How does Ingress translate to Gateway API?

Gateway API splits what Ingress mixed together. A platform team owns the Gateway (listeners, TLS, addresses), and application teams own HTTPRoute resources that attach to it. Here is a minimal pair:

YAML

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: public
  namespace: gateway-system
spec:
  gatewayClassName: example-class
  listeners:
    - name: https
      port: 443
      protocol: HTTPS
      tls:
        mode: Terminate
        certificateRefs:
          - name: wildcard-example-net
      allowedRoutes:
        namespaces:
          from: All
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: payment
  namespace: payments
spec:
  parentRefs:
    - name: public
      namespace: gateway-system
  hostnames: ["pay.example.net"]
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: payment-api
          port: 8080

The gatewayClassName depends on your implementation. In production, restrict allowedRoutes to labeled namespaces instead of All.

Common annotations map to standard route features, but some need implementation-specific policy:

ingress-nginx annotation	Gateway API equivalent
`ssl-redirect`	RequestRedirect filter
`rewrite-target`	URLRewrite filter
`proxy-body-size`, timeouts	Implementation policy
`configuration-snippet`	No equivalent

The ingress2gateway tool from Kubernetes SIGs can convert many Ingress resources automatically. Treat its output as a first draft and review it by hand.

How do you migrate without an outage?

Run the new controller beside the old one, test with real traffic, then shift traffic gradually. Never replace the controller in place.

flowchart TD A[1. Inventory
annotations] --> B[2. Install new
controller, new LB] B --> C[3. Convert and
test routes] C --> D[4. Weighted DNS
shift traffic] D --> E{Errors or
latency up?} E -->|Yes| F([Roll back DNS]) E -->|No| G([Retire old
controller]) classDef step fill:#DBEAFE,color:#1E293B classDef action fill:#326CE5,color:#FFFFFF classDef gate fill:#F59E0B,color:#111827 classDef bad fill:#EF4444,color:#FFFFFF classDef good fill:#10B981,color:#FFFFFF class A,C step class B,D action class E gate class F bad class G good

Follow these steps:

Install the new controller with its own IngressClass or GatewayClass and its own load balancer, so both stacks serve traffic in parallel.
Convert routes and test each hostname by sending requests directly to the new load balancer with a Host header.
Check the details that break: TLS versions and ciphers, redirects, rewrites, timeouts, large uploads, WebSockets, gRPC and client IP preservation.
Shift traffic gradually with weighted DNS (for example 5, 25, 50, 100 percent), watching error rate and p99 latency.
Keep the old controller idle for a few days as a rollback path, then remove it.

Trade-offs and Alternatives

Choosing a controller type:

Factor	Traefik (Ingress mode)	Gateway API native
Migration effort	Lower	Higher
Resource model	Existing Ingress	Gateway and HTTPRoute
Best fit	Tight deadline	Planned standardization

Operational shape:

Factor	Traefik	Istio or Cilium
Scope	Edge proxy	Edge plus mesh
Added complexity	Low	Higher
Future path	Gateway API supported	Gateway API first

Route propagation speed differs across implementations, but published numbers depend heavily on test setup. Benchmark with your own route counts and deploy frequency if this matters to you.

Production Implementation Guidelines

If you are still on the retired controller, treat it as a security task with a clock on it. The unpatched software is already live at your edge.

Choose by capacity. With limited time, move to an Ingress-compatible controller first, which removes the unpatched risk quickly. With capacity and a mesh or Gateway API plan, go straight to Gateway API once.
Budget real engineering time. No alternative is a drop-in replacement, so test annotations, TLS and rate limits explicitly.
Migrate in parallel, with weighted DNS and an instant rollback path.
Tighten the new setup: restrict which namespaces can attach routes, avoid raw config snippets, and enable access logs and metrics before cutover.
Remove the old controller and its admission webhook and RBAC once traffic is fully moved.

References and Further Reading

Ingress NGINX Statement from Kubernetes Committees - Official retirement announcement

Gateway API Documentation - Resources, implementations and guides

ingress2gateway - Conversion tool for Ingress resources

Traefik Documentation - Ingress and Gateway API providers

Frequently Asked Questions

Does the ingress-nginx retirement affect the NGINX Ingress Controller from F5?

No. The retired project is the community kubernetes/ingress-nginx, governed by Kubernetes SIG Network. F5's nginxinc/kubernetes-ingress is a separate codebase with a similar name. Check your Helm chart and image names, because the naming overlap causes frequent mix-ups.

Is the Kubernetes Ingress API being removed?

No. The Ingress resource is not being removed, but it is feature-frozen and gets no new capabilities. Active development has moved to Gateway API, which is why newer controllers invest there.

Is there a drop-in replacement for ingress-nginx?

No. Annotation behavior, TLS defaults, rewrite rules and rate limiting differ between controllers, and configuration-snippet style annotations have no direct equivalent. Treat the move as a migration with testing, not a Helm chart swap.

Why was ingress-nginx hard to secure?

Its annotation model let users inject raw NGINX configuration, which led to a long history of injection-style vulnerabilities, including the critical IngressNightmare issues disclosed in March 2025. The project also lacked enough maintainers to keep up with that attack surface.

Should you move straight to Gateway API or to another Ingress controller first?

Move straight to Gateway API if you already planned to standardize on it or adopt a mesh, because it avoids a second migration. If you have limited time, a controller that supports your existing Ingress resources, such as Traefik, is the lower-risk first step.

Discussion0

Found a mistake, an outdated step or a broken link?

Nginx Ingress vs Traefik vs Gateway API in 2026

Ingress-NGINX is retired. Compare Traefik and Gateway API controllers as replacements, plus a safe migration plan that avoids outages.

Which NGINX ingress are you actually running?

Name	Maintainer	Status
kubernetes/ingress-nginx	Kubernetes community	Retired
nginxinc/kubernetes-ingress	F5 NGINX	Maintained
Ingress API	Kubernetes	Frozen, not removed

Confirm what you run before you plan anything:

Bash

kubectl get pods -A \
  -l app.kubernetes.io/name=ingress-nginx
kubectl get ingressclass

If the first command returns pods, you are on the retired community controller. A chart or image named ingress-nginx almost always means the same.

Why was ingress-nginx retired?

What are your options as a replacement?

Traefik (Ingress-compatible). Traefik reads your existing Ingress resources, updates routes dynamically instead of reloading a config file, and also supports Gateway API. Recent Traefik releases include compatibility for common ingress-nginx annotations, so check which ones are supported before you rely on it.
Gateway API controller. Envoy Gateway, Istio, Cilium, Kong, NGINX Gateway Fabric and Traefik itself all implement Gateway API, with Gateway and HTTPRoute resources from day one. It is a bigger change, but you only migrate once.
Managed cloud option. The AWS Load Balancer Controller, GKE's gateway and Azure's application gateway products remove the in-cluster proxy but tie you to one cloud.
Vendor-supported bridge. Some vendors offer extended support for NGINX-based ingress. This buys planning time, but it is a bridge, not a destination, so read the terms carefully.

How do you find out what you depend on?

Inventory your annotations first, because they are where migrations break. Every nginx.ingress.kubernetes.io/ annotation is behavior you must reproduce in the new controller.

Bash

kubectl get ingress -A -o json \
  | jq -r '.items[].metadata.annotations // {} | keys[]' \
  | grep nginx.ingress | sort | uniq -c | sort -rn

How does Ingress translate to Gateway API?

YAML

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: public
  namespace: gateway-system
spec:
  gatewayClassName: example-class
  listeners:
    - name: https
      port: 443
      protocol: HTTPS
      tls:
        mode: Terminate
        certificateRefs:
          - name: wildcard-example-net
      allowedRoutes:
        namespaces:
          from: All
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: payment
  namespace: payments
spec:
  parentRefs:
    - name: public
      namespace: gateway-system
  hostnames: ["pay.example.net"]
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: payment-api
          port: 8080

The gatewayClassName depends on your implementation. In production, restrict allowedRoutes to labeled namespaces instead of All.

Common annotations map to standard route features, but some need implementation-specific policy:

ingress-nginx annotation	Gateway API equivalent
`ssl-redirect`	RequestRedirect filter
`rewrite-target`	URLRewrite filter
`proxy-body-size`, timeouts	Implementation policy
`configuration-snippet`	No equivalent

The ingress2gateway tool from Kubernetes SIGs can convert many Ingress resources automatically. Treat its output as a first draft and review it by hand.

How do you migrate without an outage?

Run the new controller beside the old one, test with real traffic, then shift traffic gradually. Never replace the controller in place.

Follow these steps:

Install the new controller with its own IngressClass or GatewayClass and its own load balancer, so both stacks serve traffic in parallel.
Convert routes and test each hostname by sending requests directly to the new load balancer with a Host header.
Check the details that break: TLS versions and ciphers, redirects, rewrites, timeouts, large uploads, WebSockets, gRPC and client IP preservation.
Shift traffic gradually with weighted DNS (for example 5, 25, 50, 100 percent), watching error rate and p99 latency.
Keep the old controller idle for a few days as a rollback path, then remove it.

Trade-offs and Alternatives

Choosing a controller type:

Factor	Traefik (Ingress mode)	Gateway API native
Migration effort	Lower	Higher
Resource model	Existing Ingress	Gateway and HTTPRoute
Best fit	Tight deadline	Planned standardization

Operational shape:

Factor	Traefik	Istio or Cilium
Scope	Edge proxy	Edge plus mesh
Added complexity	Low	Higher
Future path	Gateway API supported	Gateway API first

Route propagation speed differs across implementations, but published numbers depend heavily on test setup. Benchmark with your own route counts and deploy frequency if this matters to you.

Production Implementation Guidelines

If you are still on the retired controller, treat it as a security task with a clock on it. The unpatched software is already live at your edge.

Choose by capacity. With limited time, move to an Ingress-compatible controller first, which removes the unpatched risk quickly. With capacity and a mesh or Gateway API plan, go straight to Gateway API once.
Budget real engineering time. No alternative is a drop-in replacement, so test annotations, TLS and rate limits explicitly.
Migrate in parallel, with weighted DNS and an instant rollback path.
Tighten the new setup: restrict which namespaces can attach routes, avoid raw config snippets, and enable access logs and metrics before cutover.
Remove the old controller and its admission webhook and RBAC once traffic is fully moved.

References and Further Reading

Ingress NGINX Statement from Kubernetes Committees - Official retirement announcement

Gateway API Documentation - Resources, implementations and guides

ingress2gateway - Conversion tool for Ingress resources

Traefik Documentation - Ingress and Gateway API providers

Frequently Asked Questions

Does the ingress-nginx retirement affect the NGINX Ingress Controller from F5?

Is the Kubernetes Ingress API being removed?

No. The Ingress resource is not being removed, but it is feature-frozen and gets no new capabilities. Active development has moved to Gateway API, which is why newer controllers invest there.