Hello, Kong Nation 👋 ! We've fashioned a pristine version of the Kong Gateway (OSS) 2.5, which is now available on the normal channels. Read on for more release information.

Performance

A New Testing Framework

Imagine you're visiting a banking website to transfer funds to friends and family during the holiday season. If the wire transfer doesn't send within a certain number of seconds or fails completely, as a user, you'll likely close the browser and head to alternatives.

When it comes to building healthy production systems and APIs, understanding performance is critical to the well-being of your customers who consume your services, or you may lose them to competitors. This need to understand performance is why with v2.5, we are releasing a new Performance Testing Framework which provides an efficient way of carrying out performance benchmarks on the Kong Gateway (OSS).

The Framework is used to assess the performance of the Kong Gateway (OSS) itself with bundled or custom plugins, as well as plot frame graphs to debug performance bottlenecks. Built into Kong Gateway's (OSS) existing integration testing approach, the Framework makes developing performance tests easier. Check out the examples over at the Kong Repository to get you started.

If you're capacity planning/evaluating how to build the right Kong Gateway (OSS) environment to match your deployment requirements, the Performance Testing Framework would assist you in understanding the Gateway's requests per second on say, a specific EC2 instance. In this way, you can accurately estimate hardware requirements and save on costs. Or if you'd like to understand how a particular configuration of the Kong Gateway (OSS) with custom plugins operates in your environment, use the Framework to measure the latency of the upstream APIs that the Gateway manages. Running the Performance Testing Framework on your own hardware is straightforward once you have a handle on building the Kong Gateway (OSS) and running tests. Be on the lookout for a blog we plan to post soon on how to do exactly that!

Over at the Kong Gateway (OSS) Github Repository, we've started integrating the Framework using Github Actions - giving maintainers the ability to trigger performance tests on individual pull requests or release branches. Maintaining the Kong Gateway (OSS) requires a constant trade-off between performance and delivering rich feature sets. With this performance framework in place, our maintainers have the ability to plot performance trends over time, thus ensuring the high-performance bar expected from the Kong Gateway (OSS) community is maintained with every commit.

Hybrid Mode

Strengthening the Foundation

In Hybrid Mode, Kong Gateway (OSS) plays the role of a data plane which dynamically delegates request traffic for your APIs, and a control plane to synchronize gateway configurations across multiple Kong Gateway data planes. As one of the most popular deployment models for the Kong Gateway (OSS), we are beginning to lay the foundation in 2.5 for some advanced features coming soon! Check out the latest enhancements below to the Hybrid Mode deployment model.

Hybrid Mode additions include:

• Kong Gateway now exposes an upstream health check endpoint (using the status API) on the Data Plane for better observability. See Read Only Status API Endpoints on Data Plane for more information. #7429
• Control Planes are now more lenient when checking Data Planes’ compatibility in Hybrid mode. See the Version compatibility section of the Hybrid Mode guide for more information. #7488
• Control Planes can now send updates to new Data Planes even if the Control Planes lose connection to the database for better resiliency. #6938
• Kong now automatically adds cluster_cert (cluster_mtls=shared) or cluster_ca_cert (cluster_mtls=pki) into lua_ssl_trusted_certificate when operating in Hybrid Mode. Before, Hybrid Mode users needed to configure lua_ssl_trusted_certificate manually as a requirement for Lua to verify the Control Plane's certificate. The will make setting up Data Planes a bit faster. See Starting Data Plane Nodes in the Hybrid Mode guide for more information. #7044
• Also, be sure to review the number of additional fixes.

Plugin Developments

The following plugin improvements are available:

• hmac-auth: The HMAC Authentication plugin now includes support for the @request-target field in the signature string. Before, the plugin used the request-line parameter, which contains the HTTP request method, request URI and the HTTP version number. The inclusion of the HTTP version number in the signature caused requests to the same target but using different request methods(such as HTTP/2) to have different signatures. The newly added request-target field only includes the lowercase request method and request URI when calculating the hash, avoiding those issues. See the HMAC Authentication documentation for more information. #7037
• syslog: The Syslog plugin now includes facility configuration options, which are a way for the plugin to group error messages from different sources. See the description for the facility parameter in the Parameters section of the Syslog documentation for more information. #6081
• Prometheus: The Prometheus plugin now exposes connected data planes’ status on the control plane. New metrics include the following: data_plane_last_seen, data_plane_config_hash and data_plane_version_compatible. These metrics can be useful for troubleshooting when data planes have inconsistent configurations across the cluster. See the Available Metrics section of the Prometheus plugin documentation for more information. #98
• Zipkin: The Zipkin plugin now includes the following tags: kong.route, kong.service_name, kong.route_name. See the Spans section of the Zipkin plugin documentation for more information. #115

📓 A full list of changes and related PRs are in the CHANGELOG here.

🗣️ You can find our Kong Gateway (OSS) Distributions here as well.

THANK YOU

The community collectively benefits from the expertise, care and attention of individual contributors. With gratitude and a special thank you, we'd like to recognize the following contributors to the 2.5 release: @jideel, @ealogar, @yamaken1343, @onematchfox, @maxipavlovic@yamaken1343, @ocean-moist, @lockdown56, @hnlq715 and @jackkav.