NGINX Plus R16 の発表

[ngx_snippet name='テーブルスタイルブログ']
NGINX Plus リリース 16 (R16)が利用可能になったことをお知らせします。 本日のリリースは、NGINX の技術的ビジョンを前進させる上で最も重要なものの 1 つです。 R16 では、NGINX Plus はすべてのアプリケーションに対して単一の柔軟な入力層と出力層として機能するようになりました。 つまり、ロードバランサー、API ゲートウェイ、WAF の機能を、あらゆるクラウドにまたがる単一のソフトウェア パッケージに統合できるということです。

今日私たちが話をする多くの企業は、これらの各コンポーネントを持っていますが、多くの場合、異なるベンダーからのものです。 これにより、運用チームが各ポイント ソリューションを個別に管理する必要があるため、コストと複雑さが増大します。 また、ホップが増えるごとにレイテンシと障害ポイントが増えるため、パフォーマンスと信頼性も低下します。

NGINX Plus R16の新機能を使用すると、インフラストラクチャの統合と簡素化を開始し、レガシー アプリケーションと最新アプリケーションの両方に対して弾力性のあるイングレス/エグレス層を設計できるようになります。 NGINX Plus R16には、新しいクラスタリング機能、強化された UDP ロード バランシング、DDoS 緩和が含まれており、高価なF5 BIG-IPハードウェアやその他のロード バランシング インフラストラクチャのより完全な代替品となります。 グローバル レート制限の新たなサポートにより、NGINX Plus は多くの API ゲートウェイ ソリューションの軽量な代替手段となります。 最後に、ランダム 2 つの選択肢によるロード バランシングの新しいサポートにより、NGINX Plus は、Kubernetes などの拡張環境または分散環境でのマイクロサービス トラフィックのロード バランシングに最適な選択肢になります。

NGINX Plus R16の新機能の概要

NGINX Plus R16の新機能は次のとおりです。

• クラスター対応のレート制限– NGINX Plus R15では状態共有モジュールを導入し、NGINX Plus クラスター全体でデータを同期できるようになりました。 このリリースでは、状態共有がレート制限機能に拡張され、NGINX Plus クラスター全体でグローバルなレート制限を指定できるようになりました。 グローバル レート制限は API ゲートウェイにとって重要な機能であり、NGINX Plus で非常によく使用されるユースケースです。
• クラスター対応のキーバリューストア– NGINX Plus R13では、動的 IP アドレスのブラックリストを作成したり、 HTTP リダイレクトを管理したりするために使用できるキーバリューストアを導入しました。 このリリースでは、キー値ストアをクラスター全体で同期できるようになり、新しいタイムアウトパラメータが含まれるようになったため、個々のキー値ペアを自動的に削除できるようになりました。 新しい同期サポートにより、キー値ストアを使用して、動的な DDoS 軽減策を提供したり、認証されたセッション トークンを配布したり、分散コンテンツ キャッシュ (CDN) を構築したりできるようになりました。
• 2 つの選択肢によるランダムな負荷分散- ロード バランサーをクラスタリングする場合、個々のバックエンド サーバーに誤って過負荷をかけない負荷分散アルゴリズムを使用することが重要です。 2 つの選択肢によるランダムなロード バランシングは、スケールされたクラスターにとって非常に効率的であり、Kubernetes 用の NGINX Ingress Controller の次のリリースではデフォルトの方法になります。
• 強化された UDP ロード バランシング- NGINX Plus R9で初めて UDP ロード バランシングを導入しました。 この最初の実装は、サーバーとのやり取りごとにクライアントから 1 つの UDP パケットを期待する UDP アプリケーション (DNS や RADIUS など) に限定されていました。 NGINX Plus R16 はクライアントからの複数の UDP パケットを処理できるため、OpenVPN、Voice over IP (VoIP)、仮想デスクトップ インフラストラクチャ (VDI) などのより複雑な UDP プロトコルをサポートできます。
• AWS PrivateLink サポート– AWS PrivateLinkは、仮想プライベートクラウドへの安全な VPN トンネルを作成するための Amazon のテクノロジーです。 このリリースでは、トラフィックの認証、ルーティング、負荷分散、AWS PrivateLink データセンター内でのトラフィックの流れの最適化が可能になりました。 この機能は、 PROXY プロトコル v2の新しいサポートに基づいて構築されています。

