NGINX Gateway Fabric 1.2.0リリースのお知らせ

NGINX | 2024年3月29日

Akash Ananthanarayananテクニカルマーケティングマネージャー | F5 NGINX

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は、RouteオブジェクトでのURL書き換えをサポートするようになりました。この機能を使用すると、元のリクエストURLを簡単に変更し、より適切な宛先にリダイレクトできます。これにより、バックエンドアプリケーションのAPIが変更されても、クライアントに公開するAPIの一貫性を維持できます。
製品テレメトリ – NGINX Gateway Fabricに製品テレメトリが導入されたことで、お客さまの環境における製品の利用状況を把握し、インフラストラクチャの運用効率をさらに向上できるよう支援します。また、ミーティングの場で、得られた知見をコミュニティと定期的に共有する予定です。

以下では、新機能について詳しく見ていきます。

NGINX Gateway Fabric 1.2.0の新機能

NGINX Plusのサポート

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

追加のPrometheusメトリクス

NGINX Plusをデータプレーンとして使用すると、NGINX Open Sourceで通常取得できるメトリクスに加えて、高度なメトリクスもエクスポートされます。主なものとして、HTTPリクエスト、ストリーム、接続などに関するメトリクスがあります。完全な一覧については、NGINXのPrometheus Exporterにある便利な一覧をご確認ください。ただし、NGINX Gateway FabricでこのExporterが必須というわけではありません。PrometheusまたはPrometheus互換のスクレイパーを導入すれば、これらのメトリクスをオブザーバビリティスタックに取り込み、アーキテクチャ内の一貫したレイヤーを使用してダッシュボードやアラートを構築できます。Prometheusメトリクスは、NGINX Gateway FabricのHTTPポート9113で自動的に利用できます。Podテンプレートを更新して、デフォルトポートを変更することも可能です。簡単にセットアップする方法については、GitHubページで、Prometheusをデプロイおよび設定して収集を開始する方法をご確認ください。セットアップを省略してメトリクスだけを確認する場合は、次のセクションで説明するNGINX Plusダッシュボードを使用できます。クラスターにPrometheusをインストールした後、バックグラウンドでポートフォワーディングを実行すると、そのダッシュボードにアクセスできます。kubectl -n monitoring port-forward svc/prometheus-server 9090:80

NGINX Gateway Fabricの接続が受け入れられたことを示すPrometheusグラフ

図2：NGINX Gateway Fabricで受け入れられた接続を示すPrometheusグラフ

データプレーンとしてデフォルトのNGINX Open Sourceを使用している場合でも、上記の設定は機能します。ただし、NGINX Plusが提供する追加メトリクスは表示されません。クラスターの規模と範囲が拡大するにつれて、キャパシティプランニングの問題やインシデント、さらにはバックエンドアプリケーションの障害を迅速に解決するうえで、NGINX Plusのメトリクスがどのように役立つかを確認することを推奨します。

アップストリームの動的リロード

NGINX PlusとともにインストールするとNGINX Gateway Fabricによって自動的に有効化される動的アップストリームリロードにより、NGINX Gateway FabricはNGINXをリロードせずにNGINXの設定を更新できます。従来、NGINXのリロードが発生すると、既存の接続は古いワーカープロセスが処理し、新しく設定されたワーカーが新規接続を処理します。既存の接続がすべて完了すると、古いワーカーは停止し、NGINXは新しく設定されたワーカーのみで処理を続行します。この仕組みにより、NGINX Open Sourceでも設定変更を適切に処理できます。ただし、NGINXの負荷が高い場合、古いワーカーと新しいワーカーの両方を維持するとリソースのオーバーヘッドが生じ、問題につながる可能性があります。特に、NGINX Gateway Fabricを可能な限り少ないリソースで実行しようとする場合に顕著です。NGINX Plusの動的アップストリームリロードでは、設定変更用のAPIエンドポイントが提供されます。このエンドポイントが存在する場合、NGINX Gateway Fabricが自動的に使用するため、この問題を回避でき、リロード処理中に古いワーカーと新しいワーカーを処理するための追加のリソースオーバーヘッドを抑えられます。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 Dashboardの概要

BackendTLSPolicy

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


kind: ConfigMap
apiVersion: v1
metadata:
  name: backend-cert
data:
  ca.crt: 
         < -----BEGIN CERTIFICATE-----
	   -----END CERTIFICATE-----
          >

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


apiVersion: gateway.networking.k8s.io/v1alpha2
kind: BackendTLSPolicy
metadata:
  name: backend-tls
spec:
  targetRef:
    group: ''
    kind: Service
    name: secure-app
    namespace: default
  tls:
    caCertRefs:
    - name: backend-cert
      group: ''
      kind: ConfigMap
    hostname: secure-app.example.com

URLRewrite

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


apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: cafe
spec:
  gatewayClassName: nginx
  listeners:
  - name: http
    port: 80
    protocol: HTTP

HTTPRouteリソースを作成し、/coffeeへのリクエストを/beansに書き換えるようにリクエストフィルターを設定します。また、バックエンドで処理できるように/latteプレフィックスを除去する書き換えを行う/latteエンドポイントも提供できます（「/latte/126」は「/126」になります）。


apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: coffee
spec:
  parentRefs:
  - name: cafe
    sectionName: http
  hostnames:
  - "cafe.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /coffee
    filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplaceFullPath
          replaceFullPath: /beans
    backendRefs:
    - name: coffee
      port: 80
  - matches:
    - path:
        type: PathPrefix
        value: /latte
    filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplacePrefixMatch
          replacePrefixMatch: /
    backendRefs:
    - name: coffee
      port: 80

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

製品テレメトリ

1.2リリースの一環として、フィードバックを受動的に収集する仕組みである製品テレメトリを導入することにしました。この機能は、お客さまの環境からさまざまなメトリクスを収集し、24時間ごとにF5のデータ収集プラットフォームへ送信します。個人を特定できる情報（PII）は収集しません。収集する情報の全一覧はこちらでご確認いただけます。F5は、テレメトリ機能に関する完全な透明性の確保に取り組んでいます。収集するすべてのフィールドを文書化し、コードから収集内容を検証できるようにします。また、この機能はいつでも完全に無効化できます。収集した統計に基づく注目すべき知見について、コミュニティの皆さまとコミュニティミーティングで定期的に検討する予定です。ぜひご参加ください。

リソース

NGINX Gateway Fabric 1.2.0の変更履歴の全文については、リリースノートをご覧ください。NGINX Plusを使用してKubernetes向けNGINX Gateway Fabricをお試しいただくには、今すぐ30日間の無料トライアルを開始するか、ユースケースについてお問い合わせください。開発への参加、今後の予定の確認、またはNGINX Gateway Fabricのソースコードの閲覧をご希望の場合は、GitHubのリポジトリをご覧ください。コミュニティミーティングは隔週月曜日の太平洋時間午前9時／GMT午後5時に開催しています。ミーティングのリンク、最新情報、議題、議事録は、NGINX Gateway Fabricミーティングカレンダーでご確認いただけます。リンクはGitHubのREADMEからもいつでもご利用いただけます。