NGINX ゲートウェイ ファブリック リリース 1.2.0 の発表

Kubernetes Gateway API に準拠した実装である NGINX Gateway Fabric の最新ニュースをお知らせできることを嬉しく思います。最近、いくつかのエキサイティングな新機能と改善を加えてバージョン 1.2.0 にアップデートしました。 このリリースでは、プラットフォームの機能を強化し、ユーザーの要求を満たすことに重点が置かれています。 F5 NGINX Plus のサポートが追加され、最も要求の多いユースケースをカバーするために API サーフェスが拡張されました。 これらの機能強化により、すべてのユーザーのエクスペリエンスが向上し、目標をより効率的に達成できるようになると考えています。

図1: NGINX Gateway Fabricの設計とアーキテクチャの概要

NGINX Gateway Fabric 1.2.0 の概要:

• NGINX Plus サポート– NGINX Gateway Fabric は、データ プレーン用の NGINX Plus をサポートするようになりました。これにより、可用性の向上、詳細なメトリック、リアルタイムの観測ダッシュボードが提供されます。
• BackendTLSPolicy – TLS 検証により、NGINX Gateway Fabric はバックエンド アプリケーションの ID を確認できるため、悪意のあるアプリケーションによる接続のハイジャックを防止できます。 さらに、TLS はクラスター内のトラフィックを暗号化し、クライアントとバックエンド アプリケーション間の安全な通信を保証します。
• URLRewrite – NGINX Gateway Fabric は、ルート オブジェクトでの URL 書き換えをサポートするようになりました。 この機能を使用すると、元のリクエスト URL を簡単に変更し、より適切な宛先にリダイレクトできます。 こうすることで、バックエンド アプリケーションの API が変更されても、クライアントに公開する API の一貫性を保つことができます。
• 製品テレメトリ– NGINX Gateway Fabric に製品テレメトリが導入されたことにより、お客様の環境で製品がどのように使用されているかを把握し、インフラストラクチャの運用効率をさらに向上させることができます。 また、私たちは会議中にこれらの洞察をコミュニティと定期的に共有する予定です。

以下で新機能について詳しく見ていきましょう。

NGINX Gateway Fabric 1.2.0 の新機能は何ですか?

NGINX Plus サポート

NGINX Gateway Fabric バージョン 1.2.0 がリリースされ、NGINX Plus がサポートされ、ユーザーに多くの新しいメリットが提供されます。 新しいアップグレードにより、ユーザーは追加の Prometheus メトリック、動的なアップストリーム リロード、NGINX Plus ダッシュボードなど、NGINX Plus の高度な機能をデプロイメントで活用できるようになりました。 このアップグレードにより、ご使用の環境に対して NGINX から直接サポートを受けるオプションも提供されます。

追加の Prometheus メトリック

NGINX Plus をデータ プレーンとして使用すると、NGINX Open Source で通常取得されるメトリックとともに、追加の高度なメトリックがエクスポートされます。 ハイライトとしては、HTTP リクエスト、ストリーム、接続などに関するメトリックが含まれます。 完全なリストについては、NGINX の Prometheus エクスポーターで確認できますが、NGINX Gateway Fabric ではエクスポーターは厳密には必要ないことに注意してください。 Prometheus または Prometheus 互換スクレーパーをインストールすると、これらのメトリックを可観測性スタックにスクレイピングし、アーキテクチャ内の 1 つの一貫したレイヤーを使用してダッシュボードとアラートを構築できます。 Prometheus メトリックは、HTTP ポート 9113 を介して NGINX ゲートウェイ ファブリックで自動的に利用できるようになります。 Pod テンプレートを更新してデフォルトのポートを変更することもできます。 シンプルなセットアップをお探しの場合は、 GitHub ページにアクセスして、Prometheus をデプロイして構成し、収集を開始する方法の詳細を確認してください。 あるいは、メトリクスの表示のみを行い、セットアップをスキップする場合は、次のセクションで説明する NGINX Plus ダッシュボードを使用できます。 クラスターに Prometheus をインストールした後、バックグラウンドでポート転送を実行してダッシュボードにアクセスできます。kubectl -n monitoring port-forward svc/prometheus-server 9090:80

図2: 受け入れられた NGINX ゲートウェイ ファブリック接続を示す Prometheus グラフ

上記の設定は、データ プレーンとしてデフォルトの NGINX Open Source を使用している場合でも機能します。 ただし、NGINX Plus が提供する追加のメトリックは表示されません。 クラスターのサイズと範囲が拡大するにつれて、NGINX Plus メトリックが容量計画の問題、インシデント、さらにはバックエンド アプリケーションの障害を迅速に解決するのにどのように役立つかを検討することをお勧めします。

