ブログ | NGINX

NGINX Plus を Red Hat OCP および Kubernetes の外部ロードバランサーとして構成する

NGINX-F5 水平黒タイプ RGB の一部
マーク・ボディントン サムネイル
マーク・ボディントン
2020年7月24日公開

コンテナ オーケストレーションの世界では、よく目にする 2 つの名前があります。 RedHat OpenShift Container Platform (OCP) と Kubernetes。 ご存知のとおり、OpenShift は、他の多くのコンテナ オーケストレーション プラットフォームと同様に、基盤として Kubernetes を使用します。 外部トラフィックを Kubernetes または OpenShift 環境にルーティングすることは、次の 2 つの点で常に少し困難でした。

  • Kubernetes 内にデプロイされたサービスを外部に公開します。 解決策は、 NGINX Plus Ingress Controllerのような Ingress コントローラーです。 詳細については、弊社のブログ「Red Hat OpenShift での NGINX Ingress Operator の使用開始」をご覧ください。
  • Kubernetes ノード間でトラフィックを負荷分散します。 この問題を解決するために、組織は通常、外部ハードウェアまたは仮想ロードバランサー、あるいはクラウドネイティブ ソリューションを選択します。 ただし、 NGINX Plus は外部ロードバランサーとしても使用できるため、パフォーマンスが向上し、テクノロジー投資が簡素化されます。

このブログでは、NGINX Plus を使用して、2 番目の問題をシンプルかつ効率的に解決し、アプリケーション開発チームが Kubernetes 内の Ingress 構成と外部のロードバランサ構成の両方を管理できるようにする方法に焦点を当てます。 始める際に役立つリファレンス アーキテクチャとして、GitHub にnginx-lb-operatorプロジェクトを作成しました。NGINX Load Balancer Operator ( NGINX-LB-Operator ) は、Red Hat Operator Frameworkと SDK を使用して作成された、 NGINX コントローラー用の Ansible ベースの Operator です。 NGINX-LB-Operator は、 NGINX コントローラーの宣言型 API を駆動して、Kubernetes クラスター内で新しいサービスが追加されたり、ポッドが変更されたり、デプロイメントが拡張されたりしたときに、外部 NGINX Plus ロードバランサーの構成を更新します。

NGINX-LB-Operator は、NGINX Plus または NGINX Controller サポート契約の対象外であることにご注意ください。 GitHubでバグを報告したり、トラブルシューティングのサポートを依頼したりできます。

Kubernetes と NGINX テクノロジー – レビュー

NGINX-LB-Operator は多数の Kubernetes および NGINX テクノロジーに依存しているため、全員が同じ認識を持つように簡単にレビューします。 すでにこれらに精通している場合は、 「NGINX ロードバランサーオペレーター」に進んでください。

Kubernetes コントローラーとオペレーター

Kubernetes は、疎結合された中央 API を中心に構築されたオーケストレーション プラットフォームです。API は、リソース定義のコレクションと、それらのリソースを監視および管理するためのコントローラー (通常はプラットフォーム内でポッドとして実行されます) を提供します。 Kubernetes API は拡張可能であり、Operators (コントローラーの一種) を使用して Kubernetes の機能を拡張できます。

  • コントローラー– Kubernetes システムのコア部分。 特定の Kubernetes リソースの「ウォッチ」を作成し、リソースの変化に応じて各リソースの目的の状態に到達するために必要な手順を実行します。 顧客との会話で最もよく話題になる Kubernetes コントローラーは「Ingress コントローラー」です。
  • オペレーター– カスタム リソース定義 (CRD) を定義および使用して、アプリケーションとそのコンポーネントを管理するカスタム コントローラー。

Kubernetes 向け NGINX Ingress コントローラー

