Kubernetesの負荷分散に対応するNGINXおよびNGINX Plus Ingress Controller

Michael Pleshakov

複数のマシンで構成されるクラスター全体にわたり、コンテナ内のマイクロサービスアプリケーションを大規模に実行、管理することは容易ではありません。Kubernetesは、強力なコンテナオーケストレーションソリューションによって、この課題への対応を支援します。耐障害性、自動スケーリング、ローリングアップデート、ストレージ、サービスディスカバリ、負荷分散など、重要な機能を備えています。

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

［編集者注：これまでNGINXとNGINX Plusで別々に提供されていたコントローラーは、両方に対応する単一の「Ingress controller」に統合されました。］

このブログ記事では、Ingressを使用したKubernetes向けHTTPロードバランシングのみを取り上げます。その他のロードバランシングオプションについて詳しくは、F5のブログ記事「NGINX PlusによるKubernetesサービスのロードバランシング」をご覧ください。

注：このブログ記事で取り上げる手順の詳細な説明は、F5の「GitHubリポジトリ」でご確認いただけます。この記事では必要な手順をすべて説明するのではなく、該当する説明へのリンクを掲載しています。

NGINXおよびNGINX Plus向けIngress Controller

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

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

クラスターにNGINXまたはNGINX Plus Ingress Controllerをデプロイするための詳しい手順については、F5の「GitHubリポジトリ」をご覧ください。

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

このサンプルアプリケーションは、複数のサービスで構成され、それぞれが個別にデプロイされる一般的なマイクロサービスWebアプリケーションです。cafeという名前のこのアプリケーションでは、teaサービスを介して紅茶を、またはcoffeeサービスを介してコーヒーを注文できます。HTTPリクエストのURIで希望する飲み物を指定します。末尾が/teaのURIでは紅茶を、末尾が/coffeeのURIではコーヒーを注文できます。アプリケーションへの接続はSSL/TLSで保護する必要があります。

以下の図は、アプリケーションの概念図です。NGINX Plusロードバランサーは、クライアントリクエストを適切なサービスにルーティングするとともに、SSL/TLSでクライアント接続を保護するという重要な役割を担います。

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

IngressによるKubernetesロードバランシングの設定

このcafeアプリでは、ロードバランサーが次の2つの機能を提供する必要があります。

• リクエストURIに基づくルーティング（「パスベースルーティング」とも呼ばれます）
• SSL/TLS終端

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

このリソースでは、ドメイン名ごとに複数の仮想サーバーを定義できます。通常、仮想サーバーは、クラスターにデプロイされた1つのマイクロサービスアプリケーションに対応します。各サーバーでは、次の設定が可能です。

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

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

以下は、cafe‑ingress.yaml（cafeアプリ用）のIngressリソースです。

コード例を読み込み中…

1行ずつ確認すると、次のことがわかります。

• 4行目で、リソースに「cafe‑ingress」という名前を付けます。
• 6～9行目でSSL/TLS終端を設定します：
  • 9行目では、Secretリソースを名前「cafe‑secret」で参照しています。このリソースにはSSL/TLS証明書と鍵が含まれており、Ingressリソースより先にデプロイする必要があります。
  • 8行目では、証明書とキーをcafe.example.com仮想サーバーに適用します。
• 11行目では、ドメイン名「cafe.example.com」を持つ仮想サーバーを定義します。
• 13～21行目では、パスに基づく2つのルールを定義します。
  • 14～17行目で定義されているルールは、ロードバランサーに対し、URIが「/tea」のリクエストを、クラスター内に「tea」サービスとしてデプロイされている「tea‑svc」という名前のコンテナ間で分散するよう指示します。
  • 18～21行目で定義されているルールは、ロードバランサーに対し、URIが「/coffee」のリクエストを、クラスター内に「coffee‑svc」という名前でデプロイされている「coffee‑svc」サービスのコンテナ間で分散するよう指示します。
  • どちらのルールも、対応するサービスのポート80にリクエストを分散するようロードバランサーに指示します。

クラスターにIngressリソースとSecretリソースをデプロイする手順の詳細については、F5のGitHubリポジトリをご覧ください。

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

NGINX Plus Ingress Controller、アプリケーション、Ingressリソース、Secretリソースをデプロイすると、アプリケーションをテストできます。

When we make a tea request with the /tea URIを使用してteaリクエストを送信すると、ブラウザーにteaサービスが生成したページが表示されます。

「tea」サービスと「coffee」サービスが実際に飲み物を提供するのではなく、実行中のコンテナに関する情報とリクエストの詳細を返すことに、あまりがっかりされないことを願います。返される情報には、コンテナのホスト名とIPアドレス、リクエストURI、クライアントIPアドレスが含まれます。ページを更新するたびに、異なるコンテナからレスポンスが返されます。

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

Ingress Controllerの拡張機能

Ingressは、基本的なHTTP負荷分散機能を提供します。しかし、アプリケーションの負荷分散要件はより複雑になることが多く、Ingressでは対応できない場合があります。こうした要件の一部に対応するため、Ingress Controllerに複数の拡張機能を追加しました。これにより、ロードバランサーを直接設定する代わりに、引き続きKubernetesリソースを使用して負荷分散を設定しながら、高度な負荷分散機能も活用できます。

利用可能な拡張機能の一覧については、F5の「GitHubリポジトリ」をご覧ください。

さらに、Kubernetesリソースを使用して、NGINX設定をカスタマイズするための仕組みも提供しています。ConfigMapリソースまたはアノテーションを介して設定できます。たとえば、proxy_connect_timeoutディレクティブやproxy_read_timeoutディレクティブの値をカスタマイズできます。

負荷分散の要件がIngressとF5の拡張機能でサポートされる範囲を超える場合は、Ingress Controllerを使用せずにNGINX Plusをデプロイして構成する別の方法を推奨します。詳しくは、F5のブログ記事「NGINX PlusによるKubernetesサービスの負荷分散」をご覧ください。

NGINX PlusとControllerを組み合わせるメリット

NGINX Plusを使用すると、Ingress Controllerでは、NGINXで得られるメリットに加えて、次のメリットも得られます。

• 変化の激しい環境での安定性 – Ingress経由で公開されるサービスのPod数が変わるたびに、Ingressコントローラーは、その変更を反映するためにNGINXまたはNGINX Plusの設定を更新する必要があります。NGINX Open Sourceでは、設定ファイルを手動で変更し、設定を再読み込みする必要があります。NGINX Plusでは、動的再設定APIを使用して、設定ファイルを再読み込みせずに設定を更新できます。これにより、設定の再読み込みが非常に頻繁に行われた場合に発生する可能性がある、メモリ使用量の増加やシステム全体の過負荷を防止できます。
• リアルタイム統計 – NGINX Plusは、高度なリアルタイム統計を提供します。APIまたは組み込みのダッシュボードからアクセスでき、NGINX Plusとアプリケーションのパフォーマンスを把握するのに役立ちます。
• セッション維持 – セッション維持を有効にすると、NGINX Plusは「sticky cookie」方式を使用して、同じクライアントからのすべてのリクエストが常に同じバックエンドコンテナに渡されるようにします。

まとめ

Kubernetesは、Ingressを使用して外部トラフィックをクラスター内のサービスにルーティングするためのHTTPロードバランシング機能を標準で提供します。NGINXとNGINX PlusはKubernetesのロードバランシングと統合され、Ingressの機能を完全にサポートするとともに、より高度なロードバランシング要件に対応する拡張機能も提供します。

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

著者について

Michael Pleshakov

Michael Pleshakovのその他のブログ記事