ダイナミックアップストリームリロード

NGINX Plus とともにインストールされると NGINX Gateway Fabric によって自動的に有効になる動的アップストリーム リロードにより、NGINX Gateway Fabric は NGINX をリロードせずに NGINX 構成を更新できるようになります。 従来、NGINX のリロードが発生すると、既存の接続は古いワーカー プロセスによって処理され、新しく構成されたワーカーが新しい接続を処理します。 古い接続がすべて完了すると、古いワーカーは停止され、NGINX は新しく構成されたワーカーのみで続行されます。 このようにして、NGINX オープンソースでも構成の変更が適切に処理されます。 ただし、NGINX の負荷が高い場合、古いワーカーと新しいワーカーの両方を維持すると、リソースのオーバーヘッドが発生し、特に NGINX Gateway Fabric をできるだけ効率的に実行しようとすると、問題が発生する可能性があります。 NGINX Plus に搭載されている動的アップストリーム リロードは、NGINX Gateway Fabric が（存在する場合）自動的に使用する構成変更用の API エンドポイントを提供することでこの問題を回避し、リロード プロセス中に古いワーカーと新しいワーカーを処理するための追加のリソース オーバーヘッドの必要性を減らします。 NGINX Gateway Fabric に頻繁に変更を加えるようになると、リロードがより頻繁に発生するようになります。 現在の NGF インストールでリロードがどのくらいの頻度で、いつ発生するかを知りたい場合は、Prometheus メトリックnginx_gateway_fabric_nginx_reloads_totalを確認してください。 この問題について詳しく知りたい場合は、Nick Shadrin の記事をこちらでご覧ください。 以下は、Prometheus ダッシュボードに NGINX Gateway Fabric が 2 つデプロイされている環境のメトリックの例です。

図3: NGINX Gateway Fabricのリロード合計を示すPrometheusグラフ

NGINX Plusダッシュボード

前述のように、Prometheus のインストールや可観測性スタックを使用せずに NGINX Plus メトリックをすばやく表示する方法をお探しの場合は、NGINX Plus ダッシュボードを使用すると、インシデントのトラブルシューティングやリソース容量の監視に使用できるパフォーマンス メトリックをリアルタイムで監視できます。 ダッシュボードでは、NGINX Plus が提供するすべてのメトリックのさまざまなビューをすぐに表示でき、内部ポートから簡単にアクセスできます。 ダッシュボードの機能がどのようなものか簡単に確認したい場合は、 demo.nginx.comにあるダッシュボードのデモ サイトをご覧ください。 NGINX Gateway Fabric インストール上の NGINX Plus ダッシュボードにアクセスするには、ポート転送を介してローカル マシンのポート 8765 に接続を転送できます: kubectl port-forward -n nginx-gateway 8765:8765次に、任意のブラウザーを開き、アドレス バーに http://localhost:8765/dashboard.html と入力します。

図4: NGINX Plusダッシュボードの概要

バックエンドTLSポリシー

このリリースには、待望のBackendTLSPolicyのサポートが追加されました。 BackendTLSPolicy は、NGINX Gateway Fabric とアプリケーション間の暗号化された TLS 通信を導入し、通信チャネルのセキュリティを大幅に強化します。 信頼できる証明機関 (CA) に対してサーバー証明書を検証するときに、TLS 暗号やプロトコルなどの設定を指定してポリシーを適用する方法を示した例を次に示します。 BackendTLSPolicy を使用すると、ユーザーは NGF とバックエンド間のトラフィックを保護できます。 最小の TLS バージョンと暗号スイートを設定することもできます。 これにより、悪意のあるアプリケーションによる接続の乗っ取りを防ぎ、クラスター内のトラフィックを暗号化します。 バックエンドの TLS 終了を構成するには、まず、使用する CA 証明書を含むConfigMapを作成します。 内部 Kubernetes 証明書の管理に関するヘルプについては、このガイドをご覧ください。

親切： ConfigMap
apiVersion: v1
メタデータ:
名前: backend-cert
データ:
ca.crt:
< -----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
>

次に、 secure-appサービスを対象とし、前の手順で作成した ConfigMap を参照する BackendTLSPolicy を作成します。

