2025/5/23 Red Hat K.K. Account Solution Architect Masataka Tsukamoto a.k.a. ＿・）つかまん （@tsukaman） 🔥熱々🔥のUDN🍜を喰らえ！ マルチテナントもVM統合も思いのまま！ 新機能で切り拓くk8sネットワークの未来 

自己紹介 塚本 正隆 [email protected] 2 ● 所属
 ○ レッドハット - ソリューションアーキテクト（技術営業本部 公共・コーポレート事業部）
 ● 経歴
 ○ 伊藤忠テクノソリューションズ - 教育事業部（営業、講師、新人研修PM）− 13年
 ○ Hewlett-Packard Enterprise - WW Hybrid Cloud CoE（Solution Architect、Consultant）− 8年
 ● 技術的経験
 ○ UNIX、Linux、OpenStack、Cloud Foundry、Ceph、Kubernetes、Ansible、vSphere 、AWS 等
 ● 著書
 ○ Ansible実践ガイド（インプレス）、Raspberry Pi〔実用〕入門（技術評論社） 他
 ● 好き
 ○ 音楽活動、合気道、眼鏡、漫画、ゲーム、ものづくり、ガジェット、コミュニティ活動
 

▸ CNI（Container Network Interface）のおさらい ･ CNIの役割 ･ いろいろなCNI ▸ OVN-Kubernetes CNI Plug-inの紹介 ･ OVN-Kubernetesの特徴 ･ OVN-Kubernetesのアーキテクチャ ▸ UserｰDefined Network（UDN）とは？ ･ OVN-Kubernetesの新機能「UDN」 ･ いままでの苦労をUDNで楽に！ ▸ デモ ･ テナント単位のカスタムネットワーク作成 ･ UDNへのワークロード接続 ▸ まとめ お品書き 3 

CNI ｰ Container Network Interfaceの おさらい 4 目次に戻る 

CNI（Cotainer Network Interface）とは？ https://www.cni.dev/ 5 ● CNCFがホストするIncubator Projectの1つ ● コンテナにネットワークインターフェイスを構成して管理 するための標準仕様（API）やライブラリなどを提供 ● CNI標準仕様に準拠したPlug-inが多数存在する ● ネットワーク毎にどのCNI Plug-inを使うか選択できる ● CNI Plug-inは、コンテナ実⾏時にネットワークインター フェイスを追加したり、IPアドレス割り当て（IPAM）、 オーバーレイネットワークの構成などを担当する ● 使⽤するCNI Plug-in実装によって、ネットワーク機能が拡 張される 

いろいろなCNI https://github.com/containernetworking/plugins https://github.com/containernetworking/cni#3rd-party-plugins 6 Multus 複 数 のCNIプラグイン （ネットワークインター フェイス）をコンテナに 接続する「メタCNIプラグ イン」として動 作。複 雑 なネットワーク要 件を実 現可能とする。 Cilium カーネル機 能のeBPFによ り、⾼ 速なパケット処 理 や 動 的 トラフィックフィ ルタリングなどを 実 現 す る。セキュリティ、 負 荷 分 散 、モニタリングなど ⾼度な管理機能を提供。 OVN-Kubernetes OVS/OVNをベース技 術と してKubernetesネット ワークを 管 理 する。 Geneveオーバーレイネッ トワークや、ACLベースの NetworkPolicy、 分 散 論 理ルータなどを提供。 Calico BGPを 採 ⽤ して、フラッ トなL3ネットワークを 構 成 することで、シンプル でスケーラブルなネット ワークを 実 現 する。 NetworkPolicyによるセ キュリティ機能も提供。 

いろいろなCNI https://github.com/containernetworking/plugins https://github.com/containernetworking/cni#3rd-party-plugins 7 Multus 複 数 のCNIプラグイン （ネットワークインター フェイス）をコンテナに 接続する「メタCNIプラグ イン」として動 作。複 雑 なネットワーク要 件を実 現可能とする。 Cilium カーネル機 能のeBPFによ り、⾼ 速なパケット処 理 や 動 的 トラフィックフィ ルタリングなどを 実 現 す る。セキュリティ、 負 荷 分 散 、モニタリングなど ⾼度な管理機能を提供。 OVN-Kubernetes OVS/OVNをベース技 術と してKubernetesネット ワークを 管 理 する。 Geneveオーバーレイネッ トワークや、ACLベースの NetworkPolicy、 分 散 論 理ルータなどを提供。 Calico BGPを 採 ⽤ して、フラッ トなL3ネットワークを 構 成 することで、シンプル でスケーラブルなネット ワークを 実 現 する。 NetworkPolicyによるセ キュリティ機能も提供。 