その他の機能強化には、OpenID Connect 不透明セッション トークンのサポート、暗号化セッション動的モジュール、NGINX JavaScript モジュールの更新などがあります。 NGINX Plus R16 はNGINX Open Source 1.15.2 をベースとしており、オープン ソース リリースのすべての機能が含まれています。

NGINX Plus R16の開発中に、NGINX Plus の代表的なユースケースである Kubernetes 用の公式 NGINX Ingress Controller にも、いくつかの重要な機能強化が追加されました。

NGINX Conf 2018で、 NGINX Plus R16と NGINX に関するすべての詳細を学びましょう。 すべての新機能について詳しく説明するために、専用のセッション、デモ、専門家を用意しています。

行動における重要な変化

• 統合されたNGINX Plus APIに置き換えられ、非推奨となった Upstream Conf および Status API は削除されました。 2017 年 8 月、 NGINX Plus R13では、アップストリーム グループの動的な再構成とメトリックの監視を行うまったく新しいNGINX Plus APIが導入され、これまでこれらの機能を実装していた Upstream Conf および Status API が置き換えられました。 当時発表されたとおり、廃止された API はかなりの期間にわたって引き続き利用可能でサポートされていましたが、現在はその期間が終了しています。 設定にupstream_conf ディレクティブやstatusディレクティブが含まれている場合は、R16 へのアップグレードの一環として、それらをapiディレクティブに置き換える必要があります。

  新しいNGINX Plus APIへの移行に関するアドバイスやサポートについては、ブログの移行ガイドを参照するか、サポート チームにお問い合わせください。

• サポート終了 OS バージョンのサポート終了– NGINX Plus は、Ubuntu 17.10 (Artful) 、FreeBSD 10.3、FreeBSD 11.0 ではサポートされなくなりました。

  サポートされているプラットフォームの詳細については、 NGINX Plusおよび動的モジュールの技術仕様を参照してください。

• NGINX New Relic プラグインは、新しいNGINX Plus API を使用するように更新され、オープンソース プロジェクトになりました。 更新されたプラグインは、NGINX Plus の R13 以降のすべてのバージョンで動作しますが、NGINX, Inc. によるサポートやメンテナンスは行われなくなりました。

新機能の詳細

クラスター対応レート制限

NGINX Plus R15 では、クラスター内のすべての NGINX Plus ノード間でランタイム状態を共有できるようにするzone_syncモジュールが導入されました。

最初の同期機能は、スティッキー ラーン セッション永続性でした。 NGINX Plus R16 では、状態共有がレート制限機能に拡張されています。 クラスターにデプロイすると、NGINX Plus は、リクエストがクラスターのどのメンバーノードに到着するかに関係なく、受信リクエストに一貫したレート制限を適用できるようになりました。 一般的にグローバル レート制限として知られている、クラスター全体に一貫したレート制限を適用することは、API ゲートウェイのユースケースに特に関連しており、クライアントが指定されたレート制限を超えないようにするサービス レベル アグリーメント (SLA) に従って API を配信します。

NGINX Plus の状態共有ではプライマリノードは必要なく、プライマリノードも使用しません。すべてのノードはピアであり、フルメッシュトポロジでデータを交換します。 NGINX Plus 状態共有クラスターは、次の 3 つの要件を満たす必要があります。

• すべてのクラスタノード間のネットワーク接続
• 同期された時計
• 次のスニペットのように、 zone_syncモジュールを有効にするすべてのノード上の構成。

