Kubernetes Ingress-NGINX retirement

If you’re running Kubernetes workloads in production, there’s a good chance you’re using ingress-nginx, the community-maintained NGINX Ingress Controller that has served as the de facto standard for routing external traffic into clusters for years. In November 2025, the Kubernetes community announced its retirement, sending ripples through the ecosystem and prompting questions about migration strategies, timelines, and alternatives.

This article provides a clear-eyed assessment of the situation: what’s happening, what it means for your infrastructure, and how to plan your path forward without unnecessary panic.

 

Understanding What’s Being Retired

First, let’s clear up a common source of confusion. There are two different NGINX-based ingress controllers:

Project	Maintainer	Status
kubernetes/ingress-nginx	Kubernetes SIG-Network (community volunteers)	Retiring March 2026
nginxinc/kubernetes-ingress	F5/NGINX Inc. (commercial entity)	Actively maintained

The retirement announcement affects only the community project (kubernetes/ingress-nginx), the one installed via the ingress-nginx Helm chart. The F5-maintained nginx-ingress controller remains fully supported and is actively adding Gateway API features.

This distinction matters. If you’re already using the F5/NGINX controller, the retirement doesn’t directly affect you. If you’re unsure which one you have, check your Helm release name or the container image (the community version uses registry.k8s.io/ingress-nginx/controller, while the F5 version uses nginx/nginx-ingress).

 

The Retirement Timeline

The official timeline from the Kubernetes community:

Date	Milestone
January 2025	End-of-support phase announced
November 2025	Formal retirement blog post published
March 2026	End of best-effort maintenance
Post-March 2026	No further releases, bugfixes, or security updates

What this means practically:

• Existing deployments will continue to work – nothing breaks automatically
• Helm charts and container images will remain available in registries
• No security patches for newly discovered vulnerabilities
• New Kubernetes versions may introduce incompatibilities that won’t be addressed

For security-conscious organizations, the real deadline is March 2026 – after that, you’re running unsupported software exposed to the internet.

Why Is This Happening?

The retirement reflects two converging factors:

1. The Rise of Gateway API

The Kubernetes Gateway API reached General Availability (v1.0) in October 2023 and has matured rapidly. It offers significant advantages over the original Ingress API:

Capability	Ingress API	Gateway API
Role-based resource separation	❌ Single resource	✅ GatewayClass → Gateway → Routes
Protocol support	HTTP/HTTPS only	HTTP, HTTPS, gRPC, TCP, UDP
Header-based routing	Via annotations (non-portable)	Native, standardized
Traffic splitting/canary	Not standard	Built-in weighted backends
Cross-namespace routing	Limited	Native with ReferenceGrant
Extensibility	Vendor annotations	Policy resources (portable)

Gateway API represents the future direction of Kubernetes networking, and the community is focusing efforts there rather than maintaining the legacy Ingress implementation.

2. Volunteer Sustainability

The ingress-nginx project was maintained primarily by community volunteers. As the complexity of maintaining security patches, keeping up with NGINX updates, and supporting multiple Kubernetes versions grew, the maintainer pool couldn’t keep pace. Rather than let the project slowly decay, the community chose a clean sunset.

 

Is Gateway API Ready for Production?

Yes, but with caveats.

The core resources – GatewayClass, Gateway, and HTTPRoute – are GA and stable. For standard HTTP/HTTPS routing, Gateway API is production-ready with multiple conformant implementations.

However, you should evaluate your specific needs:

Ready for production:

• HTTP/HTTPS routing with host and path matching
• TLS termination
• Header-based routing and manipulation
• Traffic splitting for canary deployments
• gRPC routing (via GRPCRoute, now GA)

Still maturing:

• TCP/UDP routing (implementation-dependent)
• Advanced rate limiting and circuit breaking
• Some Policy resources (check your controller’s conformance)

If you’re using complex ingress-nginx annotations—custom Lua snippets, ModSecurity WAF rules, or exotic configurations – verify that your target Gateway API implementation supports equivalent functionality.

 

Migration Options

You have several paths forward, each with different tradeoffs:

Option 1: Migrate to Gateway API

Best for: Organizations wanting to future-proof their infrastructure and adopt Kubernetes standards.

Gateway API is the strategic direction. The migration involves:

1. Install Gateway API CRDs in your cluster
2. Deploy a Gateway API controller (Envoy Gateway, Traefik, NGINX Gateway Fabric, etc.)
3. Create Gateway resources to replace your Ingress configuration
4. Convert Ingress rules to HTTPRoute resources
5. Migrate annotations to Policy resources or controller-specific configurations

