Kubernetesによる負荷分散のための コミュニティ版NGINXおよびNGINX Plus Ingress Controller

投稿者: | 2018年8月1日
0件のコメント

この記事はNGINX,Inc.のブログ記事「NGINX and NGINX Plus Ingress Controllers for Kubernetes Load Balancing」を和訳した内容となります。

URL:　https://www.nginx.com/blog/nginx-plus-ingress-controller-kubernetes-load-balancing/

マシンのクラスタ全体で、コンテナ内のマイクロサービスアプリケーションを実行して管理することは、困難な作業です。Kubernetesは、コンテナオーケストレーションのための強力なソリューションを提供することで、チャレンジを達成するのに役立ちます。フォールトトレランス、自動スケーリング、ローリングアップデート、ストレージ、サービスディスカバリ、ロードバランシングなどのいくつかの重要な機能が含まれています。

このブログ記事では、コミュニティ版NGINXまたはNGINX PlusとIngressの使い方について説明します。Ingressは、HTTPトラフィック用のKubernetesロードバランシングフレームワークを内蔵しています。Ingressでは、Kubernetesクラスタ内のサービスへの外部トラフィックのルーティングを制御するルールを設定できます。Ingress Controllerは、クラスタに展開しKubernetesとロードバランサを統合するソフトウェアで、任意のロードバランサを選択できます。ここでは、Ingressを備えたマイクロサービスアプリケーションと、NGINX PlusおよびNGINX用で提供されているIngress Controllerのロードバランシングを設定する方法を説明します。

[編集者 – 以前はNGINXとNGINX Plus用に別々のControllerがありましたが、
現在両方のIngress Controllerに統合しました。]

このブログ記事では、KubernetesとIngressのHTTPロードバランシングのみを調査します。他のロードバランシングオプションの詳細については、ブログでLoad Balancing Kubernetes Services with NGINX Plusを参照してください。

注：このブログ記事で説明されている手順の詳細は、GitHubリポジトリを参照してください。この投稿はすべての必要なステップを追うものではなく、それらの指示へのリンクを提供します。

コミュニティ版NGINXおよびNGINX PlusのIngress Controllers

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

Ingress Controllerは、特定のロードバランサとKubernetesを統合するソフトウェアです。私たちはコミュニティ版NGINXとNGINX Plusの両方のIngress Controllerを開発しました。GitHub リポジトリで利用できます。他にはサードパーティ製のものもあります。詳細については、KubernetesのGitHubリポジトリのIngress Controllersページを参照してください。

クラスタにNGINXまたはNGINX Plus Ingress Controllerを導入する方法の詳細については、GitHubリポジトリを参照してください。

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

サンプルアプリケーションは、それぞれが別々にデプロイされた複数のサービスで構成された典型的なマイクロサービス Webアプリケーションです。cafeと呼ばれるこのアプリケーションは、coffeeサービスを通じてteaやcoffeeを注文することができます。飲み物の好みをHTTPリクエストのURIで指定します。/ teaで終わるURIは、/ coffeeで終わるteaとURIで終わります。またアプリケーションへの接続はSSL / TLSで保護する必要があります。

以下の図は、NGINX Plusロードバランサがクライアントのリクエストを適切なサービスにルーティングする重要な役割を担い、SSL / TLSによるクライアント接続のセキュリティを確保しながら、アプリケーションを概念的に示しています。

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

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

私たちのcafeアプリでは、2つの機能を提供するためにロードバランサが必要です。

  • 要求URIに基づくルーティング（パスベースルーティングとも呼ばれる）
  • SSL / TLSターミネーション

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

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

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

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

cafeアプリ（cafe-ingress.yaml）のIngressリソースは次のとおりです。

1. apiVersion: extensions/v1beta1
 2. kind: Ingress
 3. metadata:
 4.  name: cafe-ingress
 5. spec:
 6.  tls:
 7.  – hosts:
 8.    – cafe.example.com
 9.    secretName: cafe-secret
10.  rules:
11.  – host: cafe.example.com
12.    http:
13.      paths:
14.      – path: /tea
15.        backend:
16.          serviceName: tea-svc
17.          servicePort: 80
18.      – path: /coffee
19.        backend:
20.          serviceName: coffee-svc
21.          servicePort: 80