apiバージョン: gateway.networking.k8s.io/v1alpha2
種類: BackendTLSPolicy
メタデータ:
名前: backend-tls
仕様:
ターゲット参照:
グループ: ''
種類: サービス
名前: secure-app
名前空間: default
tls:
caCertRefs:
-名前: backend-cert
グループ: ''
種類: ConfigMap
ホスト名: secure-app.example.com

URL書き換え

URLRewrite フィルターを使用すると、受信リクエストの元の URL を変更し、パフォーマンスに影響を与えることなく別の URL にリダイレクトできます。 これは、バックエンド アプリケーションが公開 API を変更したが、既存のクライアントとの下位互換性を維持したい場合に特に便利です。 この機能を使用すると、一貫した API URL をクライアントに公開しながら、異なる API URL を持つさまざまなアプリケーションにリクエストをリダイレクトし、クライアントの利便性とパフォーマンスのために複数の異なる API の機能を組み合わせた「エクスペリエンス」 API を提供することもできます。 まず、NGINX ゲートウェイ ファブリックのゲートウェイを作成しましょう。 これにより、HTTP リスナーを定義し、最適なパフォーマンスを得るためにポート 80 を構成できるようになります。

apiバージョン: gateway.networking.k8s.io/v1
種類: ゲートウェイ
メタデータ:
名前: cafe
仕様:
ゲートウェイクラス名: nginx
リスナー:
-名前: http
ポート: 80
プロトコル: ウェブ

HTTPRoute リソースを作成し、/coffee へのリクエストを /beans に書き換えるようにリクエスト フィルターを構成しましょう。 バックエンドが処理できるように /latte プレフィックスを含むように書き換えられた /latte エンドポイントを提供することもできます (「/latte/126」は「/126」になります)。

apiバージョン: gateway.networking.k8s.io/v1
種類: HTTPRoute
メタデータ:
名前: coffee
仕様:
親参照:
- 名前: cafe
セクション名: http
ホスト名:
- "cafe.example.com"
ルール:
- 一致:
- パス:
タイプ: PathPrefix
値: /coffee
フィルター:
- タイプ: URLRewrite
urlRewrite:
パス:
タイプ: ReplaceFullPath
replaceFullPath: /beans
backendRefs:
- name: coffee
port: 80
- 一致:
- パス:
タイプ: PathPrefix
値: /latte
フィルター:
- タイプ: URLRewrite
urlRewrite:
パス:
タイプ: ReplacePrefixMatch
replacePrefixMatch: /
backendRefs:
- 名前: コーヒー
ポート: 80

HTTP 書き換え機能は、クライアント側のエンドポイントと、それらがバックエンドにマッピングされる方法の間の柔軟性を確保するのに役立ちます。 また、ある URL から別の URL へのトラフィックのリダイレクトも可能になります。これは、コンテンツを新しい Web サイトまたは API トラフィックに移行する場合に特に役立ちます。 NGINX Gateway Fabric はパスベースの書き換えをサポートしていますが、現在パスベースのリダイレクトはサポートしていません。 お知らせください これがあなたの環境に必要な機能であるかどうか。

製品テレメトリ

1.2 リリースの一部として、受動的にフィードバックを収集するメカニズムとして製品テレメトリを組み込むことにしました。 この機能は、環境からさまざまなメトリックを収集し、24 時間ごとに当社のデータ収集プラットフォームに送信します。 個人識別情報は収集されません。収集される情報の完全なリストは、こちらでご覧いただけます。 当社はテレメトリ機能に関して完全な透明性を提供することに尽力しています。 当社が収集するすべてのフィールドは文書化され、コードによって収集内容を検証できますが、完全に無効にするオプションは常にあります。 私たちはコミュニティ ミーティングでコミュニティと共に収集した統計に基づいて、興味深い観察結果を定期的にレビューする予定ですので、ぜひお立ち寄りください。

リソース

NGINX Gateway Fabric 1.2.0 の完全な変更ログについては、リリース ノートを参照してください。 NGINX Plus で Kubernetes 用の NGINX Gateway Fabric を試すには、今すぐ30 日間の無料トライアルを開始するか、弊社にお問い合わせの上、ユースケースについてご相談ください。 参加したい場合、今後の予定を確認したい場合、または NGINX Gateway Fabric のソースコードを確認したい場合は、 GitHubのリポジトリをご覧ください。 私たちは隔週で月曜日の午前 9 時 (太平洋標準時) / 午後 5 時 (グリニッジ標準時) にコミュニティ ミーティングを開催しています。 会議リンク、最新情報、議題、メモは、NGINX Gateway Fabric 会議カレンダーに掲載されています。 リンクは、GitHub の readme からもいつでも入手できます。