BIG-IP と NGINX Ingress Controller を同じアーキテクチャに導入する

前回のブログ シリーズ「Kubernetes でのアプリケーション サービスのデプロイ」では、デジタル トランスフォーメーションの過程で多くのお客様に見られるパターンについて説明しました。 ほとんどの旅は、アプリ (通常はモノリス) の作成と展開の従来のモデルから始まり、これら 2 つの機能の責任をサイロ化された開発チームと運用チームの間で分割します。 組織がより現代的なモデルに移行するにつれて、マイクロサービス ベースのアプリが作成され、従来のサイロ間の境界を曖昧にする DevOps プラクティスを使用して展開されます。

DevOps チームとアプリケーション所有者は、アプリケーションのデプロイ、管理、配信の方法をより直接的に制御するようになっていますが、サイロの壁を一度にすべて取り壊すことは現実的ではないことが多く、また、その必要性も感じていません。 代わりに、責任の論理的な分割が依然として適用されることがわかります。

• ネットワークおよびセキュリティ チームは、企業インフラストラクチャの全体的なセキュリティ、パフォーマンス、可用性に引き続き重点を置いています。 彼らが最も気にかけているのは、一般的にそのインフラストラクチャの「玄関口」に展開されるグローバル サービスです。

  これらのチームは、グローバル サーバー ロード バランシング(GSLB)、 DNS解決とロード バランシング、高度なトラフィック シェーピングなどのユース ケースにF5 BIG-IPを活用しています。 BIG‑IQと NGINX Controller [現在はF5 NGINX Management Suite ] は、NetOps チームに最適な形式でメトリックとアラートを提供し、SecOps チームには、組織の資産を保護し、業界の規制に準拠するために SecOps が持つ必要のあるセキュリティの可視性と制御を提供します。

• 運用チーム (Ops に重点を置いた DevOps) は、関連する事業部門の要件に応じて個々のアプリケーションを作成および管理します。 彼らが最も重視するのは、更新された機能をより迅速に反復するのに役立つ自動化や CI/CD パイプラインなどのサービスです。このようなサービスは一般に、Kubernetes 環境内など、アプリの「近く」にデプロイされます。

  これらのチームは、Kubernetes クラスターを含む複数の環境でホストされる分散型マイクロサービスベースのアプリケーションの負荷分散とトラフィック シェーピングに、 NGINX Plus 、 NGINX App Protect 、 NGINX Ingress Controller 、 NGINX Service Meshなどの NGINX 製品を活用しています。 使用例には、TLS 終了、ホストベースのルーティング、URI 書き換え、JWT 認証、セッション永続性、レート制限、ヘルスチェック、セキュリティ (統合 WAF としての NGINX App Protect を使用) などがあります。

Kubernetes 環境における NetOps と DevOps

NetOps チームと DevOps チームの異なる懸念は、Kubernetes 環境で果たす役割と、その役割を果たすために使用するツールに反映されています。 単純化しすぎるリスクはありますが、NetOps チームは主に Kubernetes クラスター外部のインフラストラクチャとネットワーク機能に関心を持ち、DevOps チームはクラスター内部の機能に関心を持っていると言えます。

NetOps チームは、Kubernetes クラスターにトラフィックを誘導するために、すでに使い慣れているオーバーレイ ネットワーキング テクノロジーの機能と範囲をサポートする外部ロード バランサーとして BIG-IP を使用できます。 ただし、BIG-IP だけでは、Kubernetes クラスター内のポッド セットの変更 (ポッドの数や IP アドレスの変更など) を追跡することはできません。 この制約を回避するために、 F5 Container Ingress Services (CIS) がクラスター内のオペレーターとして展開されます。 CIS はポッド セットの変更を監視し、それに応じて BIG-IP システムの負荷分散プール内のアドレスを自動的に変更します。 また、新しい Ingress、Route、カスタム リソースの作成を検索し、それに応じて BIG-IP 構成を更新します。

BIG-IP と CIS を組み合わせて使用して、アプリケーション ポッドへのトラフィックを直接負荷分散することもできますが、実際には、NGINX Ingress Controller は、たとえば、変化する需要レベルに対応するためにアプリケーション ポッドを水平方向にスケーリングする場合など、多数のサービスを表すポッドやワークロードに対する動的なアプリケーションの変更を検出して対応するための理想的なソリューションです。

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

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

ご存知のとおり、BIG‑IP と NGINX Ingress Controller は、もともと 2 つの別々の会社 (それぞれ F5 と NGINX) によって設計されました。 F5 が NGINX を買収して以来、2 つのツール間の相互運用性を向上させることでインフラストラクチャの管理が簡素化されるとお客様からお聞きしています。 これに応じて、私たちは IngressLink という新しい Kubernetes リソースを開発しました。

IngressLink リソースは、Kubernetes CustomResourceDefinition (CRD) を使用して NGINX Ingress Controller と BIG‑IP を「リンク」するシンプルな拡張機能です。 簡単に言えば、NGINX Ingress Controller ポッドのセットが変更されるたびに、CIS が BIG-IP に「伝える」ことができるようになります。 この情報により、BIG-IP は対応する負荷分散ポリシーを迅速に変更して一致させることができます。

Kubernetes クラスターへの負荷分散のために BIG-IP が展開され、NGINX Ingress Controller が入出力トラフィックを処理する場合、トラフィック フローは次のようになります。

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

はじめる

IngressLink リソースの動作の詳細 (展開ガイドを含む) については、 F5 CloudDocs をご覧ください。

NGINX App Protect WAF および DoS を備えた NGINX Ingress Controller の30 日間無料トライアルをリクエストして開始してください。 まだ BIG-IP ユーザーでない場合は、チームに最適なトライアルを F5.com で選択してください。