Dec 9, 2025
9.12.2025
9.12.2025
The Kubernetes SIG Network and the Security Response Committee have announced the end of support for Ingress NGINX. Until March 2026, one of the most widely used Kubernetes Ingress controllers will only receive best-effort support. Here is why you should take action now.
If you currently rely on Ingress NGINX as a central gateway and reverse proxy for external traffic to your applications in Kubernetes, we strongly recommend a structured migration as soon as possible to minimize security risks and downtime. In this blog post, we outline viable alternatives and walk you through predictable migration paths — including the transition to the newer Gateway API standard.
Updates for Ingress NGINX are already being released solely on a best-effort basis, which will likely be limited to security fixes. No new features will be developed, and once support officially ends in March 2026, even security updates will be discontinued. This marks the end of one of the most widely used Kubernetes Ingress controllers.
As of November 2025, roughly four months remain for organizations to migrate. It is therefore crucial to define and implement a structured migration plan as early as possible. Key considerations include evaluating suitable alternatives and deciding whether now is the right time to transition from the traditional Ingress model to the newer Gateway API standard.
The most notable difference between Gateway API and Ingress is Gateway API’s strict separation of concerns.
Another major difference: Gateway API natively supports many advanced features that previously required controller-specific annotations in Ingress resources. This significantly reduces configuration dependency on specific controllers and enables more flexible controller changes. A simple example is HTTPS redirection. In Ingress NGINX, HTTPS redirect is configured via an annotation:
...
metadata:
annotations:
nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
...
In Gateway API, the same behavior can be configured directly in an HTTPRoute resource using a RequestRedirect filter:
...
spec:
rules:
- filters:
- type: RequestRedirect
requestRedirect:
scheme: https
statusCode: 301
...
(see: https://gateway-api.sigs.k8s.io/guides/http-redirect-rewrite/#redirects)
These and other capabilities clearly favor adopting Gateway API over the traditional Ingress model. However, migration requires considerable effort, and infrastructure code complexity will increase. Since Kubernetes will continue supporting Ingress resources, switching to Gateway API is not mandatory now — but depending on your requirements and future plans, it can be a strategically valuable step.
For these reasons, we recommend choosing controllers that support both Ingress and Gateway API and provide explicit migration paths from Ingress NGINX. This enables a gradual, low-risk transition.
Several controllers are available as replacements for Ingress NGINX. The best option depends on your specific use case and should be evaluated on a case-by-case basis. Below is a concise overview of selected options.
A straightforward option is the NGINX Ingress Controller by F5. It offers many similarities to Ingress NGINX, including comparable annotations, and provides a defined migration path.
However, it does not support Gateway API resources. To use Gateway API, the F5 NGINX Gateway Fabric needs to be deployed. Both products are available as open-source software under the Apache-2.0 license and work with open-source NGINX (https://github.com/nginx/nginx, BSD-2-Clause license). Additional enterprise features are available with NGINX Plus.
Traefik aims to provide an easy drop-in replacement by leveraging its Ingress NGINX provider, which enables support for Ingress NGINX annotations in existing Ingress resources. After switching controllers, you can continue using your current Ingress definitions and migrate to Traefik-specific configurations at your own pace.
Traefik Proxy supports both Ingress and Gateway API resources. It is available as open-source software under the MIT license, with additional features such as Traefik Hub and support services available through commercial licensing.
The HAProxy Ingress Controller was developed as an alternative to Ingress NGINX and follows a similar annotation approach. However, it is not a direct drop-in replacement due to differences in certain configuration behaviors. HAProxy offers powerful load balancing and high throughput. The HAProxy Unified Gateway enables parallel use of both Ingress and Gateway API resources, though it is currently still in beta. Both components are available as open-source software under the Apache-2.0 license, with additional commercial licensing options.
Envoy Gateway is built natively for Gateway API. For migrating existing Ingress NGINX setups, the tool “ingress2gateway” automatically converts existing Ingress resources into Envoy-compatible Gateway API resources. Envoy Gateway is available as open-source software under the Apache-2.0 license.
The upcoming end of support for Ingress NGINX requires timely action: planning and gradually executing the Ingress controller migration should begin as soon as possible. While Gateway API offers advantages in governance, portability, and functionality, it also increases infrastructure complexity. Whether you adopt Gateway API now should depend on your platform and infrastructure strategy. Since Kubernetes will continue to support classic Ingress resources, focusing on replacing the NGINX Ingress Controller itself is a valid option.
In practice, the best approach in many cases is choosing a controller that supports both Ingress and Gateway API and offers smooth migration paths from Ingress NGINX. This provides flexibility and makes the currently optional introduction of Gateway API significantly easier.
Still using Ingress NGINX or have questions about your Kubernetes infrastructure? Get in touch — we’ll help you design an efficient, scalable, and future-proof setup!
Domain Lead Cloud Transformation & Data Infrastructure
Domain Lead Cloud Transformation & Data Infrastructure
b.telligent – that’s Data Analytics, AI, Customer Engagement, and Data Visualization. It’s Germany, Austria, Switzerland, and Romania. But most importantly, it’s our team: people with a true passion for data, working together to create innovative solutions that drive sustainable progress for businesses.
Private networking in Azure increases security, but it also comes with higher costs and greater architectural effort. We explain which risks are often overlooked and when private endpoints actually make sense.
You want to manage your infrastructure with Terraform, but then it happens – manual changes are made, and you need to find a solution. How to handle this depends on the specific case.
One of Terraform’s greatest strengths is its ability to handle changes made outside its managed resources. The keywords are: data, import, removed, ignore_changes, lock, variables.
No previous post
No next post
