BGPでクラスターに到達？

NGINX | 2023年2月28日

堅牢なKubernetes環境を構築・管理するには、ネットワークチームとアプリケーションチームの円滑な連携が欠かせません。しかし、両チームでは優先事項や仕事の進め方が大きく異なることが多く、対立が生じる場合があります。その結果、アプリケーション開発の遅延、デプロイの遅れ、さらにはネットワークのダウンタイムなど、深刻な影響につながる可能性があります。

共通の目標に向かって取り組む両方のチームが成功してこそ、今日のモダンアプリケーションを適切なセキュリティと拡張性を確保しながら、予定どおりに提供できます。では、各チームのスキルと専門知識を活かしつつ、連携を促進するにはどうすればよいのでしょうか。

ホワイトペーパー「Get Me to the Cluster」では、Kubernetesサービスへの外部アクセスを可能にし、ネットワークチームとアプリケーションチームが対立することなく互いの強みを生かせるソリューションについて詳しく説明しています。

Kubernetesクラスター内のアプリを外部公開する方法

このソリューションは、オンプレミスでホストされるKubernetesクラスターに特化しています。ノードはベアメタルまたは従来型のLinux仮想マシン（VM）上で稼働し、標準的なレイヤー2スイッチとレイヤー3ルーターがデータセンター内の通信用ネットワークを提供します。クラウドプロバイダーのデータセンター内にあるコアネットワークや、マネージドKubernetes環境内のネットワークは制御できないため、クラウドでホストされるKubernetesクラスターには対応していません。

オンプレミスでホストされるKubernetesクラスターの図。ノード、標準的なレイヤー2スイッチ、レイヤー3ルーターが、データセンター内の通信用ネットワークを提供しています。

F5のソリューションの詳細を説明する前に、Kubernetesクラスター内のアプリケーションを公開する他の標準的な方法が、オンプレミス環境では機能しない理由を確認しましょう。

Service – 同じアプリを実行するPodをグループ化します。Pod間の内部通信には非常に便利ですが、クラスター内からしかアクセスできないため、アプリを外部に公開する用途には役立ちません。
NodePort – クラスター内の各ノードで特定のポートを開き、対応するアプリにトラフィックを転送します。これにより外部ユーザーがサービスにアクセスできるようになりますが、構成が静的であることに加え、ウェルノウンポートのような小さい番号のポートではなく、番号の大きいTCPポートを使用し、他のアプリとポート番号を調整する必要があるため、最適とはいえません。また、複数のアプリで共通のTCPポートを共有することもできません。
LoadBalancer – 各ノードのNodePort定義を使用して、外部からKubernetesノードへのネットワークパスを作成します。AWS、Google Cloud Platform、Microsoft Azureをはじめとするほとんどのクラウドプロバイダーが、簡単に構成でき、適切に機能する機能としてサポートしているため、クラウドでホストされるKubernetesに最適です。また、サービスに必要なパブリックIPアドレスと、それに対応するDNS Aレコードも提供します。ただし、オンプレミスクラスターには同等の機能がありません。

オンプレミスのKubernetesクラスターへの外部ユーザーアクセスを有効化

そこで選択肢となるのが、KubernetesのIngressオブジェクトです。これは、クラスター外部のユーザーからクラスター内部のPodへ流れるトラフィック（ノースサウストラフィック）向けに設計されています。Ingressは、外部ユーザーが複数のサービスにアクセスできる単一のIPアドレスまたはDNS名として、クラスターに外部HTTP/HTTPSエントリーポイントを作成します。まさに必要な機能です。IngressオブジェクトはIngressコントローラーによって実装されます。このソリューションでは、エンタープライズグレードのF5 NGINX Ingress Controllerを使用します。これはNGINX Plusをベースとしています。

意外に思われるかもしれませんが、このソリューションのもう1つの主要コンポーネントは、Border Gateway Protocol（BGP）というレイヤー3ルーティングプロトコルです。しかし、優れたソリューションが複雑である必要はありません。

「Get Me to the Cluster」で概説したソリューションは、実際には4つのコンポーネントで構成されています。

iBGPネットワーク – Internal BGP（iBGP）は、データセンター内の自律システム（AS）内でルーティング情報を交換するために使用され、ネットワークの信頼性と拡張性の確保に役立ちます。ほとんどのデータセンターでは、iBGPがすでに導入されており、ネットワークチームによってサポートされています。
Project Calico CNIネットワーキング – Project Calicoは、トラフィックフローをきめ細かく制御しながら、オンプレミスデータセンター内の環境を柔軟に接続するオープンソースのネットワーキングソリューションです。Kubernetesクラスターのネットワーキングには、BGPを有効にしたProject CalicoのCNIプラグインを使用します。これにより、Podに割り当てるIPアドレスプールを制御でき、ネットワークの問題を迅速に特定しやすくなります。
NGINX PlusベースのNGINX Ingress Controller – NGINX Ingress Controllerを使用すると、PodのサービスエンドポイントIPアドレスを監視し、トラフィック処理を中断することなくアップストリームサービスのリストを自動的に再構成できます。アプリケーションチームは、アクティブヘルスチェック、mTLS、JWTベースの認証など、NGINX Plusが備えるその他の多彩なエンタープライズグレードのレイヤー7 HTTP機能も活用できます。
エッジでリバースプロキシとして機能するNGINX Plus – NGINX PlusはKubernetesクラスターのエッジにリバースプロキシとして配置され、データセンター内のスイッチおよびルーターと、Kubernetesクラスター内の内部ネットワークとの間の経路を提供します。これはKubernetesのLoadBalancerオブジェクトの代替として機能し、BGPにはQuaggaを使用します。

この図はソリューションのアーキテクチャを示すもので、リクエスト処理中にデータが交換される順序ではなく、ソリューションの各コンポーネントが通信に使用するプロトコルを示しています。