トップ > Kubernetes > OVN-Kubernetes with OVN Interconnectのご紹介

OVN-Kubernetes with OVN Interconnectのご紹介

Kubernetes OVN OpenShift

本ブログ記事は、OpenShift Advent Calendar 2023のエントリーです。(年を越してしまいましたが...)

OpenShift v4.14のリリースノートに、「Open Virtual Network (OVN) 最適化によるスケーリングと安定性の向上」という項目があり、下記のような記述になっています。

OpenShift Container Platform 4.14 では、Open Virtual Network Kubernetes (OVN-K) の最適化が導入されており、内部アーキテクチャーが変更されて運用遅延が短縮され、ネットワーキングコントロールプレーンのスケールとパフォーマンスに対する障壁が取り除かれています。ネットワークフローデータは、コントロールプレーンに情報を集中させるのではなく、クラスターノードにローカライズされるようになりました。これにより、操作遅延が短縮され、ワーカーノードとコントロールノード間のクラスター全体のトラフィックが削減されます。その結果、ノードが追加されるたびにネットワーク容量が追加され、大規模なクラスターが最適化されるため、クラスターネットワークのノード数は線形にスケールします。ネットワークフローはすべてのノードでローカライズされるため、コントロールプレーンノードの RAFT リーダー選出は必要なくなり、不安定性の主な原因が除去されました。ローカライズされたネットワークフローデータのさらなる利点は、ネットワーク上のノード損失の影響が障害が発生したノードに限定され、クラスターの残りのネットワークには影響を及ぼさないため、クラスターの障害シナリオに対する回復力が高まることです。詳細は、OVN-Kubernetes アーキテクチャー を参照してください。

この中身について簡単にご紹介します。

...とその前に。本題に入る前に書いておきたいことがありまして、それはOpenShift/Kubernetes (もしくはCNIプラグイン) の観点からは、OVNK LegacyもOVNK Interconnectも同じように見える、という点です。したがいまして、OpenShift v4.13 (OVNK Legacy) からv4.14 (OVNK Interconnect) にアップグレードした場合でも、利用者(Pod/Service/Network Policy等のk8s API)の観点からは全く同じ使い方ができます。

OVN-Kubernetes、OVN、OVN Interconnect、OVN-Kubernetes with OVN Interconnect

まずはじめにOVN周りの用語を整理したいと思います。

  • OVN (Open Virtual Network): Software Defined Networkingを実現するOSSのひとつ。主にOpen vSwitchコミュニティのメンバーで開発されています。さまざまなCMS (Cloud Management System、仮想基盤やコンテナ基盤のコントローラと思ってください) と連携することを想定しています。具体的には、OpenStack、oVirt、Docker、Kubernetes等から使用することができます。
  • OVN Interconnect: OVNのクラスター間をGeneveトンネルで結ぶことで、複数のOVNクラスターを接続するOVNの機能。OVN-ICと略すこともあります
  • OVN-Kubernetes: Kubernetes上でOVNを使ってPod/Serviceの通信を行うためのCNIプラグイン。OpenShiftでは、OVN-Kubernetesはv4.2からTech Previewとして導入され、v4.6から正式サポートのCNIプラグインとなりました。v4.12以降はOVN-KubernetesがデフォルトのCNIプラグインです。OVNK、OVN-Kなどと略すこともあります
  • OVN-Kubernetes with OVN Interconnect: OVN-Kubernetesの中でOVN Interconnectを使う構成のこと。OVNK-ICと略すこともあります

冒頭のOpenShift v4.14のリリースノートの文言は、OpenShiftでOVN-Kubernetesを使う際の構成が、従来のOVN-KubernetesからOVN-Kubernetes with OVN Interconnectに変わった、ということを意味しているのでした。

従来のOVN-Kubernetesの構成

OVNを構成するコンポーネントは、図1のようになっています。

図1: OVNの構成要素

従来のOVN-Kubernetes (OVNK Legacy) では図2のように、OVNを構成するコンポーネントのうち、コントロールプレーンを構成するNorthboud DB (nbdb)、northd、Southbound DB (sbdb) がcontrol planeノードで ovnkube-master というPodとして稼働し、データプレーンとなるovn-controllerおよびovs-vswitchd、ovsdb-serverが全ノードで稼働します。

図2: OVN-Kubernetes Legacyのコンポーネント

OVN-Kubernetesのおおまかな動きとしては、OVNのオーバーレイ論理ネットワークに変化が起きた場合 (例えばPodを新たにデプロイした場合)、ovnkube-masterがk8sのAPIリソースの更新を検知してNorthbound DB (nbdb) にオーバーレイ論理ネットワークの更新を書き込みます。その後northdがそれを検知して論理フローに変換してSouthbound DB (sbdb) に書き込み、ovn-controllerがそれを検知して自ノードのOVSブリッジに必要なOpenFlowのフローを投入します。何らかのイベントによってノードのポート状態が変化した場合 (例えばPodが死んだ場合) は逆に、該当Podが稼働するノードのovn-controllerがそれを検知してSouthbound DBに書き込み、northdがそれを検知してNorthbound DBを更新し、最後にovnkube-masterがk8sのAPIサーバ経由でetcdにその情報を記録します。

nbdb, sbdbは各control planeノードで稼働するOVSDBで、OVNK Legacyではそれぞれが冗長化のためにcontrol planeノード間でRAFTクラスターを構成します。また各ノードのovn-controllerはcontrol planeノードのsbdbにOVSDB Management Protocolで接続します。このためOVNK Legacyには、ノード数が増えるとその分sbdbに対する接続数が増え、またPodやServiceが増えるとその分「control planeノードのsbdb」↔「各ノードのovn-controller」の通信が増える、という課題がありました。

