はじめに
みなさん、こんにちは。
KubernetesをMulti-Clusterで利用することを考えたときに、課題の一つとしてCluster間のネットワークをどのように構成するのかが挙げられます。
本稿では、主にKubernetesのMulti-Cluster Networkingの内、特にCluster間のEast-West通信の実現手法にフォーカスし、想定される要件に対して各手法の比較をまとめます。
※尚、本稿で述べてる見解は個人的見解であり、所属組織の公式見解ではありません。
Kubernetes Multi-Clusterのユースケース
そもそも、KubernetesをMulti-Clusterで使用するユースケースとは何でしょうか？
私の経験上、下記な感じに分かれる所感です。
| パターン | ユースケース概要 |
|---|---|
| 単一インフラ環境パターン | ・ClusterアップデートをCluster Migrationで行いたい ・Clusterを二重化して耐障害性を向上させたい、など |
| マルチクラウドパターン | ・クラウドのダイバーシティを取り、耐障害性を向上させたい、など |
| ハイブリッドクラウドパターン | ・オンプレでデータ管理したまま、パブリッククラウドを使いたい ・クラウドをオンプレ障害時の保険にしたい ・オンプレのClusterアップデートを安全に行いたい、など |
| エッジクラウドパターン | ・ジオロケーションサービスを提供したい ・応答性の改善を図りたい ・カスタマーエッジでは処理できないヘビーな処理を近いネットワークエッジへオフロードしたい、など |
- 多くは単一のインフラ環境パターン
- 次に今後ユースケースが増えそうなのはマルチクラウド、ハイブリッドクラウドパターン
な所感です。
エッジクラウドは、F5社のVolterraなどで一部実現されています。
私の妄想では、CDN事業者や通信キャリアの提供するMEC(Multi-access Edge Computing)にてインターネットのレイヤやネットワークエッジが、デバイスとクラウドのアプリケーション通信を中継する役割として機能する可能性もあるなぁ・・・と夢想しています。
Multi-Cluster Networkingの想定要件
Multi-Clusterを構成したときに、ネットワーク観点では主に、クライアントからClusterへのインバウンド通信(North-South通信)と、Cluster間通信(East-West通信)をどの様に構成するかが検討ポイントになるかと思います。
North-South通信は以下の記事でも言及しましたが、特にMEC(Multi-access Edge Computing)での課題が大きく、Kubernetesとは異なるレイヤでの解決策も必要になるでしょう。
例えば、Verizonが北米で提供するVerizon 5G Edgeは、独自のEdge Discovery Service(EDS)と言うAPIを提供し、複数のエッジサイト(例えば、Wavelengthゾーン)へ展開されたアプリケーションへ端末がアクセスする際に、適切なエッジエンドポイントを返却するソリューションを提供しています。
また、似たようなものにMobiledgeXのDME(Distributed Matching Engine)と言うソリューションも存在しています。(詳細は上記のMECの記事にて言及しています)
本稿のトピックであるEast-West通信に関して、想定される各要件を以下の通りまとめてみました。
| 想定要件 | 概要 |
|---|---|
| セットアップ | 手動 or 自動 |
| セキュリティ | Cluster間のセキュアトンネリング、など |
| サービスディスカバリ | 外部DNS or 内部DNS |
| テナント分離 | Cluster Level or Namespace Level |
| トポロジ | Full Mesh, Hub&Spoke... |
| NAT配下でのMulti-Cluster可否 | ClusterがNATの後ろに位置している時に導入可能か |
| インフラのFWルール管理の煩雑さ | Cluster間通信のFWルールの設定容易さ |
| Cluster間通信の制御の柔軟性 | ClusterからClusterへの負荷分散、など |
| CNI非依存 | CNIに依存せずに導入可能か |
| Namespace拡張 | Cluster間でNamespaceを延伸する機能の有無 |
| クラスタ間でのIP重複 | Cluster間でIP重複できるか |
| 2クラスタ以上のサポート | 2以上のクラスタをサポートしているか |
| 成熟度 | 技術的な成熟度 |
| ベンダロック | ベンダロックインが発生するかどうか |
Cluster間通信のソリューション
私が調べた限り、方式が近いものをまとめると以下の5カテゴリ8手法に分類できました。
8手法の比較を以下の表にて示します。
各手法の違いをざっくりサマると、以下の図みたいな感じでしょうか。
各手法の使い分けを考えてみる
もやもやと考えて、以下の様な図でまとめてみました。
①Ingressパターン
①Ingressパターンの用途は、例えば「Cluster=システムの様になってて、システムAとシステムBでそれぞれ開発主管が違う。システムAからシステムBの開発したAPIを実行したい」、という様なケースしか思いつきませんでした。
②ServiceMeshパターン
②ServiceMeshパターンはGatewayを介したServiceMeshの延伸、
③Tunneling、④L7 MessagingパターンはClusterのOverlay Network間接続、とイメージしています。
Cluster間の通信制御の柔軟性という点だと、②ServiceMeshパターンの方が③④よりも優位だろうと考えます。
一方、セキュリティを高めたいニーズに対しては、⑤SaaS(F5社のVoltMesh)が優位と感じました。
VoltMeshは
- 独自のロードバランサ(VoltMesh)を用いてMulti-ClusterでServiceMeshを実現
- ノード間をIPsec/SSLトンネルで接続する構成
- アプリケーション間通信はInternetでなく、
Volterra Global BackboneというVolterra構築のバックボーンを経由
という構成で、独自バックボーン経由とその上でIPsec/SSLトンネル上での通信の2点で優位に感じました。
但し、VoltMeshはF5社の提供するSaaSですので、ベンダロックという点が懸念されます。
参考記事
そこで、IstioとSubmarinerの両方を用いたパターンも考えられます。
Multi-ClusterでServiceMeshを構成する際はPod間がreachableという必要があります。
SubmarinerでCluster間をL3 Interconnectし、フラットなMulti-Clusterネットワークを構成した上で、
Istioを用いてServiceMeshを構成する、というハイブリッドな使い方も想定されます。
参考記事
アプリケーション間通信がVolterra Global Backboneを介し、かつIPsec/SSLトンネル上で処理されるのか、
Internet上のIPsecトンネルを介するのかで、若干セキュリティレベルの違いはあると思いますが、
オープンソースの組み合わせである程度対応可能です。
③Tunnelingパターン vs ④L7 Messagingパターン
③Tunnelingパターンの懸念事項としては、Cluster数増加に伴うFWルール追加の煩雑さが考えられます。
Gateway間疎通に、例えば4500/UDPなどのFWの穴開けが必要です。
また、エッジデバイスでKubernetesクラスタを構成し、クラウド上のClusterと連携する、というようなユースケースを実現したい場合に、IPsecではエッジデバイスのリソース面で課題となる可能性もあります。
したがって、Cluster数が増える場合やエッジコンピューティングのユースケースを想定する場合、
④L7 Messagingパターンの方が優位な所感です。
さいごに
本稿では、Kubernetes Multi-Cluster Networkingの手法と各手法の比較をまとめ、もやもやと使い分けを考察してみました。
特に異なるインフラ環境で3 Cluster以上使うなんて、まだまだ先の話かなぁとも思いますが、エッジコンピューティングなど新しいユースケースでの有力なソリューションになる期待もありますので、Multi-Clusterのユースケースを深掘っていきたいと思います！
最後に、各ソリューションの比較や使い方などは色んな意見を知りたいので、コメントまたはTwitterなどで議論できると嬉しいです。