On 29 January 2026, the Kubernetes Steering Committee (KSC) and the Security Response Committee delivered a critical update to the community: the official community-maintained Ingress NGINX controller (kubernetes/ingress-nginx) will be retired in March 2026.
While existing installations won’t “shut off” overnight, the project will be archived. This means no more security patches, no bug fixes, and no compatibility updates for future Kubernetes versions. If you are part of the 50% of the ecosystem currently using this controller, the clock is officially ticking.
What is Retiring (and What Isn’t)
It is important to distinguish between the API and the Implementation:
- The Controller is retiring: Specifically, the
kubernetes/ingress-nginximplementation. - The Ingress API is NOT retiring: The standard
Ingressresource remains part of Kubernetes. However, the community’s innovation is shifting almost entirely to the Gateway API.
The Risks of Doing Nothing
- Security Vulnerabilities: As a public-facing entry point, an unpatched controller is a prime target for exploits.
- Platform Drift: Future Kubernetes releases may change internal APIs that the retired controller relies on, leading to unexpected crashes.
- Reliability: You are essentially running “best effort” software with zero upstream support.
Analyzing Your Current Architecture
Your current setup, as shown in the diagram below, follows the classic “North-South” traffic pattern.
In this model, the Ingress-managed load balancer acts as the gateway. The Ingress Controller (the “brain”) watches for routing rules and configures the underlying NGINX proxy to send traffic to the correct Service and Pods.
While this flow is conceptually sound, the “brain” (the Ingress Controller box) needs a replacement before March.
The Way Forward: 4 Migration Options
Option 1: Move to Gateway API (Recommended)
The Gateway API is the formal successor to Ingress. It offers a more expressive, role-oriented model that separates concerns between infrastructure (GatewayClass), operations (Gateway), and application developers (HTTPRoute).
Top Implementations: Envoy Gateway, Cilium Gateway API.
| Pros | Cons |
| Future-Proof: This is the standard for the next decade of K8s networking. | Migration Effort: Requires refactoring Ingress YAML into Gateway API resources. |
| Role Separation: Better for multi-team environments. | Learning Curve: New CRDs and concepts to master. |
| Rich Routing: Native support for header manipulation, traffic splitting, and more. | Implementation Gaps: Feature parity varies between controllers. |
Choosing a successor to ingress-nginx often comes down to two heavyweights: Envoy Gateway and Cilium Gateway API. While both use Envoy under the hood for Layer 7 routing, their architectural philosophies are fundamentally different.
The following table breaks down how they compare in a production environment as of early 2026.
Envoy Gateway vs. Cilium Gateway API
| Feature | Envoy Gateway | Cilium Gateway API |
| Primary Goal | A dedicated, lightweight “front door” for K8s. | A holistic networking and security stack (CNI). |
| Data Plane | Pure Envoy Proxy. | Hybrid: eBPF (L4) + Envoy (L7). |
| L4 Performance | High (Standard Linux networking). | Unrivaled (Kernel-level eBPF acceleration). |
| L7 Capabilities | Native OIDC, Rate Limiting, & WAF. | Deep L7 visibility & Identity-based security. |
| Architecture | Standalone control plane deployment. | Embedded within the Cilium Agent/Operator. |
| Observability | Standard Envoy metrics/traces. | Deep visibility via Hubble (Flow logs, service maps). |
| Complexity | Low to Moderate (Easy to drop into any cluster). | High (Requires replacing or integrating with CNI). |
| Ideal Use Case | Organizations needing a modern, robust Ingress. | Platforms standardizing on eBPF for networking. |
Understanding the Architectural Difference
The choice between these two usually depends on whether you want a specialized tool or a unified platform.
- Envoy Gateway is the “purest” migration from NGINX. It focuses exclusively on the Gateway API spec and provides a clean, standalone control plane. It is highly portable, you can run it on top of any CNI (Flannel, Calico, etc.).
- Cilium Gateway API is essentially a “feature flag” within your networking layer. If you are already using Cilium for your CNI, enabling the Gateway API is nearly zero-overhead. However, because it is tied to the kernel via eBPF, it is more complex to debug if something goes wrong deep in the stack.
[Image comparing Envoy Gateway architecture vs Cilium eBPF-based Gateway architecture]
Strategic Recommendation
- Choose Envoy Gateway if: You have a diverse set of clusters, use different CNIs, or simply want a modular, high-performance Ingress controller that “just does routing” without touching your kernel networking.
- Choose Cilium if: You are already moving toward a Zero Trust architecture or Service Mesh. The synergy between eBPF network policies and Gateway API routing allows you to secure and route traffic in a single, unified workflow.
Option 2: Swap the Controller (The Pragmatic Path)
If you aren’t ready for the Gateway API, you can keep your existing Ingress resources but swap the underlying controller for one that is still actively maintained.
- F5 NGINX Ingress Controller: A separate, commercially-backed (with an OSS version) implementation that is not affected by the community retirement.
- Traefik / HAProxy: Mature, performance-oriented controllers with strong community backing.
- Contour (Envoy-based): A great stepping stone if you eventually want to move to Envoy Gateway.
Pros: Minimal YAML changes; keeps the familiar Ingress API.
Cons: Many ingress-nginx specific annotations (like custom snippets) will not work and require manual translation.
Option 3: Use a Maintained Fork (The “Safety” Bridge)
Some vendors are offering maintained forks of the community project to buy users more time (up to 2 years in some cases).
Pros: Zero immediate code changes; buys time for a proper migration.
Cons: Postpones the inevitable; you are still tied to a legacy API that is no longer the focus of community innovation.
Option 4: Move “Edge” Concerns to Cloud L7 LB
Offload the routing to your cloud provider’s managed Load Balancer (for example, AWS ALB, Google Cloud LB) and use a simpler in-cluster mechanism for internal routing.
Pros: Reduces cluster complexity; offloads TLS/WAF/DDoS to the provider.
Cons: Can be more expensive; increases vendor lock-in.
Decision Framework: Which path should you take?
- High Reliance on Annotations? If your YAML is full of
nginx.ingress.kubernetes.io/tags, consider Option 2 (F5 NGINX) for the smoothest transition. - Building a Multi-Tenant Platform? If you manage clusters for multiple teams, Option 1 (Gateway API) is the only choice that scales.
- Need a Fix Yesterday? Look for a Maintained Fork (Option 3) to stop the security clock while you plan a 2026 migration.
Conclusion
The retirement of Ingress NGINX marks the end of an era, but it’s also an opportunity to modernize. Continuing to run unpatched infrastructure at your cluster’s edge is a risk that most organizations cannot afford. Whether you choose the “pragmatic swap” or the “future-aligned” Gateway API, the time to start testing your migration path is now.