Kong Gateway 3.0.x 最新の変更
アップグレードする前に、現在のインストールに影響するこのバージョンおよび以前のバージョンの構成または下位互換性のない変更を確認してください。
デプロイ方法、使用している機能セット、カスタムプラグインなどに応じて、異なるアップグレード手順を採用する必要がある場合があります。
プラグイン
プラグインの下位互換性のない変更については、お使いのKong GatewayバージョンのKong Gateway変更履歴を参照してください。
Kongプラグイン
インストールに新しいプラグインを追加する場合は、プラグイン名を指定して
kong migrations up
を実行する必要があります。例えば、
KONG_PLUGINS=tls-handshake-modifier
。
3.0リリースには以下の新しいプラグインが含まれています。
-
OpenTelemetry (
opentelemetry
) -
TLS Handshake Modifier(
tls-handshake-modifier
) -
TLS Metadata Headers(
tls-metadata-headers
) -
WebSocket Size Limit(
websocket-size-limit
) -
WebSocket Validator (
websocket-validator
)
Kongプラグインは、CREDENTIAL_USERNAME
(X-Credential-Username
)をサポートしなくなりました。
認証情報にアップストリームヘッダーを設定する場合は、定数CREDENTIAL_IDENTIFIER
(X-Credential-Identifier
)を使用してください。
デプロイメント
Amazon Linux 1 および Debian 8 (Jessie) のコンテナとパッケージは非推奨となり、 Kong Gatewayの新しいバージョンでは生成されなくなりました。
ブルーグリーンデプロイメント
従来モード :2.8.1 およびそれ以前のバージョンから 3.0.0 へのブルーグリーンアップグレードは現在サポートされていません。 これは既知の問題であり、次の 2.8リリースで修正される予定です。2.8 のリリースバージョンがリリースされたら、2.x ユーザーは 3.0 へのブルーグリーンアップグレードを開始する前に、そのバージョンにアップグレードする必要があります。
ハイブリッド モード : 以下のアップグレード手順を参照してください。
依存関係
提供されているバイナリパッケージ(DebianとRHELを除く)を使用している場合は、ゲートウェイに必要なすべての依存関係が バンドルされているため、このセクションは省略できます。
Kong Gateway 3.0以降、DebianとRHELのイメージは最小限の依存関係でビルドされ、公開前に自動セキュリティスキャナを通じて実行されます。これらには、 Kong Gatewayを実行するために必要な最小限のものだけが含まれています。ベースイメージと依存関係をさらにカスタマイズしたい場合は、 独自のDockerイメージを構築してください。
Debian、RHELを使用している場合、または手動で依存関係を構築している場合は、以前のリリースから変更が加えられているため、最新のパッチを使用して再構築する必要があります。
Kong Gateway 3.0.x に必要な OpenResty のバージョンは 1.21.4.1 です。アップグレードされた OpenResty に加えて、lua-kong-nginx-module の最新リリースを含む、この新しいバージョン用の正しい OpenResty パッチが必要です。kong-build-tools リポジトリには openresty-build-tools が含まれており、必要なパッチやモジュールを使って OpenResty をより簡単にビルドすることができます。
移住
移行ヘルパーライブラリ(主にCassandraの移行に使用)は、Kong Gatewayでは提供されなくなりました。
PostgreSQLの移行で、Cassandraの移行と同様に、up_f
部分を含め、呼び出す関数を指定できるようになりました。up_f
の部分はup
部分が、PostgreSQLとCassandraの両方データベースに対して実行された後に呼び出されます。
廃止および変更されたパラメータ
StatsD Advancedプラグインは非推奨となり、4.0で削除されます。 現在、すべての機能がStatsDプラグインで利用できるようになっています。
以下のプラグインの設定パラメータが変更または削除されました。必要に応じて、設定を慎重に確認し、更新する必要があります。
ACL、Bot Detection、IP Restriction
- 非推奨の
blacklist
とwhitelist
構成パラメータを削除しました。代わりにallow
またはdeny
を使用します。
- 設定パラメータのデフォルト値は
auth_method
token
になりました。
- AWSリージョンが必須になりました。
aws_region
フィールドパラメータまたは環境変数でプラグインを構成して設定できます。 - 現在、プラグインでは
host
フィールドとaws_region
フィールドを同時に設定できるようになり、常にSigV4署名が適用されます。
- 以前は値の配列を取っていた
headers
フィールドは、ヘッダー名ごとに1つの文字列しか入力できなくなりました。
- 認証されたJWTはnginxコンテキスト (
ngx.ctx.authenticated_jwt_token
)に入れられなくなりました。その名前で設定されている値に依存するカスタムプラグインは、3.0にアップグレードする前に、代わりにKongの共有コンテキスト(kong.ctx.shared.authenticated_jwt_token
)を使用するように更新する必要があります。
-
高カーディナリティメトリックはデフォルトで無効になりました。
-
次のメトリック名は、可能な限り標準化するために単位を追加するために調整されました。
-
http_status
http_requests_total
へ。 -
latency
からkong_request_latency_ms
(HTTP)、kong_upstream_latency_ms
、kong_kong_latency_ms
、session_duration_ms
(ストリーム)。 Kongとアップストリームのレイテンシは、それぞれ異なるレベルのコマンドで動作する可能性があります。メモリのオーバーヘッドを削減するには、これらのバケットを分離します。 -
kong_bandwidth
kong_bandwidth_bytes
へ。 -
nginx_http_current_connections
とnginx_stream_current_connections
はnginx_connections_total
に統合されました。 -
request_count
とconsumer_status
はhttp_requests_total
に統合されました。per_consumer
構成がfalse
に設定されている場合、consumer
ラベルは空になります。per_consumer
構成がtrue
の場合、consumer
ラベルが入力されます。
-
-
その他のメトリクスの変更:
- 次のメトリックを削除しました:
http_consumer_status
。 -
http_requests_total
新しいラベルsource
があります。exit
、error
、service
のいずれかに設定できます。 - すべてのメモリメトリクスに新しいラベルが付けられました:
node_id
。 - このプラグインはステータスコード、レイテンシ、帯域幅、アップストリームのヘルスチェックメトリクスをデフォルトでエクスポートしませんが、 今後も、
status_code_metrics
、lantency_metrics
、bandwidth_metrics
、upstream_health_metrics
をそれぞれ設定することでこの機能をオンにできます。
- 次のメトリックを削除しました:
Pre-functionプラグインとPost-functionプラグイン
- 非推奨の
config.functions
構成パラメータをpost-function
とpre-function
プラグインのスキーマから削除しました。代わりに、config.access
フェーズを使用してください。
-
サービスに関連するすべてのメトリック名に
service.
プレフィックスkong.service.<service_identifier id="sl-md0000000">.request.count
が付くようになりました。- メトリクス
kong.<service_identifier id="sl-md0000000">.request.status.<status id="sl-md0000000">
はkong.service.<service_identifier id="sl-md0000000">.status.<status id="sl-md0000000">
に改名されました。 - メトリクス
kong.<service_identifier id="sl-md0000000">.user.<consumer_identifier id="sl-md0000000">.request.status.<status id="sl-md0000000">
はkong.service.<service_identifier id="sl-md0000000">.user.<consumer_identifier id="sl-md0000000">.status.<status id="sl-md0000000">
に改名されました。
- メトリクス
-
メトリクス
status_count
およびstatus_count_per_user
からメトリクス*.status.<status id="sl-md0000000">.total
が削除されました。
Proxy Cache、Proxy Cache Advanced、GraphQL Proxy Cache Advanced
- 上記プラグインは
ngx.ctx.proxy_cache_hit
に応答データを保存しなくなりました。 - 現在、応答データを必要とするログ取得プラグインは、データを
kong.ctx.shared.proxy_cache_hit
から読み取る必要があります。
カスタムプラグインとPDK
-
プラグインのDAOは、読み込み順序が明示的になるように、配列にリストされなければなりません。ハッシュのようなテーブルへの読み込みは、サポートされなくなりました。
-
プラグインの
handler.lua
ファイル内には、有効なPRIORITY
(整数)およびVERSION
(「x.y.z」形式)フィールドが必要です。無い場合は、プラグインは読み込みに失敗します。 -
古い
kong.plugins.log-serializers.basic
ライブラリは PDK に置き換えられて削除されました 関数kong.log.serialize
。 PDK を使用するにはプラグインをアップグレードしてください。 -
非推奨となっていたレガシーのプラグインスキーマのサポートは削除されました。カスタムプラグインがいまだに古い(
0.x era
)スキーマを使用している場合は、それらをアップグレードする必要があります。 -
一部のプラグインの優先度を更新しました。
これはプラグインの実行順序に影響する可能性があるため、カスタムプラグインを実行するユーザーにとって重要ですが、 Kong Gatewayの標準的なインストールにおけるプラグインの実行順序は変更されません。
古いプラグインと新しいプラグインの優先度の値:
-
acme
を1007
から次の値へ変更:1705
-
basic-auth
を1001
から次の値へ変更:1100
-
canary
を13
から次の値へ変更:20
-
degraphql
を1005
から次の値へ変更:1500
-
graphql-proxy-cache-advanced
を100
から次の値へ変更:99
-
hmac-auth
を1000
から次の値へ変更:1030
-
jwt
を1005
から次の値へ変更:1450
-
jwt-signer
は999
から1020
に変更されました。 -
key-auth
を1003
から次の値へ変更:1250
-
key-auth-advanced
を1003
から次の値へ変更:1250
-
ldap-auth
を1002
から次の値へ変更:1200
-
ldap-auth-advanced
を1002
から次の値へ変更:1200
-
mtls-auth
を1006
から次の値へ変更:1600
-
oauth2
を1004
から次の値へ変更:1400
-
openid-connect
を1000
から次の値へ変更:1050
-
rate-limiting
を901
から次の値へ変更:910
-
rate-limiting-advanced
を902
から次の値へ変更:910
-
route-by-header
を2000
から次の値へ変更:850
-
route-transformer-advanced
を800
から次の値へ変更:780
-
pre-function
を+inf
から次の値へ変更:1000000
-
vault-auth
1003
から変更1350
-
-
kong.request.get_path()
PDK関数は、呼び出し元に返される文字列においてパスの正規化を行うようになりました。未加工の非正規化バージョン リクエストパスはkong.request.get_raw_path()
経由で取得できます。 -
pdk.response.set_header()
、pdk.response.set_headers()
、pdk.response.exit()
は、手動で設定されたTransfer-Encoding
ヘッダーを無視し、警告を発するようになりました。 -
PDKのバージョン管理は終了しました。
-
JavaScript PDKは、
kong.request.getRawBody
、kong.response.getRawBody
、kong.service.response.getRawBody
でUint8Array
を返すようになりました。 Python PDKは、kong.request.get_raw_body
、kong.response.get_raw_body
、kong.service.response.get_raw_body
でbytes
を返します。 以前は、これらの関数は文字列を返していました。 -
go_pluginserver_exe
およびgo_plugins_dir
ディレクティブはサポートされなくなりました。 Goプラグインサーバーを使用している場、アップグレードする前に Go PDKを使用するにはプラグインを移行してください。 -
3.0以降、Kong Gatewayのスキーマライブラリの
process_auto_fields
機能は、所与のコンテキストがselect
である場合、渡されるデータをディープコピーしません。 その理由は、ほとんどの場合、データがpgmoon
やlmdb
のようなドライバーから取得されるとKongが考えるテーブルを過度にディープコピーしないようにするためです。カスタムプラグインが指定されたテーブルをオーバライドしない
process_auto_fields
に依存していた場合は、今すぐ関数に渡す前に独自のコピーを作成する必要があります。 -
KongプラグインまたはDAOスキーマの非推奨の
shorthands
フィールドは削除され、 代わりに入力されたshorthand_fields
が使用されます。カスタムスキーマでまだshorthands
を使用している場合は、shorthand_fields
を使用するよう更新する必要があります。 -
legacy = true/false
属性のサポートは、KongスキーマおよびKongフィールドスキーマから削除されました。 -
Kongシングルトンモジュール
kong.singletons
は、PDKkong.*
が優先されたため削除されました。
新しいルーター
現在、
Kong Gatewayでは、route.path
が正規表現パターンかどうかの推測にヒューリスティックを使用していません。3.0以降は、すべての正規表現パスは"~"
プレフィックスで始める必要があり、"~"
で始まらないパスはすべてプレーンテキストと見なされます。
移行プロセスでは、2.xから3.0にアップグレードする際に、正規表現パスが自動的に変換されます。
route.path
の正規化ルールが変更されました。Kong Gateway は正規化されていないパスを保存するようになりましたが、
正規表現のパスは常に正規化されたURIとパターンマッチします。 以前は、Kong Gateway がパーセントエンコーディングに置き換えられました
正規表現のパスパターンを使用して、さまざまな形式のURIが一致するようにします。
これはサポートされなくなりました。 で定義されている予約文字を除き、
RFC3986 、
その他のすべての文字はパーセントエンコードなしで書き込みます。
宣言型とDBレス
宣言型構成のバージョン番号(_format_version
)は、route.path
の変更により 3.0
に引き上げられました。古いバージョンの宣言型構成は、移行中に3.0
にアップグレードされます。
宣言型構成ファイルを 2.8 以前から 3.0 に同期しないでください (
deck gateway sync
)。 古い構成ファイルは構成を上書きし、互換性の問題を引き起こします。 更新された構成を取得するには、移行が完了した後に 3.0 ファイルをdeck gateway dump
ます。
.lua
形式を使用してkong
CLI ツールから宣言型構成ファイルをインポートすることはできなくなりました。JSON形式とYAML形式のみがサポートされています。Kong Gatewayでのアップデート手順にkong config db_import config.lua
の実行が含まれる場合、config.lua
ファイルをconfig.json
またはconfig.yml
ファイルに変換してからアップグレードします。
Admin API
Admin APIエンドポイント /vitals/reports
は削除されました。
POST
リクエストが/targets
エンドポイントに対するものである場合、既存エンティティを更新できなくなりました。
このリクエストでは新しいエンティティの作成のみできます。
/targets
を変更するためにPOST
リクエストを使用するスクリプトがある場合、適切なエンドポイントへのPUT
リクエストに変更してからKong 3.0に更新します。
サーバーで利用できると報告されたプラグインのリストは、ブール値のtrue
ではなく、プラグインごとのメタデータのテーブルを帰すようになりました。
構成
X-Credential-Username
の値を持つKong定数CREDENTIAL_USERNAME
は
削除されました。
システム CA ストアから信頼された CA リストを自動的に読み込むために、デフォルト値の lua_ssl_trusted_certificate
が system
に変更されました。
データプレーンの構成キャッシュメカニズムとそれに関連する構成オプション(data_plane_config_cache_mode
とdata_plane_config_cache_path
)は削除され、代わりにLMDBが使用されます。
ngx.ctx.balancer_address
は、ngx.ctx.balancer_data
が優先されたため削除されました。
Kubernetes向けKongに関する考慮事項
Helm チャートはアップグレード移行プロセスを自動化します。helm upgrade
を実行すると、チャートは、kong migrations up
を実行するための初期ジョブを生成し、更新されたバージョンで新しい Kong ポッドを生成します。これらのポッドの準備が整うと、トラフィックの処理が開始され、古いポッドは終了されます。これが完了すると、チャートは別のジョブを生成して kong migrations finish
を実行します。
移行自体は自動化されていますが、チャートは、推奨されているアップグレードパスに従うことを自動的に保証するものではありません。 複数のマイナー Kong Gatewayバージョンからさかのぼってアップグレードする場合は、推奨されるアップグレードパスを確認してください。
必須ではありませんが、ユーザーはチャートのバージョンとKong Gatewayバージョンを個別にアップグレードする必要があります。問題が発生した場合、これは問題がKubernetesリソースの変更に起因するものか、Kong Gatewayの変更変更に起因するものかを明確にするのに役立ちます。
Kong for Kubernetesのバージョンアップグレードに関する具体的な考慮事項については、アップグレードに関する考慮事項を参照してください。
Kongデプロイメントは複数のリリースに分割
標準のチャートアップグレード自動化プロセスでは、Kong Gatewayクラスタ内でKong Gatewayリリースが1つだけであると
想定しており、migrations up
とmigrations finish
の両方のジョブを実行します。
Kong Gatewayデプロイメントを複数のHelmリリースに分割する場合(たとえば、プロキシ専用ノードや管理者専用ノードなど)、アップグレードの順番に応じて、どの移行ジョブを実行するかを設定する必要があります。
複数のリリースに分割されたクラスタを処理するには、次の操作を行う必要があります。
-
次のいずれかのリリースをアップグレードします。
helm upgrade RELEASENAME -f values.yaml \ --set migrations.preUpgrade=true \ --set migrations.postUpgrade=false
-
残りのリリースのうち 1 つを除くすべてを次のようにアップグレードします。
helm upgrade RELEASENAME -f values.yaml \ --set migrations.preUpgrade=false \ --set migrations.postUpgrade=false
-
最終リリースを次のようにアップグレードします。
helm upgrade RELEASENAME -f values.yaml \ --set migrations.preUpgrade=false \ --set migrations.postUpgrade=true
これにより、すべてのインスタンスが、kong migrations finish
を実行する前に新しい
Kong Gatewayパッケージを使用していることが保証されます。
ハイブリッド モードに関する考慮事項
重要: 現在ハイブリッドモードで実行している場合は、最初にコントロールプレーン(CP)をアップグレードし、次にデータプレーン(DP)をアップグレードします。
- 現在、クラシック(従来モード)で2.8.xバージョンを実行している場合で、ハイブリッドモードの実行に切り替えたい場合は、移行を行った後、ハイブリッドモード インストール手順 に従ってください。
- カスタムプラグイン(独自のプラグインまたはKong Gatewayに付属していないサードパーティ製プラグイン)は、 ハイブリッドモードでコントロールプレーン(CP)とデータプレーン(DP)の両方にインストールする必要があります。プラグインは、 最初にコントロールプレーン(CP)にインストールし、次にデータプレーン(DP)にインストールします。
-
Rate Limiting Advancedプラグインは、ハイブリッドモードでの
cluster
ストラテジをサポートしていません。 代わりに、redis
ストラテジを使用する必要があります。
テンプレートの変更
2.0.x以降のKong Gatewayのマイナーバージョンとメジャーバージョンの間では、Nginx構成ファイルに変更があります。
3.0.xで非推奨のKong.serve_admin_api
エイリアスが削除されました。
カスタムNginxテンプレートをまだ使用している場合は、Kong.admin_content
に変更してください。