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 によって自動的に生成されるプロセスの数です。 |
参考リンク
「Qing Yu Nian 2」の海賊版リソースが npm にアップロードされたため、npmmirror は unpkg サービスを停止せざるを 得なくなりました。 周宏儀: すべての製品をオープンソースにすることを提案します 。ここで time.sleep(6) はどのような役割を果たしますか? ライナスは「ドッグフードを食べる」ことに最も積極的! 新しい iPad Pro は 12GB のメモリ チップを使用していますが、8GB のメモリを搭載していると主張しています。People 's Daily Online は、オフィス ソフトウェアのマトリョーシカ スタイルの充電についてレビューしています。「セット」を積極的に解決することによってのみ、 Flutter 3.22 と Dart 3.4 のリリース が可能になります。 Vue3 の新しい開発パラダイム、「ref/reactive」、「ref.value」不要 MySQL 8.4 LTS 中国語マニュアルリリース: データベース管理の新しい領域の習得に役立ちます Tongyi Qianwen GPT-4 レベルのメイン モデルの価格が値下げされました97%、1元と200万トークンNJet アプリケーション エンジンは、カーネルの再構築を通じて独自のランタイム動的構成読み込み機能を実現し、新世代の高性能 Web アプリケーション エンジンです。 NJet は、高性能のデータ プレーン処理機能を備えており、NJet 独自のコパイロット CoPilot サービス フレームワークを通じて、クラスタリング、高可用性、アクティブ ヘルス チェック、宣言型 API などの複数の補助機能をスケジュールして、機能拡張を促進し、管理/制御機能ペアを分離します。データ プレーンへの影響を考慮すると、NJet アプリケーション エンジンのパフォーマンスは、CNCF が推奨する Envoy アプリケーション エンジンの 3 倍を超えています。メールグループ公式サイト