NGINX には 2 つの主要な Ingress コントローラー オプションがありますが、GitHub 内の名前が非常に似ているため、区別するのが少し混乱することがあります。 このトピックについては以前のブログで詳しく説明しましたが、ここで簡単に復習します。

  • kubernetes/ingress-nginx – Kubernetes オープンソース コミュニティによってサポートおよび保守されている Ingress コントローラー。 使いやすさを考慮して、これを「コミュニティの Ingress コントローラー」と呼びます。 当然のことながら、これは NGINX オープンソースに基づいています。 サードパーティの Lua モジュールによって有効化される追加機能を提供しますが、残念ながらパフォーマンスが低下する傾向があります。

  • nginxinc/kubernetes-ingress – F5 の NGINX チームによって管理されている Ingress コントローラー。 2 つのバージョンがあります。1 つは NGINX Open Source 用 (速度を重視して構築)、もう 1 つは NGINX Plus 用 (速度を重視して構築されていますが、商用サポートとエンタープライズ グレードの追加機能を備えています) です。 これらを「NGINX（または当社の）Ingress コントローラー」と呼びます。

    標準の Kubernetes Ingress リソースを使用して、両方の Ingress コントローラーを管理できます。 また、Ingress 仕様で提供される限定された機能を拡張するために、アノテーションとConfigMap もサポートしていますが、この方法でリソースを拡張することは理想的ではありません。

    Ingress コントローラーのリリース 1.6.0以降には、Kubernetes API を拡張し、Kubernetes ネイティブの方法で追加機能を提供する、 VirtualServer および VirtualServerRouteと呼ばれるカスタムNGINX Ingress リソースという、より優れたソリューションが含まれています。 NGINX Ingress リソースは、より多くの NGINX 機能を公開し、Ingress で高度な負荷分散機能を使用したり、ブルーグリーン リリースやカナリア リリース、サーキット ブレーカー パターンを実装したりできるようになります。

これら 3 つの Ingress コントローラー オプションの主な違いの概要については、 GitHub リポジトリを参照してください。

NGINX コントローラー

NGINX コントローラーは、複数の環境で NGINX Plus インスタンスを管理し、パフォーマンスとエラー状態に関する重要な洞察を活用するための、クラウドに依存しないコントロール プレーンです。 そのモジュールは、アプリケーション配信(負荷分散) とAPI 管理のための集中構成管理を提供します。 NGINX コントローラーは、物理、仮想、クラウドなど、さまざまな環境にわたる NGINX Plus インスタンスの構成を管理できます。 これは、最終的に一貫性のある宣言型 API を中心に構築されており、アプリとそのコンポーネントのアプリ中心のビューを提供します。 CI/CD パイプラインと簡単にインターフェースし、コードからインフラストラクチャを抽象化して、開発者が仕事に集中できるように設計されています。

Kubernetes に関しては、NGINX コントローラーは、リバース プロキシまたは API ゲートウェイとして前面に展開された NGINX Plus インスタンスを管理できます。 ただし、NGINX コントローラーが NGINX Plus Ingress コントローラー自体を管理するのは意味がありません。Ingress コントローラーはコア Kubernetes リソース (Ingress) の制御ループ機能を実行するため、Kubernetes プラットフォームのツール (標準の Ingress リソースまたは NGINX Ingress リソースのいずれか) を使用して管理する必要があります。

外部ロードバランサ

NGINX Plus Ingress Controller for Kubernetes は、Kubernetes 内のサービスを外部に公開するのに最適な方法ですが、Kubernetes ノードまたはクラスターへのトラフィックを管理するために外部の負荷分散レイヤーが必要になることがよくあります。 パブリック クラウドで実行している場合、外部ロード バランサーとしては、NGINX Plus、 F5 BIG-IP LTM Virtual Edition、またはクラウド ネイティブ ソリューションを使用できます。 オンプレミスまたはプライベート クラウドに展開する場合は、NGINX Plus またはBIG-IP LTM (物理または仮想) アプライアンスを使用できます。 他にもロードバランサーが利用できると聞きましたが、信じられません 😉 。

外部ロードバランサーの管理に関しては、NGINX コントローラーを直接使用して外部 NGINX Plus インスタンスを管理できます。 宣言型 API は CI/CD パイプラインとのインターフェースを目的として設計されており、これを使用して各アプリケーション コンポーネントをデプロイできます。 しかし、Ingress レイヤーがスケーラブルで、動的に割り当てられた Kubernetes NodePorts を使用する場合、またはOpenShift Routes が変更される可能性がある場合はどうなるでしょうか?