いろいろなCNI https://github.com/containernetworking/plugins https://github.com/containernetworking/cni#3rd-party-plugins 8 Multus 複 数 のCNIプラグイン （ネットワークインター フェイス）をコンテナに 接続する「メタCNIプラグ イン」として動 作。複 雑 なネットワーク要 件を実 現可能とする。 Cilium カーネル機 能のeBPFによ り、⾼ 速なパケット処 理 や 動 的 トラフィックフィ ルタリングなどを 実 現 す る。セキュリティ、 負 荷 分 散 、モニタリングなど ⾼度な管理機能を提供。 OVN-Kubernetes OVS/OVNをベース技 術と してKubernetesネット ワークを 管 理 する。 Geneveオーバーレイネッ トワークや、ACLベースの NetworkPolicy、 分 散 論 理ルータなどを提供。 Calico BGPを 採 ⽤ して、フラッ トなL3ネットワークを 構 成 することで、シンプル でスケーラブルなネット ワークを 実 現 する。 NetworkPolicyによるセ キュリティ機能も提供。 今日の主役はこの 
 OVN-Kubernetes CNI 
 です
 

OVN-Kubernetes CNI Plug-inの紹介 9 目次に戻る 

OVN-Kubernetesの特徴 https://ovn-kubernetes.io/ 10 ● OVSとOVNをベースに、堅牢なKubernetesネットワーク を構成することを⽬標に開発されているCNI Plug-in ● Kubernetes標準ネットワーク機能では対応できないユー スケースのために、CRDによる機能拡張を提供 ● Helm Chartを利⽤してインストール可能 ● OVS (Open vSwitch) ○ Apache 2.0ライセンスのもと開発される、オープン ソースな仮想ソフトウェアスイッチ ○ LACP、802.1Qといった標準的なネットワークプロト コルや、OpenFlowによるFlow制御などサポート ○ OpenStackなど、様々な仮想プラットフォームで採⽤ 

OVN-Kubernetesの特徴 （続き） https://ovn-kubernetes.io/ 11 ● OVN (Open Virtual Network) ○ OVSのサブプロジェクトとして2015年から開始 ○ OVSでのFlow制御における課題解決などを⽬的とする ○ OVSの機能を補完し、論理ネットワークを抽象化 ○ Logical Flowによる設定をDBに保持する ○ 論理スイッチ/ルーター、NAT、ACL、LB、DHCPと いったネットワーク機能をネイティブ実装し、SDNソ リューションを実現 ○ Geneveによるオーバーレイネットワークを実現 

参考：OVN-Kubernetesのアーキテクチャ https://ovn-kubernetes.io/design/architecture/ 12 ● デプロイモデルの違いで2種類のアーキテクチャがある ○ defaultモード（中央制御プレーンモデル） ○ interconnect モード（分散制御プレーンモデル） ■ 右図はinterconnectモード ■ 各DBがデータプレーンに分散配置されるのが特徴 ■ 参照: OVN-Kubernetes with OVN Interconnectのご紹介 ● https://rheb.hatenablog.com/entry/ovnk-ic ● nbdb: Northbound DB ○ 論理ネットワークのDesired Stateを格納するDB ● sbdb: Southbound DB ○ 現在の状態（Runtime State）を格納するDB 

参考：OVN-Kubernetesのアーキテクチャ https://ovn-kubernetes.io/design/architecture/ 13 ● デプロイモデルの違いで2種類のアーキテクチャがある ○ defaultモード（中央制御プレーンモデル） ○ interconnect モード（分散制御プレーンモデル） ■ 右図はinterconnectモード ■ 各DBがデータプレーンに分散配置されるのが特徴 ■ 参照: OVN-Kubernetes with OVN Interconnectのご紹介 ● https://rheb.hatenablog.com/entry/ovnk-ic ● nbdb: Northbound DB ○ 論理ネットワークのDesired Stateを格納するDB ● sbdb: Southbound DB ○ 現在の状態（Runtime State）を格納するDB そんな
 OVN-Kubernetesに 
 新しい機能が追加 
 されました 
 

