Kong四大参考説明

4316 ワード

Kongの公式には、プロファイル、コマンドライン、Admin API、エージェント、負荷等化など、詳細な参考説明がたくさんあります.次に、どのような内容が提供されているかを簡単に見てみましょう.
ここでは主にKong 1.3バージョンに基づいて説明します.更新があれば、最新のドキュメントを参照してください.
プロファイル
コンフィギュレーション・ファイルの詳細な理解により、Kongクラスタ、使用するデータベース、構成Nginxを最適化できます.公式の参考資料はConfiguration Referenceです.
Kongは、起動時に、-cまたは--confのパラメータでプロファイルを指定できます.たとえば、次のようになります.

kong start -c /path/to/kong.conf

checkコマンドを使用してプロファイルの構文の正確性を検証できます.

$ kong check 
configuration at 
 is valid

Kongの構成はロード時にも同じ名前の環境変数を探して、すべて環境変数でKongを構成することができて、しかも環境変数の優先度は構成ファイルより高いです.環境変数でKongを構成できるため、コンテナベースの導入と実行が容易になります.環境変数を使用する場合は、KONG_フィールドで始まる必要があります.
コマンドラインリファレンス
CLI(コマンドラインインタフェース)を使用すると、Kongインスタンスを起動、停止、管理できます.CLIは、現在のマシンなどのローカルノードを管理することができる.公式サイトのドキュメントCLI Referenceを参照できます
主に以下のコマンドにより
グローバルタグ
すべてのコマンドで次のパラメータを使用できます.

--help:印刷コマンドのヘルプ情報

--v:詳細モード

を開く

--vv:debugモード

を開く
使用可能なコマンド

kong checkプロファイル構文など

をチェック

kong configは、明示的なプロファイルを使用します.

kong healthノード上のkongが

を実行しているかどうかを確認します.

kong migration管理Kongのデータベース

kong prepareこのコマンドは、Kong接頭辞フォルダとそのサブフォルダとファイルを準備します.

kong quit優雅な脱退Kong例

kong reloadリロードkongインスタンス構成

kong restart再起動kongインスタンス

kong start起動kongインスタンス

kong stop停止kongインスタンス

kong version印刷バージョン情報

Admin APIリファレンス
Admin APIの説明は、公式サイトのドキュメント:Admin API Referenceを参照してください.
Admin APIは、各端末に2つの接続タイプを受け入れる.それぞれは

application/x-www-from-urlencoded

application/json

9つのオブジェクトがあり、それぞれ:

Service Object

Route Object

Consumer Object

Plugin Object-Precedence

Certificate Object

CA Certificate Object

SNI Object

Upstream Object

Target Object

Proxyリファレンス
本書では,Kongのルーティング機能と内部動作原理を詳細に説明することにより,そのエージェント機能を紹介する.
Kongは、2つの構成プロパティで調整できるいくつかのインタフェースを開示しています.

proxy_Listenは、クライアントからの共通通信を受信し、上流サービスにエージェントするアドレス/ポートのリストを定義します(デフォルトは8000).

admin_Listenは、アドレスとポートのリストも定義していますが、Kongの構成機能であるAdmin API(デフォルトでは8001)を公開しているため、管理者のみがアクセスできるように制限する必要があります.Proxy Reference

Kongでよく使われる用語は次のとおりです.

client:下流のお客様がKongエージェントポートに要求することを指します.

upstreamサービス:Kongの後ろに自分がいるAPI/serviceを指し、クライアント要求がこれらのAPI/serviceに転送される.

Service:名前の通り、サービスエンティティは上流サービスの抽象です.サービスの例としては、データ変換マイクロサービス、課金API等が挙げられる.

Route:Kongルーティングエンティティを指します.RouteはKongのエントリポイントに入り、一致するリクエストに対してルールを定義し、所定のサービスにルーティングします.

Pluggin:エージェントライフサイクルで実行されるビジネスロジックのセグメントであるKongの「plugins」を指します.プラグインは、管理APIによって構成することができます.グローバル(すべての受信トラフィック)でも、特定のルーティングおよびサービス上で構成することもできます.

ふかへいこうさんしょう
Kongは、複数のバックエンド・サービスに対して、DNSベースの単純な方法と、DNSサーバを必要とせずにサービス登録を可能にするよりダイナミックなリング・バランサとを提供する複数のロード・バランシング要求方法を提供する.
ロード・バランシングは、公式サイトのドキュメントLoad Balancing Referenceを参照してください.
DNSベースの負荷分散
DNSベースのロード・バランシングを使用する場合、バックエンド・サービスの登録はKongの外で行われ、KongはDNSサーバからの更新のみを受信する.
ホスト名が上流名またはDNSホストファイルの名前として解析されていない場合、IPアドレスではなくホスト名を含むホスト定義を使用する各サービスは、DNSベースのロード・バランシングを自動的に使用します.
DNSレコードttl設定(生存時間)は、情報リフレッシュの頻度を決定する.ttlが0の場合、各リクエストは、独自のDNSクエリを使用して解析されます.これはパフォーマンスの損失をもたらしますが、更新/変更の遅延は非常に低くなります.
Aレコード
1つのAレコードは1つまたは複数のIPアドレスに対応するため、ホスト名がAレコードとして解析されると、各バックエンドサービスには独自のIPアドレスが必要となる.
ウェイト情報がないため、すべてのエントリは負荷バランサで同等のウェイトとみなされ、バランサは直接ループします.
SRVレコードSRVレコードは、すべてのIPアドレスの重みとポート情報を含む.バックエンドサービスは、IPアドレスとポート番号の一意の組み合わせによって識別することができる.したがって、1つのIPアドレスは、異なるポート上で同じサービスの複数のインスタンスをベアラすることができる.
ウェイト情報は使用可能であるため、各エントリは負荷バランサで独自のウェイトを取得し、重み付けループを実行します.
DNSの優先度
1、前の解析の最後の成功タイプ2、SRV記録3、A記録4、CNAME記録
これらは、プロファイルのdns_orderで構成することができる.
Ring-balancerベースの負荷等化
Ring-balancerを使用する場合、バックエンドサービスの追加と削除はKongによって処理され、DNS更新は必要ありません.Kongはサービス登録所になります.ノードは、1つのHTTP要求によって追加/削除され、直ちにトラフィックの受信を開始/停止することができる.
Ring-balancer作業を構成するには、Upstreamとtargetの2つのエンティティが必要です.

target:バックエンド・サービスが存在するポート番号を持つIPアドレスまたはホスト名.たとえば.“192.168.100.12:80”.各ターゲットは、相対的な負荷が得られることを示す追加の重みを得る.IPアドレスは、IPv 4およびIPv 6形式であってもよい.

upstream:virtual hostname、ルーティングに使用可能なhostフィールド、例えばupstreamがweatherである.v 2はサービスを受け取るv2.サービスのすべてのリクエスト.

小結
本来,Kongのプロファイル,コマンドライン,エージェント,ロードバランシングなどを大まかに述べている.

Pythonでその日の任意の時間のdatetimeインスタンスを取得する

bzoj 1834:[ZJOI 2010]networkネットワーク拡張(isap+費用フロー)