ストリーム { リゾルバー 10.0.0.53 有効 = 20 秒; サーバー { リッスン 10.0.0.1:9000;ゾーン同期;ゾーン同期サーバーnginx-cluster.example.com:9000 解決; } }

zone_syncディレクティブは、クラスター内の共有メモリ ゾーンの同期を有効にします。 zone_sync_serverディレクティブは、クラスター内の他の NGINX Plus インスタンスを識別します。 NGINX Plus は DNS サービス検出をサポートしているため、クラスター ノードをホスト名で識別でき、すべてのノードで構成が同一になります。 これは最小限の構成であり、本番環境への展開に必要なセキュリティ制御が含まれていないことに注意してください。 詳細については、 NGINX Plus R15 の発表とzone_syncモジュールのリファレンス ドキュメントを参照してください。

この構成がすべてのノードに適用されると、 limit_req_zoneディレクティブに新しいsyncパラメータを追加するだけで、クラスター全体にレート制限を適用できるようになります。 次の構成では、NGINX Plus はクライアントの IP アドレスに基づいて、各クライアントに 1 秒あたり 100 リクエストのレート制限を課します。

limit_req_zone $remote_addr zone=per_ip:1M rate=100r/s sync ; # クラスター対応サーバー { listen 80; location / { limit_req zone=per_ip; # ここでレート制限を適用 proxy_pass http://my_backend; } }

さらに、状態共有クラスタリング ソリューションは、ネットワークの復元力のためのkeepalivedベースの高可用性ソリューションからは独立しています。 したがって、そのソリューションとは異なり、状態共有クラスターは物理的な場所にまたがることができます。

クラスター対応のキーバリューストア

NGINX Plus R13 では、ネイティブ NGINX モジュールとして軽量のインメモリ キー値ストアが導入されました。 このモジュールは NGINX Plus に同梱されており、追加のソフトウェア コンポーネントをインストールせずに、シンプルなデータベース ストレージを必要とするソリューションを構成できます。 さらに、キー値ストアはNGINX Plus APIを通じて制御されるため、REST インターフェイスを通じてエントリを作成、変更、削除できます。

NGINX Plus キー値ストアの使用例には、動的 IP アドレスのブラックリスト、動的帯域幅制限、認証トークンのキャッシュなどがあります。

NGINX Plus R16では、キー値ストアがクラスター対応になり、クラスター内のすべてのノード間でエントリが同期されるようになりました。 つまり、NGINX Plus キーバリューストアを使用するソリューションは、アクティブ/パッシブ、アクティブ/アクティブ、さらには広範囲に分散されたあらゆる種類のクラスター環境に導入できます。

その他のクラスター対応機能については、状態共有 ( zone_syncおよびzone_sync_serverディレクティブを使用) がすでに構成されているクラスターのkeyval_zoneディレクティブにsyncパラメータを追加するだけで、キー値ストアの同期を構成できます。

キー値ストアも拡張され、キー値ストアに追加された各キー値ペアにタイムアウト値を設定する機能も追加されました。 このようなエントリは、指定されたタイムアウト期間が経過すると自動的に期限切れになり、キー値ストアから削除されます。 同期されたキー値ストアを構成する場合、タイムアウトパラメータは必須です。

動的 DDoS 防御のための NGINX Plus キーバリューストアの使用

NGINX Plus の新しいクラスタリング機能を組み合わせて、DDoS 攻撃から保護する高度なソリューションを構築できます。 NGINX Plus インスタンスのプールがアクティブ/アクティブ クラスターに展開されている場合、または広域ネットワーク全体に分散されている場合、悪意のあるトラフィックがそれらのインスタンスのいずれかに到達する可能性があります。 このソリューションは、次のように、同期されたレート制限と同期されたキー値ストアを使用して、DDoS 攻撃に動的に応答し、その影響を軽減します。

