Kube-OVNでKubernetesのテナントネットワークを設計する
SDN とクラウド ネイティブの間のブリッジ (CNCF 下のプロジェクト)。 Vlan/アンダーレイのサポート: Kube-OVN は、オーバーレイ ネットワークに加えて、アンダーレイおよび VLAN モード ネットワークもサポートし、パフォーマンスの向上と物理ネットワークとの直接接続を実現します。
ひと目でわかる
- これは何？
- OVNベースの仮想ネットワークをKubernetesへ統合し、Namespace subnet、VPC、VLAN、Underlayを扱うCNCF Sandboxプロジェクト。
- 誰に向いている？
- KubernetesでNamespaceごとのアドレス空間やテナント分離を設計し、物理ネットワークへの接続も検討するチームに向きます。READMEは機能の入口とInstallation Guideへのリンクを示しますが、環境別の互換性や性能基準は載せていません。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Go です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月14日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
SDNとCloud Nativeの接続点
Kube-OVNはOVNベースのネットワーク仮想化をKubernetesへ統合するプロジェクトです。READMEはCNCF Sandbox Projectとして、KubeVirt対応とマルチテナント機能を特徴に挙げています。KubernetesのPodネットワークを単純に置き換えるというより、アドレス空間やネットワーク境界をリソースとして扱う設計が中心です。
READMEには導入コマンドの完全な貼り付け例はなく、Installation Guideへ案内しています。クラスタのKubernetes版、CNI、OVN、ノードのカーネル、物理NICを確認し、公式ガイドの前提を満たすかを先に照合します。
NamespaceごとのSubnet設計
Namespaced Subnetsでは、各Namespaceに固有のSubnetを割り当て、Logical Switchを裏付けにPodのIPを配布できます。複数NamespaceでSubnetを共有する構成もREADMEに記載されています。名前空間を作るだけで同じ分離が完成すると考えず、割り当て、ルート、通信許可を実際のリソースで確認します。
試験では二つのNamespaceに別Subnetを設定し、同一Namespaceの通信、Namespace間の通信、共有Subnetの通信を比較します。Pod再作成後にアドレスがどう変わるか、ServiceとNetworkPolicyの挙動、アドレス重複時のエラーを記録します。
VPCとマルチテナントの境界
READMEのVPC Supportは、テナントごとに独立したアドレス空間とネットワーク基盤を持つ構成として説明されています。EIP、NAT gateway、security group、load balancerをテナント単位で扱える点が挙げられています。これは設計上の機能説明であり、環境ごとの隔離性能を測った結果ではありません。
一つのテナントから別テナントのPod、NAT、ロードバランサーへ到達できないことを、許可した通信と拒否した通信の両方で確認します。管理者権限を持つユーザーがどのリソースを見られるか、設定変更が他のテナントへ波及しないかも対象にします。
OverlayからVLANとUnderlayへ
Kube-OVNはOverlayに加えてUnderlayとVLAN modeをサポートし、物理ネットワークへの直接接続や性能面の利点をREADMEで説明しています。方式を変えると必要なスイッチ設定、NIC、MTU、ルーティングが変わるため、Overlayの設定をそのまま移せるとは限りません。
評価では同じアプリケーションをOverlay、VLAN、Underlayで動かし、Pod間、外部ネットワーク、Node間の経路を確認します。MTU不一致、ノード障害、IP重複、物理スイッチ側の設定ミスを意図的に作り、ログと復旧時間を測ります。READMEは大規模時の数値を示していません。
KubeVirtを含む対象範囲
READMEはKubeVirtへの強化されたサポートにも触れています。VMとPodが同じネットワーク設計に関わる場合、IP割り当て、到達性、移動や再起動時の状態を分けて検証する必要があります。READMEの機能紹介だけでは、すべてのKubeVirt構成との互換性は確認できません。
Adopters欄は利用者とユースケースを`USERS.md`で確認する入口です。導入判断では採用者の一覧を性能保証と見なさず、自分のKubeVirt版、ストレージ、ロードバランサー、監視を組み合わせた小規模クラスターで試します。
Installation GuideとApache-2.0
READMEはQuick StartからInstallation Guideへ誘導し、コミュニティへの参加を案内しています。リポジトリのSPDXはApache-2.0です。ライセンスは再配布や改変の条件を確認する材料であり、ネットワーク分離や安全性を保証するものではありません。
向くのは、Kubernetesのネットワーク、OVN、物理スイッチを一緒に管理できるチームです。まず検証クラスターで一つのSubnetを作り、通信、削除、再作成、Node停止を確認します。その後VPC、VLAN、Underlayへ進み、設定、経路、メトリクス、復旧記録を残してから本番範囲を決めます。
通信経路を方式ごとに検証する
検証クラスターで一つのNamespace subnetを作り、同じNamespaceのPod間通信と別Namespaceへの通信を確認します。次にSubnet共有、VPCのテナント分離、EIP、NAT gateway、load balancerの到達性を許可・拒否の両方で測ります。`USERS.md`の採用例は参考にしますが、互換性は別に試します。
Overlayの後にVLANとUnderlayへ進み、MTU、物理NIC、スイッチ設定、外部経路、Node停止後の復旧を記録します。KubeVirtではVMとPodのIP、再起動、移動後の通信を分けて確認します。マニフェストと経路情報を保存し、削除と再適用で同じ状態へ戻せることを採用条件にします。
変更前の経路を保存する
Subnet、VPC、VLAN、UnderlayのマニフェストとNodeのNIC、MTU、ルートを変更前に保存します。PodとVMの通信を許可・拒否の両方で確認し、Node停止後にどの経路へ切り替わるかを記録します。削除と再適用で同じIP割り当て方針へ戻せること、外部ネットワークへ意図しない経路が開かないことを確認してから運用へ進めます。 導入前には、各方式のマニフェストと通信結果を保存し、変更を戻せることを確認します。 物理ネットワークの変更前後でMTUとルートを保存し、通信断の範囲を確認します。 さらに、Namespace間の拒否、VPCのNAT、VLANの外部到達、Underlayの障害復旧を別々に記録します。 NetworkPolicy、Service、DNS、外部ゲートウェイを方式ごとに分離し、復旧後のIPと名前解決も確認します。
編集部の結論
KubernetesでNamespaceごとのアドレス空間やテナント分離を設計し、物理ネットワークへの接続も検討するチームに向きます。READMEは機能の入口とInstallation Guideへのリンクを示しますが、環境別の互換性や性能基準は載せていません。まず隔離クラスターでPod間通信、Namespace共有、VPC、VLAN/Underlay、障害時の復旧を順に検証してください。
コミュニティノート