Breaking changes in the 3.0.0.0 release.
If you are adding a new plugin to your installation, you need to run
kong migrations up
with the plugin name specified. For example,
KONG_PLUGINS=tls-handshake-modifier
.
The 3.0 release includes the following new plugins:
Kong plugins no longer support CREDENTIAL_USERNAME
(X-Credential-Username
).
Use the constant CREDENTIAL_IDENTIFIER
(X-Credential-Identifier
) when
setting the upstream headers for a credential.
Amazon Linux 1 and Debian 8 (Jessie) containers and packages are deprecated and are no longer produced for new versions of Kong Gateway.
Traditional mode: Blue-green upgrades from versions of 2.8.1 and below to 3.0.0 are not currently supported.
This is a known issue planned to be fixed in the next 2.8 release. When that version is released, 2.x users should upgrade to that version before beginning a blue-green upgrade to 3.0.
Hybrid mode: See the upgrade instructions below.
If you are using the provided binary packages (except Debian and RHEL), all necessary dependencies
for the gateway are bundled and you can skip this section.
As of Kong Gateway 3.0, Debian and RHEL images are built with minimal dependencies and run through automated security scanners before being published.
They only contain the bare minimum required to run Kong Gateway.
If you would like further customize the base image and any dependencies, you can
build your own Docker images.
If you are using Debian, RHEL, or building your dependencies by hand, there are changes since the
previous release, so you will need to rebuild them with the latest patches.
The required OpenResty version for Kong Gateway 3.0.x is
1.21.4.1. In addition to an upgraded
OpenResty, you need the correct OpenResty patches
for this new version, including the latest release of lua-kong-nginx-module.
The kong-build-tools
repository contains openresty-build-tools,
which allows you to more easily build OpenResty with the necessary patches and modules.
The migration helper library (mostly used for Cassandra migrations) is no longer supplied with Kong Gateway.
PostgreSQL migrations can now have an up_f
part like Cassandra
migrations, designating a function to call. The up_f
part is
invoked after the up
part has been executed against the database
for both PostgreSQL and Cassandra.
The StatsD Advanced plugin has been deprecated and will be removed in 4.0.
All capabilities are now available in the StatsD plugin.
The following plugins have had configuration parameters changed or removed. You will need to carefully review and update your configuration as needed:
ACL, Bot Detection, and IP Restriction
- Removed the deprecated
blacklist
and whitelist
configuration parameters. Use allow
or deny
instead.
ACME
- The default value of the
auth_method
configuration parameter is now token
.
AWS Lambda
- The AWS region is now required. You can set it through the plugin configuration with the
aws_region
field parameter, or with environment variables.
- The plugin now allows
host
and aws_region
fields to be set at the same time, and always applies the SigV4 signature.
HTTP Log
- The
headers
field now only takes a single string per header name,
where it previously took an array of values.
JWT
- The authenticated JWT is no longer put into the nginx
context (
ngx.ctx.authenticated_jwt_token
). Custom plugins which depend on that
value being set under that name must be updated to use Kong’s shared context
instead (kong.ctx.shared.authenticated_jwt_token
) before upgrading to 3.0.
Prometheus
Pre-function and Post-function plugins
- Removed the deprecated
config.functions
configuration parameter from the
post-function
and pre-function
plugins’ schemas. Use the config.access
phase instead.
StatsD
- Any metric name that is related to a Gateway Service now has a
service.
prefix: kong.service.<service_identifier>.request.count
.
- The metric
kong.<service_identifier>.request.status.<status>
has been renamed to kong.service.<service_identifier>.status.<status>
.
- The metric
kong.<service_identifier>.user.<consumer_identifier>.request.status.<status>
has been renamed to kong.service.<service_identifier>.user.<consumer_identifier>.status.<status>
.
- The metric
*.status.<status>.total
from metrics status_count
and status_count_per_user
has been removed.
Proxy Cache, Proxy Cache Advanced, and GraphQL Proxy Cache Advanced
- These plugins don’t store response data in
ngx.ctx.proxy_cache_hit
anymore.
- Logging plugins that need the response data must now read it from
kong.ctx.shared.proxy_cache_hit
.
- DAOs in plugins must be listed in an array, so that their loading order is explicit. Loading them in a
hash-like table is no longer supported.
- Plugins MUST now have a valid
PRIORITY
(integer) and VERSION
(“x.y.z” format)
field in their handler.lua
file, otherwise the plugin will fail to load.
- The old
kong.plugins.log-serializers.basic
library was removed in favor of the PDK
function kong.log.serialize
. Upgrade your plugins to use the PDK.
-
The support for deprecated legacy plugin schemas was removed. If your custom plugins
still use the old (0.x era
) schemas, you are now forced to upgrade them.
-
Updated the priority for some plugins.
This is important for those who run custom plugins as it may affect the sequence in which your plugins are executed.
This does not change the order of execution for plugins in a standard Kong Gateway installation.
Old and new plugin priority values:
-
acme
changed from 1007
to 1705
-
basic-auth
changed from 1001
to 1100
-
canary
changed from 13
to 20
-
degraphql
changed from 1005
to 1500
-
graphql-proxy-cache-advanced
changed from 100
to 99
-
hmac-auth
changed from 1000
to 1030
-
jwt
changed from 1005
to 1450
-
jwt-signer
changed from 999
to 1020
.
-
key-auth
changed from 1003
to 1250
-
key-auth-advanced
changed from 1003
to 1250
-
ldap-auth
changed from 1002
to 1200
-
ldap-auth-advanced
changed from 1002
to 1200
-
mtls-auth
changed from 1006
to 1600
-
oauth2
changed from 1004
to 1400
-
openid-connect
changed from 1000
to 1050
-
rate-limiting
changed from 901
to 910
-
rate-limiting-advanced
changed from 902
to 910
-
route-by-header
changed from 2000
to 850
-
route-transformer-advanced
changed from 800
to 780
-
pre-function
changed from +inf
to 1000000
-
vault-auth
change from 1003
to 1350
-
The kong.request.get_path()
PDK function now performs path normalization
on the string that is returned to the caller. The raw, non-normalized version
of the request path can be fetched via kong.request.get_raw_path()
.
-
pdk.response.set_header()
, pdk.response.set_headers()
, pdk.response.exit()
now ignore and emit warnings for manually set Transfer-Encoding
headers.
-
The PDK is no longer versioned.
-
The JavaScript PDK now returns Uint8Array
for kong.request.getRawBody
,
kong.response.getRawBody
, and kong.service.response.getRawBody
.
The Python PDK returns bytes
for kong.request.get_raw_body
,
kong.response.get_raw_body
, and kong.service.response.get_raw_body
.
Previously, these functions returned strings.
-
The go_pluginserver_exe
and go_plugins_dir
directives are no longer supported.
If you are using
Go plugin server, migrate your plugins to use the
Go PDK before upgrading.
-
As of 3.0, Kong Gateway’s schema library’s process_auto_fields
function will not make deep
copies of data that is passed to it when the given context is select
. This was
done to avoid excessive deep copying of tables where Kong believes the data most of
the time comes from a driver like pgmoon
or lmdb
.
If a custom plugin relied on process_auto_fields
not overriding the given table, it must make its own copy
before passing it to the function now.
-
The deprecated shorthands
field in Kong plugin or DAO schemas was removed in favor
of the typed shorthand_fields
. If your custom schemas still use shorthands
, you
need to update them to use shorthand_fields
.
-
The support for legacy = true/false
attribute was removed from Kong schemas and
Kong field schemas.
- The Kong singletons module
kong.singletons
was removed in favor of the PDK kong.*
.
Kong Gateway no longer uses a heuristic to guess whether a route.path
is a regex pattern. From 3.0 onward,
all regex paths must start with the "~"
prefix, and all paths that don’t start with "~"
will be considered plain text.
The migration process should automatically convert the regex paths when upgrading from 2.x to 3.0.
The normalization rules for route.path
have changed. Kong Gateway now stores the unnormalized path, but
the regex path always pattern-matches with the normalized URI. Previously, Kong Gateway replaced percent-encoding
in the regex path pattern to ensure different forms of URI matches.
That is no longer supported. Except for the reserved characters defined in
rfc3986,
write all other characters without percent-encoding.
The version number (_format_version
) of declarative configuration has been bumped to 3.0
for changes on route.path
.
Declarative configurations with older versions will be upgraded to 3.0
during migrations.
Do not sync (deck gateway sync
) declarative configuration files from 2.8 or earlier to 3.0.
Old configuration files will overwrite the configuration and create compatibility issues.
To grab the updated configuration, deck gateway dump
the 3.0 file after migrations are completed.
It is no longer possible to use the .lua
format to import a declarative configuration file from the kong
CLI tool. Only JSON and YAML formats are supported. If your update procedure with Kong Gateway involves
executing kong config db_import config.lua
, convert the config.lua
file into a config.json
or config.yml
file
before upgrading.
The Admin API endpoint /vitals/reports
has been removed.
POST
requests on /targets
endpoints are no longer able to update
existing entities. They are only able to create new ones.
If you have scripts that use POST
requests to modify /targets
, change them to PUT
requests to the appropriate endpoints before updating to Kong 3.0.
The list of reported plugins available on the server now returns a table of
metadata per plugin instead of a boolean true
.
The Kong constant CREDENTIAL_USERNAME
with the value of X-Credential-Username
has been
removed.
The default value of lua_ssl_trusted_certificate
has changed to system
to automatically load the trusted CA list from the system CA store.
The data plane config cache mechanism and its related configuration options
(data_plane_config_cache_mode
and data_plane_config_cache_path
) have been removed in favor of LMDB.
ngx.ctx.balancer_address
was removed in favor of ngx.ctx.balancer_data
.
The Helm chart automates the upgrade migration process. When running helm upgrade
,
the chart spawns an initial job to run kong migrations up
and then spawns new
Kong pods with the updated version. Once these pods become ready, they begin processing
traffic and old pods are terminated. Once this is complete, the chart spawns another job
to run kong migrations finish
.
While the migrations themselves are automated, the chart does not automatically ensure
that you follow the recommended upgrade path. If you are upgrading from more than one minor
Kong Gateway version back, check the upgrade path recommendations.
Although not required, users should upgrade their chart version and Kong Gateway version independently.
In the event of any issues, this will help clarify whether the issue stems from changes in
Kubernetes resources or changes in Kong Gateway.
For specific Kong for Kubernetes version upgrade considerations, see
Upgrade considerations
The standard chart upgrade automation process assumes that there is only a single Kong Gateway release
in the Kong Gateway cluster, and runs both migrations up
and migrations finish
jobs.
If you split your Kong Gateway deployment across multiple Helm releases (to create proxy-only
and admin-only nodes, for example), you must set which migration jobs run based on your
upgrade order.
To handle clusters split across multiple releases, you should:
-
Upgrade one of the releases with:
helm upgrade RELEASENAME -f values.yaml \
--set migrations.preUpgrade=true \
--set migrations.postUpgrade=false
-
Upgrade all but one of the remaining releases with:
helm upgrade RELEASENAME -f values.yaml \
--set migrations.preUpgrade=false \
--set migrations.postUpgrade=false
-
Upgrade the final release with:
helm upgrade RELEASENAME -f values.yaml \
--set migrations.preUpgrade=false \
--set migrations.postUpgrade=true
This ensures that all instances are using the new Kong Gateway package before running
kong migrations finish
.
Important: If you are currently running in hybrid mode,
upgrade the control plane first, and then the data planes.
- If you are currently running 2.8.x in classic (traditional)
mode and want to run in hybrid mode instead, follow the hybrid mode
installation instructions
after running the migration.
- Custom plugins (either your own plugins or third-party plugins that are not shipped with Kong Gateway)
need to be installed on both the control plane and the data planes in hybrid mode. Install the
plugins on the control plane first, and then the data planes.
- The Rate Limiting Advanced plugin does not
support the
cluster
strategy in hybrid mode. The redis
strategy must be used instead.
There are changes in the Nginx configuration file between every minor and major
version of Kong Gateway starting with 2.0.x.
In 3.0.x, the deprecated alias of Kong.serve_admin_api
was removed.
If your custom Nginx templates still use it, change it to Kong.admin_content
.
To view all of the configuration changes between versions, clone the
Kong repository and run git diff
on the configuration templates, using -w
for greater readability.
Here’s how to see the differences between previous versions and 3.0.x:
git clone https://github.com/kong/kong
cd kong
git diff -w 2.0.0 3.0.0 kong/templates/nginx_kong*.lua
Adjust the starting version number (2.0.0 in the example) to the version number you are currently using.
To produce a patch file, use the following command:
git diff 2.0.0 3.0.0 kong/templates/nginx_kong*.lua > kong_config_changes.diff
Adjust the starting version number to the version number (2.0.0 in the example) you are currently using.
The default template for Kong Gateway can be found using this command
on the system running your Kong Gateway instance:
find / -type d -name "templates" | grep kong
.
When upgrading, make sure to run this command on both the old and new clusters,
diff the files to identify any changes, and apply them as needed.