The Kubernetes landscape is dynamic, with the Ingress resource defining external traffic flow and the Ingress controller providing crucial routing and load balancing.
Ingress-nginx, the community-maintained Ingress controller, has been widely adopted. It effectively translates standard Kubernetes Ingress objects into NGINX configurations, providing a reliable entry point for services.
However, cloud-native infrastructure is constantly evolving. And with that comes new directions for ingress in the Kubernetes community. In fact, the Kubernetes documentation now states:
This indicates a shift in community focus away from the Ingress API, though ingress itself remains essential. F5 NGINX is also fully committed to the Kubernetes Gateway API, delivering the highly performant and enterprise-ready NGINX Gateway Fabric. Concurrently, the open source NGINX Ingress Controller, developed by F5 NGINX, has gained immense traction, with ~40% market share and over 10 million downloads. It’s engineered for high-performance, scalable, and secure production environments, with the F5 NGINX team continuously evolving and improving NGINX Ingress Controller.
Why Move?
Migrating controllers can seem daunting, but recent events highlight its importance. Critical vulnerabilities in ingress-nginx, like Ingress Nightmare CVE-2025-1974 (CVSS 9.8), which could allow cluster takeover, underscore the need for actively supported solutions. (It is worth noting that the recently reported vulnerabilities did not impact the NGINX Ingress Controller.)
While patched, these events highlight the risks associated with critical infrastructure components and underscore the need for long-term stability and security. As Kubernetes deployments mature, the demand for sophisticated traffic management, advanced security, and deeper operational visibility often reveals limitations in the basic Ingress API, driving exploration of more feature-rich alternatives.
The use of LUA for ingress-nginx can also prove to be a challenge, as it can degrade performance. LUA, for example, can lead to memory leaks in NGINX worker processes. There have also been reports of Out-Of-Memory crashes in worker processes, causing degraded behavior of API endpoints. However, the use of NGINX JavaScript (njs) with its tight integration has fewer external dependencies without the need for an additional runtime and reduces the attack surface. And with the inclusion of the QuickJS engine, NGINX supports the full ES2023 specification.
Community vs. F5 NGINX Ingress
Both controllers leverage the NGINX engine, but differ in development philosophy, features, and support models.
ingress-nginx
This open-source solution by the Kubernetes project is widely adopted for its accessibility. It translates standard Kubernetes Ingress resources into NGINX configurations, primarily facilitating HTTP and HTTPS routing, including host-based routing and basic SSL termination.
Configuration largely relies on standard Ingress resources, with advanced features using annotations. This “annotation overload” can make complex setups less portable and challenging.
A key consideration is its development trajectory: the underlying Kubernetes Ingress API is “frozen” as community efforts shift to the Gateway API. While ingress-nginx receives maintenance and security updates, new feature development for the Ingress API has stopped. In fact, with the emergence of the Kubernetes InGate project, the ingress-nginx project will transition to maintenance mode, with no new features from the core maintainers.
NGINX Ingress Controller
In contrast, the open source NGINX Ingress Controller is an F5 NGINX product, building on either NGINX Open Source or NGINX Plus. It’s an enterprise-grade solution for demanding production environments, designed for high performance, robustness, security, scalability, and supportability in managing API gateways, load balancers, and Kubernetes Ingressx
For security, it offers integrated Web Application Firewall (WAF) via NGINX App Protect, DDoS protection, and robust authentication (JWT, OIDC, basic authentication) with Role-Based Access Control (RBAC). It supports end-to-end encryption with SSL/TLS passthrough and termination, promoting a “shift left” security approach.
Traffic management features include sophisticated Layer 4 and Layer 7 load balancing, dynamic reconfiguration, rate limiting, circuit breaking, and request buffering. It supports advanced deployment patterns like blue-green, canary, and A/B testing, with fine-grained traffic splitting for complex rollouts. Beyond HTTP/S, it natively supports WebSockets, gRPC, TCP, and UDP, offering a unified entry point.
Operational visibility is strong with detailed logging and integrations with Prometheus, Grafana, and OpenTelemetry. Designed for high scalability and resiliency, it ensures uptime with active health checks and prevents connection timeouts. Its design facilitates multi-tenancy and self-service via RBAC, empowering teams to manage ingress securely.
While supporting standard Kubernetes Ingress resources with annotations, NGINX Ingress Controller primarily uses custom resource definitions (CRDs): VirtualServer, VirtualServerRoute, Policy, TransportServer, and GlobalConfiguration. These CRDs provide a “native, type-safe, and indented configuration style” for complex scenarios, reducing annotation sprawl and offering a structured approach. Its performance is highly regarded, and setup is straightforward, especially with Helm charts.
NGINX Ingress Controller’s capabilities extend significantly beyond the basic Kubernetes Ingress API, meeting evolving enterprise demands for advanced security, protocol handling, and traffic management. As the “frozen” status of Ingress development directly influences future evolution within ingress-nginx, NGINX Ingress Controller continues to advance its scope to meet emerging challenges and needs.
Despite both being NGINX-based, community ingress-nginx will likely face a plateau in new feature development directly within that API. Migrating to NGINX Ingress Controller offers a robust pathway for evolving Kubernetes networking. The decision is a strategic alignment choice: ingress-nginx remains viable for simple HTTP/S routing, but NGINX Ingress Controller offers performance, robustness, and a Kubernetes-native approach to advanced traffic management and security. The “frozen” Ingress API means advanced functionality must come from controller-specific extensions, making the controller and its extension model a critical long-term strategic decision.
NGINX Ingress Controller (F5) leverages CRDs like VirtualServer and Policy. These CRDs provide a schema-backed, Kubernetes-native way to define complex configurations. While CRDs might have an initial learning curve, they offer a more structured method for complex traffic policies, leading to cleaner, more manageable YAML and reduced misconfigurations due to built-in validation and better API discoverability.
The following table provides a comparison of key features:
| Feature/Aspect | ingress-nginx | NGINX Ingress Controller | Notes |
| Maintainer/Origin | Kubernetes Community (Open Source) | F5/NGINX Inc. (Open Source, Commercial) | |
| Primary Config for Advanced Features | Annotations | Custom Resources (CRDs) | CRDs offer structured, type-safe configuration. |
| Development Status | Ingress API “frozen” | Actively Developed, continuous feature releases | Allows continuous evolution. |
| Enterprise Support | Community support | 24×7 Support available | Crucial for mission-critical applications. |
| Advanced Traffic Management | Limited, via annotations | Native CRD support (blue/green, canary, A/B testing, advanced load balancing, circuit breaking) | More robust, integrated capabilities. |
| Security Features | Basic TLS, some annotation-driven features | WAF (App Protect), mTLS, JWT/OIDC, DDoS, RBAC, SSL/TLS orchestration | Comprehensive security suite. |
| Protocol Support (beyond HTTP/S) | TCP/UDP via ConfigMap | Native CRD support (TransportServer for TCP/UDP, gRPC, WebSockets) | Unified traffic management for diverse applications. |
| Observability | Basic logging and metrics | Metrics, detailed logging, Prometheus/Grafana/OpenTelemetry integration | Enhanced troubleshooting and performance insights. |
| Configuration Complexity for Advanced Features | Annotation sprawl for complex features | Steeper initial CRD learning curve, but cleaner, more manageable, type-safe for complex configs | Favorable trade-off between immediate simplicity and long-term maintainability. |
| Cost | Free/Open Source | Free/Open Source and Commercial License (NGINX Plus) | Fit to needs, features, support, value |
If you are starting to explore Kubernetes Gateway API, check out open source NGINX Gateway Fabric, which is NGINX’s solution built for the future-ready Kubernetes Gateway API.
Wrapping Up Part 1
Moving to a stronger Kubernetes networking layer requires careful planning, thorough testing, and a strategic traffic cutover. By embracing the open source NGINX Ingress Controller’s capabilities, organizations can establish a more resilient, secure, and performant foundation for their applications, one that is ready for tomorrow’s cloud-native world.
In Part 2, we’ll suggest a roadmap for migrating to NGINX Ingress Controller.
Download NGINX Ingress Controller from GitHub and get started today.
Also, please join us in the NGINX Community Forum to provide feedback, ask questions, or share your insights.
