Announcing F5 NGINX Gateway Fabric 2.0.0 with a New Distributed Architecture

Today, F5 NGINX Gateway Fabric (NGF) is reaching an important milestone. The release of NGINX Gateway Fabric 2.0 marks our transition into a distributed architecture that is highly scalable, secure, and flexible. This architecture also easily enables more advanced capabilities and prepares us for integration for observability and fleet management with F5 NGINX One. Here are the big highlights for this major release:  

• Control and Data Plane Separation  

• Multiple Gateway Support  

• HTTP Request Mirror  

• Listener Isolation  

• As always, bug fixes  

 

The NGINX One Console 

Part of our strategy around “NGINX One” is to include all of our products into the NGINX One Console – a management solution to configure, secure, and monitor NGINX at scale. This online portal will show you all your connected NGINX instances across all environments, track CVEs, and eventually, give you an incredible Observability experience. All of this is available for no additional cost when you have an NGINX One subscription. 

With 2.1, NGINX Gateway Fabric now has a mechanism for you to add a token to your installation that will send telemetry data to the Console. This will let you view all of your NGINX estate from one place. Currently, you can track current NGINX and NGINX Gateway Fabric versions, as well as track CVEs related to those versions. 

In the future, we plan to include performance metrics and logs to show dashboards, perform analysis, and create alerts. For advanced users, you’ll even be able to see the NGINX configuration for every NGINX instance you have, including NGINX Gateway Fabric. We also plan to deliver integration with F5 WAF through the Console to ensure all NGINX products have the appropriate configuration. 

 

Horizontal Pod Autoscaling 

Thanks to the awesome work of one of our open-source contributors, @nowjean on GitHub, we could include Kubernetes horizontal pod autoscaling support for NGINX Gateway Fabric! This means you can set up your Gateway infrastructure to automatically scale up or down with instances of NGINX depending on the level of CPU or memory that is being consumed.  

If you have big differences in the amount of traffic coming into your cluster during the day or unpredictable spikes, autoscaling can deliver the extra power when you need it and scale down when it’s not. 

 

Provisioned Resource Patching 

As a part of our 2.0 release, NGINX Gateway Fabric now provisions resources within Kubernetes without you having to explicitly define their deployments yourself. This applies to the Services, Deployments, and DaemonSets NGINX Gateway Fabric creates when you apply Gateway objects to your cluster. 

After 2.0, our users quickly found that they were unable to change these resources to fit the unique constraints of their environment, so for 2.1, we built a mechanism for you to be able to modify them entirely. For details on how to start making changes, you can check out our how-to guide on data plane configuration here! 

 

What’s Next 

NGINX Gateway Fabric 2.2.0 will primarily be centered on the implementation of the Gateway API Inference extension. This extension seeks to extend the Gateway API to include routing use cases specific to inference workloads on Kubernetes: 

As LLM usage and agentic AI increases within almost every major product on the internet, we want to make sure that NGINX Gateway Fabric can support the unique routing use cases that these models introduce. As we know, the traffic patterns for these models can be widely different over time, and over different types of prompts. 

We are also looking at tweaking how NGINX Gateway Fabric is installed in OpenShift environments.  We understand that there are some unique challenges to overcome when deploying to a typical OpenShift environment. Users can look forward to an operator offering with these tweaks as well. But as always, let us know on GitHub if you’re running into issues with installation, even with 2.1!  

In addition to some more extended features, such as the GatewayAddresses field, we are also looking into support for the ExternalName Service. This will allow you to route traffic from NGINX Gateway Fabric to a destination outside your cluster when your architecture or use case calls for it. 

 

Resources 

For the complete changelog for NGINX Gateway Fabric 2.1.0, see the Release Notes. To try NGINX Gateway Fabric for Kubernetes with NGINX Plus, start your free 30-day trial today or contact us to discuss your use cases. 

If you would like to get involved, see what is coming next, or see the source code for NGINX Gateway Fabric, check out our repository on GitHub! 

We have weekly community meetings on Tuesdays at 9:30AM Pacific/12:30PM Eastern/5:30PM GMT. The meeting link, updates, agenda, and notes are on the NGINX Gateway Fabric Meeting Calendar. Links are also always available from our GitHub readme.