このような場合には、外部ロードバランサの構成を Kubernetes の状態とマージし、Kubernetes Operator を介して NGINX コントローラ API を駆動することが必要になる可能性があります。 この図は、外部ロードバランサーを管理するためのオペレーター ( NGINX-LB-Operator ) のみを含むサンプルのデプロイメントを示しており、NGINX Plus Ingress Controller と NGINX Controller の違いを強調しています。

どこ：

  • Ingress リソース (青いボックス) - 標準の Ingress リソースと NGINX VirtualServer リソースがプロジェクト名前空間で定義されています。
  • 青い矢印– Ingress リソースは Kubernetes API で作成され、別の名前空間で実行されている NGINX Plus Ingress コントローラーによって取得されます。
  • カスタム リソース (緑色のボックス) – NGINX-LB-Operatorとともにインストールされた CRD のインスタンス化であるカスタム リソースは、プロジェクトの名前空間で定義され、同じ名前空間で実行されているNGINX-LB-Operatorによって使用されます。
  • 緑の矢印– リソースは API で作成され、その後NGINX-LB-Operatorによって取得されます。 同じ Pod で実行されるローカル NGINX Plus インスタンスを構成する Ingress Controller とは異なり、 NGINX-LB-Operator はNGINX Controller に対して API 呼び出しを行います。
  • オレンジ色の矢印– NGINX コントローラーは、NGINX Plus Ingress コントローラーに負荷分散するように外部 NGINX Plus インスタンスを構成します。

このトポロジでは、カスタム リソースに外部ロード バランサーの望ましい状態が含まれており、アップストリーム (ワークロード グループ) が NGINX Plus Ingress Controller に設定されます。 NGINX-LB-Operator はIngress Pod に関する情報を収集し、その情報を目的の状態とマージしてから NGINX コントローラー API に送信します。

NGINX ロードバランサーオペレーター

Kubernetes 用の Operator を作成するのは、最初は困難な作業のように思えるかもしれませんが、Red Hat と Kubernetes オープンソース コミュニティがOperator Framework を維持しているため、この作業は比較的簡単になります。 Operator SDK を使用すると、誰でも Go、Ansible、Helm を使用して Kubernetes Operator を作成できます。 F5 では、 NGINX コントローラの認定コレクションを含む多くの製品向けの Ansible コレクションをすでに公開しているため、外部の NGINX Plus インスタンスを管理し、NGINX コントローラとインターフェースする Operator を構築するのは非常に簡単です。

Operator SDK を使用して、名前空間またはクラスター スコープを使用してデプロイし、いくつかのカスタム リソースを監視できる NGINX ロード バランサー Operator (NGINX-LB-Operator)を作成しました。 カスタム リソースは、NGINX コントローラー オブジェクト (証明書、ゲートウェイ、アプリケーション、コンポーネント) に直接マップされるため、NGINX コントローラーのアプリケーション中心のモデルを Kubernetes で直接表現します。 Kubernetes で設定されたカスタム リソースはNGINX-LB-Operatorによって取得され、NGINX コントローラーに同等のリソースが作成されます。

NGINX-LB-Operator を使用すると、NGINX コントローラの宣言型 API を使用して外部 NGINX Plus インスタンスの構成を管理できます。NGINX コントローラが外部インスタンスを管理するため、監視とアラートの追加の利点と、NGINX コントローラが提供する詳細なアプリケーション分析情報が得られます。

この図は次のことを示しています。

  1. プロジェクト名前空間にカスタム リソースを作成し、Kubernetes API に送信します。
  2. NGINX-LB-Operator は、新しく構成されたリソースを確認し、Ingress 名前空間の Ingress コントローラーからコンポーネントの目的の状態とデプロイメント情報を収集します。
  3. 定義と Ingress コントローラーの現在の状態からマージされた構成が NGINX コントローラーに送信されます。
  4. 設定は要求された NGINX Plus インスタンスに配信され、NGINX コントローラーは新しいアプリケーションのメトリックの収集を開始します。

詳細なデプロイメント手順とサンプルアプリケーションはGitHubで提供されています。 ロールプレイが嫌いな方、または TL;DR バージョンを観るためにここに来た方は、今すぐそちらへ行ってください。

