コンテンツにスキップ
|
Kong Gateway
3.8.x
report-issue問題を報告する
旧バージョンのドキュメントを参照しています。 最新のドキュメントはこちらをご参照ください。

概要

Kong Gatewayは、次の4つの異なるモードでデプロイできます。

  • Konnect（ホストされたコントロールプレーン（CP））
  • ハイブリッド
  • 従来モード（データベース）
  • DBレスで宣言的

各モードには利点と制限があるため、 Kong Gatewayを本番環境にインストールする際にどのモードを使用するかを決定する際には、それらを慎重に検討することが重要です。

次のセクションでは、各モードについて簡単に説明します。

Konnect

Kong Gatewayを使用する場合、 Konnect使用すると、最速で開始できます。独自のコントロールプレーン（CP）やデータベースをデプロイしなくても、独自のデータプレーンノード（DP）をデプロイして顧客のトラフィックを処理できます。

Konnectは、Kongがユーザー向けにコントロールプレーン（CP）をホストする、ハイブリッドモードのデプロイメントです。つまり、ユーザーはハイブリッドモードのデプロイメントのすべてのメリットが得られるうえ、複数のコントロールプレーンノードを自分で実行する必要もありません。

 
flowchart TD
A(Dev Portal • Gateway Manager • Analytics • Service Hub)
B( Control plane \n #40;Kong Gateway instance#41;)
B2( 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 [Konnect]
A --- B & B2
end

id1 --Kong proxy 
configuration---> id2 & id3

subgraph id2 [Kong-managed cloud node]
C
end

subgraph id3 [Self-managed local and 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
style B2 stroke:none,fill:#0E44A2,color:#fff

図1: Konnectにおいて、Kongはコントロールプレーンと関連するすべてのアプリケーションをホス トしています：Dev Portal、Gateway Manager、Analytics、 Service Catalogなど。トラフィックを処理するためにデータプレーンをKonnectに接続し、コントロールプレーンからすべての設定を取得します。

構成の変更は、 Konnect UI と構成ウィザードを使用して行うことも、decK を使用して自動的に適用することもできます。

自己管理型ハイブリッドモードと同様に、コントロールプレーン（CP）がオフラインの場合でも、データプレーン（DP）ノードは引き続きトラフィックを処理します。また、Kong Gateway がコントロールプレーン（CP）の保護を行ってくれるため、保護について心配する必要はありません。

最後に、Konnect はクラウド管理のコントロールプレーンとコントロールプレーングループをサポートしているため、必要に応じて構成をセグメント化できます。それは、ビジネス単位または環境単位で指定できます。ハイブリッドモードを使用してこれを実現するには、セグメントごとに 1 つのコントロールプレーン（CP）をデプロイする必要がありますが、Konnect では同じ UI と API を使用して複数の構成セットを管理できます。

今すぐKonnectを無料で始めましょう。

ハイブリッドモード

ハイブリッドモードでは、クラスタ内の Kong Gateway ノードは 2 つのロールに分割されます。構成の管理と Admin API の提供を行うコントロールプレーン（CP）と、プロキシのトラフィックを提供するデータプレーン（DP）です。多数の DP ノードが 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 グループごとにローカルでクラスタ化されたデータベースを必要とせずに、異なるデータセンター、地域、またはゾーンにデータプレーン（DP）のグループをデプロイできます。
  • データベースの可用性はデータプレーン（DP）の可用性には影響しません。コントロールプレーン（CP）がオフラインの場合、データプレーン（DP）は最後に認識された構成を使用して実行されます。
  • データベースへの直接接続が必要なのはCPノードのみであるため、データベースを往復するトラフィック量を大幅に減らします。
  • DPノードの1つが危険にさらされても、攻撃者は Kong Gateway クラスターの他のノードに影響を与えることはできません。

従来（データベース）モード

従来のモードでは、 Kong Gatewayにはルート、サービス、プラグインなどの構成されたエンティティを保存するためのデータベースが必要です。サポートされているデータベースを参照してください。

 
flowchart TD

A[(Database)]
B( Kong Gateway instance)
C( Kong Gateway instance)
D( Kong Gateway instance)

A <---> B & C & D

style B stroke:none,fill:#0E44A2,color:#fff
style C stroke:none,fill:#0E44A2,color:#fff
style D stroke:none,fill:#0E44A2,color:#fff

図3：従来のデプロイでは、すべてのKong Gatewayノードがデータベースに接続します。各ノードは、独自の構成を管理します。

Kongを使い始めるには、従来モードでKong Gatewayを実行する方法が最も簡単です。この方法は、データベースを必要とするプラグイン（クラスタストラテジを伴う流量制限やOAuth2など）をサポートする唯一のデプロイメントトポロジーです。ただし、欠点もいくつかあります。

従来モードで実行している場合、すべての Kong Gateway ノードはコントロールプレーン（CP）とデータプレーン（DP）の両方として動作します。これは、 ノードのいずれかが危険にさらされると 、実行中のゲートウェイ構成全体が危険にさらされることを意味します。対照的に、ハイブリッドモードでは個別の CP ノードと DP ノードがあり、攻撃対象領域が縮小されます。

さらに、Kong ManagerでKong Gateway Enterpriseを実行している場合、分析データとグラフをレンダリングするためにコストのかかる計算が実行されるため、Kong Managerを実行しているノードでのリクエストスループットが低下する可能性があります。

Admin APIまたは宣言型構成ファイル(decK)を使用して、 Kong Gatewayを従来モードで構成できます。

DBレスモードと宣言型モード

DBレスモードを有効にすると、複雑さが軽減され、より柔軟なデプロイパターンを作成できます。このモードでは、ルート、サービス、プラグインなどの設定済みのエンティティがノードのメモリに保存されます。

 
flowchart TD

A( Kong Gateway instance)
B( Kong Gateway instance)
C( Kong Gateway instance)

A2(fa:fa-file kong1.yml)
B2(fa:fa-file kong2.yml)
C2(fa:fa-file kong3.yml)

A2 --> A
B2 --> B
C2 --> C

style A stroke:none,fill:#0E44A2,color:#fff
style B stroke:none,fill:#0E44A2,color:#fff
style C stroke:none,fill:#0E44A2,color:#fff

*図4：DBレスモードでは、構成はYAMLファイルを介して適用されます。

Kong Gatewayノードはデータベースにも他のノードにも接続されていません。*

DB-lessモードで実行する場合、2番目のファイルを使用してKong Gatewayに構成が提供されます。このファイルには、Kongの宣言型構成構文を使用したYAMLまたはJSON形式の構成が含まれています。

Kong Ingress ControllerでもDBレスモードを使用します。この場合、Kubernetes APIサーバーは、変更が加えられる都度、Kongの/configエンドポイントを使用して、メモリ内の実行構成を更新します。

DBレスモードと宣言型構成の組み合わせには、次のような利点があります。

  • 依存関係の数の削減: ユースケースの設定全体がメモリ内に収まる場合は、データベースのインストールを管理する必要はありません。
  • 構成は常に既知の状態です。サービスの作成とAdmin APIを使用したルート間には中間状態はありません。
  • CI/CD シナリオの自動化に適しています。エンティティの構成は、Gitリポジトリを経由で管理される信頼できる唯一の情報源で保存できます。

このモードには、次のような制限があります。

  • Admin APIは読み取り専用です。
  • 流量制限（クラスタモード）など、データベースに情報を保存するプラグインは完全には機能しません。