BGP を使ってクラスターにアクセスできますか?

堅牢な Kubernetes 環境を作成および管理するには、ネットワーク チームとアプリケーション チーム間のスムーズな連携が必要です。 しかし、彼らの優先順位や作業スタイルは通常かなり異なっており、衝突が生じて、アプリ開発の遅延、展開の遅れ、さらにはネットワークのダウンタイムなど、深刻な結果を招く可能性があります。

共通の目標に向かって取り組む両チームの成功によってのみ、今日の最新アプリケーションが適切なセキュリティとスケーラビリティを備えて予定どおりに提供されることが保証されます。 では、各チームのスキルと専門知識を活用しながら、連携して作業するにはどうすればよいでしょうか?

当社のホワイトペーパー「Get Me to the Cluster」では、Kubernetes サービスへの外部アクセスを可能にし、ネットワーク チームとアプリケーション チームが競合することなくそれぞれの強みを組み合わせられるようにするソリューションについて詳しく説明しています。

Kubernetes クラスターでアプリを公開する方法

このソリューションは、オンプレミスでホストされる Kubernetes クラスターに特化しており、ノードはベアメタルまたは従来の Linux 仮想マシン (VM) 上で実行され、標準のレイヤー 2 スイッチとレイヤー 3 ルーターがデータセンター内の通信用ネットワークを提供します。 クラウド プロバイダーは、データセンター内のコア ネットワークや管理対象の Kubernetes 環境内のネットワークを制御することを許可していないため、クラウドでホストされる Kubernetes クラスターには適用されません。

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

• サービス– 同じアプリを実行しているポッドをグループ化します。 これは内部のポッド間通信には最適ですが、クラスター内でのみ表示されるため、アプリを外部に公開するのには役立ちません。
• NodePort – クラスター内のすべてのノードで特定のポートを開き、対応するアプリにトラフィックを転送します。これにより、外部ユーザーがサービスにアクセスできるようになりますが、構成が静的であり、既知の低いポート番号ではなく高い番号の TCP ポートを使用し、他のアプリとポート番号を調整する必要があるため、理想的ではありません。 また、異なるアプリ間で共通の TCP ポートを共有することはできません。
• LoadBalancer – 各ノードの NodePort 定義を使用して、外部から Kubernetes ノードへのネットワーク パスを作成します。 これは、AWS、Google Cloud Platform、Microsoft Azure、および他のほとんどのクラウド プロバイダーが、簡単に構成でき、適切に機能し、サービスに必要なパブリック IP アドレスと一致する DNS Aレコードを提供する機能としてサポートしているため、クラウドでホストされる Kubernetes に最適です。 残念ながら、オンプレミスのクラスターに相当するものはありません。

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

残っているのは、クラスター外部のユーザーからクラスター内部のポッドに流れるトラフィック (North-South トラフィック) 専用に設計された Kubernetes Ingress オブジェクトです。 Ingress は、クラスターの外部 HTTP/HTTPS エントリ ポイント (外部ユーザーが複数のサービスにアクセスできる単一の IP アドレスまたは DNS 名) を作成します。 まさにこれこそが必要なものなのです！ Ingress オブジェクトは Ingress コントローラによって実装されます。当社のソリューションでは、 NGINX Plusに基づくエンタープライズ グレードのF5 NGINX Ingress コントローラが使用されています。

ソリューションのもう 1 つの重要なコンポーネントが、レイヤー 3 ルーティング プロトコルであるBorder Gateway Protocol (BGP) であることに驚かれるかもしれません。 しかし、優れたソリューションは複雑である必要はありません。

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

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

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

ホワイトペーパーを無料でダウンロード

明確に定義されたコンポーネントを使用してソリューションを実装するために協力することで、ネットワーク チームとアプリケーション チームは最適なパフォーマンスと信頼性を簡単に実現できます。

当社のソリューションは、最新のネットワーク ツール、プロトコル、既存のアーキテクチャを使用します。 安価で簡単に実装、管理、サポートできるように設計されているため、使いやすさが向上し、チーム間の橋渡しが行われます。

コードの動作を確認し、ソリューションをデプロイする方法を段階的に学習するには、 「Get Me to the Cluster」を無料でダウンロードしてください。