旧バージョンのドキュメントを参照しています。 最新のドキュメントはこちらをご参照ください。
ハイブリッドモードの概要
従来、Kongは、ルート、サービス、プラグインなどの構成されたエンティティを保存するためにデータベースを常に必要としていました。ハイブリッドモードは、コントロールプレーン(CP)コントロールプレーン/データプレーン(DP)とも呼ばれ、すべてのノードにデータベースが不要になります。
このモードでは、クラスタ内のKongノードは2つのロールに分割されます。構成の管理とAdmin APIの提供を行うコントロールプレーン(CP)と、プロキシのトラフィックを提供するデータプレーン(DP)です。各DPノードはCPノードの1つに接続され、CPノードのみがデータベースに直接接続されます。
データベースの内容に直接アクセスする代わりに、DPノードはCPノードとの接続を 維持し、最新の構成を受け取ります。
flowchart TD A[(Database)] B( Control plane \n #40;Kong Gateway instance#41;) C( Data plane 3\n #40;Kong Gateway instance#41;) D( Data plane 1\n #40;Kong Gateway instance#41;) E( Data plane 2\n #40;Kong Gateway instance#41;) subgraph id1 [Self-managed control plane node] A---B end B --Kong proxy configuration---> id2 & id3 subgraph id2 [Self-managed on-premise node] C end subgraph id3 [Self-managed cloud nodes] D E end style id1 stroke-dasharray:3,rx:10,ry:10 style id2 stroke-dasharray:3,rx:10,ry:10 style id3 stroke-dasharray:3,rx:10,ry:10 style B stroke:none,fill:#0E44A2,color:#fff
図 2: 自己管理型ハイブリッドモードでは、コントロールプレーン(CP)とデータプレーン(DP)は異なるノードでホストされます。コントロールプレーン(CP)はデータベースに接続し、データプレーン(DP)はコントロールプレーン(CP)から構成を受け取ります。
新しいデータプレーン(DP)ノードを作成すると、そのノードはコントロールプレーン(CP)との接続を確立します。
コントロールプレーンは接続のためにポート8005
をリッスンし、そのデータプレーンからの受信データを追跡します。
接続されると、コントロールプレーン(CP)上のすべてのAdmin APIまたはKong Managerアクションによって、クラスタ内のデータプレーン(DP)の更新がトリガーされます。
利点
ハイブリッドモードのデプロイには、次のようなメリットがあります。
- デプロイメントの柔軟性: ユーザーは、DPグループごとにローカルでクラスタ化されたデータベースを必要とせずに、異なるデータセンター、地域、またはゾーンにデータプレーン(DP)のグループをデプロイできます。
-
信頼性の向上: データベースの可用性は、データプレーンの可用性に影響しません。各 DP は、コントロールプレーン(CP)から受信した最新の構成をローカルディスクストレージにキャッシュするため、CP ノードがダウンしても DP ノードは機能し続けます。
- CP がダウンしている間、DPノードは常に通信の再確立を試行します。
- DPノードはCPがダウンしている間も再起動できますが、通常、トラフィックのプロキシは維持されます。
- トラフィックの削減: データベースへの直接接続が必要なのはCPノードのみであるため、データベースを往復するトラフィック量を大幅に減らします。
- セキュリティの向上: DPノードの1つが侵害された場合、 攻撃者はKongクラスタ内の他のノードに影響を与えることができません。
- 管理の容易さ: 管理者は CP ノードを操作するだけで、Kong クラスタ全体のステータスの制御および監視ができます。
プラットフォームの互換性
Kong Gateway は、 Kong Gateway がサポートされている任意のプラットフォームでハイブリッドモードで実行できます。
Kubernetesのサポートと追加ドキュメント
Kubernetes上のKong Gatewayは、Kong Ingress Controllerの有無にかかわらず、ハイブリッドモードのデプロイメントを完全にサポートします。
Kubernetes ハイブリッドモードに関する完全なドキュメントは、kong/charts
リポジトリ内のハイブリッドモードを参照してください。
バージョンの互換性
Kong Gatewayコントロールプレーン(CP)は、同じメジャーなバージョンのデータプレーン(DP)からの接続のみを許可します。コントロールプレーン(CP)はより新しいマイナーバージョンのデータプレーン(DP)からの接続を許可しません。
次はKong Gateway v2.5.2コントロールプレーン(CP)の例です。
- Kong Gateway 2.5.0、2.5.1、2.5.2のデータプレーン(DP)を受け入れます。
- Kong Gateway 2.3.8、2.2.1、および 2.2.0 のデータプレーン(DP)を受け入れます。
- Kong Gateway 2.5.3データプレーン(DP)を受け入れます(データプレーン(DP)上の新しいパッチバージョンが受け入れられます)。
- Kong Gateway 1.0.0のデータプレーンを拒否(メジャーバージョンは異なる)。
- Kong Gateway 2.6.0データプレーンを拒否(データプレーンのマイナーバージョンの方が新しい)。
さらに、Kong Gateway コントロールプレーン(CP)で設定されているすべてのプラグインについて 、新しい構成は、構成されたプラグインがインストールされロードされた データプレーン(DP)にのみプッシュされます。これらの設定済みプラグインのメジャーバージョンは コントロールプレーンとデータプレーンの両方で同じである必要があります。また、データプレーン(DP)上の マイナーバージョンのプラグインは、コントロールプレーン(CP)にインストールされているバージョンより 新しいものであってはなりません。Kong Gatewayバージョンチェックと同様に、 互換性を判断する際には、プラグイン パッチ バージョンも無視されます。
構成済みプラグインとは、グローバルに有効になっているか、またはサービス、ルート、もしくはコンシューマによって構成されているプラグインを意味します。
たとえば、Kong Gatewayコントロールプレーン(CP)にplugin1
v1.1.1
およびplugin2
v2.1.0がインストールされている場合、plugin1
はRoute
オブジェクトによって構成されます。
- Kong Gateway データプレーン(DP)で
plugin1
v 1.1.2 とplugin2
がインストールされていないものを受け入れます。 - 次のKong Gatewayデータプレーン(DP)を受け入れます:
plugin1
v 1.1.2、plugin2
v2.1.0、plugin3
v9.8.1がインストールされたもの。 -
plugin1
v1.1.1 でplugin3
v9.8.1 がインストールされているKong Gatewayデータプレーン(DP)を受け入れます。 -
plugin1
v 1.2.0、plugin2
v 2.1.0がインストールされている Kong Gateway データプレーンは拒否されます。(データプレーン(DP)のプラグインのマイナーバージョンが新しい) -
plugin1
がインストールされていないKong Gatewayデータプレーン(DP)を拒否します (プラグインはコントロールプレーン(CP)に設定されていますが、データプレーン(DP)にはインストールされていません)。
コントロールプレーン(CP)とデータプレーン(DP)の間のバージョン互換性のチェックは、構成の読み取り時に発生します。各データプレーンプロキシは構成の更新を受け取ると、要求された機能を有効にできるかどうかを確認します。コントロールプレーンの Kong Gateway が、データプレーンプロキシよりも新しいバージョンであるが、この新しいバージョンには新機能が含まれていない場合、データプレーンプロキシは想定どおりこれを読み取り、適用します。
たとえば、Kong Gateway の新しいバージョンには新しいプラグインが追加されており、そのバージョンを使用してコントロールプレーンを更新するとします。新しいプラグインを構成に追加していなければ、より古いバージョンで動作しているデータプレーンであっても、引き続き構成を送信することができます。新しいプラグインを構成に追加する場合は、データプレーンがコントロールプレーンから読み込みを続行するために、データプレーンを新しいバージョンに変更する必要があります。
互換性チェックが失敗すると、コントロールプレーンは互換性のないデータプレーンが壊れないようにするために新しい構成の送信を停止します。
互換性チェックの失敗により設定をデータプレーン(DP)にプッシュできない場合、コントロールプレーン(CP)のerror.log
には次のようなwarn
レベルの行が含まれます。
unable to send updated configuration to DP node with hostname: localhost.localdomain ip: 127.0.0.1 reason: version mismatches, CP version: 2.2 DP version: 2.1
unable to send updated configuration to DP node with hostname: localhost.localdomain ip: 127.0.0.1 reason: CP and DP does not have same set of plugins installed or their versions might differ
さらに、/clustering/data-planes
Admin API エンドポイントは、データプレーンノードのバージョンと、ノードが使用している最新の構成ハッシュを返します。このデータは、コントロールプレーン側からバージョンの非互換性を検出するのに役立ちます。
フォールトトレランス
コントロールプレーン(CP)ノードがダウンした場合でも、データプレーン(DP)は機能し続けます。データプレーン(DP)は ローカル ディスク上のコントロールプレーン(CP)から受信した最新の構成をキャッシュします。 コントロールプレーン(CP)が機能しなくなった場合でも、データプレーン(DP)はキャッシュされた構成を使用して リクエストを処理し続けます。コントロールプレーン(CP)と通信を再構築しようと し続けながら実行します。
つまり、コントロールプレーン(CP)ノードは長期間でも停止でき、 時間が経過しても、データプレーン(DP)は通常どおりトラフィックをプロキシするということです。データプレーン(DP) ノードは切断モードでも再起動でき、作業を開始するためのキャッシュ内の 最後の構成をロードします。コントロールプレーン(CP)が 再び起動すると、データプレーン(DP)ノードがそれらに接続し、接続モードを再開します。
接続が切断されたモード
切断された状態でもデータプレーン(DP)が存続できるということは、コントロールプレーン(CP)の更新やデータベースの復元を安心して実行できることを意味します。まず、コントロールプレーン(CP)をダウンさせ、必要なすべてのダウンタイムプロセスを実行し、手順の成功と正確性を確認した後にのみコントロールプレーン(CP)を実行します。その間、データプレーン(DP)は最新の構成で動作し続けます。
コントロールプレーンのダウンタイム中に、新しいデータプレーンノードをプロビジョニングできます。このためには、他のデータプレーンノードからLMDBディレクトリ(dbless.lmdb
)をコピーするか、宣言的な設定を用いる必要があります。いずれも、"data_plane"
のロールを持つ場合は、コントロールプレーンが再び立ち上がるまで、コントロールプレーンとの接続を試行します。
切断されたデータプレーン(DP)ノードの構成を変更するには、LMDB ディレクトリ (dbless.lmdb
)を削除し、declarative_config
パラメータまたは KONG_DECLARATIVE_CONFIG
環境変数が設定されていることを確認して、参照されている YAML ファイルに構成全体を設定する必要があります。
データプレーン(DP)キャッシュ構成
デフォルトでは、データプレーン(DP)は、Kong Gateway の prefix
パス内にある暗号化されていない LMDB データベース dbless.lmdb
内のファイルシステムに構成を保存します。このデータベースを暗号化することもできます。
暗号化されている場合、データプレーンはクラスター証明書キーを使用して起動時の LMDBデータベースを復号化します。
制限
構成の柔軟性のなさ
構成の変更がAdmin APIからコントロールプレーン(CP)レベルで行われる場合、クラスタ全体ですべてのデータプレーン(DP)構成の更新が即座にトリガーされます。 具体的には、CPからすべてのDPに同じ構成が同期されることになります。この更新はスケジュールすることもバッチ処理することもできません。 異なるDPに違う構成を適用するには、それぞれのDPに固有のCPインスタンスが必要です。
プラグインの非互換性
プラグインがハイブリッドモードのデータプレーン(DP)で実行されている場合、そのDPから直接公開されるAdmin APIはありません。Admin APIはコントロールプレーン(CP)からのみ公開されるため、すべてのプラグイン設定はCPから行う必要があります。この設定と、CPとDP間の設定同期形式により、一部のプラグインにはハイブリッドモードで制限があります。
-
Key Auth Encrypted:認証情報が有効な期間を決定する有効期限設定(
ttl
)は、ハイブリッドモードでは機能しません。 -
Rate Limiting、Rate Limiting Advanced、および Response Rate Limiting: これらのプラグインは、ハイブリッドモードでの
cluster
ストラテジ/ポリシーをサポートしていません。代わりに、local
またはredis
のストラテジ/ポリシーの 1 つを使用する必要があります。 -
GraphQL Rate Limiting Advanced: このプラグインはハイブリッドモードでの
cluster
ストラテジをサポートしていません。代わりに、redis
ストラテジを使用する必要があります。 - OAuth 2.0 Authentication:このプラグインはハイブリッドモードと互換性がありません。通常のワークフローでは、プラグインはトークンの生成と削除の両方を行い、それらの変更をデータベースにコミットする必要がありますが、これはCP/DP分離では不可能です。
カスタムプラグイン
カスタムプラグイン(独自のプラグインまたは Kong に付属していないサードパーティ製プラグイン)は、ハイブリッドモードでコントロールプレーン(CP)とデータプレーン(DP)の両方にインストールする必要があります。
コンシューマグループ
プラグインのスコープをコンシューマグループに限定する機能は Kong Gateway バージョン3.4で追加されました。異なるバージョンが混在する Kong Gateway クラスタ(3.4コントロールプレーンで3.3以上のデータプレーン)の実行は、コンシューマグループスコープのプラグインを使用している場合、サポートされません。
ロードバランシング
現在、コントロールプレーンとデータプレーン間の接続ではロードバランシングは自動化されていません。複数のコントロールプレーンの使用と TCP プロキシを使用したトラフィックのリダイレクトによって、手動でロードバランシングできます。
データプレーン(DP)上の読み取り専用 Status API エンドポイント
Admin API からのいくつかの読み取り専用エンドポイントは、データプレーン(DP)の Status API に公開されます。
- GET /upstreams/{upstream}/targets/
- GET /upstreams/{upstream}/health/
- GET /upstreams/{upstream}/targets/all/
- GET /upstreams/{upstream}/targets/{target}
エンドポイントの詳細については、Admin APIドキュメントのアップストリームオブジェクトを参照してください。
ハイブリッドモードでのキーリング暗号化
キーリングモジュールはデータベースのデータを暗号化するので、データプレーンノード上のデータを暗号化できません。これらのノードはデータベースなしで動作し、コントロールプレーンからデータを取得するためです。