> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # The NGINX Ingress Deprecation Crisis > Describes NGINX Ingress end of life, security vulnerabilities, and steps to migrate clusters to Gateway API with auditing, prototyping, and vendor evaluation. 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](https://kubernetes.github.io/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](https://kubernetes.github.io/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](https://gateway-api.sigs.k8s.io/) (released October 31, 2023) is a modern, extensible standard developed by the [Kubernetes SIG-Network](https://github.com/kubernetes/community/tree/master/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 | Aspect | Ingress (legacy) | Gateway API | | - | - | - | | Model | Single resource type with extensions | Composable primitives (`Gateway`, `HTTPRoute`, `TCPRoute`) | | Expressiveness | Limited for complex routing | Richer routing, filters, and matching rules | | Separation of concerns | Less clear | Clear data plane/control plane separation | | Validation & security | Fewer built-in validation patterns | Stronger validation surface and isolation options | | Vendor interoperability | Varies by implementation | Standardized across controllers and vendors | Migration considerations You can migrate from [Ingress-NGINX](https://kubernetes.github.io/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 * Gateway API: [https://gateway-api.sigs.k8s.io/](https://gateway-api.sigs.k8s.io/) * Ingress-NGINX: [https://kubernetes.github.io/ingress-nginx/](https://kubernetes.github.io/ingress-nginx/) * Kubernetes Ingress documentation: [https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/) * Kubernetes SIG-Network: [https://github.com/kubernetes/community/tree/master/sig-network](https://github.com/kubernetes/community/tree/master/sig-network) 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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.