Web Server Load Balancing with NGINX Plus

[Editor – This post was updated in August 2022 to mark availability of the beta version of F5 NGINX Kubernetes Gateway.]

Having worked the past several years to help you succeed on your Kubernetes journey, F5 NGINX has reached another milestone – we’ve released the beta version of the newest addition to the NGINX family: F5 NGINX Kubernetes Gateway!

NGINX Kubernetes Gateway is a controller that implements the Kubernetes Gateway API specification, which evolved from the Kubernetes Ingress API specification. Gateway API is an open source project managed by the Kubernetes Network Special Interest Group (SIG‑NETWORK) community to improve and standardize service networking in Kubernetes. NGINX is an active contributor to this project.

If you are actively working with Kubernetes, you may already be familiar with the Ingress API object and the many available Ingress implementations. Gateway API is the newest way to expose your Kubernetes apps and APIs. To learn more about the other currently available options, see Kubernetes Networking 101.

As organizations have deployed Ingress controllers over the past few years in production‑grade Kubernetes clusters across diverse hybrid, multi‑cloud environments, they have come to recognize the need for Gateway API to help solve various challenges:

  • One challenge is that the original Ingress resource is designed with only one user role in mind – the Kubernetes operator or administrator who oversees the entire configuration. That model doesn’t fit many organizations, where multiple teams – application developers, platform operators, security administrators, and others – need to control different aspects of the Ingress configuration as they collaborate on app development and delivery. Gateway API recognizes the new model and makes it easy to delegate control over networking configuration across multiple roles.

  • Another challenge is the proliferation of annotations and custom resource definitions (CRDs) in many Ingress implementations, where they unlock the capabilities of different data planes and implement features that aren’t built into the Ingress resource, like header‑based matching, traffic weighting, and multi‑protocol support. Gateway API delivers such capabilities as part of the core API standard.

What Is NGINX Kubernetes Gateway?

As the evolution of an Ingress controller, NGINX Kubernetes Gateway addresses the challenges of enabling multiple teams to manage Kubernetes infrastructures in modern customer environments. It also helps simplify deployment and administration by delivering many capabilities without the need to implement CRDs. NGINX Kubernetes Gateway leverages proven NGINX technology as its data plane to deliver best-in-class performance, visibility, and security.

NGINX Kubernetes Gateway standardizes on three primary Gateway API resources (GatewayClass, Gateway, and Routes) with role‑based access control (RBAC) mapping to the associated roles (infrastructure providers, cluster operators, and application developers).

Clearly defining the scope of responsibility and separation for different roles streamlines and simplifies administration. Specifically, infrastructure providers define GatewayClasses for Kubernetes clusters while cluster operators deploy and configure Gateways within a cluster, including policies. Application developers are then free to attach Routes to Gateways to expose their applications externally.

In addition, NGINX Kubernetes Gateway simplifies deployment and management of service networking in Kubernetes environments by standardizing built‑in core functionality for most use cases, thereby reducing the need for CRDs. The beta implementation of NGINX Kubernetes Gateway is focused on delivering Ingress controller functionality with Layer 7 (HTTP and HTTPS) routing. Future capabilities will be driven by community feedback and use cases, including Layer 4 routing capabilities. The long‑term roadmap for the Gateway API and NGINX Kubernetes Gateway is eventually to deliver a superset of features that are offered by Ingress controllers.

How Is NGINX Kubernetes Gateway Different from NGINX Ingress Controller?

F5 NGINX Ingress Controller implements the Ingress API specification to deliver core functionality, using custom annotations, CRDs, and NGINX Ingress resources for expanded capabilities. NGINX Kubernetes Gateway conforms to the Gateway API specification, simplifies implementation, and aligns better with the organizational roles that deal with service networking configurations.

The following table compares the key high‑level features of the standard Ingress API, NGINX Ingress Controller with CRDs, and Gateway API to illustrate their capabilities.

Feature Standard Ingress API NGINX Ingress Controller with CRDs Gateway API
API specification Ingress API Ingress API + CRDs Gateway API
Multi-user management
Layer 7 protocols (HTTP/HTTPS, gRPC)
Layer 7 load balancing Custom policy
Request routing
Request manipulation Limited
Response manipulation Limited
Layer 4 protocols (TLS, TCP, UDP)
Layer 4 load balancing Custom policy
Allow/deny lists Custom policy
Certificate validation Custom policy
Authentication (OIDC) Custom policy
Rate limiting Custom policy

Is NGINX Kubernetes Gateway Going to Replace NGINX Ingress Controller?

NGINX Kubernetes Gateway is not replacing NGINX Ingress Controller. Rather, it is an emerging technology based on the alpha release of the Gateway API specification and is intended for evaluation purposes only – it is not for use in production. NGINX Ingress Controller is a mature, stable technology used in production by many customers. It can be tailored for specific use cases through custom annotations and CRDs. For example, to implement the role‑based approach, NGINX Ingress Controller uses NGINX Ingress resources, including VirtualServer, VirtualServerRoute, TransportServer, and Policy.

We don’t expect NGINX Kubernetes Gateway to replace NGINX Ingress Controller any time soon – if that transition does happen, it’s likely to be years away. NGINX Ingress Controller will continue to play a critical role in managing north‑south network traffic for a diverse variety of environments and use cases, including load balancing, traffic limiting, traffic splitting and security.

Is NGINX Kubernetes Gateway an API Gateway?

While it’s reasonable to think something named “Gateway API” is an “API gateway”, this is not the case. As we discuss in How Do I Choose? API Gateway vs. Ingress Controller vs. Service Mesh, “API gateway” describes a set of use cases that can be implemented via different types of proxies – most commonly an ADC or load balancer and reverse proxy, and increasingly an Ingress controller or service mesh. That said, much like NGINX Ingress Controller, NGINX Kubernetes Gateway can be used for API gateway use cases, including routing requests to specific microservices, implementing traffic policies, and enabling canary and blue‑green deployments. The beta release is focused on processing HTTP/HTTPS traffic. More protocols and use cases are planned for future releases.

How Do I Get Started?

Ready to evaluate this exciting new technology? Get the beta release of NGINX Kubernetes Gateway.

For deployment instructions, see the README.

For detailed information on the Gateway API specifications, refer to the Kubernetes Gateway API documentation.

We encourage you to submit feedback, feature requests, use cases, and any other suggestions so that we can help you solve your challenges and succeed. Please share your feedback at our GitHub repo.

Hero image
Taking Kubernetes from Test to Production

A practical guide to selecting and deploying Kubernetes traffic management tools

About The Author

Ilya Krutov

Ilya Krutov

Product Marketing Manager, NGINX

About F5 NGINX

F5, Inc. is the company behind NGINX, the popular open source project. We offer a suite of technologies for developing and delivering modern applications. Together with F5, our combined solution bridges the gap between NetOps and DevOps, with multi-cloud application services that span from code to customer.

Learn more at or join the conversation by following @nginx on Twitter.