OpenNJet KIC V2.0 がリリースされました!

[深セン] 源創輝: 午後 5 時 26 分、パーティー会場があなたを待っています。」

NGINX はクラウドネイティブに進化し、すべて OpenNJetで実現

概要

OpenNJet KIC (Kubernetes Ingress Controller) は、OpenNJet プロキシの動的特性と高性能実装に基づいています。クラウドネイティブシナリオにおける nginx の欠点を補います。動的ロケーション、ホスト/パスルーティング、ロードバランシング、動的アップストリーム、カナリアパブリッシング、TLS 終端/SNI、TCP/UDP、WebSocket などの豊富なトラフィック管理機能を提供します。

このバージョンの主な機能:

シャーディング処理をサポート Ingress/VS CR
ADCとの統合をサポート
HTTPヘッダー操作のサポート
TCPプロキシをサポート
クロスネームスペースのサポート
WebSocketプロキシをサポート
UDPプロキシをサポート
動的 NJet VS/アクセスログをサポート
TCPアクティブヘルスチェックをサポート
ワーカープロセス数の動的な調整をサポート

この記事では、これらの新機能について簡単に紹介します。

アーキテクチャ図は次のとおりです。

新機能の概要

シャーディング処理 Ingress/VS CR

さまざまな Ingress/VS リソースを処理するための特別な KIC があります。これが KIC シャーディングメカニズムです。

さまざまな Ingress/VS リソースは ingressClass によって識別されます。Ingress リソースはアノテーション kubernetes.io/ingress.class または spec.ingressClassName によって識別でき、VS リソースは spec.ingressClassName によって識別できます。

このシャーディングメカニズムの各 KIC は KIC のタイプと呼ばれ、k8s クラスターでは複数の Njet KIC がある場合、複数の IngressClass オブジェクトを作成する必要があることに注意してください。 KIC の各タイプは複数のコピーを持つことができます (k8s アーキテクチャの複数のポッドに対応します)。

シャーディングメカニズムにより、各 KIC は、k8s クラスター内のすべての Ingress/VS リソースではなく、関心のある独自の Ingress/VS リソースを持つようになります。単一タイプの KIC では完全構成の圧力に耐えられないという問題を解決することを目的としています。

ADCとの統合

KIC が ADC と統合されると、ADC は KIC のフロントエンド LB として機能し、ADC を通じてクライアントトラフィックを管理し、最終的には KIC サービスへの負荷分散を行うことができます。 KIC は次の機能を完了しました。

ADC ドメイン名登録: KIC は、k8s Ingress や vs CR を通じて管理されるサービスなど、KIC によって管理される k8s クラスター内のサービスのドメイン名を ADC に登録します。この機能により、クライアントはドメイン名を通じて直接リクエストを行うことができます (ADC の DNS サーバーをデフォルトの DNS サーバーとして構成する必要があります)。
ADC SlbPool 登録: KIC は、KIC サービスに関連付けられたアプリケーションプール (nodeIP+nodePort) を ADC に登録します。この機能により、ADC が KIC サービスにルーティングできるようになります。
ADC VS 登録: KIC は VS を ADC に登録し、2 番目のステップで作成されたアプリケーションプールに関連付けます。この機能により、クライアントは VS に直接アクセスできるようになり、ADC が KIC のフロントエンド LB として機能できるようになります。

ADC VS の VIP は、KIC によって管理されるサービスのドメイン名に対応します。
ADC VS の VIP はパブリックネットワーク IP であり、外部クライアントから直接アクセスできます。

全体構造

シーングラフ:

インタラクションアーキテクチャ図:

HTTPヘッダーの操作

OpenNJet KIC ヘッダー操作は、クライアント要求ヘッダーを変更し、プロキシされたサービスの応答ヘッダーを操作できます。ユーザー定義のヘッダーと HTTP 仕様で定義されたヘッダーが含まれます。

TCPプロキシ

KIC TCP プロキシは、アップストリーム TCP サービスをプロキシできます。 TCP プロキシは負荷分散機能を提供します。 TCP プロキシは完全に動的に実装されており、OpenNJet がリロード操作を実行する必要はありません。

