このページは、まだ日本語ではご利用いただけません。翻訳中です。
旧バージョンのドキュメントを参照しています。 最新のドキュメントはこちらをご参照ください。
Kong Enterprise LTS 2.8 to 3.4 upgrade guide
Kong Gateway supports direct upgrades between long-term support (LTS) versions of Kong Gateway Enterprise.
This guide walks you through upgrading from Kong Gateway Enterprise 2.8 LTS to Kong Gateway Enterprise 3.4 LTS, specifically covering 2.8.0.0-2.8.4.1 up to 3.4.0.0. Carefully review each entry and make changes to your configuration accordingly.
There are three upgrade strategies available for the LTS to LTS upgrade. This guide nominates the best applicable strategy for each deployment mode that Kong Gateway supports. Additionally, it lists some fundamental factors that play important roles in the upgrade process, and explains how to back up and recover data.
This guide uses the following terms in the context of Kong Gateway:
- Upgrade: The overall process of switching from an older to a newer version of Kong Gateway.
- Migration: The migration of your data store data into a new environment. For example, the process of moving 2.8 data from an old PostgreSQL instance to a new one for 3.4 is referred to as database migration.
To make sure your upgrade is successful, carefully review all the steps in this guide. It’s very important to understand all the preparation steps and choose the recommended upgrade path based on your deployment type.
Caution: The migration pattern described in this document can only happen between two LTS versions, Kong Gateway Enterprise 2.8 LTS and Kong Gateway Enterprise 3.4 LTS. If you apply this document to other release intervals, database modifications may be run in the wrong sequence and leave the database schema in a broken state. To migrate between other versions, see the general upgrade guide.
Prerequisites
- Starting from 3.4, Cassandra is not supported. If you’re using Cassandra as your data store, migrate off of Cassandra first and upgrade second.
- Review version compatibility between your platform version and the version of that you are upgrading to:
- Review KIC upgrade compatibility.
- If you’re using decK, upgrade it to the latest version.
Read this document thoroughly to successfully complete the upgrade process, as it includes all the necessary operational knowledge for the upgrade.
Upgrade journey overview
Preparation phase
There are a number of steps you must complete before upgrading to Kong Gateway 3.4 LTS:
- Work through any listed prerequisites.
- Back up your database or your declarative configuration files.
- Choose the right strategy for upgrading based on your deployment topology.
- Review the Kong Gateway changes from 2.8 to 3.4 for any breaking changes that affect your deployments.
- Conduct a thorough examination of the modifications made to the
kong.conf
file between the LTS releases. - Using your chosen strategy, test migration in a pre-production environment.
Performing the upgrade
The actual execution of the migration is dependent on the type of deployment you have with Kong Gateway. In this part of the upgrade journey, you will use the strategy you determined during the preparation phase.
- Execute your chosen upgrade strategy on dev.
- Move from dev to prod.
- Smoke test.
- Wrap up the upgrade or roll back and try again.
Now, let’s move on to preparation, starting with your backup options.
Preparation: Choose a backup strategy
The kong migrations
commands used during upgrade and database migration are not reversible.
Always back up your database or declarative configuration files before an upgrade.
There are two main types of backup for Kong Gateway entities:
- Database backup: PostgreSQL has native exporting and importing tools that are reliable and performant, and that ensure consistency when backing up or restoring data. If you’re running Kong Gateway in traditional or hybrid mode, you should always take a database-native backup.
- Declarative backup: Kong ships two declarative backup tools: decK and the Kong CLI, which support managing Kong Gateway entities in the declarative format. For traditional and hybrid mode deployments, use these tools to create secondary backups. For DB-less mode deployments, use the Kong CLI and manually manage declarative configuration files.
We highly recommend backing up your data using both methods if possible, as this offers you recovery flexibility.
The database-native tools are robust and can restore data instantly compared to the declarative tools. In case of data corruption, try to do a database-level restore first. Otherwise, bootstrap a new database and use declarative tools to restore configuration from backup files.
Review the Backup and Restore guide to prepare backups of your configuration. If you run into any issues and need to roll back, you can also reference that guide to restore your old data store.
Preparation: Choose an upgrade strategy based on deployment mode
Upgrade strategies introduced in this section are generic and may or may not fit in with your deployment environment.
Choose your deployment mode:
Here’s a flowchart that breaks down how the decision process works:
flowchart TD A{Deployment type?} --> B(Traditional mode) A{Deployment type?} --> C(Hybrid mode) A{Deployment type?} --> D(DB-less mode) A{Deployment type?} --> E(Konnect DP) B ---> F{Enough hardware to run another cluster?} C --> G(Upgrade CP first) & H(Upgrade DP second) D ----> K([Rolling upgrade]) E ----> K G --> F F ---Yes--->I([Dual-cluster upgrade]) F ---No--->J([In-place upgrade]) H ---> K click K "/gateway/latest/upgrade/rolling-upgrade/" click I "/gateway/latest/upgrade/dual-cluster/" click J "/gateway/latest/upgrade/in-place/"
Figure 1: Choose an upgrade strategy based on your deployment type. For traditional mode, choose a dual-cluster upgrade if you have enough resources, or an in-place upgrade if you don’t have enough resources. For DB-less mode and Konnect DPs, use a rolling upgrade. For hybrid mode, use one of the traditional mode strategies for CPs, and the rolling upgrade for DPs.
See the following sections for breakdowns of each strategy.
Traditional mode
A traditional mode deployment is when all Kong Gateway components are running in one environment, and there is no control plane/data plane separation.
You have two options when upgrading Kong Gateway in traditional mode:
- Dual-cluster upgrade: A new Kong Gateway cluster of version Y is deployed alongside the current version X, so that two clusters serve requests concurrently during the upgrade process.
- In-place upgrade: An in-place upgrade reuses the existing database and has to shut down cluster X first, then configure the new cluster Y to point to the database.
We recommend using a dual-cluster upgrade if you have the resources to run another cluster concurrently. Use the in-place method only if resources are limited, as it will cause business downtime.
Dual-cluster upgrade
Upgrading Kong Gateway from one LTS version to another LTS version with zero downtime can be achieved through a dual-cluster upgrade strategy. This approach involves setting up a new cluster running the upgraded version of Kong Gateway alongside the existing cluster running the current version.
At a high level, the process typically involves the following steps:
-
Provisioning a same-size deployment: You need to ensure that the new cluster, which will run the upgraded version of Kong Gateway, has the same capacity and resources as the existing cluster. This ensures that both clusters can handle the same amount of traffic and workload.
-
Setting up dual-cluster deployment: Once the new cluster is provisioned, you can start deploying your APIs and configurations to both clusters simultaneously. The dual cluster deployment allows both the old and new clusters to coexist and process requests in parallel.
-
Data synchronization: During the dual cluster deployment, data synchronization is crucial to ensure that both clusters have the same data. This can involve migrating data from the old cluster to the new one or setting up a shared data storage solution to keep both clusters in sync. Import the database from the old cluster to the new cluster by using a snapshot or
pg_restore
. -
Traffic rerouting: As the new cluster is running alongside the old one, you can start gradually routing incoming traffic to the new cluster. This process can be done gradually or through a controlled switchover mechanism to minimize any impact on users. This can be achieved by any load balancer, like DNS, Nginx, F5, or even a Kong Gateway node with Canary plugin enabled.
-
Testing and validation: Before performing a complete switchover to the new cluster, it is essential to thoroughly test and validate the functionality of the upgraded version. This includes testing APIs, plugins, authentication mechanisms, and other functionalities to ensure they are working as expected.
-
Complete switchover: Once you are confident that the upgraded cluster is fully functional and stable, you can redirect all incoming traffic to the new cluster. This step completes the upgrade process and decommissions the old cluster.
By following this dual cluster deployment strategy, you can achieve a smooth and zero-downtime upgrade from one LTS version of Kong Gateway to another. This approach helps ensure high availability and uninterrupted service for your users throughout the upgrade process.
In-place upgrade
While an in-place upgrade allows you to perform the upgrade on the same infrastructure, it does require some downtime during the actual upgrade process. Plan a suitable maintenance or downtime window during which you can perform the upgrade. During this period, the Kong Gateway will be temporarily unavailable.
For scenarios where zero downtime is critical, consider the dual-cluster upgrade method, keeping in mind the additional resources and complexities.
DB-less mode
In DB-less mode, each independent Kong Gateway node loads a copy of declarative Kong Gateway configuration data into memory without persistent database storage, so failure of some nodes doesn’t spread to other nodes.
Deployments in this mode should use the rolling upgrade strategy.
You could parse the validity of the declarative YAML contents with version Y, using the deck gateway validate
or the kong config parse
command.
You must back up your current kong.yaml
file before starting the upgrade.
Hybrid mode
Hybrid mode comprises of one or more control plane (CP) nodes, and one or more data plane (DP) nodes. CP nodes use a database to store Kong configuration data, whereas DP nodes don’t, since they get all of the needed information from the CP. The recommended upgrade process is a combination of different upgrade strategies for each type of node, CP or DP.
The major challenge with a hybrid mode upgrade is the communication between the CP and DP. As hybrid mode requires the minor version of the CP to be no less than that of the DP, you must upgrade CP nodes before DP nodes. The upgrade must be carried out in two phases:
- First, upgrade the CP according to the recommendations in the section Traditional Mode, while DP nodes are still serving API requests.
- Next, upgrade DP nodes using the recommendations from the section DB-less Mode. Point the new DP nodes to the new CP to avoid version conflicts.
The role decoupling feature between CP and DP enables DP nodes to serve API requests while upgrading CP. With this method, there is no business downtime.
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.
See the following sections for a breakdown of the options for hybrid mode deployments.
Control planes
CP nodes must be upgraded before DP nodes. CP nodes serve an admin-only role and require database support. So, you can select from the same upgrade strategies nominated for traditional mode (dual-cluster or in-place), as described in figure 2 and figure 3 respectively.
Upgrading the CP nodes using the dual-cluster strategy:
flowchart TD DBA[(Current database)] DBB[(New database)] CPX(Current control plane X) Admin(No admin write operations) CPY(New control plane Y) DPX(fa:fa-layer-group Current data plane X nodes) API(API requests) DBA -.- CPX -."DP connects to either \nCP X...".- DPX Admin -.X.- CPX & CPY DBB --pg_restore--- CPY -."...OR to CP Y".- DPX API--> DPX style API stroke:none style DBA stroke-dasharray:3 style CPX stroke-dasharray:3 style Admin fill:none,stroke:none,color:#d44324 linkStyle 2,3 stroke:#d44324,color:#d44324
Figure 2: The diagram shows a CP upgrade using the dual-cluster strategy. The new CP Y is deployed alongside the current CP X, while current DP nodes X are still serving API requests.
Upgrading the CP nodes using the in-place strategy:
flowchart DBA[(Database)] CPX(Current control plane X \n #40;inactive#41;) Admin(No admin \n write operations) CPY(New control plane Y) DPX(fa:fa-layer-group Current data plane X nodes) API(API requests) DBA -..- CPX -."DP connects to either \nCP X...".- DPX Admin -.X.- CPX & CPY DBA --"kong migrations up \n kong migrations finish"--- CPY -."...OR to CP Y".- DPX API--> DPX style API stroke:none style CPX stroke-dasharray:3 style Admin fill:none,stroke:none,color:#d44324 linkStyle 2,3 stroke:#d44324,color:#d44324
Figure 3: The diagram shows a CP upgrade using the in-place strategy, where the current CP X is directly replaced by a new CP Y. The database is reused by the new CP Y, and the current CP X is shut down once all nodes are migrated.
From the two figures, you can see that DP nodes X remain connected to the current CP node X, or alternatively switch to the new CP node Y. Kong Gateway guarantees that new minor versions of CPs are compatible with old minor versions of the DP, so you can temporarily point DP nodes X to the new CP node Y. This lets you pause the upgrade process if needed, or conduct it over a longer period of time.
This setup is meant to be temporary, to be used only during the upgrade process. We do not recommend running a combination of new versions of CP nodes and old versions of DP nodes in a long-term production deployment.
After the CP upgrade, cluster X can be decommissioned. You can delay this task to the very end of the DP upgrade.
Data planes
Once the CP nodes are upgraded, you can move on to upgrade the DP nodes. The only supported upgrade strategy for DP upgrades is the rolling upgrade. The following diagrams, figure 4 and 5, are the counterparts of figure 2 and 3 respectively.
Using the dual-cluster strategy with a rolling upgrade workflow:
flowchart TD DBX[(Current \n database)] DBY[(New \n database)] CPX(Current control plane X) CPY(New control plane Y) DPX(Current data planes X) DPY(New data planes Y) API(API requests) LB(Load balancer) Admin(No admin \n write operations) Admin2(No admin \n write operations) subgraph A Admin -.X.- CPX DBX -.- CPX DBY --- CPY CPX -."Current DP connects to \neither CP X...".- DPX Admin2 -.X.- CPY CPY -."...OR to CP Y".- DPX DPX -.90%..- LB CPY --- DPY --10%---- LB end subgraph B API --> LB & LB & LB end linkStyle 0,4 stroke:#d44324,color:#d44324 linkStyle 8,9 stroke:#b6d7a8 style CPX stroke-dasharray:3,fill:#eff0f1ff,stroke:#c1c6cdff style DPX stroke-dasharray:3 style DBX stroke-dasharray:3,fill:#eff0f1ff,stroke:#c1c6cdff style API stroke:none style A stroke:none,color:#fff style B stroke:none,color:#fff style Admin fill:none,stroke:none,color:#d44324 style Admin2 fill:none,stroke:none,color:#d44324
Figure 4: The diagram shows a DP upgrade using the dual-cluster and rolling strategies. The new CP Y is deployed alongside with the current CP X, while current DP nodes X are still serving API requests. In the image, the background color of the current database and CP X is grey instead of white, signaling that the old CP is already upgraded and might have been decommissioned.
Using the in-place strategy strategy with a rolling upgrade workflow:
flowchart DBA[(Database)] CPX(Current control plane X \n #40;inactive#41;) CPY(New control plane Y) DPX(Current data planes X) DPY(New data planes Y) API(API requests) LB(Load balancer) Admin(No admin \n write operations) Admin2(No admin \n write operations) subgraph A Admin -.X.- CPX DBA -.X.- CPX DBA --- CPY CPX -."Current DP connects to \neither CP X...".- DPX Admin2 -.X.- CPY CPY -."OR to CP Y".- DPX -.90%..- LB CPY --- DPY --10%---- LB end subgraph B API --> LB & LB & LB end linkStyle 0,1,4 stroke:#d44324,color:#d44324 linkStyle 8,9 stroke:#b6d7a8 style CPX stroke-dasharray:3,fill:#eff0f1ff,stroke:#c1c6cdff style DPX stroke-dasharray:3 style A stroke:none,color:#fff style B stroke:none,color:#fff style Admin fill:none,stroke:none,color:#d44324 style Admin2 fill:none,stroke:none,color:#d44324
Figure 5: The diagram shows a DP upgrade using the in-place and rolling strategies. The diagram shows that the database is reused by the new CP Y, while current DP nodes X are still serving API requests.
Preparation: Review gateway changes
The following tables categorize all relevant changelog entries from Kong Gateway Enterprise 2.8.0.0-2.8.4.1 up to 3.4.0.0. Carefully review each entry and make changes to your configuration accordingly.
新機能
次の表に、3.xリリースで導入された新機能を示します。 これらの機能は、既存の構成に影響を与える可能性があります。
変更 | カテゴリー | アクションが必要です |
---|---|---|
Request Validatorプラグイン Request Validatorプラグインは、パラメータ付きの 「content-type」を持つリクエストが、パラメータなしの「content-type」とマッチすることを許可するようになりました。 |
プラグイン |
いいえ |
データプレーン(DP)構成キャッシュが削除されました。 構成の永続化は、LMDB によって自動的に実行されるようになりました。 データプレーン(DP)の設定キャッシュメカニズムとそれに関連する設定任意 (data_plane_config_cache_modeとdata_plane_config_cache_path) は削除され、LMDBが優先されました。 |
DB設定 |
Kong構成からパラメーターを削除します。 |
route.pathの変更に合わせて、宣言型構成のバージョン番号を 3.0 に上げました。 古いバージョンを使用した宣言型構成は、移行中に 3.0 にアップグレードされます。 |
DB設定 |
もし設定が(GitOps モデルに従って)リポジトリに保存されているなら、deck convert を使ってアップグレードする必要があります、これらはdeck convert を使ってアップグレードする必要があります。 |
タグにスペースを含めることができるようになりました。 |
DB設定 |
いいえ |
lua_ssl_trusted_certificateのデフォルト値がsystemに変更され、システムCAストアから 信頼済みCAリストを自動的にロードするようになりました。 |
kong.conf |
このフィールドを明示的に構成していない場合は、サーバー上のすべての証明書を自動的に取り込むという 新しいデフォルト値の動作が、デプロイメントに適していることをご確認ください。それ以外の場合は、設定を調整します。 |
流量制限、Rate Limiting Advanced、およびResponse Rate Limitingプラグイン。 これらのプラグインのデフォルトポリシーは、すべてのデプロイモードで localになりました。 |
プラグイン |
いいえ |
プラグインのバッチキューイング HTTPログ、StatsD、OpenTelemetry、Datadogプラグイン。 キューイングシステムが作り直され、いくつかのプラグインパラメータが期待通りに機能しなくなりました。 |
プラグイン |
これらのプラグインでキューを使用する場合は、新しいパラメータを構成する必要があります。 詳細については、各プラグインのドキュメントをご参照ください。 モジュール kong.tools.batch_queueがkong.tools.batch に変更され、APIが変更されました。 カスタムプラグインがキューを使用している場合は、新しいパラメータを使用するように更新する必要があります。 |
OpenSSL 3.2では、デフォルトのSSL/TLSセキュリティレベルが1から2に変更されました。 これは、セキュリティレベルが112ビットに設定されることを意味します。 その結果、以下の行為は禁止されます。
|
OpenSSL |
構成が新しいセキュリティレベル要件に準拠していることを確認します。 |
削除または非推奨
次の表の機能は、完全に削除されました。 以下の表に基づいて設定を更新することで、 非推奨のエイリアスを使用することで発生する可能性のある問題を回避し、Kongインスタンスが最新の変更と改善で正しく機能するようにすることができます。
システムの安定性、セキュリティ、最適なパフォーマンスを維持するためには、 コンフィギュレーションを常に最新の状態に保つことが不可欠です。
変更 | カテゴリー | アクションが必要です |
---|---|---|
Deprecated and stopped producing Debian 8 (Jessie) and Debian 10 (Buster) containers and packages. |
デプロイメント |
Debian 11 and 12 are available. Upgrade to one of these versions before upgrading to Kong 3.4. |
Amazon Linux 1のコンテナとパッケージは非推奨となり、製造が中止された。 |
デプロイメント |
AWSからのアップデート、セキュリティパッチ、サポートを継続的に受けるために、 Amazon Linux 2またはサポートされている他のオペレーティングシステムに移行することをお勧めします。 |
非推奨となり、Alpine Linuxのイメージとパッケージの生産を停止しました。 便利なDockerタグの基礎となるオペレーティングシステム(OS)
(例えば、 |
デプロイメント |
OS 固有の構成についてDockerfileを確認し、必要に応じて調整します。 便利なイメージのいずれかを使用している場合は、Ubuntu用に設定を調整してください。 そうでない場合は、特定のOSタグ (例えば3.4.0.0-debian)を使ったイメージに切り替えてください。 |
Ubuntu 18.04 (「Bionic」) の標準サポートが2023年6月をもって終了したため、 Ubuntu 18.04 (「Bionic」) パッケージを非推奨とし、生産を停止しました。 |
デプロイメント |
Ubuntu 20.04 および 22.04 が利用可能です。Kong 3.4 にアップグレードする前に、これらのバージョンのいずれかにアップグレードしてください。 |
KongプラグインやDAOスキーマの 非推奨のshorthandsフィールドは削除されました。 |
プラグイン |
カスタムスキーマでまだ「shorthands」を使用している場合は、「shorthand_fields」を 使用するように更新する必要があります。このアップデートは Kongの最新バージョンとの互換性を確保するために必要です。 |
Kongスキーマと Kongフィールドスキーマから「legacy = true | false」属性のサポートが削除されました。 |
スキーマ内でlegacy属性は使用できなくなりました。 カスタムスキーマの中で「legacy=true | false」を参照している場合は、 「legacy」属性なしで最新のスキーマ仕様に適合するように更新する必要があります。 |
|
Kong.serve_admin_apiの非推奨のエイリアスが削除されました。 |
Nginxテンプレート |
Nginxのカスタムテンプレートでエイリアスを使用している場合は、「Kong.admin_content」に変更してください。 |
Kongシングルトモジュールkong.singletonsPDK ‘kong.*’ を支持して削除されました。 |
PDK |
「kong.singletons」を削除します。モジュールの代わりにkongグローバル変数を使用してください。 例:’singletons.db.daos’ -> ‘kong.db.daos’ |
ngx.ctx.balancer_address は削除され、 ngx.ctx.balancer_dataが採用されました。 |
トレース |
以前に ngx.ctx.balancer_address を使用していた場合、代わりに「ngx.ctx.balancer_data」を使用してください。 |
「route.path」の正規化ルールが変更となりました。 Kong Gatewayは正規化されていないパスを保存しますが、正規表現パスは常に 正規化されたURIとパターンマッチします。 以前、Kong Gatewayは、異なる形式のURIマッチを確実にするために、 正規表現パスパターンでパーセントエンコーディングを置き換えていました。これはサポートされなくなりました。 RFC 3986で定義されている予約文字を除き、 その他のすべての文字はパーセントエンコードなしで書き込みます。 |
ルーター |
アップグレード後、 古い方法でルートを設定するとアラートが表示され、 新しいルート設定方法で影響を受けるルートを再設定する必要があります。 |
Kong Gateway は、ルートパスが正規表現パターンであるかどうかを推測するためにヒューリスティックを使用しなくなりました。 3.0以降では、 すべての正規表現パスは接頭辞「~」で始まる必要があり、「~」で始まらないパスはすべてプレーンテキストとみなされます。 |
ルーター |
手動での移行は必要ありません。 2.8から3.4にアップグレードすると、移行プロセスで正規表現パスが自動的に変換されるはずです。 今後、正規表現を記述するときは、「~」記号で始める必要があります。 |
nginx-opentracingモジュールのサポートは 3.0 で非推奨となり、Kong 4.0 では削除される予定です。 |
いいえ |
|
Admin API エンドポイント「/vitals/reports」と「/vitals/reports/:entity_type」が削除されました。 |
Admin API |
アップグレード後は、代わりに Vitals API の次のいずれかのエンドポイントを使用します。
|
「/targets」エンドポイントのPOSTリクエストでは、既存のエンティティを更新できなくなりました。 新しいものを作ることしかできません。 |
Admin API |
POSTリクエストを使って「/targets」を変更するスクリプトがある場合は、Kong Gateway 3.4にアップデートする前に、 適切なエンドポイントへのPUTリクエストに変更してください。 |
‘kong.request.get_path()’PDK 関数は、呼び出し元に返される文字列に対してパスの正規化を実行するようになりました。 リクエストパスの生の非正規化バージョンは、 kong.request.get_raw_path() を介して取得できます。 |
PDK |
いいえ |
|
PDK |
いいえ |
「go_pluginserver_exe」ディレクティブと「go_plugins_dir」ディレクティブはサポートされなくなりました。 |
Go PDK |
Goプラグインサーバーを使用している場合は、アップグレードする前にプラグインを移行してGo PDKを使用するようにしてください。 |
X-Credential-Usernameの値を持つ Kong 定数CREDENTIAL_USERNAMEが削除されました。 Kongプラグインもこの定数をサポートしていません。 |
プラグイン |
認証情報のアップストリームヘッダを設定する際には、定数 |
KongのCLIツールで |
宣言型構成 |
Kong Gatewayのアップデート手順に「Kong config db_import config.lua」の実行が含まれる場合は、アップグレードする前にconfig.luaのファイルを「config.json」または「config.yml」ファイルに変換します。 |
プラグイン内の DAO は、読み込み順序が明示的になるように配列にリストする必要があります。 ハッシュのようなテーブルにそれらをロードすることはサポートされなくなりました。 |
プラグイン |
カスタムプラグインを確認します。DAOをリストするためにハッシュのようなテーブルを使うプラグインがある場合、それらを配列に変換しましょう。 |
プラグインは「handler.lua」に有効な PRIORITY (整数) と VERSION ( |
プラグイン |
カスタムプラグインを確認します。すべてのカスタムプラグインに、それぞれの形式で PRIORITY と VERSION を追加します。 |
‘kong.plugins.log-serializers.basic’ ライブラリは削除され、代わりに PDK 関数kong.log.serializeが導入されました。 |
PDK |
新しいPDK機能を使用するには、プラグインをアップグレードしてください。 |
非推奨のレガシープラグインスキーマのサポートは削除されました。 |
プラグイン |
カスタムプラグインがまだ古い(0.x era)スキーマを使用している場合は、それらをアップグレードする必要があります。 |
一部のプラグインの優先度を更新しました。 プラグインが実行される順序に影響する可能性があるため、カスタムプラグインを実行する人にとって重要です。 これにより、標準の Kong Gateway インストールにおけるプラグインの実行順序は変更されません。 新旧のプラグイン優先度の値:
|
プラグイン |
カスタムプラグインの優先順位を確認します。 優先順位を変更した結果、期待された動作が損なわれた場合は、必要に応じて調整します。 |
JWT プラグイン 認証された JWT は、Nginx コンテキスト (ngx.ctx.authenticated_jwt_token) に配置されなくなりました。 |
プラグイン |
この名前で設定された値に依存しているカスタムプラグインは、3.4 にアップグレードする前に代わりにKongの共有コンテキスト
( |
JWTプラグイン (jwt) JWTプラグインは、 JWTトークンの検索場所に異なるトークンがあるリクエストを拒否するようになりました。 |
プラグイン |
いいえ |
** StatsD プラグイン** サービスに関連するメトリクス名にはすべて「service」が付くようになりました。接頭辞: ‘kong.service.
|
プラグイン |
いいえ |
Proxy Cache、Proxy Cache Advanced、および GraphQL Proxy Cache Advanced プラグイン。 これらのプラグインはレスポンスデータを |
プラグイン |
応答データを必要とするログプラグインは、 kong.ctx.shared.proxy_cache_hitからそれを読み取る必要があります。 |
デバッグ用のKong-Debugヘッダーを制限するために、 kong.confにallow_debug_header構成プロパティを追加しました。 この任意のデフォルトはoffです。 |
DB設定 |
デバッグ情報を提供するためにKong-Debugヘッダーに依存していた場合は、
ヘッダーを削除するための回避策としてResponse Transformerプラグインを使用している場合は、 プラグインは必要ありません。無効にして削除します。 |
lua-resty-sessionライブラリが v4.0.0 にアップグレードされました。このバージョンには完全版が含まれています セッションライブラリの書き換えで、下位互換性がありません。 このライブラリは、Session、OpenID Connect、SAML などのプラグインによって使用されます。これらのプラグインで使用される多くのセッションパラメータは、名前が変更されたり削除されました。 これは、セッションまたはOpenID Connectを使用するセッション構成にも影響します。 Kong Manager および Dev Portal のセッションを含む、バックグラウンドでのプラグイン。 |
プラグイン |
このバージョンにアップグレードすると、既存のセッションはすべて無効になります。 このバージョンでセッションが期待どおりに機能するには、すべてのノードで Kong Gateway 3.4.x を実行する必要があります。 そのため、アップグレード中は、バージョンが混在しているプロキシノードはできるだけ短時間実行することをお勧めします。 その間、無効なセッションが原因で障害が発生したり、部分的なダウンタイムが発生する可能性があります。 次のような動作が予想されます。
**すべてのCPおよびDPノードを3.4にアップグレードし、環境が安定していることを確認した後、 パラメータを新しい名前に変更したバージョンに更新できます。設定は以前と同じように機能しますが、 将来の予期せぬ動作を避けるため、設定を調整することをお勧めします。 すべてのセッション設定の変更と、既存のセッション設定の変換方法については、 下位互換性のない変更に関する書類 をご確認ください。 |
Cassandra DB のサポートは削除されました。Kong Gateway のデータストアとしてはサポートされなくなりました。 |
DB設定 |
互換性
以下の表は、データベース設定や「kong.conf」が失敗する原因となる可能性のある動作の変更を以下に挙げています。 これには、非推奨の(ただし削除されない)機能も含まれます。
変更 | カテゴリー | アクションが必要です |
---|---|---|
atc-router での正規表現のルックアラウンドとバック参照のサポートが削除されました。 これらはめったに使用されない機能であり、それらのサポートを削除すると、正規表現のマッチングの速度が向上します。 現在使用している正規表現がルックアラウンドや後方参照を使用している場合、Kongを起動しようとすると、 互換性のない正規表現を示すエラーが表示されます。 |
ルーター |
アップグレード後の動作の一貫性を確保するために、router_flavor = traditional に設定するか、正規表現を変更してルックアラウンドや後方参照を削除してください。 正規表現パスを確認し、削除された機能が使用されていないことを確認します。 それに応じて正規表現ルーターを更新します。 |
ACL、ボット検知、IP制限プラグイン 非推奨の「blacklist」と「whitelist」設定パラメータを削除しました。 |
プラグイン |
非推奨のblacklistおよびwhitelist構成パラメータを削除します。 代わりにdenylistとallowlistを使用してください。 |
ACME プラグイン auth_method構成パラメータのデフォルト値はtokenになりました。 |
プラグイン |
注意:アップグレード後、 |
AWS Lambda プラグイン *AWSリージョンが必須になりました。aws_regionフィールドパラメータまたは環境変数を使用してプラグイン設定を通じて設定できます。
|
プラグイン |
設定を確認するか、Kongサポートチームにお問い合わせください。 |
HTTPログ(http-log)プラグイン headers` フィールドは、以前は値の配列を受け取っていたが、 ヘッダー名ごとに単一の文字列のみを受け取るようになりました。 |
プラグイン |
設定を確認するか、Kongサポートチームにお問い合わせください。 |
プロメテウスプラグイン プラグインの完全なオーバーホール: *カーディナリティの高いメトリクスはデフォルトで無効になりました。
*kong_bandwidth からkong_bandwidth_bytes 。 *nginx_http_current_connectionsとnginx_stream_current_connectionsはnginx_hconnections_totalに統合されました *request_countとconsumer_statusは http_requests_total に統合されました。 per_consumer設定がfalseに設定されている場合、 consumerラベルは空になります。per_consumer設定がtrueの場合、 consumerラベルが入力されます。
*http_requests_totalに新しいラベルsourceが追加されました。exit 、 error 、またはserviceに設定できます。
|
プラグイン |
データを見逃さないようにするには、新しい設定を使用するようにプラグインの設定を調整してください。 カスタム・ダッシュボードがある場合、またはカスタムPromQLを記述している場合は、それらを確認し、名前の変更でエラーが出ていないことをご確認ください。 |
StatsD Advanced プラグイン StatsD Advancedプラグインは非推奨となり、4.0で削除されます。 すべての機能がStatsDプラグインで利用可能になりました。 |
プラグイン |
StatsDプラグインへの移行をお勧めしますが、StatsD Advancedは3.4でも機能します。 |
サーバーレス関数 ( Serverless Functions プラグインのスキーマから設定パラメータを取得します。 |
プラグイン |
「config.access」を使用し代わりにフェーズを実行します。 |
デフォルトの PostgreSQL SSL バージョンが TLS 1.2 に引き上げられました。「kong.conf」では:
これは、PostgreSQL 12.x 以降の ssl_min_protocol_version 設定を反映します。 このパラメータについての詳細は[PostgreSQLドキュメント] (https://postgresqlco.nf/doc/en/param/ssl_min_protocol_version/)をご確認ください。 |
DB設定 |
「kong.conf」の値を変更するかまたは環境変数をtlsv1_0からtlsv1_2に変更します。 ‘kong.conf’ のデフォルト設定を使用するには、PostgresサーバーがTLS 1.2以上のバージョンをサポートしていることを確認するか、TLSのバージョンを自分で設定してください。 tlsv1_2`より低いTLSバージョンは既に非推奨であり、PostgreSQL 12.x以降では安全でないと考えられています。 |
consumer_groups/:id/overridesエンドポイントは非推奨となり、より一般的なプラグインスコープの仕組みが採用されます。 |
Admin API |
オーバーライドを設定する代わりに、プラグイン・インスタンスをコンシューマ・グループ・エンティティに適用できます。詳しくは Rate Limiting Advanced のドキュメントをご参照ください。 |
admin_api_uriプロパティは非推奨となり、今後のKong Gatewayバージョンでは完全に削除される予定です。 |
Admin API |
構成プロパティ admin_api_uriの名前を admin_gui_api_url に変更します。 |
相談可能
次の機能を使用するアップグレードには Kong のサポートが必要になる場合があります。
Kongのサポートチームは、 データ移行、カスタムプラグインの統合、既存の設定PDKとのシームレスな連携など、 特定のビジネスニーズに合わせた高度な機能とプロフェッショナルサービスを提供します。
変更 | カテゴリー | アクションが必要です |
---|---|---|
3.0では、Kong Gatewayのスキーマライブラリの カスタムプラグインが |
プラグイン |
カスタムプラグインがディープコピーによってデータを取得する必要がある場合は、関数を呼び出す前に ディープコピーのトリガーとなる
|
サーバー上で利用可能な報告済みプラグインのリストは、ブール値
|
プラグイン |
ブール値の代わりに新しいメタデータを使用するように適応します。 |
動作の変更に関する通知
次の表には、知っておく必要はあるものの、アクションを必要としない変更点が掲載されています。
変更 | カテゴリー |
---|---|
PDKのバージョン管理は終了しました。 |
PDK |
移行ヘルパーライブラリ (主にカサンドラの移行に使用) は、Kong Gateway では提供されなくなりました。 |
DB設定 |
PostgreSQL の移行では、Cassandra の移行と同様に、呼び出す関数を指定する up_f 部分を持つことができるようになりました。 up_f 部分は、データベースに対して up 部分が実行された後に呼び出されます。 |
DB設定 |
Kong プラグインは個別にバージョン管理されなくなりました。 3.0.0 から、すべての Kong プラグインのバージョンが Kong Gateway のバージョンに合わせて更新されました。 |
プラグイン |
HTTP ログプラグイン ログサーバーが 3xx HTTPステータスコードで応答した場合、プラグインはそれを次のように認識するようになります エラーが発生し、再試行設定に従って再試行します。以前は、3xxのステータスコードが解釈されていました が成功すると、ログエントリが削除されます。 |
プラグイン |
サーバーレス関数 (ポスト関数またはプレ関数) kong.cacheキャッシュインスタンスを指している Serverless Functions プラグイン専用ですグローバル Kong Gateway キャッシュへのアクセスは提供されません。 「kong.conf」の特定のフィールドへのアクセス も制限されています。 |
プラグイン |
Zipkinプラグイン このプラグインは現在、内部バッファリングにキューを使用しています。 キューイング動作を制御するために、標準キューパラメータセットを使用できます。 |
プラグイン |
kong.conf changes
2.8 | 3.4 |
---|---|
data_plane_config_cache_mode = unencrypted |
Removed in 3.4 |
data_plane_config_cache_path |
Removed in 3.4 |
admin_api_uri |
Deprecated. Use admin_gui_api_url instead |
database |
Accepted values are postgres and off . All Cassandra options have been removed |
pg_keepalive_timeout = 60000 |
Specify the maximal idle timeout (in ms) for the Postgres connections in the pool. If this value is set to 0 then the timeout interval is unlimited. If not specified this value will be the same as lua_socket_keepalive_timeout . |
worker_consistency = strict |
worker_consistency = eventual |
prometheus_plugin_* |
Disabled Prometheus plugin high-cardinality metrics. |
lua_ssl_trusted_certificate No default value |
Default value: lua_ssl_trusted_certificate = system
|
pg_ssl_version = tlsv1 |
pg_ssl_version = tlsv1_2 |
– |
allow_debug_header = off (new parameter) |
Perform upgrade
Now that you have chosen an upgrade strategy, reviewed all the relevant changes between the 2.8 and 3.4 LTS releases you can move on to performing the upgrade with your chosen strategy:
Traditional mode or control planes in hybrid mode:
DB-less mode or data planes in hybrid mode:
Troubleshooting
If you run into issues during the upgrade and need to roll back, restore Kong Gateway based on the backup method.