サンプル展開

それではロールプレイをしてみましょう。 私がスーザンになって、あなたがデイブになってください。

デイブとして、あなたはお気に入りの架空の複合企業で事業を運営します。 あなたは子供たちと仲良く、状況を把握しているなど、すべてのアプリケーションとマイクロサービスを OpenShift にデプロイし、Ingress には Kubernetes 用の NGINX Plus Ingress Controller を使用します。 すべてのアプリケーションは OpenShift プロジェクト (名前空間) としてデプロイされ、NGINX Plus Ingress コントローラーは独自の Ingress 名前空間で実行されます。

デフォルトの Ingress 仕様で利用できる機能に満足したことがなく、ConfigMap と Annotations が少し扱いにくいと常に思っていました。 NGINX が NGINX Plus Ingress Controller が独自の CRD のサポートを開始すると発表したとき、皆さんが大喜びしたのはそのためです。 現在、アプリケーション開発者は、 VirtualServer および VirtualServerRoutes リソースを使用して、NGINX Plus Ingress Controller へのアプリケーションのデプロイメントを管理し、OpenShift 内の内部ルーティングとエラー処理を構成しています。

NGINX Plus Ingress Controller でも利用可能なTransportServerカスタム リソースのおかげで、非 HTTP サービスを公開することもあります。 開発者は独自のプロジェクト名前空間でカスタム リソースを定義し、それを NGINX Plus Ingress Controller が取得してすぐに適用することができます。 これは素晴らしいことですが、OpenShift クラスターのエッジにある外部ネットワーク ロード バランサーも同様に簡単に管理できればよいと思います。 Ingress レイヤーをスケーリングする必要がある場合、常に腰痛が悪化します。

土曜日の夜、ディスコに行くべきなのに、昨日 Ingress レイヤーを再びスケーリングしなければならず、腰が痛いです。 ピン！ 煙の雲の中に、あなたの妖精のおばあさんスーザンが現れます。

「こんにちは、デイブ」と彼女は言う。

"あなたは誰ですか？ 「私のペルシャ絨毯に何をしたのか見てみろ」とあなたは答えます。

あなたの態度を無視して、スーザンは GitHub で現在入手可能な NGINX-LB-Operator について説明を続けます。 彼女は、OpenShift のエッジにある NGINX Plus クラスターと、アプリケーション中心の観点からそれを管理する NGINX コントローラーを使用することで、NGINX Plus ロードバランサーの構成方法を定義するカスタム リソースを作成できると説明しています。

NGINX-LB-Operator はこれらのリソースを監視し、それらを使用してアプリケーション中心の構成を NGINX コントローラーに送信します。 次に、NGINX コントローラーは必要な NGINX Plus 構成を生成し、それを外部の NGINX Plus ロードバランサーにプッシュします。

エンドユーザーはアプリケーションにすぐにアクセスできるようになり、外部の NGINX Plus ロードバランサーの変更を必要とする変更を制御できるようになります。

NGINX コントローラーは、外部の NGINX Plus ロードバランサーからメトリックを収集し、すでに利用しているのと同じアプリケーション中心の視点からメトリックを提示します。 次回 NGINX Plus Ingress レイヤーをスケーリングすると、NGINX-LB-Operator によって NGINX コントローラーと外部 NGINX Plus ロードバランサーが自動的に更新されます。 腰痛はもうありません！

結論

Kubernetes は、コンテナ化されたアプリケーションを管理するために構築されたプラットフォームです。 NGINX コントローラーは、アプリケーションの負荷分散を検討および管理するためのアプリケーション中心のモデルを提供します。 NGINX-LB-Operator はこれら 2 つを組み合わせ、基盤となるインフラストラクチャを気にすることなく、フルスタックをエンドツーエンドで管理できるようにします。 NGINX-LB-Operatorに関するより詳しい技術情報と完全なサンプルのウォークスルーについては、 GitHubをご覧ください。

当社のソリューションの詳細については、以下をご覧ください。

F5 NGINX に関するブログ投稿をもっと読む ›

「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"