• クラスター対応のレート制限は、どの NGINX Plus ノードがリクエストを受信するかに関係なく、1 秒あたり 100 件を超えるリクエストを送信するクライアントをキャッチします。
• クライアントがレート制限を超えると、 NGINX Plus APIを呼び出して、その IP アドレスが「sin bin」キー値ストアに追加されます。sin bin はクラスター全体で同期されます。
• sin bin 内のクライアントからのさらなるリクエストは、どの NGINX Plus ノードがそれを受信するかに関係なく、非常に低い帯域幅制限の対象となります。 帯域幅を制限すると、DDoS 軽減策が有効になっていることがクライアントに明確に伝わらないため、リクエストを完全に拒否するよりも好ましい方法です。
• 10 分後、クライアントは自動的に sin bin から削除されます。

次の構成は、この動的 DDoS 軽減ソリューションの簡略化された実装を示しています。

limit_req_zone $remote_addr zone=per_ip:1M rate=100r/s sync; # クラスター対応のレート制限limit_req_status 429;

keyval_zone zone=sinbin:1M timeout=600 sync; # クラスター対応の「sin bin」 
# 10 分の TTL
keyval $remote_addr $in_sinbin zone=sinbin; # 一致したクライアント IP アドレスを $in_sinbin に入力します

server {
listen 80;
location / {
if ($in_sinbin) {
set $limit_rate 50; # 不正なクライアントの帯域幅を制限します
}

limit_req zone=per_ip; # ここでレート制限を適用します
error_page 429 = @send_to_sinbin; # 過剰なクライアントは 
# この場所に移動します
proxy_pass http://my_backend;
}

location @send_to_sinbin {
rewrite ^ /api/3/http/keyvals/sinbin break; # 「sin bin」キー値の URI を設定します
proxy_method POST;
proxy_set_body '{"$remote_addr":"1"}';
proxy_pass http://127.0.0.1:80;
}

location /api/ {
api write=on;
# API へのアクセスを制御するディレクティブ
}
}

2つの選択肢を持つランダムな負荷分散

アプリケーション配信環境と API 配信環境の両方で、拡張または分散された負荷分散層を使用してクライアント要求を受信し、共有アプリケーション環境に渡すことがますます一般的になっています。 複数のロード バランサが同じバックエンド サーバーのセットにリクエストを渡す場合、個々のバックエンド サーバーに誤って過負荷をかけないロード バランシング メソッドを使用することが重要です。

アクティブ/アクティブ構成で展開された NGINX Plus クラスター、または複数のエントリ ポイントを持つ分散環境では、各ロード バランサーがバックエンド サーバーに送信されたすべてのリクエストを完全に把握できないため、従来のロード バランシング方法に課題が生じる一般的なシナリオになります。

コンテナ化されたクラスター内の負荷分散は、スケールアウトされたアクティブ アクティブ展開と同じ特性を持ちます。 Ingress リソースの複数のインスタンスを含むレプリカ セットにデプロイされた Kubernetes Ingress コントローラーは、クラスター内の各サービスを提供するポッドに負荷を効果的に分散する方法という課題にも直面します。

ワークロードの変動は、分散負荷分散の有効性に大きな影響を与えます。 各リクエストがバックエンド サーバーに同じ負荷をかける場合、各サーバーが以前のリクエストにどれだけ速く応答したかを測定することは、次のリクエストをどこに送信するかを決定する効果的な方法です。 NGINX Plus 独自のLeast Timeロード バランシング メソッドがまさにそれを実現します。 しかし、バックエンド サーバーの負荷が変動する場合 (たとえば、読み取り操作と書き込み操作の両方が含まれる場合)、過去のパフォーマンスは将来のパフォーマンスを示す指標としては不十分です。

分散環境で負荷を分散する最も簡単な方法は、バックエンド サーバーをランダムに選択することです。 時間が経つにつれて負荷は平均化されますが、これは粗雑なアプローチであり、時々個々のサーバーにトラフィックの急増が送信される可能性があります。

