By on October 25, 2019

Kong Gateway 1.4 Released! Auto-Detect Cassandra Topology Changes, Custom Host Header and Much More!

We’re pleased to announce that our first release in the 1.4 series is out! Our engineering team and awesome community members added numerous new features, improvements and fixes in this release.

Read below on the most relevant changes in Kong Gateway 1.4 and how you can make the most of these additions. Please refer to the Changelog for complete details and the Upgrade Path for instructions on how to upgrade from previous Kong versions.

Auto-detect Cassandra topology changes

Starting on Kong Gateway 1.4, any changes made to an Apache Cassandra cluster topology will be auto-detected, avoiding Kong restarts.

How to take advantage of this new functionality:

The new configuration cassandra_refresh_frequency sets how long Kong must wait before checking for Cassandra cluster topology changes. The default frequency is to check every 60 seconds, though this value can be increased, decreased or even disabled according to needs.

Hostname attribute in upstreams

Any upstream defined in Kong now can make use of an optional attribute called hostname, which defines the Host header that will be used when proxying connections through Kong servers.

Key benefits:

Often servers listen to server names that are different from the names to which they resolve, and this new property guarantees that Kong will use the correct ones when proxying connections and when actively checking the host’s health.

New transformations DAO property

The new property transformations has been added to DAO schemas, enabling developers to add functions that run when database entries are inserted or updated.

New status interface

With the new status interface, plugins can add endpoints to the already existent /status endpoint to expose insensitive health data, avoiding the need to expose Kong’s Admin API.

Key benefits:

  • Users can expose Kong’s health data and protect Kong’s Admin API at the same time.
  • It is easier to perform HTTP-based health checks for a Kong node running with a disabled Admin interface.

Additional new features in Kong Gateway 1.4

New Admin API response header X-Kong-Admin-Latency

  • This new response header reports how long each request to Kong’s Admin API has taken to process.

New configuration option router_update_frequency

  • This new configuration option allows setting the frequency that router and plugins will be checked for changes.
  • This avoids performance degradation when Kong routes or plugins are frequently changed.
  • This option gives power to the administrators to choose whether it is better to delay the availability of the changes in router and plugins configurations or to increase the database load.

Service-level support in rate-limiting plugin

  • In addition to consumer, credential and IP levels, now the rate-limiting plugin has service-level support.

Other Improvements and Bug Fixes in Kong Gateway 1.4

Kong Gateway 1.4 also improves the rate-limiting plugin memory use, expiring its local policy counters using the shared dictionary’s TTL to avoid keeping unnecessary counters in memory.

Some important bug fixes are present in this release, such as the beginning of service mesh deprecation, it will be replaced in favor of Kuma (kuma.io) moving forward. Service mesh is known to cause HTTPS requests to upstream to ignore proxy_ssl* directives, so it is being discontinued in the next major release of Kong Gateway. In this release, it is disabled by default, avoiding this issue and still can be enabled using the new configuration option service_mesh.

Another relevant fix is related to using log plugins to log NGINX-produced errors, which used to incorrectly report some request properties as the request method and works as expected now.

We also fixed an issue where targets were not properly updated in all Kong workers when they were removed, balancing traffic to those removed targets in heavy use scenarios.

As always, the documentation for Kong Gateway 1.4 is available here. Additionally, we will be discussing the key features in 1.4 in subsequent posts and on community calls, so stay tuned!

Thank you to our community of users, contributors and core maintainers for your continuing support of Kong’s open source platform.

Please give Kong Gateway 1.4 a try and be sure to let us know what you think!

Kong Nation

As usual, feel free to ask any questions on Kong Nation, our Community forum. Learning from your feedback will allow us to better understand the mission-critical use cases and keep improving Kong.

Happy Konging!