プロキシされた TCP サービスには独自のリスニングポートがあり、プロキシされたサービスが増えるほど、より多くのポートがリッスンする必要があります。リロードの問題を解決するために、新しいリッスンのたびにポート転送が必要になります。 . このメソッドは、TCP サービスのプロキシを実装します。具体的なデザインは以下の通りです。

OpenNJet ストリーム設定は 12003 ポートを事前にリッスンします (プロキシ TCP サービスによって監視されるポートは 12003 にリダイレクトされます)。
KIC は、顧客定義 API を通じて iptables ルールを生成し、要求された TCP サービスポートを iptables ルールを通じてポート 12003 にリダイレクトします。
OpenNJetストリームがクライアント経由でアクセスする「TCPサービスポート」は、お客様がAPIを通じて事前に設定したアップストリームと一致します。このプロセスはストリームマップを通じて照合されます。
OpenNJet ストリームは、正常に一致したアップストリームのサーバーにクライアントリクエストを送信します (負荷分散はストリーム lua によって実装されます)。

iptables ルールとマップコンテンツの更新は API を使用して動的に更新され、リロード操作が回避されます。

OpenNJet 構成は次のように実装されます。

 map $njtmesh_port \$stream_upstream {
 }
 
 server {
 listen 12003 mesh;
 set $proxy_upstream_name \$stream_upstream;
 proxy_pass upstream_balancer;
 }

クライアントによって要求されたポートは、常に TransportServer のリスナーのポートです。
このポートは KIC によって内部的に使用されるため、プロキシサービスでは使用できません。説明については次の表で説明します。

ポート	説明する
80	httpプロキシ
443	httpsプロキシ
12001	OpenNJet コントロールプレーン
12002	tcp lua アップストリーム
12003	TCPプロキシポート
12004	UDPプロキシポート
8080	stub_status と http lua アップストリーム
8081	KIC ポッド準備ポート

名前空間間で

K8 の組み込み Ingress は、同じ ns 内のサービスのルーティングのみを処理でき、ns をまたぐ操作は実行できません。クロスネームスペース構成機能は、この制限を解決します。

Ingress がサポートするクロス名前空間構成に加えて、VS もクロス ns 構成をサポートしており、ユーザーは独自の状況に応じて選択できます。

Ingress は、さまざまな Ingress タイプを通じてこの機能を実装します。Ingress 自体にはタイプの概念はありません。「njet.org.cn/mergeable-ingress-type」という注釈を追加することでそれを表現します。注釈は次の表から値を取得できます。

価値	説明する	述べる
マスター	メインイングレス	1つ
ミニオン	FromIngress	複数の可能性があり、ホストを介してマスター Ingress に関連付けられます

同じホストのマスターとミニオンは、同じ ns に存在することも、異なる ns に存在することもできます。

Cross-ns 構成に加えて、ホストに多数のパスがあり、単一の Ingress の保守が複雑な場合に、この機能を選択してパスを管理することもできます。

VS CR は Ingress と同じ機能を持ちますが、実装方法が異なります。VS CR は、サブルートリソースを参照することによってクロス ns 構成を実行します。サブルートは、VSR を表すために使用されます。 VSR は K8s CR であり、この機能のために導入された新しい CR です。

WebSocketプロキシ

WebSocket は、独立した TCP ベースのアプリケーション層プロトコルであり、全二重通信プロトコルです。 HTTP との唯一の関係は、そのハンドシェイクが HTTP サーバーによって HTTP アップグレード要求として解釈されることですが、ハンドシェイクは HTTP とは何の関係もありません。このプロトコルには、ハンドシェイクとデータ転送の 2 つの部分があります。ハンドシェイクフェーズを次の図に示します。

Ingress は、アノテーションを追加することでこの機能を実装します。これは、アノテーション "njet.org.cn/websocket-services" を追加することで表現されます。

注釈名	値の形式	説明する
njet.org.cn/websocket-services	service,service2 (カンマ区切りのサービス名)	Webソケットのサポート

VS には設定は必要ありません。

UDPプロキシ

KIC UDP プロキシは、アップストリーム UDP サービスをプロキシできます。 UDP プロキシは負荷分散機能を提供します。 UDP プロキシは完全に動的に実装されており、OpenNJet がリロード操作を実行する必要はありません。

