We are happy to announce release 2.2 of our flagship open source API gateway!
Those were some busy three months since the release of Kong Gateway 2.1! We have pushed a number of patch releases in the 2.1 series, we’ve had our first fully-digital Kong Summit, and of course, we’ve been very busy building new features that are now shipping in Kong Gateway 2.2!
Similarly to what we have done in the 2.1 series, we are also releasing a Beta release of Kong Enterprise 2.2, incorporating all features from Kong Gateway 2.2. You can learn more about Kong Enterprise and its additional capabilities here.
And now let’s jump right into the highlights for Kong Gateway 2.2:
UDP Support
For a long time, Kong has supported not only HTTP/HTTPS traffic with REST and gRPC APIs, but also raw TCP streams, in order to address gateway use-cases for a multitude of protocols. Continuing Kong’s mission to support all kinds of data in flight, in version 2.2 we now extend our support to include UDP-based protocols as well. UDP is used in a wide range of applications, ranging from audio/video streaming and gaming servers to financial services, so this opens a wide range of new possibilities for using Kong.
Kong Gateway 2.2 support for UDP includes proxying, load balancing and running plugins, giving users similar functionality for UDP that was already available for TCP. Using Kong for load balancing UDP data is particularly interesting since there is no inherent sense of connection in UDP, so Kong can ensure incoming packets are balanced consistently across upstream services, ensuring optimal cache use in those services.
To see UDP support in action, check out this video of a demo presented by Kong engineer Datong Sun at the Kong Online Meetup!
Extended functionality for Go plugins
If you are building custom plugins for Kong using Go, we have good news for you! We have listened to your feedback since we added Go support in Kong 2.0, and have extended the range of Kong functionality accessible from Go code.
Previously, Go support in Kong covered only reading the request data. Now, when running Go plugins, Kong reads the upstream response and presents it to Go plugins as well through a new response callback. This allows you, for example, to read headers from the upstream service’s response and perform custom plugin logic based on this data.
Configurable Request and Response Buffering
In Kong 2.2 you can now configure whether to enable or disable buffering of requests and responses on a per-Route basis. Previously, this was a static configuration which required modifications of template files and was an all-or-nothing proposition, and now this can be done dynamically by simply setting configuration attributes in your routes.
These new attributes allow you to better adjust Kong’s buffering behaviors for each endpoint, to ensure optimal latency especially for endpoints that deal with large payloads.
For a demo of this feature, check out Kong engineer Aapo Talvensaari presenting this feature at the Kong Online Meetup!
Support for Automatically Loading OS Certificates
Another feature built based on feedback we have received from you is a new option for automatically loading certificates that are pre-installed with the operating system. Now, the configuration option for setting the certificate file to be used accepts multiple entries and also a special value that matches the path of the certificate file bundled with the OS.
This makes it much easier operationally to support HTTPS services in the open internet while also enabling custom certificates for internal services. Here’s a video of Kong engineer Enrique García Cota discussing this feature in more detail at our recent Online Meetup.
Other Improvements and Fixes in Kong Gateway 2.2
- Rate-limiting by path – the URL path can now be used as a criteria for maintaining separate rate-limiting counts, without having to create a separate Route for each path.
- Removed target history from the database – When load balancing, Kong no longer needs to maintain the history of past changes to upstream targets in order to preserve consistent hashing. This removes the need for periodic database cleanup of targets, improves consistent hashing behavior for DB-less scenarios, and also means that the Admin API for Targets now behaves more closely to that of other entities, for example, supporting PATCH and DELETE methods as usual.
- Per-upstream client certificate for proxying – In Kong 2.1, the client certificate set in an Upstream was used only for active health checks. Now it can be used for proxying as well, if a client certificate is not set in a Service. This allows multiple Services that share the same Upstream to have their client certificate set only once in the Upstream, simplifying the configuration.
- Admin API and PDK now honor the setting for headers – Kong includes a headers setting in its configuration that allow you to control which headers are added by Kong when proxying. Now this setting is honored for Admin API and PDK-generated responses as well.
- Various improvements for Hybrid Mode – There were several improvements made in Hybrid Mode in Kong 2.2, most of which are generally transparent for the user but which result in an overall smoother scenario: communication between Control Plane and Data Plane nodes is now more efficient, graceful exit of nodes in failure scenarios was improved, and so on.
- Fixes for TCP and UDP support in logging plugins – Various logging plugins received adjustments to better support streaming modes using TCP and UDP services.
- OpenResty 1.17.8.2 – including multiple bug fixes, features and optimizations.
Kong Nation and Online Meetups
As always, feel free to ask any questions on Kong Nation, our community forum. Your feedback allows us to better understand the mission-critical use cases and keep improving Kong.
And if you want to stay on top of everything that’s going on as we develop future releases, join us in our monthly Online Meetups where Kongers present the latest and greatest stuff and often give sneak previews of the goodies that are coming through the pipeline!
Happy Konging!