17
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

Kubernetes Multi-Cluster Networkingの比較(2022年2月時点)

Last updated at Posted at 2022-02-08

はじめに

みなさん、こんにちは。
KubernetesをMulti-Clusterで利用することを考えたときに、課題の一つとしてCluster間のネットワークをどのように構成するのかが挙げられます。

本稿では、主にKubernetesのMulti-Cluster Networkingの内、特にCluster間のEast-West通信の実現手法にフォーカスし、想定される要件に対して各手法の比較をまとめます。

※尚、本稿で述べてる見解は個人的見解であり、所属組織の公式見解ではありません。

Kubernetes Multi-Clusterのユースケース

そもそも、KubernetesをMulti-Clusterで使用するユースケースとは何でしょうか?
私の経験上、下記な感じに分かれる所感です。

image.png

パターン ユースケース概要
単一インフラ環境パターン ・ClusterアップデートをCluster Migrationで行いたい
・Clusterを二重化して耐障害性を向上させたい、など
マルチクラウドパターン ・クラウドのダイバーシティを取り、耐障害性を向上させたい、など
ハイブリッドクラウドパターン ・オンプレでデータ管理したまま、パブリッククラウドを使いたい
・クラウドをオンプレ障害時の保険にしたい
・オンプレのClusterアップデートを安全に行いたい、など
エッジクラウドパターン ・ジオロケーションサービスを提供したい
・応答性の改善を図りたい
・カスタマーエッジでは処理できないヘビーな処理を近いネットワークエッジへオフロードしたい、など
  • 多くは単一のインフラ環境パターン
  • 次に今後ユースケースが増えそうなのはマルチクラウド、ハイブリッドクラウドパターン

な所感です。

エッジクラウドは、F5社のVolterraなどで一部実現されています。
私の妄想では、CDN事業者や通信キャリアの提供するMEC(Multi-access Edge Computing)にてインターネットのレイヤやネットワークエッジが、デバイスとクラウドのアプリケーション通信を中継する役割として機能する可能性もあるなぁ・・・と夢想しています。

Multi-Cluster Networkingの想定要件

Multi-Clusterを構成したときに、ネットワーク観点では主に、**クライアントからClusterへのインバウンド通信(North-South通信)**と、**Cluster間通信(East-West通信)**をどの様に構成するかが検討ポイントになるかと思います。

image.png

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手法に分類できました。

image.png

8手法の比較を以下の表にて示します。

image.png

各手法の違いをざっくりサマると、以下の図みたいな感じでしょうか。

image.png

各手法の使い分けを考えてみる

もやもやと考えて、以下の様な図でまとめてみました。

image.png

①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などで議論できると嬉しいです。

参考リンク

17
8
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
17
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?