Notifications
Clear all
Topic starter
24/06/2026 8:45 pm
TL;DR: Kubernetes SIG Network has announced the retirement of Ingress NGINX, with best-effort maintenance ending in March 2026 and no future fixes after that, according to Kong. The practical issue is not just migration timing but the security and governance debt created by keeping critical ingress paths on a component with no ongoing vulnerability response.
NHIMG editorial — based on content published by Kong: Farewell Ingress NGINX: Explore a Better Path Forward with Kong
Questions worth separating out
Q: How should teams migrate from Ingress NGINX to Gateway API without breaking existing traffic?
A: Treat the move as a phased control-plane migration, not a simple YAML translation.
Q: What happens when a Kubernetes ingress component reaches end of maintenance?
A: The main risk is lifecycle exposure.
Q: What do platform teams get wrong about ingress migration?
A: They often treat it as a technical rewrite instead of an operational ownership problem.
Practitioner guidance
- Inventory every Ingress NGINX dependency Identify clusters, namespaces, routes, and application owners that still rely on Ingress NGINX, then classify each dependency by business criticality and replacement complexity.
- Assign retirement ownership for ingress components Create a named owner for ingress lifecycle decisions, including support status, migration sequencing, exception handling, and decommission sign-off.
- Pilot Gateway API on low-risk services first Use a limited workload set to validate routing parity, policy behaviour, and observability before moving high-traffic or regulated services.
What's in the full article
Kong's full blog covers the operational detail this post intentionally leaves for the source:
- How Kong's ingress2gateway translation tool maps existing Ingress NGINX resources into Gateway API objects.
- What Kong Operator's dual-API support means for teams that need to run old and new routing models together.
- Which operational features Kong highlights for zero-downtime upgrades, scaling, and plugin-based traffic control.
- How Kong Konnect is positioned for API lifecycle management during and after migration.
👉 Read Kong's analysis of Ingress NGINX retirement and Gateway API migration →
Ingress NGINX retirement: what it means for Kubernetes teams?
Explore further
25/06/2026 5:31 am
Ingress retirement is a lifecycle governance event, not an infrastructure footnote. Once an ingress component loses upstream security maintenance, the organisation inherits support risk as well as migration risk. That changes the governance question from "what features do we need" to "which access path is now operating outside an active security lifecycle". Practitioners should treat unsupported ingress as an exposure class in its own right.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who should be accountable for retiring legacy ingress in Kubernetes?
A: Accountability should sit with the team that owns platform networking governance, with security, SRE, and application owners sharing review responsibilities. The critical point is that retirement is a managed lifecycle event, so it needs an explicit owner, a migration plan, and a decommission date.
👉 Read our full editorial: Ingress NGINX retirement accelerates Gateway API migration pressure