参考：OVN-Kubernetesのアーキテクチャ https://ovn-kubernetes.io/design/architecture/ 14 ● デプロイモデルの違いで2種類のアーキテクチャがある ○ defaultモード（中央制御プレーンモデル） ○ interconnect モード（分散制御プレーンモデル） ■ 右図はinterconnectモード ■ 各DBがデータプレーンに分散配置されるのが特徴 ■ 参照: OVN-Kubernetes with OVN Interconnectのご紹介 ● https://rheb.hatenablog.com/entry/ovnk-ic ● nbdb: Northbound DB ○ 論理ネットワークのDesired Stateを格納するDB ● sbdb: Southbound DB ○ 現在の状態（Runtime State）を格納するDB それが
 

参考：OVN-Kubernetesのアーキテクチャ https://ovn-kubernetes.io/design/architecture/ 15 ● デプロイモデルの違いで2種類のアーキテクチャがある ○ defaultモード（中央制御プレーンモデル） ○ interconnect モード（分散制御プレーンモデル） ■ 右図はinterconnectモード ■ 各DBがデータプレーンに分散配置されるのが特徴 ■ 参照: OVN-Kubernetes with OVN Interconnectのご紹介 ● https://rheb.hatenablog.com/entry/ovnk-ic ● nbdb: Northbound DB ○ 論理ネットワークのDesired Stateを格納するDB ● sbdb: Southbound DB ○ 現在の状態（Runtime State）を格納するDB 

UserｰDefined Network （UDN）とは？ 16 目次に戻る 

OVN-Kubernetesの新機能「UDN」 https://www.redhat.com/ja/blog/enhancing-kubernetes-pod-network-user-defined-networks 17 ● ユーザーによるカスタムネットワーク作成が可能 ○ クラスター管理者: ■ 1つ以上のNamespaceにまたがるUDNを作成可能 ○ Namespace（テナント）管理者: ■ NamespaceレベルでUDNネットワークを作成可能 ● 現時点ではL2とL3のトポロジを利⽤可能 ● 通信はUDN毎に分離されるためシンプル&セキュア ○ 異なるUDNで同じCIDRを利⽤しても構わない ■ 論理的に分離されているのでIPアドレスは重複しない ● Pod ネットワーク（クラスターネットワーク）に接続 しない場合の制限に注意 ○ DNSやヘルスチェック、NetworkPolicyなど node-1 udn-network-3 udn-network-2 pod-1 172.16.0.2 pod-2 172.16.0.3 pod-1 10.10.0.2 pod-2 (VM) 10.10.0.3 node-2 udn-network-3 udn-network-2 pod-1 172.16.1.3 pod-2 172.16.1.4 pod-3 10.10.0.4 pod-4 (VM) 10.10.0.5 ovn_layer2_switch (10.10.0.0/16) 172.16.0.0/24 172.16.1.0/24 udn-network-1 pod-1 172.16.0.2 pod-2 172.16.0.3 udn-network-1 pod-1 172.16.1.3 pod-2 172.16.1.4 172.16.0.0/24 172.16.1.0/24 L3 topology L3 topology 

いままでの苦労をUDNで楽に！ https://docs.redhat.com/ja/documentation/openshift_container_platform/4.18/html/networking/ primary-networks#nw-udn-benefits_about-user-defined-networks 18 単⼀のL3Podネットワークという考え⽅に慣れない‧‧‧🔥 ○ いままで：CIDRも選べないし、通信制御はNetworkPolicyで設定‧‧‧ ○ これから：テナントに閉じたネットワークを⾃由かつシンプルに使える❗ VMをライブマイグレーションしたらIPアドレス変わっちゃう🔥 ○ いままで：Multusつかってセカンダリネットワークで静的設定を‧‧‧ ○ これから：L2UDNを使ってプライマリネットワークで実現可能❗❗ 外部ネットワークとの間でBGP経路公告したいなぁぁぁぁあああ🔥 ○ いままで：MultusつかってCalicoと組み合わせて複雑な感じに。。。 ○ これから：BGP対応したUDNだけで対応できちゃう❗❗❗ ■ OVN-KubernetesでのBGP対応は鋭意開発中💪🔥なのでもう少し待ってね〜🎶 

Demo 19 目次に戻る 

