Kong Gateway swings to hit 1.4

Kong

The team behind microservice abstraction layer Kong Gateway has released version 1.4 of their project, offering admins more configuration options and sprinkling some automation into the mix.

Kong Gateway 1.4 includes a new status interface which allows the exposure of insensitive health, metrics, and error read-only information from Kong. It facilitates the monitoring of a system’s status without injecting custom server blocks that could compromise the project’s Admin API. Speaking of the latter, the Gateway was also fitted with a new response header called X-Kong-Admin-Latency that reports on how long the API needs to process requests, if that is something you plan to look into.

Admins can now use cassandra_refresh_frequency to define how long Kong has to wait before checking for changes in the topology of an Apache Cassandra cluster, the default being 60 seconds between runs. Any changes will be detected automatically, which is supposed to avoid sudden Kong restarts. If this behaviour isn’t desired, the checks can be disabled.

Something similar is also available for the frequency in which routers and plugins are checked for changes. The respective configuration option is aptly named router_update_frequency

Advertisement

Users looking for more control can define an optional hostname attribute to make sure the system only uses this fixed Host header to proxy connections through Kong servers. A property transformations in the DAO schema meanwhile provides a way to add functions that only run in case a database entry changes.

The release of version 1.4 marks the beginning of the project’s service mesh deprecation. The feature will be removed in the next major release, since it has caused proxy_ssl* directives to be ignored under certain circumstances. It will be replaced by the Kuma project, but can be reactivated by using the new service_mesh configuration option for now. A complete list of changes can be found in the Kong changelog.

- Advertisement -