マシンのクラスター全体でコンテナ内のマイクロサービス アプリケーションを大規模に実行および管理することは、困難な作業です。 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 リポジトリで入手できます。 この投稿では、必要なすべての手順を説明するのではなく、代わりにそれらの手順へのリンクを提供します。
サンプル アプリケーションをデプロイして負荷分散を構成する前に、ロード バランサーを選択し、対応する 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 リポジトリの指示に従ってください。
私たちのカフェアプリでは、ロード バランサーが次の 2 つの機能を提供する必要があります。
Ingress で負荷分散を構成するには、 Ingress リソースでルールを定義します。 ルールは、外部トラフィックをクラスター内のサービスにルーティングする方法を指定します。
リソースでは、それぞれ異なるドメイン名に対して複数の仮想サーバーを定義できます。 仮想サーバーは通常、クラスターにデプロイされた単一のマイクロサービス アプリケーションに対応します。 各サーバーでは、次の操作を実行できます。
Ingress のより詳しい説明と例については、 Ingress のドキュメント ページをご覧ください。
以下は、カフェアプリの Ingress リソース ( cafe‑ingress.yaml ) です。
行ごとに調べてみると、次のことがわかります。
6行目から9行目ではSSL/TLSの終了を設定します。
13行目から21行目では、2つのパスベースのルールを定義します。
クラスターに 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 を使用すると、Ingress コントローラーは NGINX で得られる利点に加えて、次の利点も提供します。
Kubernetes には、Ingress を使用して外部トラフィックをクラスター内のサービスにルーティングするための組み込み HTTP ロード バランシング機能が備わっています。 NGINX と NGINX Plus は Kubernetes のロード バランシングと統合され、Ingress 機能を完全にサポートし、拡張されたロード バランシング要件をサポートする拡張機能も提供します。
NGINX Plus と Ingress コントローラーを試すには、今すぐ30 日間の無料トライアルを開始するか、お問い合わせの上、ユースケースについてご相談ください。
「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"