NGINXでオンプレミスのKubernetesサービスへのTCP負荷分散を自動化

Chris Akker

モダンアプリケーションの開発者は、さまざまなオープンソースツールと、場合によっては商用ツールを使用して、新しいアプリケーションやコンテナの作成、テスト、デプロイ、管理を行います。また、開発、テスト、ステージング、本番の各環境でこれらのコンテナやPodを実行するために、Kubernetesを採用しています。さらに、マイクロサービスや、Cloud Native Computing Foundationなどの最新の業界標準が提唱するアーキテクチャと概念を取り入れています。

この取り組みを進める中で、Kubernetesが確かに強力であることを実感されたでしょう。しかし同時に、扱いが難しく、柔軟性に欠け、思いどおりにならないことに驚かれたかもしれません。ルーター、ファイアウォール、ロードバランサーなどのネットワークデバイスに対する変更や更新を実施し、調整する作業は、特に自社のデータセンターでは手に負えなくなることがあります。開発者が泣きたくなるのも無理はありません。

こうした課題への対処方法は、Kubernetesをどこでどのように実行するか（マネージドサービスまたはオンプレミス）によって大きく異なります。この記事では、導入方法の選択が使いやすさに影響する重要な領域であるTCPロードバランシングについて解説します。

マネージドKubernetesによるTCPロードバランシング（簡単な選択肢）

Kubernetes向けのパブリッククラウドプロバイダーなどのマネージドサービスを利用すれば、煩雑なネットワーク関連作業の多くを任せられます。わずか1つのコマンド（kubectl apply -f loadbalancer.yaml）を実行するだけで、ServiceタイプのLoadBalancerによって、パブリックIP、DNSレコード、TCPロードバランサーを利用できます。たとえば、Amazon Elastic Load Balancerで、NGINX Ingress Controllerを含むPodにトラフィックを分散するよう設定できます。このコマンドを使用すれば、バックエンドが変更されても心配する必要はありません。あまりに簡単なので、当たり前のことだと思っているかもしれません。

オンプレミスKubernetesでのTCP負荷分散（別名：難しい方法）

オンプレミスクラスターでは、状況がまったく異なります。必要なネットワーク機能は、自社またはネットワーク担当者が用意しなければなりません。「ユーザーがKubernetesアプリにアクセスできるようにするのは、なぜこれほど難しいのか」と疑問に思うかもしれません。その答えは単純ですが、少し驚くべきものです。クラスターの入口となるLoadBalancerタイプのServiceは、実際には存在しないのです。

アプリとServiceをクラスター外部に公開するには、ネットワークチームが機器を再構成する前に、チケットの起票、承認、所定の手続き、場合によってはセキュリティレビューまで必要になるでしょう。あるいは、すべてを自分で行う必要があり、アプリケーションデリバリーのペースが大幅に低下するかもしれません。さらに厄介なことに、NodePortが変わるとトラフィックがブロックされる可能性があるため、Kubernetes Serviceにはうかつに変更を加えられません。500エラーが発生すれば、ユーザーが喜ばないことは言うまでもありません。上司はなおさらでしょう。

オンプレミスのTCP負荷分散を改善するソリューション：NGINX Loadbalancer for Kubernetes

新しいプロジェクト「NGINX Loadbalancer for Kubernetes」を利用すれば、「難しい選択肢」を「簡単な選択肢」に変えられます。この無料プロジェクトは、KubernetesコントローラーとしてNGINX Ingress Controllerを監視し、ロードバランシング用に構成された外部のNGINX Plusインスタンスを自動的に更新します。非常にシンプルな設計のため、インストールも運用も簡単です。このソリューションを導入することで、オンプレミス環境にTCPロードバランシングを実装できます。手動操作を必要とせず、新しいアプリやサービスが即座に検出され、トラフィックを受信できるようになります。

アーキテクチャと処理フロー

NGINX Loadbalancer for KubernetesはKubernetesクラスター内に配置されます。Kubernetesに登録され、nginx-ingress Service（NGINX Ingress Controller）を監視します。バックエンドに変更があると、NGINX Loadbalancer for KubernetesはWorker IPとNodePortのTCPポート番号を収集し、IP:ポートをNGINX Plus API経由でNGINX Plusに送信します。NGINXのアップストリームサーバーは再読み込み不要で更新され、NGINX Plusは適切なアップストリームサーバーとKubernetes NodePortにトラフィックを負荷分散します。NGINX Plusインスタンスを追加することで、高可用性を実現できます。

NGINX Loadbalancer for Kubernetesの動作例

以下のスクリーンショットには、NGINX Loadbalancer for Kubernetesがデプロイされ、動作している様子を示す2つのウィンドウがあります。

1. サービスタイプ – LoadBalancer（nginx-ingress用）
2. 外部IP – NGINX Plusサーバーに接続
3. ポート – NodePortは443:30158にマッピングされ、対応するNGINXアップストリームサーバーに接続されます（NGINX Plusの「リアルタイムダッシュボード」に表示されているとおりです）
4. ログ – NGINX Loadbalancer for KubernetesからNGINX Plusへのデータ送信が正常に行われていることを示します

注記：この例では、Kubernetesワーカーノードは10.1.1.8と10.1.1.10です

今すぐ始める

Kubernetesクラスターのエッジにおけるネットワークの課題にお困りの場合は、ぜひこのプロジェクトをお試しいただき、ご意見をお聞かせください。NGINX Loadbalancer for KubernetesのソースコードはApache 2.0ライセンスの下でオープンソースとして公開されており、インストール手順はすべてGitHubでご確認いただけます。

フィードバックは、リポジトリにコメントを投稿するか、NGINX Community Slackでメッセージをお送りください。

著者について

Chris Akker

Chris Akkerのその他のブログ記事