UDP サービスプロキシの実装は、基本的に TCP サービスプロキシと同じですが、OpenNJet ストリーム設定が 12004 ポートを事前リッスンするのに対し (プロキシ UDP サービスによって監視されるポートは 12004 にリダイレクトされます)、TCP は 12004 ポートを事前リッスンする点が異なります。 12003ポート。詳細な手順については、「TCP プロキシ」を参照してください。

OpenNJet 構成は次のように実装されます。

map $njtmesh_port \$stream_upstream_udp {
}

server {
listen 12004 udp mesh;
set $proxy_upstream_name $stream_upstream_udp;
proxy_pass upstream_balancer;
}

ダイナミックNJet VS

最初のバージョンと比較して、HTTP ホストヘッダーのマッチングとパスマッチングを実現するために、単一サーバーと複数の場所のアプローチを、複数のサーバーと複数の場所のアプローチに変更しました。ホストヘッダーのマッチングの実装には、nginx 標準の server_name を使用しました。はい、リロード操作は必要ありません。 2 番目のバージョンでは、Ingress と VirtualServer の追加機能は追加されません。

動的アクセスログ

KIC アクセスログ機能を使用すると、アクセスログポリシー (スイッチステータスやアクセスログファイルパスを含む) を特定のアプリケーションに個別に適用できます。 njet-config ConfigMap を通じてグローバル設定を行うこともできますが、「アクセスログポリシーをアプリケーションに個別に適用する」方が優先されます。

TCP プロアクティブなヘルスチェック

トランスポートサーバーリソースの場合、TCP ポートの構成がサポートされており、アクティブなヘルスチェックは、構成されたチェック間隔に従って TCP ポートが正常にリッスンしているかどうかを検出し、チェック結果に基づいてバックエンドがオンラインまたはオフラインになります。

apiVersion: k8s.njet.org/v1alpha1
 kind: TransportServer
 metadata:
 name: testapp-tcp
 spec:
 listener:
 name: test-tcp
 protocol: TCP
 upstreams:
 - name: testapp1
 service: testapp
 port: 80
 healthCheck:
 enable: true
 interval: 20s
 timeout: 5s
 fails: 1
 passes: 1
 port: 83
 action:
 pass: testapp1

構成手順は次のとおりです。

分野	説明する	タイプ	必要ですか?
有効にする	ヘルスチェックを有効にするかどうか、デフォルトは false	ブール値	いいえ
間隔	チェック間の間隔。デフォルトは5です	弦	いいえ
失敗する	数回失敗すると、オフラインとみなされます。デフォルト 1 回	整数	いいえ
パスする	いくつかの成功を経て、オンライン化が検討される予定です。デフォルト 1 回	整数	いいえ
ポート	ヘルスチェックサービスが配置されているポート	整数	いいえ
タイムアウト	ヘルスチェック接続タイムアウト	弦	いいえ

ワーカープロセス数の動的な調整

ConfigMap リソースを介した njet インスタンスのワーカープロセスの数の構成をサポートします。ConfigMap の構成項目が更新された後、ワーカープロセスの数は動的に変更されます。

設定項目	説明する	フィールドタイプ	デフォルト値	述べる
ワーカープロセス	ワーカープロセスの数 (許容値 1 ～ 512)	弦	デフォルトは、CPU コアの数に基づいて auto によって自動的に生成されるプロセスの数です。

参考リンク

OpenNJetKIC ユーザーマニュアル

OpenNJet KIC ソースコードアドレス

NJet アプリケーションエンジンは、カーネルの再構築を通じて独自のランタイム動的構成読み込み機能を実現し、新世代の高性能 Web アプリケーションエンジンです。 NJet は、高性能のデータプレーン処理機能を備えており、NJet 独自のコパイロット CoPilot サービスフレームワークを通じて、クラスタリング、高可用性、アクティブヘルスチェック、宣言型 API などの複数の補助機能をスケジュールして、機能拡張を促進し、管理/制御機能ペアを分離します。データプレーンへの影響を考慮すると、NJet アプリケーションエンジンのパフォーマンスは、CNCF が推奨する Envoy アプリケーションエンジンの 3 倍を超えています。メールグループ公式サイト