Kubernetes ロード バランシングのための NGINX および NGINX Plus Ingress コントローラー

マシンのクラスター全体でコンテナ内のマイクロサービス アプリケーションを大規模に実行および管理することは、困難な作業です。 Kubernetes は、コンテナ オーケストレーションのための強力なソリューションを提供することで、課題の解決を支援します。 フォールト トレランス、自動スケーリング、ローリング アップデート、ストレージ、サービス検出、負荷分散などの重要な機能がいくつか含まれています。

このブログ記事では、HTTP トラフィック用の組み込み Kubernetes ロードバランシング フレームワークであるIngressでNGINX Open SourceまたはNGINX Plus を使用する方法について説明します。 Ingress を使用すると、Kubernetes クラスター内のサービスへの外部トラフィックのルーティングを制御するルールを構成できます。 Ingress コントローラーを提供する任意のロードバランサーを選択できます。Ingress コントローラーは、Kubernetes とロードバランサーを統合するためにクラスターにデプロイするソフトウェアです。 ここでは、Ingress と、NGINX Plus および NGINX 用に提供されている Ingress コントローラーを使用して、マイクロサービス アプリケーションの負荷分散を構成する方法を説明します。

[編集者注 – 以前は別々だった NGINX と NGINX Plus のコントローラーが、両方に対して 1 つのIngress コントローラーに統合されました。]

このブログ記事では、Ingress を使用した Kubernetes の HTTP ロード バランシングのみを検討します。 その他の負荷分散オプションの詳細については、ブログの「NGINX Plus を使用した Kubernetes サービスの負荷分散」を参照してください。

注記： このブログ記事で説明した手順の完全な説明は、 GitHub リポジトリで入手できます。 この投稿では、必要なすべての手順を説明するのではなく、代わりにそれらの手順へのリンクを提供します。

NGINX および NGINX Plus の Ingress コントローラー

サンプル アプリケーションをデプロイして負荷分散を構成する前に、ロード バランサーを選択し、対応する Ingress コントローラーをデプロイする必要があります。

Ingress コントローラーは、特定のロードバランサーを Kubernetes と統合するソフトウェアです。 私たちは、NGINX Open Source と NGINX Plus の両方に対応した Ingress コントローラーを開発しました。現在、 GitHub リポジトリで公開されています。 サードパーティによって作成された他の実装もあります。詳細については、Kubernetes の GitHub リポジトリのIngress Controllersページをご覧ください。

クラスターに NGINX または NGINX Plus Ingress コントローラーをデプロイするための詳細な手順については、 GitHub リポジトリを参照してください。

サンプルマイクロサービスアプリケーション

サンプル アプリケーションは、それぞれが個別にデプロイされた複数のサービスで構成される典型的なマイクロサービスWeb アプリケーションです。 「カフェ」と呼ばれるこのアプリケーションでは、ティーサービス経由でお茶を注文したり、コーヒーサービス経由でコーヒーを注文したりできます。 HTTP リクエストの URI で飲み物の好みを指定します。 /teaで終わる URI ではお茶がもらえ、 /coffeeで終わる URI ではコーヒーがもらえます。 アプリケーションへの接続は SSL/TLS で保護する必要があります。

以下の図はアプリケーションを概念的に表しており、NGINX Plus ロードバランサーがクライアント要求を適切なサービスにルーティングし、SSL/TLS を使用してクライアント接続を保護するという重要な役割を果たしています。

アプリケーションをクラスターにデプロイするには、 GitHub リポジトリの指示に従ってください。

Ingress 経由で Kubernetes ロード バランシングを構成する

私たちのカフェアプリでは、ロード バランサーが次の 2 つの機能を提供する必要があります。

• リクエスト URI に基づくルーティング (パスベース ルーティングとも呼ばれる)
• SSL/TLS 終了

Ingress で負荷分散を構成するには、 Ingress リソースでルールを定義します。 ルールは、外部トラフィックをクラスター内のサービスにルーティングする方法を指定します。

リソースでは、それぞれ異なるドメイン名に対して複数の仮想サーバーを定義できます。 仮想サーバーは通常、クラスターにデプロイされた単一のマイクロサービス アプリケーションに対応します。 各サーバーでは、次の操作を実行できます。

• 複数のパスベースのルールを指定します。 トラフィックは、リクエスト URI に基づいてアプリケーション内のさまざまなサービスに送信されます。
• SSL/TLS 証明書とキーを参照して SSL/TLS 終了を設定します。

Ingress のより詳しい説明と例については、 Ingress のドキュメント ページをご覧ください。

以下は、カフェアプリの Ingress リソース ( cafe‑ingress.yaml ) です。

行ごとに調べてみると、次のことがわかります。

• 4行目では、リソースにcafe‑ingress という名前を付けます。

