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

# はじめに

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

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

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

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/c0425c65-947a-34bd-d511-9498ff872704.png)

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

- 多くは単一のインフラ環境パターン
- 次に今後ユースケースが増えそうなのはマルチクラウド、ハイブリッドクラウドパターン

な所感です。

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

# Multi-Cluster Networkingの想定要件

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/7c94e4ec-e1c5-774d-9958-6ea1507d2ce6.png)

North-South通信は以下の記事でも言及しましたが、特にMEC(Multi-access Edge Computing)での課題が大きく、Kubernetesとは異なるレイヤでの解決策も必要になるでしょう。

https://qiita.com/ydo/items/87945c14359ca2100224

例えば、Verizonが北米で提供する`Verizon 5G Edge`は、独自の`Edge Discovery Service(EDS)`と言うAPIを提供し、複数のエッジサイト(例えば、Wavelengthゾーン)へ展開されたアプリケーションへ端末がアクセスする際に、適切なエッジエンドポイントを返却するソリューションを提供しています。

https://www.verizon.com/business/5g-edge-portal/documentation/verizon-5g-edge-discovery-service.html

また、似たようなものに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](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/9f21012a-8128-d225-4d9f-545e010587d4.png)




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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/0862cca6-e023-1421-30b7-7b93186cf565.png)



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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/74bb6304-3d33-a95a-5c85-b5402f11e192.png)



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

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559968/a9bcc3d1-3c83-6141-168b-8a98793ac293.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ですので、ベンダロックという点が懸念されます。

**参考記事**

https://www.volterra.io/docs/ves-concepts/system-overview

そこで、IstioとSubmarinerの両方を用いたパターンも考えられます。

Multi-ClusterでServiceMeshを構成する際はPod間がreachableという必要があります。
SubmarinerでCluster間をL3 Interconnectし、フラットなMulti-Clusterネットワークを構成した上で、
Istioを用いてServiceMeshを構成する、というハイブリッドな使い方も想定されます。

**参考記事**

https://cloud.redhat.com/blog/set-up-istio-multicluster-with-submariner-in-red-hat-advanced-cluster-management-for-kubernetes

アプリケーション間通信が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などで議論できると嬉しいです。

# 参考リンク
- https://submariner.io/
- https://liqo.io/
- https://skupper.io/
- https://istio.io/latest/docs/setup/install/multicluster/
- https://linkerd.io/2.10/features/multicluster/
- https://cilium.io/blog/2019/03/12/clustermesh
- https://www.volterra.io/