Skip to main content
Welcome to this lesson on the NGINX Ingress deprecation. This page explains what’s changing, why it matters, and practical next steps to prepare your clusters. Although the Ingress API remains part of Kubernetes and community maintenance continues, the most widely used controller—Ingress-NGINX—is scheduled to reach end-of-life in March 2026. After that date the project maintainers (the community and F5) will stop providing support, security fixes, and feature updates.
End of life means the project will receive no security patches, bug fixes, or new features. Plan migrations or alternatives well before March 2026.
Immediate recommendations:
  • Audit clusters for Ingress-NGINX usage and prioritize high-exposure environments.
  • Identify Ingress resources and map them to equivalent Gateway API resources (Gateways, HTTPRoutes, TCPRoutes).
  • Evaluate Gateway API–capable controllers from your preferred vendors to minimize disruption.
Why this deprecation matters
  • Ingress-NGINX historically served a large portion of the Kubernetes ecosystem. According to public guidance, an estimated 40% of clusters used it, increasing the potential blast radius for vulnerabilities.
  • On March 24, 2025, the community disclosed several critical vulnerabilities in Ingress-NGINX that could expose Kubernetes secrets and allow attackers to access cluster resources. The community implemented rapid mitigations, but the incident accelerated the move away from legacy Ingress implementations.
An infographic titled "IngressNightmare CVE" showing an attacker exploiting a misconfigured NGINX Ingress to gain access to Kubernetes cluster secrets. It also lists related CVEs, the discovery date (March 24, 2025), and a statistic claiming 40% of Kubernetes clusters use NGINX Ingress.
What is the Gateway API and why adopt it? The Gateway API (released October 31, 2023) is a modern, extensible standard developed by the Kubernetes SIG-Network. It was designed to address limitations of the legacy Ingress API by improving expressiveness, validation, and separation of concerns between control plane and data plane. Key benefits:
  • Composable routing primitives (Gateways, HTTPRoutes, TCPRoutes, UDPRoute, etc.) that model complex topologies.
  • Better separation of responsibilities: clear roles for infrastructure operators and application owners.
  • Improved validation and isolation to reduce configuration-related security risks.
  • Vendor neutrality: multiple controllers and vendors support the same Gateway API resources.
Comparison: Ingress vs Gateway API Migration considerations You can migrate from Ingress-NGINX to a Gateway API–capable controller without abandoning your preferred vendor. Popular alternatives and Gateway-capable implementations include HAProxy-based controllers and service meshes like Istio — but moving to another Ingress-only solution won’t provide Gateway API benefits. Practical next steps
  • Inventory: List clusters running Ingress-NGINX and count Ingress resources.
  • Prioritize: Rank workloads by exposure and sensitivity (public endpoints, secrets).
  • Prototype: Deploy a Gateway API controller in a non-production cluster and translate a sample Ingress to Gateway + HTTPRoute.
  • Migrate: Convert Ingress objects incrementally, validate behavior, and roll out progressively.
  • Monitor & audit: Ensure observability, RBAC, and policy checks remain functional after migration.
A slide titled "Migrating to Gateway API" that compares the current state (Ingress) and future state (Gateway API) side-by-side, showing NGINX, HAProxy, and Istio with their logos and short descriptions. It illustrates moving from legacy ingress solutions to modern Gateway API implementations.
Resources and references That’s it for this lesson. Use the checklist above to plan mitigation or migration and start early — the earlier you evaluate options and prototype, the smoother your transition will be.

Watch Video