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

ハイブリッドモードの概要

従来、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、plugin3v9.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ドキュメントのアップストリームオブジェクトを参照してください。

ハイブリッドモードでのキーリング暗号化

キーリングモジュールはデータベースのデータを暗号化するので、データプレーンノード上のデータを暗号化できません。これらのノードはデータベースなしで動作し、コントロールプレーンからデータを取得するためです。