On November 11 2025, the Kubernetes SIG Network and the Kubernetes Security Response Committee announced that the Ingress-NGINX project will be retired as of March 2026, after that point, no bug fixes or security patches will be issued.
Official announcement on kubernetes.io
If you’re still running Ingress-NGINX in production, you have a ticking clock. That makes migrating to a supported alternative, notably the Gateway API, not just a “nice to do”, but a must.
While Ingress (and by extension many Ingress controllers) has served well, it’s showing its limits in modern use cases like multi-tenant clusters, advanced routing, TLS offload, service-mesh integration, and multi-protocol support.
The Gateway API addresses these directly, with three core benefits:
| Legacy | Gateway API |
|---|---|
Ingress | HTTPRoute / TCPRoute / UDPRoute |
IngressClass | GatewayClass |
| — | Gateway (defines the actual listener/entry point) |
Gateway API hierarchy:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-app
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
ingressClassName: nginx
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: my-service
port:
number: 80
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
name: nginx
spec:
controllerName: k8s.io/nginx
Many controllers come with this pre-installed.
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: my-gateway
namespace: default
spec:
gatewayClassName: nginx
listeners:
- name: http
protocol: HTTP
port: 80
hostname: "example.com"
allowedRoutes:
namespaces:
from: Same
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: my-route
namespace: default
spec:
parentRefs:
- name: my-gateway
namespace: default
hostnames:
- "example.com"
rules:
- matches:
- path:
type: PathPrefix
value: /
backendRefs:
- name: my-service
port: 80
That covers the same host, path, backend scenario — but now using Gateway API.
Inventory your existing Ingress resources
Identify which controllers you’re using (especially Ingress-NGINX).
Check controller support
Run kubectl get gatewayclass most modern controllers support Gateway API.
Deploy GatewayClass/Gateway
Install the Gateway API CRDs if not already present, and create a shared Gateway.
Convert one Ingress
Pick a simple Ingress, convert it to an HTTPRoute, and attach it to the Gateway.
Keep the Ingress temporarily to test routing side by side.
Test and validate
Verify with:
kubectl describe gateway my-gateway kubectl get httproute kubectl get svc
Migrate gradually
Move additional Ingress resources one by one.
Decommission Ingress-NGINX
Plan to retire it before March 2026 to stay secure.
Update documentation/runbooks
Ensure teams know routing now goes through the Gateway API.
| Ingress field | Gateway API equivalent |
|---|---|
ingressClassName | gatewayClassName (in Gateway) |
spec.rules[].host | hostnames (in HTTPRoute) |
spec.rules[].http.paths[].path | rules.matches.path.value (in HTTPRoute) |
backend.service.name | backendRefs.name |
backend.service.port.number | backendRefs.port |
| Controller-specific annotations | Use filters or extensions in Gateway API |
Shared Gateway, multiple routes
Use one Gateway for many routes, isolating apps via namespaces.
Role separation
Infra owns Gateways; app teams own HTTPRoutes.
GitOps-friendly setup
Version-control Gateways, Routes, and Services together.
Avoid controller annotations
Replace nginx.ingress.kubernetes.io/* annotations with first-class Gateway filters.
Monitor routing status
Use:
kubectl describe httproute <name>
Look for Accepted or NotAccepted conditions.
Keep a fallback
During migration, keep the old Ingress until you fully validate Gateway routes.
Migrating from Ingress (especially Ingress-NGINX) to the Gateway API is more than rewriting YAML — it’s about upgrading how we manage network traffic in Kubernetes.
Given the Ingress-NGINX retirement timeline, migration should be part of your 2025–2026 cluster roadmap.
Do it once, do it cleanly — and you’ll gain a more scalable, future-proof networking layer.