Kubernetes is an open source platform designed for the automation of deployment, scaling, and management of containerized applications. These applications are deployed as containers, which are lightweight, portable packages encompassing all necessary code, libraries, and dependencies required for an application to function correctly. Within a fleet of servers, Kubernetes manages these containers, allowing operators to scale applications up or down based on demand. NGINX, created by Igor Sysoev in 2004, was originally an open-source project designed to solve pervasive instability issues related to high numbers of concurrent connections. Over time, it evolved into the most ubiquitous high-performance web server technology, primarily utilized for reverse proxying, web services, caching, and load balancing.
When integrated into Kubernetes, NGINX functions as a critical component for managing how external traffic reaches the containerized services. As a web server, NGINX handles HTTP requests from clients, such as web browsers, and provides the appropriate responses. In its role as a reverse proxy, NGINX positions itself in front of one or more web servers, acting as an intermediary that forwards client requests to the correct backend server and returns the response to the client. This synergy between the orchestration capabilities of Kubernetes and the high performance, stability, and low resource usage of NGINX allows organizations to deploy and manage applications at a massive scale.
The Lifecycle and Retirement of Ingress NGINX
Ingress NGINX was developed early in the history of the Kubernetes project. It served as an example implementation of the Ingress API and gained widespread popularity due to its independence from any specific cloud or infrastructure provider, as well as its tremendous flexibility and breadth of features. Because it was not tied to a particular vendor, it was adopted by many hosted Kubernetes platforms and countless independent user clusters.
However, this same flexibility eventually created significant maintenance challenges. As expectations for cloud-native software evolved, certain features that were previously considered helpful became identified as serious security flaws. A primary example is the ability to add arbitrary NGINX configuration directives via "snippets" annotations. This flexibility transformed into insurmountable technical debt over time.
Furthermore, Ingress NGINX struggled with insufficient maintainership. For years, the project was sustained by only one or two individuals who performed development work on their own time, specifically after work hours and on weekends. Due to these stability, security, and maintenance issues, the Kubernetes SIG Network and the Security Response Committee announced the retirement of Ingress NGINX in November 2025. Users of Ingress NGINX are now advised to migrate to the Gateway API as a modern replacement.
Ingress-NGINX Version Compatibility Matrix
The Ingress-NGINX project provides a detailed compatibility matrix to ensure that the controller version aligns with the Kubernetes cluster, the underlying Alpine Linux distribution, the NGINX binary, and the Helm chart version. While versions may function on older Kubernetes releases, the project does not provide a guarantee for such configurations.
| Ingress-NGINX Version | Kubernetes Supported Version | Alpine Version | Nginx Version | Helm Chart Version |
|---|---|---|---|---|
| v1.15.1 | 1.35, 1.34, 1.33, 1.32, 1.31 | 3.23.3 | 1.27.1 | 4.15.1 |
| v1.15.0 | 1.35, 1.34, 1.33, 1.32, 1.31 | 3.23.3 | 1.27.1 | 4.15.0 |
| v1.14.5 | 1.34, 1.33, 1.32, 1.31, 1.30 | 3.23.3 | 1.27.1 | 4.14.5 |
| v1.14.4 | 1.34, 1.33, 1.32, 1.31, 1.30 | 3.23.3 | 1.27.1 | 4.14.4 |
| v1.14.3 | 1.34, 1.33, 1.32, 1.31, 1.30 | 3.23.2 | 1.27.1 | 4.14.3 |
| v1.14.2 | 1.34, 1.33, 1.32, 1.31, 1.30 | 3.23.2 | 1.27.1 | 4.14.2 |
| v1.14.1 | 1.34, 1.33, 1.32, 1.31, 1.30 | 3.22.2 | 1.27.1 | 4.14.1 |
| v1.14.0 | 1.34, 1.33, 1.32, 1.31, 1.30 | 3.22.2 | 1.27.1 | 4.14.0 |
| v1.13.9 | 1.33, 1.32, 1.31, 1.30, 1.29 | 3.23.3 | 1.27.1 | 4.13.9 |
| v1.13.8 | 1.33, 1.32, 1.31, 1.30, 1.29 | 3.23.3 | 1.27.1 | 4.13.8 |
| v1.13.7 | 1.33, 1.32, 1.31, 1.30, 1.29 | 3.23.2 | 1.27.1 | 4.13.7 |
| v1.13.6 | 1.33, 1.32, 1.31, 1.30, 1.29 | 3.23.2 | 1.27.1 | 4.13.6 |
| v1.13.5 | 1.33, 1.32, 1.31, 1.30, 1.29 | 3.22.2 | 1.27.1 | 4.13.5 |
| v1.13.4 | 1.33, 1.32, 1.31, 1.30, 1.29 | 3.22.2 | 1.27.1 | 4.13.4 |
| v1.13.3 | 1.33, 1.32, 1.31, 1.30, 1.29 | 3.22.1 | 1.27.1 | 4.13.3 |
| v1.13.2 | 1.33, 1.32, 1.31, 1.30, 1.29 | 3.22.1 | 1.27.1 | 4.13.2 |
| v1.13.1 | 1.33, 1.32, 1.31, 1.30, 1.29 | 3.22.1 | 1.27.1 | 4.13.1 |
| v1.13.0 | 1.33, 1.32, 1.31, 1.30 | 3.22.1 | 1.27.1 | 4.13.0 |
NGINX Product Suite for Kubernetes
NGINX offers a comprehensive array of products specifically engineered for Kubernetes environments, ranging from open-source tools to enterprise-grade platforms.
NGINX Plus
NGINX Plus is the enterprise-ready, fully supported version of the NGINX open source platform. It functions as a reverse proxy and load balancing tool that fulfills multiple roles within a cluster.
- Sidecar: A sidecar is a dedicated container that runs alongside the application container within a single Kubernetes pod. This configuration is used to offload functionality required by applications operating in a service mesh environment, thereby separating the application logic from the networking logic.
- Ingress Controller: NGINX Plus includes an ingress controller that allows Kubernetes clusters to manage both ingress (incoming) and egress (outgoing) traffic.
- Firewall proxy: It provides a firewall proxy specifically for services and pods to enhance security.
- API gateway: It acts as an API gateway to manage service-to-service communication between containers and pods, ensuring controlled and secure interaction.
NGINX Service Mesh
NGINX Service Mesh is a lightweight service mesh solution. It is designed to provide data plane security, scalability, and cluster-wide traffic management. This tool provides a secure solution for both ingress and egress management, specifically tailored to support various Kubernetes implementations.
NGINX Kubernetes Gateway
The NGINX Kubernetes Gateway, currently in Beta, is a controller that implements the Kubernetes Gateway API specification. This specification evolved from the original Kubernetes Ingress API. The Gateway API is an open source project maintained by the Kubernetes Networking Special Interest Group (SIGNETWORK) community, intended to standardize and improve service networking across the Kubernetes ecosystem. NGINX is an active contributor to this project.
The NGINX Kubernetes Gateway addresses the challenge of enabling multiple teams to manage Kubernetes infrastructure in modern environments. It simplifies deployment and management by offering a variety of features without requiring the implementation of a Custom Resource Definition (CRD). It utilizes proven NGINX technology as the data plane to achieve improved security, visibility, and performance.
The Gateway API operates by mapping three key resources to specific organizational roles using Role-Based Access Control (RBAC):
- GatewayClass: Mapped to the Infrastructure Provider.
- Gateway: Mapped to the Cluster Operator.
- Routes: Mapped to the Application Developer.
Enterprise-Grade Ingress with F5 NGINX
For organizations running business-critical workloads, F5 NGINX Ingress Controller provides a production-ready alternative to community-maintained controllers. This offering is designed for teams that require a stable, enterprise-backed solution.
The F5 NGINX Ingress Controller provides a low-risk migration path for those moving away from community versions while introducing several enterprise advantages:
- Security and lifecycle assurance: Users receive regular CVE fixes, updates, and published support timelines, ensuring the environment remains secure.
- Enterprise support and roadmap: The product is backed by a fully staffed team, providing clear commitments regarding the product lifecycle and future support.
- Proven scale: The solution is trusted by enterprises globally to run critical business workloads.
- Advanced capabilities: NGINX Plus enhances the ingress capabilities with enterprise-grade features required for mission-critical workloads, focusing on observability, security, and advanced traffic management.
Comparative Analysis of NGINX Kubernetes Implementations
The transition from Ingress NGINX to the Gateway API and the utilization of NGINX Plus represent a shift from community-driven, flexible-but-fragile configurations to structured, role-based, and supported infrastructures.
The original Ingress NGINX approach relied heavily on annotations and a single API to handle routing. While this allowed for rapid deployment and high flexibility, it led to "technical debt" where the complexity of the configuration became a security liability. In contrast, the NGINX Kubernetes Gateway leverages the Gateway API to separate concerns. By dividing the configuration into GatewayClass, Gateway, and Routes, the system ensures that application developers cannot accidentally alter infrastructure-level settings, and cluster operators can manage the gateway without needing to understand every individual application route.
From a support perspective, the gap between the community-maintained Ingress NGINX and NGINX Plus/F5 NGINX is substantial. Ingress NGINX's reliance on a handful of volunteers led to maintenance struggles. Enterprise versions solve this by providing a dedicated staff, published roadmaps, and guaranteed security updates, which are essential for production environments where downtime or security breaches can have catastrophic financial consequences.