デモ1： UDNを利用するNamespaceの作成 Namespace（Project）作成時にUDN利⽤の為のlabelを付与する 20 apiVersion: project.openshift.io/v1 kind: Project metadata: name: tanuki-udn labels: k8s.ovn.org/primary-user-defined-network: "" apiVersion: project.openshift.io/v1 kind: Project metadata: name: kitsune-udn labels: k8s.ovn.org/primary-user-defined-network: "" 

デモ2： 2つのUDNを作成 WebUIからCIDRが重複する2つのUDNを作成（NADも併せて⾃動⽣成される） 21 

デモ3： 各UDNに接続する4台のVMを作成 作成した各UDNに接続するVMを2台ずつ、合計4台作成する 22 apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: labels: kubevirt.io/vm: tanuki-vm-01 name: tanuki-vm-01 namespace: tanuki-udn spec: dataVolumeTemplates: - apiVersion: cdi.kubevirt.io/v1beta1 kind: DataVolume metadata: creationTimestamp: null name: tanuki-vm-01 spec: sourceRef: kind: DataSource name: fedora namespace: openshift-virtualization-os-images storage: resources: requests: storage: 30Gi runStrategy: Always template: metadata: name: tanuki-vm-01 namespace: tanuki-udn spec: domain: devices: disks: - disk: bus: virtio name: rootdisk - disk: bus: virtio name: cloudinitdisk interfaces: - name: primary-udn binding: name: l2bridge rng: {} resources: requests: memory: 2048M networks: - pod: {} name: primary-udn terminationGracePeriodSeconds: 0 volumes: - dataVolume: name: tanuki-vm-01 name: rootdisk - cloudInitNoCloud: userData: |- #cloud-config user: fedora password: fedora chpasswd: { expire: False } name: cloudinitdisk 

デモ4： 各VMのIPアドレスを確認 Namespace/UDNが異なるVMではIPアドレスが重複しても問題ないことを確認 23 

デモ5： ライブマイグレーション前後でのIPアドレス保持を確認 稼働しているワーカーノードが変わっても、割り当てられたIPアドレスはそのまま変化しないことを確認 24 

まとめ 25 目次に戻る 

まとめ さて、この資料の中には何種類くらいUDNのイラストがあったでしょうか‧‧‧ 26 ▸ OVN-KubernetesはOVS/OVNをベースとしたCNI Plug-in ･ okdやOpenShiftのデフォルトCNIとして採⽤されている ▸ 新機能としてUser-Defined Network (UDN🍜)が実装 ･ OpenShift 4.17でTech-preview、OpenShift 4.18でGAとなった ▸ UDNによりKubernetesネットワーク構成の⾃由度が⼤幅に向上 ･ マルチテナント環境やKubeVirt（仮想マシン）利⽤時に効果を発揮 ･ シンプルなのに柔軟なネットワーク管理を実現 ▸ UDN🍜はまだまだこれからも進化🔥❗ ･ より柔軟で⾃由度の⾼いネットワークへ❗❗ ･ 機能に加えて使い勝⼿も乞うご期待❗❗ 

参考文献 美味しくUDN🍜を⾷べるために‧‧‧ 27 ▸ OpenShift 4.18 新機能：User Defined Network (UDN) を試してみた ･ ⾚帽エンジニアブログ (Mamoru Shimizu) ･ https://rheb.hatenablog.com/entry/2025/03/03/154723 ▸ OVN-Kubernetes Deep Dive ･ OpenShift.Run 2023 (Manabu Ori) ･ https://speakerdeck.com/orimanabu/ovn-kubernetes-introduction-ja-2023-01-27 ▸ KubeVirt Networking ･ ONIC Japan 2024 BOF (Manabu Ori) ･ https://speakerdeck.com/orimanabu/kubevirt-networking-onic-2024 ▸ User defined networks in Red Hat OpenShift Virtualization ･ Red Hat Blog (Matthew Secaur) ･ https://www.redhat.com/en/blog/user-defined-networks-red-hat-openshift-virtua lization 

linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHat Thank you Red Hat is the world’s leading provider of enterprise open source software solutions. Award-winning support, training, and consulting services make Red Hat a trusted adviser to the Fortune 500. 28 

linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHat Thank you Red Hat is the world’s leading provider of enterprise open source software solutions. Award-winning support, training, and consulting services make Red Hat a trusted adviser to the Fortune 500. 29 ちなみに
 うどんのイラスト 
 1つだけ沖縄そば 
 です