同一アーキテクチャへのBIG-IPとNGINX Ingress Controllerの導入

NGINX | 2021年11月15日

以前のブログシリーズ「Kubernetesでのアプリケーションサービスのデプロイ」では、多くのお客さまのデジタルトランスフォーメーションの過程で見られるパターンについて説明しました。多くの場合、まずはアプリケーション（通常はモノリス）を作成してデプロイする従来型のモデルから始まり、この2つの機能を、サイロ化された開発チームと運用チームが分担します。組織がよりモダンなモデルへ移行するにつれて、マイクロサービスベースのアプリケーションを作成し、従来のサイロ間の境界を曖昧にするDevOpsプラクティスを用いてデプロイするようになります。

DevOpsチームとアプリケーション所有者が、アプリケーションのデプロイ、管理、配信方法をより直接的に制御するようになっている一方で、部門間の壁を一度にすべて取り払うことは、多くの場合現実的ではなく、その必要もありません。むしろ、次のような合理的な責任分担が引き続き有効であることがわかっています。

ネットワークチームとセキュリティチームは、引き続き企業インフラストラクチャ全体のセキュリティ、パフォーマンス、可用性を重視します。特に重視するのは、通常、そのインフラストラクチャの「玄関口」に導入されるグローバルサービスです。これらのチームは、F5 BIG-IPを、グローバルサーバーロードバランシング（GSLB）、DNSの名前解決とロードバランシング、高度なトラフィックシェーピングなどのユースケースに活用しています。BIG‑IQとNGINX Controller［現F5 NGINX Management Suite］は、NetOpsチームに最適な形式でメトリクスとアラートを提供します。また、SecOpsチームには、組織の資産を保護し、業界規制に準拠するために必要なセキュリティの可視性と制御機能を提供します。
運用チーム（運用を重視するDevOps）は、関連する事業部門の要件に応じて個々のアプリケーションを作成、管理します。特に重視するのは、自動化やCI/CDパイプラインなど、更新された機能をより迅速に反復開発するためのサービスです。こうしたサービスは通常、Kubernetes環境内など、アプリケーションに「より近い」場所にデプロイされます。これらのチームは、NGINX Plus、NGINX App Protect、NGINX Ingress Controller、NGINX Service MeshなどのNGINX製品を利用して、Kubernetesクラスターを含む複数の環境でホストされる、分散型のマイクロサービスベースのアプリケーションの負荷分散とトラフィックシェーピングを行います。ユースケースには、TLS終端、ホストベースルーティング、URI書き換え、JWT認証、セッション維持、レート制限、ヘルスチェック、セキュリティ（NGINX App Protectを統合WAFとして使用）などがあります。

Kubernetes環境におけるNetOpsとDevOps

NetOpsチームとDevOpsチームでは重視する点が異なり、それはKubernetes環境で担う役割や、その役割を果たすために使用するツールにも表れています。単純化しすぎるおそれはありますが、NetOpsチームは主にKubernetesクラスター外部のインフラストラクチャとネットワーク機能を担当し、DevOpsチームはクラスター内部の同機能を担当すると言えます。

Kubernetesクラスターにトラフィックを転送するために、NetOpsチームは、使い慣れた機能と幅広いオーバーレイネットワーク技術をサポートする外部ロードバランサーとしてBIG‑IPを使用できます。ただし、BIG‑IP単体では、Kubernetesクラスター内のPod群の変更（Pod数やIPアドレスの変更など）を追跡できません。この制約に対処するため、F5 Container Ingress Services（CIS）をクラスター内にオペレーターとしてデプロイします。CISはPod群の変更を監視し、それに応じてBIG‑IPシステムの負荷分散プール内のアドレスを自動的に変更します。また、新しいIngress、Route、カスタムリソースの作成を検出し、それに応じてBIG‑IPの設定を更新します。

BIG‑IPとCISを組み合わせて、アプリケーションPodへのトラフィックを直接負荷分散することもできますが、実際には、多数のサービスを構成するPodやワークロードの動的な変更を検出して追従するには、NGINX Ingress Controllerが最適なソリューションです。たとえば、需要の変化に対応するためにアプリケーションPodを水平スケーリングする場合が該当します。

NGINX Ingress Controllerを導入するもう1つの利点は、アプリケーションのロードバランシング制御を、そのアプリケーションを担当するDevOpsチームに移せることです。高性能なコントロールプレーンとDevOps中心の設計により、複数の名前空間にまたがるKubernetesサービスで、インプレース再構成やローリングアップデートなど、変化の速いDevOpsユースケースを特に強力にサポートします。NGINX Ingress Controllerは、KubernetesネイティブAPIを使用して、スケーリングされるPodを検出します。

BIG-IPとNGINX Ingress Controllerの連携の仕組み

ご存じのとおり、BIG‑IPとNGINX Ingress Controllerは、もともと別々の企業（それぞれF5とNGINX）によって設計されました。F5によるNGINXの買収後、両ツール間の相互運用性が向上すれば、インフラストラクチャの管理を簡素化できるとの声がお客さまから寄せられました。これを受けて、IngressLinkという新しいKubernetesリソースを開発しました。

IngressLinkリソースは、Kubernetesの「CustomResourceDefinition」（CRD）を使用してNGINX Ingress ControllerとBIG‑IPを「連携」させるシンプルな拡張機能です。簡単に言えば、NGINX Ingress ControllerのPod構成が変更されるたびに、CISからBIG‑IPへその変更を通知できます。この情報に基づき、BIG‑IPは対応する負荷分散ポリシーを変更後の構成に合わせて迅速に調整できます。

Kubernetesクラスターへの負荷分散にBIG‑IPを導入し、イングレス／エグレスのトラフィックをNGINX Ingress Controllerで処理する場合、トラフィックフローは次のようになります。

BIG‑IPは、外部トラフィックをNGINX Ingress Controllerインスタンスに転送します。
NGINX Ingress Controllerは、トラフィックをクラスター内の適切なサービスに分散します。
NGINX Ingress Controllerは非常に効率的であるため、安定したインスタンス群で、アプリケーションPod群の頻繁かつ大規模な変更に対応できます。ただし、トラフィックの急増や減少に対応するためにNGINX Ingress Controllerを水平方向にスケールアウトまたはスケールインする必要がある場合、CISはIngressLinkリソースを介して変更をBIG‑IPに通知し、BIG‑IPがその変更に迅速に対応できるようにします。