行ごとに調べると、次のようになります。

  • 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行目で定義されているルールは、tea-svcという名前でデプロイされている、Tea Serviceのコンテナに/ tea URI とともにリクエストを分散するようにロードバランサに指示します。
    • 18行目〜21行目で定義されているルールは、クラスタ内にcoffee-svcという名前でデプロイされているCoffee Serviceの
      コンテナに、/ coffee URI とともにリクエストを分散するようロードバランサに指示します。
    • どちらのルールも、対応するサービスのポート80に要求を分散するようにロードバランサに指示します。

IngressおよびSecretリソースをクラスタに導入する方法の詳細については、GitHubリポジトリを参照してください。

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

NGINX Plus Ingress Controller、アプリケーション、Ingressリソース、およびSecretリソースを導入すると、アプリケーションをテストできます。

/ tea URIでteaをリクエストすると、ブラウザーにはTea Serviceによって生成されたページが表示されます。

teaとcoffeeのサービスが実際に飲み物を提供するだけではなく、これらサービスを
起動してコンテナやあなたのリクエストの詳細についての情報が欠損していないことが望ましいです。これらには、コンテナのホスト名とIPアドレス、要求URI、およびクライアントのIPアドレスが含まれます。ページを更新するたびに、別のコンテナから応答が返されます。

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

Ingress Controllerの拡張

Ingressは、基本的なHTTPロードバランシング機能を提供します。ただし、アプリケーションのロードバランシング要件が複雑でIngressでサポートされていないことがよくあります。これらの要件の一部に対応するため、Ingressコントローラにいくつかの拡張機能を追加しました。このようにして、Kubernetesリソースを使用してロードバランサを構成すること（ロードバランサを直接構成するのではなく）もでき、かつ高度なロードバランシング機能を活用することもできます。

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

さらに、Kubernetesのリソースを使用してConfig Mapsリソースまたは注釈を使用してNGINX設定をカスタマイズするメカニズムを提供します。たとえば、proxy_connect_timeoutまたはproxy_read_timeoutディレクティブの値をカスタマイズすることができます。

ロードバランシングの要件がIngressおよび拡張機能でサポートされている要件がある場合は、Ingressコントローラを使用しないNGINX Plusをデプロイおよび設定するための方法を提案します。私たちのブログではNGINX Plusを使ってKubernetesサービスのロードバランシングを読むことができます。

ControllerによるNGINX Plusの利点

NGINX Plus Ingress ControllerはNGINXで得られるものに加えて、以下の利点を提供します。

  • 高度に動的な環境での安定性  – Ingressを介して公開されているサービスのPod数が変更されるたびに、Ingress Controllerは変更を反映するためにNGINXまたはNGINX Plusの設定を更新する必要があります。コミュニティ版のNGINXでは、設定ファイルを手動で変更して設定をリロードする必要があります。しかし、NGINX Plusを使用すると、オンザフライで再構成 APIを使用して、設定ファイルをリロードせずに設定を更新できます。これにより、構成リロードが頻繁に発生する場合に発生する可能性のあるメモリ使用量の増加やシステム全体のオーバーロードを防ぐことができます。
  • リアルタイム統計  – NGINX Plusは高度なリアルタイム統計を提供し、APIまたは内蔵ダッシュボードのいずれかにアクセスできます。これにより、NGINX Plusとアプリケーションがどのように実行されているかを知ることができます。
  • セッション・パーシステンス  – セッション・パーシステンスを有効にすると、NGINX Plusは同じクライアントからのすべての要求が常にスティッキクッキー方式を使用して同じバックエンドのコンテナに渡されるようにします。

概要

Kubernetesには、組み込みのHTTPロードバランシング機能があり、外部トラフィックをIngressでクラスタ内のサービスにルーティングします。コミュニティ版NGINXとNGINX Plusは、Kubernetesロードバランシングと統合され、Ingress機能を完全にサポートし、拡張ロードバランシング要件をサポートする拡張機能も提供します。

NGINX PlusとIngress Controllerを試すには、今すぐ無料の30日間のトライアルを
開始するか、ライブデモをご連絡ください。

***************************************************************************

本ブログサイトの”ホワイトペーパー一覧”ページにeBOOKを公開致しました。
https://nginx.sios.jp/white-paper

***************************************************************************

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です