Original link: https://102no.com/2022/10/01/kong-3.0/

Original link: https://konghq.com/blog/kong-gateway-3-0

Kong Gateway 3.0 is an important milestone release that introduces the next evolution of our cloud-native API platform. Both the enterprise and open source versions of Kong Gateway 3.0 are now available from various distribution channels.

In Kong Gateway 3.0, we have introduced a number of powerful features that bring the following key benefits:

Greater Security and Governance: FIPS 140-2 Compliant Requirements for Secure Secret Storage (Cross-Gateway Operations and Plugins)
Flexibility and Extensibility: Customers can choose their plugin execution order, add native support for WebSocket communication, and deeply integrate OpenTelemetry.
Simple API Management: New features of Kong Manager UI enhance the user experience. Introducing a powerful new routing engine that optimizes the expression of complex routes while also improving operational performance.
Significant performance improvements: Compared with Kong 2.8.1.4, in high-complexity routing scenarios, throughput is increased by 37%, latency is reduced by at least 27%, high probability (99% of cases) is reduced by 47%, and memory consumption is reduced 9%.

Tracing and OpenTelemetry

Understanding how Kong Gateway performs is a critical part of deployment, and we’re pleased to announce extensive tracking support in both Kong Gateway Open Source and Enterprise Editions. There are two ways to get started. OTel can be sent directly to any compatible backend using the out-of-the-box OpenTelemetry plugin, or to the OpenTelemetry collector. We’ve been testing the Kong Gateway with Honeycomb and it works great.

Here is a trace that proxies a request to mockbin.org:

Figure 1: Trace of proxying a single request to mockbin.org

Then the same request, once the rate limit plugin is enabled (using Redis):

Figure 2: The same request with the rate limit plugin enabled

The second option is to use Kong’s Trace Plugin Development Kit (PDK) to hook all key events. That’s how the OpenTelemetry plugin works, giving full control over how trace information is collected and sampled, and how data is exported to other systems.

Whichever option you choose, knowing how Kong Gateway performs is key. Determining how much time is spent on each request can help you optimize for higher performance and, therefore, the user experience.

Websockets (Beta) (Enterprise Edition)

Key Management (GA)

We initially released a beta version of Secrets Management in Kong Gateway 2.8, and we are happy to announce that it is officially supported in this release.

Secrets Management allows you to securely store sensitive information in external storage (Environment Variables for OSS, AWS Secrets Manager, and HashiCorp Vault for Enterprise) that Kong can access at runtime. By storing sensitive values as secrets, you can ensure that they are not visible through the platform in clear text, in Kong.conf or declarative configuration files, logs, or the Kong Manager UI.

Additionally, using Secrets Management allows you to provide specific values for development, staging, and production environments, while configuring each environment with the exact same declarative configuration files.

Getting started with Secrets Management is easy, wherever you previously set a clear text password, replace it with a vault path, for example:

1	{ vault ://hcv/redis/password}

Kong will detect this reference and resolve it safely at runtime.

For a more in-depth look at secret management, follow our upcoming blog on how to store Redis passwords in HashiCorp Vault when using the Proxy Cache Premium Plugin.

FIPS 140-2 Compliance (Enterprise Edition)

Plugin Sorting (Enterprise Edition)

new routing engine

This new feature still has some technical content. Kong Gateway 3.0 comes with a new “expression” routing engine, which can be used to route requests to upstream APIs.

Suppose you want to route GET and POST requests, but only if they are HTTP requests. Instead of using JSON to configure routes, you can write an expression like the following:

1	net.protocol == “https” && (http.method == ” GET “ \|\| http.method == ” POST “ )

This is a simple example, but suppose you want to route requests that match a specific host and include a header that includes the hostname. This is hard to predict, so let’s see what it looks like:

( http.host == “example.com” && http.headers.x_example_version == “v2” ) ||

( http.host == “store.example.com” && http.headers.x_store_version == “v1” )

This route will only match if the host is example.com and the value of the header x-example-version header is v2 , or if the host is store.example.com and the header x-store-version header is v1 . This is a great example of the flexibility of Kong Gateway 3.0’s new routing engine. Implementing the same functionality in 2.x would have to create two separate routes.

The new routers are not only more expressive, but also perform better, and large routing configurations can now be reloaded incrementally instead of rebuilding the entire router every time the configuration changes. This reduced the P99 time from 1.5s to 0.1s in our tests.

Finally, an introduction to the JSON router in 2.x. It can still be used in this version, because the existing routing rules need to be supported, so the existing routers are retained in 3.0. You can set router_flavor to traditional in kong.conf , then the route matching will be the same as the 2.x version.

Kong Manager 3.0 (Enterprise Edition)

Deprecations and deletions

Kong’s commitment to stability means we maintain backward compatibility across all distributions within a major release. Kong Gateway 3.0 gives us the opportunity to deprecate some features and remove others to improve the quality of the product.

The following items have been deprecated or removed:

Kong Gateway no longer uses heuristics to guess whether a path is correct. Path is a regular expression pattern. Starting with 3.0, all regex paths must start with a “~” prefix, and all paths that do not start with “~” will be treated as plain text. Upgrading from 2.x to 3.0.x, the migration process should automatically convert regex paths.
Support for the nginx-opentracing module is deprecated in version 3.0 and will be removed in version 4.0. and use the new tracing PDK and OpenTracing module as a replacement
Amazon Linux 1 and Debian Jesse are no longer officially supported operating systems.
POST requests on the target endpoint are no longer able to update existing entities. They can only create new ones. If you have scripts that use POST requests to modify/target, change them to PUT requests to the appropriate endpoints before updating to Kong Gateway 3.0.
The Prometheus plugin disables high cardinality metrics by default. This will reduce the load on the database when Prometheus clears statistics.

Extra Highlights

Plugin version consistency: It can be difficult to determine which version of the plugin you were running before. As of Kong Gateway 3.0, the plugin version is aligned with the gateway version so that people know exactly which version of the plugin they are running
Slim/UBI images: We have switched the base images built by Docker to debian-slim and rhel-ubi. This means smaller images and smaller packages installed, resulting in a more secure image.
System Certificate Authority: Kong now defaults to using whatever CA certificate is installed on the host OS. This allows you to manage certificate authorities for all your software in one place
LDAP authentication: The LDAP authentication plugin can secure services by authenticating to LDAP services. Kong Gateway 3.0 adds authorization support based on group membership. For example “Only members of the FinanceDev team can access this API”.

This article is reprinted from: https://102no.com/2022/10/01/kong-3.0/
This site is for inclusion only, and the copyright belongs to the original author.