• 6行目から9行目ではSSL/TLSの終了を設定します。

  • 9 行目では、 Cafe-Secretという名前でSecretリソースを参照しています。 このリソースにはSSL/TLS 証明書とキーが含まれており、Ingress リソースの前にデプロイする必要があります。
  • 8 行目では、証明書とキーをcafe.example.com仮想サーバーに適用します。
• 11 行目では、ドメイン名cafe.example.comを持つ仮想サーバーを定義します。

• 13行目から21行目では、2つのパスベースのルールを定義します。

  • 14 行目から 17 行目に定義されているルールは、ロード バランサーに、 /tea URI を持つリクエストを、クラスター内にtea-svcという名前でデプロイされているteaサービスのコンテナー間で分散するように指示します。
  • 18 行目から 21 行目に定義されているルールは、ロード バランサーに、 /coffee URI を持つリクエストを、クラスター内にcoffee-svcという名前でデプロイされているコーヒーサービスのコンテナー間で分散するように指示します。
  • どちらのルールも、ロード バランサーに、対応するサービスのポート 80にリクエストを分散するように指示します。

クラスターに Ingress および Secret リソースをデプロイする詳細な手順については、 GitHub リポジトリを参照してください。

アプリケーションのテスト

NGINX Plus Ingress コントローラー、アプリケーション、Ingress リソース、および Secret リソースをデプロイしたら、アプリをテストできます。

/tea URI を使用して tea リクエストを行うと、ブラウザーにteaサービスによって生成されたページが表示されます。

紅茶とコーヒーのサービスでは、実際に飲み物が提供されるのではなく、飲み物が入っている容器とリクエストの詳細に関する情報が提供されるだけなので、がっかりしないでください。 これらには、コンテナのホスト名と IP アドレス、リクエスト URI、クライアント IP アドレスが含まれます。 ページを更新するたびに、異なるコンテナーから応答が返されます。

また、NGINX Plusライブ アクティビティ モニタリングダッシュボードに接続して、NGINX Plus とアプリケーションの各コンテナからのリアルタイムの負荷分散メトリックを確認することもできます。

イングレス コントローラ拡張

Ingress は基本的な HTTP ロードバランシング機能を提供します。 ただし、アプリケーションの負荷分散要件がより複雑であるため、Ingress ではサポートされないことがよくあります。 これらの要件の一部に対処するために、Ingress コントローラーにいくつかの拡張機能を追加しました。 この方法では、Kubernetes リソースを使用して負荷分散を構成する利点を引き続き活用でき (ロード バランサーを直接構成する必要はありません)、高度な負荷分散機能を活用することができます。

利用可能な拡張機能の完全なリストについては、 GitHub リポジトリをご覧ください。

さらに、Config Maps リソースまたは Annotations を介して Kubernetes リソースによってNGINX 構成をカスタマイズするメカニズムも提供します。 たとえば、 proxy_connect_timeoutまたはproxy_read_timeoutディレクティブの値をカスタマイズできます。

負荷分散の要件が Ingress および拡張機能でサポートされている要件を超える場合は、Ingress コントローラーを使用しない NGINX Plus の展開と構成の別のアプローチをお勧めします。 詳細については、弊社のブログの「NGINX Plus を使用した Kubernetes サービスの負荷分散」をお読みください。

コントローラー付きNGINX Plusの利点

NGINX Plus を使用すると、Ingress コントローラーは NGINX で得られる利点に加えて、次の利点も提供します。

• 非常に動的な環境での安定性- Ingress 経由で公開されるサービスのポッドの数が変更されるたびに、Ingress コントローラーは NGINX または NGINX Plus の構成を更新して変更を反映する必要があります。 NGINX Open Source では、構成ファイルを手動で変更し、構成を再ロードする必要があります。 NGINX Plus では、動的再構成API を使用して、構成ファイルを再ロードせずに構成を更新できます。 これにより、構成の再読み込みが頻繁に行われる場合に発生する可能性のある、メモリ使用量の増加やシステム全体の過負荷を防ぐことができます。
• リアルタイム統計– NGINX Plus は高度なリアルタイム統計を提供し、API または組み込みダッシュボードからアクセスできます。 これにより、NGINX Plus とアプリケーションのパフォーマンスに関する洞察が得られます。
• セッション永続性– セッション永続性を有効にすると、NGINX Plus は、スティッキー クッキーメソッドを使用して、同じクライアントからのすべてのリクエストが常に同じバックエンド コンテナーに渡されるようにします。

まとめ

Kubernetes には、Ingress を使用して外部トラフィックをクラスター内のサービスにルーティングするための組み込み HTTP ロード バランシング機能が備わっています。 NGINX と NGINX Plus は Kubernetes のロード バランシングと統合され、Ingress 機能を完全にサポートし、拡張されたロード バランシング要件をサポートする拡張機能も提供します。

NGINX Plus と Ingress コントローラーを試すには、今すぐ30 日間の無料トライアルを開始するか、お問い合わせの上、ユースケースについてご相談ください。