ランダム負荷分散の単純なバリエーションですが、負荷分散を改善することが証明されているのは、2 つのバックエンド サーバーをランダムに選択し、負荷が最も低いサーバーにリクエストを送信することです。 2 つのランダムな選択を比較する目的は、たとえ決定が最適でなかったとしても、不適切な負荷分散の決定を下すことを避けることです。 負荷の高いバックエンド サーバーを回避することで、各ロード バランサーは独立して動作し、個々のバックエンド サーバーにトラフィックの急増が送信されるのを回避できます。 その結果、この方法はランダム負荷分散の利点と計算効率を備えながら、明らかに優れた負荷分散を実現します。

NGINX Plus R16 では、ランダムと 2 つの選択肢によるランダムという 2 つの新しい負荷分散方法が導入されました。 後者の場合、NGINX Plus がどの負荷表示メトリックを比較して、選択した 2 つのバックエンドのどちらがリクエストを受信するかをさらに指定できます。 次の表に、使用可能なメトリックを示します。

* すべての時間ベースのメトリクスはNGINX Plus専用です

次のスニペットは、 random twoディレクティブ ( HTTP 、 Stream ) を使用した Random with Two Choices ロード バランシング構成の簡単な例を示しています。

アップストリーム my_backend { zone my_backend 64k; server 10.0.0.1; server 10.0.0.2; server 10.0.0.3; #... random two least_time=last_byte; # 2 つのランダムな選択肢から応答時間の速い方を選択します } server { listen 80; location / { proxy_pass http://my_backend; # アップストリーム グループに負荷分散します } }

2 つの選択肢によるランダム方式は、複数のロード バランサーが同じバックエンド セットにリクエストを渡す分散環境にのみ適していることに注意してください。 NGINX Plus が単一のホストにデプロイされている場合、またはアクティブ/パッシブ デプロイされている場合は使用しないでください。 このような場合、単一のロード バランサがすべてのリクエストを完全に把握し、ラウンド ロビン、最小接続、最小時間の方法によって最良の結果が得られます。

強化されたUDP負荷分散

NGINX Plus R9 では、 UDP トラフィックのプロキシと負荷分散のサポートが導入され、NGINX Plus を DNS、syslog、NTP、RADIUS などの一般的な UDP アプリケーションの前面に配置して、アプリケーション サーバーの高可用性とスケーラビリティを実現できるようになりました。 初期の実装は、サーバーとのやり取りごとにクライアントから 1 つの UDP パケットが送信されることを想定する UDP アプリケーションに限定されていました。

NGINX Plus R16では、複数の着信パケットがサポートされるため、より複雑な UDP アプリケーションをプロキシして負荷分散することができます。 これには、OpenVPN、VoIP、仮想デスクトップ ソリューション、およびデータグラム トランスポート層セキュリティ (DTLS) セッションが含まれます。 さらに、NGINX Plus によるすべての UDP アプリケーション (単純なものから複雑なものまで) の処理も大幅に高速化されます。

NGINX Plus は、最も一般的な 4 つの Web プロトコル (UDP、TCP、HTTP、HTTP/2) を同じインスタンスで同時に負荷分散する唯一のソフトウェア ロードバランサーです。

PROXY プロトコル v2 のサポート

NGINX Plus R16 では、 PROXY プロトコル v2 (PPv2) ヘッダーのサポートと、ヘッダー内のカスタムタイプ、長さ、値(TLV) 値を検査する機能が追加されました。

PROXY プロトコルは、NGINX Plus や Amazon のロードバランサーなどのレイヤー 7 プロキシによって使用され、別のレイヤー 7 プロキシ セットまたは NAT デバイスの背後にあるアップストリーム サーバーに接続情報を送信します。 これが必要なのは、プロキシが接続を中継するときに、送信元 IP アドレスやポートなどの一部の接続情報が失われる可能性があり、この情報を送信するために HTTP ヘッダー インジェクションに頼ることが常に可能であるとは限らないためです。 以前のバージョンの NGINX Plus では PPv1 ヘッダーがサポートされていましたが、 NGINX Plus R16 ではPPv2 ヘッダーのサポートが追加されました。

Amazon Network Load Balancer で PPv2 を使用する

PPv2 ヘッダーの使用例の 1 つは、Amazon のネットワーク ロード バランサー (NLB) によって中継される接続です。この接続は、ロード バランサー上のプライベート IP アドレスから発信されたように見える場合があります。 NLB は、クライアントの接続の実際の送信元 IP アドレスとポートを識別する PPv2 ヘッダーを各接続のプレフィックスとして付加します。 実際のソースは$proxy_protocol_addr変数から取得でき、 realipモジュールを使用してNGINX の内部ソース変数を PPv2 ヘッダーの値で上書きできます。

AWS PrivateLink で PPv2 を使用する

AWS PrivateLinkは、仮想プライベートクラウド (VPC) への安全な VPN トンネルを作成するための Amazon のテクノロジーです。 これは通常、プロバイダー サービス (プロバイダー VPC で実行) を公開し、1 つ以上のクライアント VPC で利用できるようにするために使用されます。 プロバイダー サービスへの接続は、プロバイダー VPC で実行されている NLB から発信されます。

多くの場合、プロバイダーサービスは各接続の発信元を知る必要がありますが、PPv2 ヘッダーの送信元 IP アドレスは基本的に意味がなく、クライアント VPC 内のルーティングできない内部アドレスに対応しています。AWS PrivateLink NLB は、PPv2 TLV レコード0xEAを使用して、送信元 VPC ID をヘッダーに追加します。

NGINX Plus は PPv2 TLV レコードを検査し、 $proxy_protocol_tlv_0xEA変数を使用して AWS PrivateLink 接続のソース VPC ID を抽出できます。 これにより、AWS PrivateLink データセンターでトラフィックを認証、ルーティング、制御できるようになります。

NGINX Plus R16のその他の新機能

OpenID Connect 不透明セッショントークン

NGINX Plus OpenID Connect リファレンス実装は、不透明なセッション トークンをサポートするように拡張されました。 このユースケースでは、JWT ID トークンはクライアントに送信されません。 代わりに、NGINX Plus キー値ストアに保存され、その代わりにランダムな文字列が送信されます。 クライアントがランダムな文字列を提示すると、それが JWT と交換され、検証されます。 このユースケースはプロトタイプ/実験段階から本番レベルにアップグレードされ、キー値ストアのエントリにタイムアウト値を設定できるようになり、クラスター全体で同期できるようになりました。

暗号化セッション動的モジュール

暗号化セッションコミュニティ モジュールは、MAC を使用した AES-256 に基づく NGINX 変数の暗号化と復号化のサポートを提供します。これは、 NGINX Plus でサポートされている動的モジュールとして、NGINX Plus リポジトリで利用できるようになりました。

NGINX JavaScript モジュールの機能強化

R16 の NGINX JavaScript モジュールには、JavaScript 言語サポートの範囲に対する多数の拡張機能が含まれています。 HTTP JavaScript モジュールが簡素化され、単一のオブジェクト( r ) が各リクエストに関連付けられたリクエスト属性とレスポンス属性の両方にアクセスできるようになりました。 以前は、リクエスト ( req ) オブジェクトとレスポンス ( res ) オブジェクトが別々にありました。 この簡素化により、HTTP JavaScript モジュールは、単一のセッションオブジェクトを持つ Stream JavaScript モジュールと一貫性を持つようになります。 この変更は完全に下位互換性があり、既存の JavaScript コードはそのまま動作しますが、この簡素化を活用するために既存の JavaScript コードを変更し、今後作成するコードでも使用することをお勧めします。

JavaScript 言語サポートには以下が含まれるようになりました:

• 文字列メソッド: bytesFrom () 、 padStart() 、 padEnd()
• 追加メソッド: getrandom()およびgetentropy()
• バイナリリテラル

JavaScript モジュールへの変更の完全なリストは、変更ログに記載されています。

新しい$ssl_preread_protocol変数

新しい$ssl_preread_protocol変数を使用すると、TCP (ストリーム) プロキシを使用してトラフィックを転送するときに、SSL/TLS と他のプロトコルを区別できます。 変数には、クライアントがサポートする最高の SSL/TLS プロトコル バージョンが含まれます。 これは、たとえば SSL/TLS と SSH サービスを同じポートで実行してファイアウォールの制限を回避する場合に便利です。

詳細については、弊社のブログの「同じポートで SSL プロトコルと非 SSL プロトコルを実行する」を参照してください。

Kubernetes Ingress コントローラーの機能強化

NGINX Plus は幅広い環境でトラフィックを管理できますが、重要な使用例の 1 つはKubernetes の Ingress ロードバランサーとしての使用です。 NGINX は、NGINX Plus を自動的に構成するIngress コントローラーソリューションを開発しており、この統合はすべての NGINX Plus サブスクライバーに対して完全にサポートされています。 (すべての NGINX オープンソース ユーザーと NGINX Plus 顧客は、GitHub でオープンソース実装を見つけることができ、正式なリリースが定期的に行われます。)

NGINX Plus R16の開発中に、Kubernetes 用の公式 NGINX Ingress Controller にいくつかの重要な機能強化が追加されました。

• Prometheus サポートにより、ユーザーは NGINX および NGINX Plus メトリックを Kubernetes 上の Prometheus に直接エクスポートできます。
• Helm チャートのサポートにより、 Ingress コントローラーのインストールと管理が簡素化されます。
• gRPC トラフィックの負荷分散のサポートにより、 gPRC ベースのアプリケーションに高い可用性とスケーラビリティが提供されます。 (リリース 1.2.0 で追加されました。)
• Kubernetes ポッドのアクティブ ヘルス チェックにより、ポッドおよびネットワーク接続の障害が迅速に検出されます。
• マルチテナントのマージ可能な構成により、関心の分離が可能になり、運用部門はフロントエンド リスナーと SSL 構成の制御を維持しながら、チームが同じ Web アプリケーションの異なるパスを個別に管理できるようになります。
• パスごとにきめ細かな JWT 認証を行うことで、リッチ アプリケーションの認証をより細かく制御できます。
• 構成テンプレートを直接管理することで、 NGINX 構成に対するカスタム変更の開発とテストがはるかに簡単になります。

NGINX Ingress Controller は、 ConfigMaps (NGINX 構成を埋め込む) を使用するか、基本テンプレートを編集することでさらに拡張でき、ユーザーは Kubernetes 上で実行されているアプリケーションのトラフィック管理ポリシーを作成するときに、すべての NGINX 機能にアクセスできるようになります。

詳細については、弊社のブログの「NGINX Ingress Controller for Kubernetes リリース 1.3.0 の発表」をご覧ください。

NGINX Plus をアップグレードまたは試用する

NGINX Plus R16には、追加のクラスタリング機能、グローバル レート制限、新しい負荷分散アルゴリズム、およびいくつかのバグ修正が含まれています。 NGINX Plus を実行している場合は、できるだけ早く R16 にアップグレードすることを強くお勧めします。 数多くの修正と改善が行われ、サポート チケットを発行する必要があるときに NGINX, Inc. がサポートしやすくなります。

アップグレードを進める前に、このブログ投稿に記載されている新機能と動作の変更をよく確認してください。

NGINX Plus をまだお試しいただいていない方は、Web アクセラレーション、負荷分散、アプリケーション配信、または強化された監視および管理 API を備えた完全にサポートされた Web サーバーとして、ぜひお試しください。 30 日間の無料トライアルで今日から無料で始めることができます。 NGINX Plus がアプリケーションの配信と拡張にどのように役立つかを実際にご確認ください。