Challenge: annotations don’t have a 1:1 equivalent. You’ll need to rethink custom configurations using the new resource model.

Option 2: Switch to F5/NGINX Ingress Controller

Best for: Organizations heavily invested in NGINX configurations that want minimal disruption.

The F5-maintained nginxinc/kubernetes-ingress controller provides a migration path that preserves most NGINX-specific configurations while adding support for the Gateway API.

Advantages:

• Similar configuration model to ingress-nginx
• Commercial support available (with NGINX Plus)
• Actively maintained with Gateway API support
• Gradual migration path—can run both Ingress and Gateway API simultaneously

Considerations:

• Some annotations differ between the projects—audit your configurations
• NGINX Plus features require a commercial license

Option 3: Adopt Another Ingress/Gateway Controller

The ecosystem offers several mature alternatives:

Controller	Backed By	Gateway API	Highlights
Traefik	Traefik Labs	✅ Full	Automatic service discovery, Let’s Encrypt integration
Envoy Gateway	CNCF	✅ Purpose-built	Reference implementation, Envoy under the hood
Istio Gateway	Google/IBM	✅ Full	Native, if you’re already using Istio service mesh
Contour	VMware	✅ Full	Envoy-based, battle-tested
Kong	Kong Inc.	✅ Full	API gateway features, plugin ecosystem
Cilium	Isovalent	✅ Full	eBPF-based, excellent performance

Option 4: Use Managed Cloud Solutions

Cloud providers offer managed Gateway implementations:

• AWS: Gateway API via AWS Gateway API Controller (or Application Load Balancer)
• GCP: GKE Gateway Controller (native integration)
• Azure: Application Gateway for Containers

These reduce operational burden but increase vendor lock-in.

 

Practical Migration Recommendations

Near-Term (Q1 2026)

1. Evaluate Gateway API implementations in a non-production environment
2. Test your critical routes with the new controller
3. Create a migration plan with rollback procedures
4. Train your team on Gateway API concepts (the resource model is different)

Migration Deadline (Before March 2026)

1. Run parallel deployments during transition
2. Switch traffic route-by-route or namespace-by-namespace
3. Validate functionality and performance
4. Decommission ingress-nginx only after full validation

 

What About the Ingress API Itself?

A final clarification: the Ingress API (networking.k8s.io/v1/Ingress) is not deprecated in Kubernetes itself. It remains a valid resource type, and many controllers will continue supporting it indefinitely.

What’s changing is:

• The community ingress-nginx implementation is retiring
• The Kubernetes community recommends Gateway API for new deployments
• Active development effort is focused on the Gateway API

You can continue using Ingress resources with controllers that support them (Traefik, F5/NGINX, HAProxy, etc.). However, new features and innovations will arrive via Gateway API, so migration is strategically wise even if not immediately urgent for some organizations.

 

Conclusion

The retirement of ingress-nginx marks a milestone in Kubernetes’ evolution toward more expressive, standardized traffic management. While the March 2026 deadline creates urgency, the ecosystem provides multiple viable paths forward.

Key takeaways:

1. Don’t panic – existing deployments won’t break, but plan your migration
2. Understand what’s retiring – only the community ingress-nginx project, not all NGINX options
3. Gateway API is production-ready for most use cases and represents the strategic direction
4. Multiple migration paths exist – choose based on your existing investment and operational preferences
5. Start planning now – migration takes time, especially if you have complex configurations

The transition from Ingress to Gateway API isn’t just about replacing one controller—it’s an opportunity to adopt a more powerful, portable traffic management model. Organizations that approach this proactively will emerge with cleaner, more maintainable infrastructure.

By Alex Coman,
Software Architect

References

• Ingress NGINX Retirement Announcement — Kubernetes Blog
• Gateway API Documentation — Official Gateway API Docs
• Migrating from Ingress NGINX to Gateway API — Migration Guide
• NGINX Ingress Controller for Kubernetes — F5/NGINX Documentation
• Kubernetes Ingress Controllers — Kubernetes Docs
• Gateway API Implementations — Conformant Controllers List

 

This guide reflects information available as of February 2026. Check the official Kubernetes and Gateway API documentation for the latest updates. Yonder, as a Kubernetes-certified service provider (KCSP), can help organizations evaluate migration options and select the most suitable path, while accounting for all associated tradeoffs.