このページは、まだ日本語ではご利用いただけません。翻訳中です。

旧バージョンのドキュメントを参照しています。 最新のドキュメントはこちらをご参照ください。

Kong Gateway 3.3.x breaking changes

Before upgrading, review any configuration or breaking changes in this version and prior versions that affect your current installation.

You may need to adopt different upgrade paths depending on your deployment methods, set of features in use, custom plugins, for example.

Plugins

For breaking changes to plugins, see the Kong Gateway Changelog for your Kong Gateway version.

Plugin queuing

The plugin queuing system was reworked in Kong Gateway 3.3.x, so some plugin parameters may not function as expected anymore. If you use queues in the following plugins, new parameters must be configured:

• HTTP Log
• OpenTelemetry
• Datadog
• StatsD
• Zipkin

For more information about how plugin queuing works and the plugin queuing parameters you can configure, see About Plugin Queuing and Plugin Queuing Reference.

Traditional compatibility router

The traditional_compat router mode has been made more compatible with the behavior of traditional mode by splitting routes with multiple paths into multiple atc routes with separate priorities. Since the introduction of the new router in Kong Gateway 3.0, traditional_compat mode assigned only one priority to each route, even if different prefix path lengths and regular expressions were mixed in a route. This was not how multiple paths were handled in the traditional router and the behavior has now been changed so that a separate priority value is assigned to each path in a route.

Upgrading Kong Gateway after adopting PostgreSQL 15

PostgreSQL 15 enforces different permissions on the public schema than prior versions of PostgreSQL. This requires an extra step to grant the correct permissions to the Kong user to make schema changes.

You can grant the permissions in one of two ways:

• Assign the Kong database owner to Kong by running ALTER DATABASE kong OWNER TO kong.
• Temporarily give the Kong user the ability to modify the public schema and then revoke that permission. This option is more restrictive and is a two-part process:
  1. Before you run the bootstrap migration commands, grant the right to modify the schema with GRANT CREATE ON SCHEMA public TO kong.
  2. After the migrations are done, remove this permission by running REVOKE CREATE ON SCHEMA public FROM kong.