Kubernetes 間をプライベートなネットワークで接続する Submariner

こんにちは、Red Hat で OpenShift を担当しています。花田です。

Red Hat の Kubernetes の Cluster 管理製品である ACM (Advanced Cluster Management) では、バージョン2.2 よりテクノロジープレビューとして、Sumbariner というコンポーネントが使えるようになりました。

Submariner は端的に言うと、異なる Kubnerentes クラスター間をオーバーレイネットワークで結ぶためのコンポーネントです。正確には異なるクラスター間で、Kubernetes の Service 名を解決するための Lighthouse というプロジェクトもセットで使われています。

Submariner を使用するための現時点での条件

現時点での前提条件は複数ありますが、マニュアルから一部をピックアップすると

ACM の Hub を稼働させる OCP 4.5 以上
相互ネットワークで接続されるクラスターのバージョンは OCP 4.4以降
各クラスターの Pod 、サービスが使用している CIDR は重複していない事

等があります。

最後のCIDRの重複については、アップストリームの Submariner 側では、Globalnet Controller というオプショナルなコンポーネントを使って解決させる事が既に考えられているようです。

Submariner のアーキテクチャー

大体のアーキテクチャーと、コンポーネント名は覚えておいた方が何かと便利なので、ほぼ公式ドキュメントページの翻訳ですが、以下に記します。コンポーネント名や用語が、アップストリームの Submariner のドキュメントと ACMのマニュアルで若干異なる所があるのですが、ここから以下はアップストリームの用語を基準としています。

Gateway Engine : クラスター間のトンネリングを管理する Engineです。Daemonsetとして、"submariner.io/gateway=true" のラベルが付いた Node に配られます。
Broker : Gatway Engine 間のメタデータの交換を助けるコンポーネントです。CRD(Custom Resrouce Definition) とそれを保管している Kubernetes の事を指し PodやService がデプロイされるわけではありませ
Route Agent :ノードからアクティブな Gateway Engine へトラフィックをルートする Agentです。Kubernetes の各 Node に存在します。
Service Disovery : クラスター間のサービスの DNS解決を提供するコンポーネント
Lighthouse Agent : 各クラスター内部に存在しているAgentで、Broker を通じて Service の情報の metadata を他のクラスターと交換します。

これらを図で表すと以下のような感じになります。ACM Hub は、この絵の中では、"Broker" となります。コンポーネントの配置は ACMでデプロイされる配置を実際に確認したわけではなく、アップストリーム Submariner のドキュメントを元に書き起こしたものになりますのでご了承下さい。

Gateway Engine の置かれた Gateway Node 間は、IPSECで結ぶ事で、異なるクラスター間のネットワークを接続します。仕組み自体は非常にシンプルです。

耐障害性も考えられており、トラフィックの出入り口になる Gateyway Node は、Acitve - Passive構成を取り、Active側の障害時には、Passive 側に切り替えが行われます。 Broker は一つしかありませんが、Broker のダウンは、Submariner に参加しているクラスターの通信に影響を与えません。新規に追加されたクラスターなどは検知できなくなりますが、Brokerが復活次第、情報の Update や同期が再開されます。

ClusterSet

ClusterSet という概念も導入されています。ClusterSet は、2つ以上のクラスターで構成されるグループの事です。Submariner を有効化する時には、ACM上から複数のクラスターで構成されるClusterSet に対して、Submariner を add-on を有効化する事で、クラスター間のネットワークが構成されます。

Service の公開

他のクラスターに対して、Service を公開するには、ServiceExport オブジェクトを作成して、service を export します。 export された Service は、

[service].[namespace].svc.clusterset.local

としてアクセス可能になります。

この時、クラスターをまたいで使用できるこの Service の名前解決は、Lighthouse DNS Server が行います。 Lighthouse DNS Server は、clusterset.local のドメイン名を所有する権威DNSとして振る舞います。Kubernetes の CoreDNS から clusterset.local の名前解決をフォワードされ、Lighthouse Agent が Broker 経由で取得してきた他のクラスターの Service のmetada を元に、Service 名を解決します。

分散環境でのKubernetes の今後

コンテナの小ささは、遠隔地にもアプリケーションを簡単に展開しやすくするため、地理的に離れた場所や、Edge でのアプリケーション展開に Kubernetes 利用したいという需要がでてきています。その場合、複数作成され、地理的に分散されたKubernetes クラスタを、もっとシンプルに透過的に使用したくなるのは当然で、Submariner もそうした背景を元に開発されてきたのだと思います。

また、距離がある場合はレイテンシーの問題はつきまといますが、Database のようなデータを扱うサービスは、そのまま一つのクラスタに偏在させておき、他のクラスターから(外部サービスとして公開せずに）内部サービスとして利用する。という事が Submariner の登場によって出来るようになりました。一方で、データ自体も分散させてしまう、Cockroach DB のような分散型のDatabaseもではじめています。

今後も新たな技術が登場し、熟成して行くと思いますが、コンテナの特性が新しい方向に技術をドライブ、発展させていくのは何とも楽しみです。