OVN-Kubernetes with OVN Interconnectionの構成

OVN Interconnectは元々、Kubernetesとは関係なく、複数のOVNクラスターを接続するために考案されたアーキテクチャです。これをOVN-Kubernetesに応用したものが、OVNK Interconnectです。OVNK Interconnectの構成は図3のようになります。

図3: OVN-Kubernetes Legacyのコンポーネント

OVNK Legacyでは、OpenShift/Kubernetesクラスター1つに対してOVNクラスターを1つデプロイしていましたが、OVNK Interconnectでは、各ノードごとに1つのOVNスタックを配置します。具体的には、OVNのコントロールプレーンとなるnbdb, sbdb, northdといったコンテナが、control planeノードではなく、全ノード上の ovnkube-node Pod内で稼働します。OVNK Legacyでは、nbdbおよびsbdbはcontrol planeノード上で稼働し、OpenShift/Kubernetesクラスター全体のオーバーレイ論理ネットワークの情報を格納していましたが、OVNK Interconnectでは各ノードに分散し、自ノードの論理ネットワークの情報だけを持ちます。また、OVNK Legacyのnbdb, sbdbは3台のcontrol planeノード間でRAFTクラスターを構成して冗長化しましたが、OVNK Interconnectではシングル構成で冗長化はしません。結果としてOVNK Interconnectでは、OVSDB Management Protocolによる通信は完全にノード内に閉じる形になります。

control planeで稼働するPod (ovnkube-cluster-manager) はクラスター全体の情報 (ノードごとのサブネット、Egress IP等) を管理し、nbdbやsbdbにはアクセスしません (情報は主にノードのannotationに記録します)。

OVNK Interconnectにすることで期待できること

OVN-KubernetesをOVN Interconnect化し、各ノードで独立したOVNスタックを持つことで、下記のようなメリットを享受することができます。

  • OVN的な処理のレイテンシーの改善 (Legacyでは論理ネットワーク全体のDB更新が必要だったのに対して、ICでは各ノードが自ノード上の論理ネットワークのみを処理するため)
  • スケーラビリティの改善 (Legacyではnbdb, sbdb, northdがボトルネックになっていたが、ICではこれらを各ノードに分散したため)
  • control planeノードの負荷の軽減 (OVNのコントロールプレーンコンポーネントであるnbdb, sbdb, northdの負荷が各ノードに分散するため)
  • ノード間通信のシンプル化 (ICではOVSDB Management Protocolによるノード間通信が必要ないため)
  • TLS証明書管理の軽減 (Legacyではノード間のOVSDB Management Protocolで使用するTLS証明書を管理する必要があったのに対して、ICではUNIXドメイン通信で済むため)
  • OVSDBのシングル構成化による運用負荷の軽減 (ICではRAFTによるクラスター化を行わないため)

このメリットは、特にHosted Control Planeで効いてきます。Hosted Control Planeとは

  • ひとつのManagement cluster: 各Hosted clusterのcontrol planeの機能をPodとして収容するOpenShiftクラスター
  • 複数のHosted cluster: workerノードのみのOpenShiftクラスター

という形で複数クラスターを管理する方式です。OVNK Interconnectにすることで、control planeのコンポーネントが小さくなり、より多くのHosted clusterをManagement clusterでホストできるようになります。

AWSでのマネージドサービスであるRed Hat OpenShift Service on AWS (ROSA)では、Hosted clusterとしてOpenShiftクラスターをデプロイすることが可能になっています(現時点ではリージョンによってはまだ使用できませんが)。ROSAのHosted Control Planeでは、Management clusterはRed Hat SREが管理するので、control planeのコンポーネントがスリム化するのはとてもうれしいのでした。

ROSA with HCPについては、こちらの記事をご参照ください。

rheb.hatenablog.com

一方で、OVNK Interconnectのデメリットとして下記が考えられます。

  • ログの増加 (各ノードでOVNスタックを持つため)
  • 各ノードのCPU/メモリ負荷の増加 (各ノードでnbdb, sbdb, northdを動かすため)
  • 論理ネットワークのパケットトレースの複雑化 (ovnkube-trace等のツールを改良中)

とはいえ、workerノードのリソースがかつかつな場合以外は、基本的にはそれほど大きな影響はないかと思います。

論理ネットワーク

OVNで作る仮想的な論理ネットワークの構成も、OVNK LegacyとOVNK Interconnectで少し異なります。OVNK Legacyの場合は図4のようなトポロジーです。ノード間を接続する論理ルーター ovn_cluster_router と論理スイッチ join が各ノードに分散します。

図4: OVN-Kubernetesのロジカルネットワーク(v4.13)

一方、OVNK Interconnectの場合は図5のようになります。ovn_cluster_router および join スイッチは分散せずに各ノード内に配置します。その代わりに、ノード間を接続する transit_switch がノードに分散する形で作られます。

図5: OVN-Kubernetesのロジカルネットワーク(v4.14)

最後に

冒頭にも書きましたが、細かい内部の話は、ユーザーの立場からはぶっちゃけあんまり気にしなくても大丈夫です。今までと同じようにご利用いただければと思います。

参考文献

余談

通常OVN Interconnectを構成するには、複数のOVNデプロイメントを管理し、クラスター間の接続情報を管理するための「ovn-ic (OVN Interconnection controller)」というデーモン(OVN-ICと紛らわしいですが、だいたい文脈でわかります)およびIC_NB/IC_SBというデータベースが必要です。しかし、OVN-Kubernetes with OVN Interconnectの場合は、全体の構成はKubernetesのetcdに情報があり、ovnkube-cluster-managerがovn-ic的な役割を果たすため、ovn-icおよびIC_NB/IC_SBは存在しません。

* 各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。