Copyright 2024 Red Hat K.K. 1

クラウドネイティブへの小さな一歩！ 既存VMからコンテナまで が実現する 『無理しないペースの移行』とは！？ 2024年11月29日 @ CloudNative Days Winter 2024 つかまん（@tsukaman） & うつぼ（@japan_rook） 2

Copyright 2024 Red Hat K.K. ● 所属
 ○ レッドハット株式会社 - テクニカルセールス本部 アカウントSA部（公共） 
 ● 経歴
 ○ 国内大手SIer - 教育事業部（営業、講師、新人研修PM）− 13年 
 ○ 外資大手IT系製造業 - WW Hybrid Cloud CoE（Solution Architect、Consultant）− 8年 
 ● 技術的経験
 ○ UNIX、Linux、OpenStack、Cloud Foundry、Ceph、Kubernetes、Ansible、vSphere 、AWS 等 
 ● 著書
 ○ Ansible実践ガイド（インプレス）、Raspberry Pi〔実用〕入門（技術評論社） 他 
 ● 好き
 ○ 音楽活動、合気道、眼鏡、漫画、ゲーム、ものづくり、ガジェット、コミュニティ活動 
 塚本 正隆 [email protected]
 3 自己紹介

4 ● Kubevirtとは？ ○ え？コンテナで仮想マシン？ ● なんで必要なの？ ○ コンテナだけでよくない？ 4 AGENDA

え？コンテナで仮想マシン？ 5 KubeVirtとは？

Copyright 2024 Red Hat K.K. 6 Kubernetesで 仮想マシンを動かし 管理する仕組みです

Copyright 2024 Red Hat K.K. 7 KubeVirtの歴史 • 2016年より開発をスタート • 2019年よりCNCFプロジェクトとなる − 現在はIncubationプロジェクト • 2024年11月現在、バージョンは1.14に到達 • Arm、Cloudflare、NVIDIAなどが採用 プロジェクトを開始 2016 2017 OSSとして公開 CNCFの Sandboxプロジェクトに 2019/6 2022/9 Incubationプロジェクトに Version1.0をリリース(GA) 2023/7

Copyright 2024 Red Hat K.K. 8 ベース技術はKVM（Kernel-based Virtual Machine） • Linuxカーネルに組み込まれた仮想化技術 • 2006年から開発され、長い歴史を持つ − 多くのLinuxディストリビューションで採用 − Linuxにおける仮想化ソリューションの基盤技術 • OpenStack • oVirt • その他、多くの製品/サービスで採用されている • Hypervisorとして成熟し、枯れている技術 − 本番環境でも長年採用される信頼の高い技術 − 仮想マシン管理に必要となる機能も一通り実装 • ライブマイグレーション • シンプロビジョニング • その他、Linux由来の技術を応用し発展

Copyright 2024 Red Hat K.K. 9 KVMの仕組み（ざっくり版） Linux User Land Hardware Linux Kernel Land KVM QEMU libvirt VM QEMU libvirt VM QEMU libvirt VM

Copyright 2024 Red Hat K.K. 10 KVMの仕組み（ざっくり版） Linux User Land Hardware Linux Kernel Land KVM QEMU libvirt VM QEMU libvirt VM QEMU libvirt VM 仮想マシンのモニター/管理機能を提供 プロセスとしては virtqemud として動く I/Oデバイスのエミュレーションを提供 プロセスとしては qemu-kvm として動く カーネルモジュールとして組み込まれた ハイパーバイザー機能

Copyright 2024 Red Hat K.K. 11 KVMの仕組み（ざっくり版） Linux User Land Hardware Linux Kernel Land KVM QEMU libvirt VM QEMU libvirt VM QEMU libvirt VM これらが協調して 仮想マシン達を 実行/管理します

Copyright 2024 Red Hat K.K. 12 KVMの仕組み（ざっくり版） Linux User Land Hardware Linux Kernel Land KVM QEMU libvirt VM QEMU libvirt VM QEMU libvirt VM これらが協調して 仮想マシン達を 実行/管理します じゃあ KubeVirtでは どうなるか？

Copyright 2024 Red Hat K.K. 13 KVMの仕組み（ざっくり版） Linux User Land Hardware Linux Kernel Land KVM QEMU libvirt VM QEMU libvirt VM QEMU libvirt VM Kubernetes Hardware Linux Kernel Land KVM QEMU libvirt VM Namespace QEMU libvirt VM QEMU libvirt VM Pod Pod Pod

Copyright 2024 Red Hat K.K. 14 KVMの仕組み（ざっくり版） Linux User Land Hardware Linux Kernel Land KVM QEMU libvirt VM QEMU libvirt VM QEMU libvirt VM Kubernetes Hardware Linux Kernel Land KVM QEMU libvirt VM Namespace QEMU libvirt VM QEMU libvirt VM Pod Pod Pod ほぼ 同じっすわ これ

Copyright 2024 Red Hat K.K. 15 もうちょっとちゃんとしたアーキテクチャ図 kubectl API server Virt API Virt controller Cluster components kubelet virt-handler Pod (DaemonSet) Worker node Virt handler ❶ Create VirtualMachine CR virt-launcher Pod ❸Create virt-launcher Pod virtqemud qemu-kvm KubeVirt component Other component KVM ❷ Schedule virt-launcher Pod ❹ Create VMI CR ❺ Notify VMI ❻ Order startup VM based on VMI spec ❼ Operate QEMU through libvirt and start VM

コンテナだけでよくない？ 16 なんで必要なの？

Copyright 2024 Red Hat K.K. 17 仮想マシンをすぐに捨てられますか？ • ペットのようにかわいがってきた仮想マシン − その背中には巨大なモノリシックなアプリが・・・ よーしパパ、モノリスアプリを バリバリモダナイゼーションして コンテナしてマイクロサービスするぞー そもそもコンテナ基盤ないし いきなりコンテナ化なんか すぐにはできっこないじゃん ほな仮想マシンのまま 動かしとくしかないかー ものりす 仮想マシンのペス

Copyright 2024 Red Hat K.K. 18 既存の仮想マシン/アプリ移行の問題点 • VM上で動く既存アプリをモダナイゼーションしたいが！ − コンテナ化してk8s上で動かすようなアプリへの再設計は難しい • 移行するにしても時間もコストも掛かってしまう − 業務影響を考えるといきなり切替は無理 − 移行するために人材の育成も必要になってしまう • 移行中は仮想マシン基盤とコンテナ基盤の両方が必要となる − それぞれの基盤ごとに運用コストが掛かってしまう − VMが残り続ける限りこのコストが掛かるが、いつ無くせるか分からない • ひょっとしたらずっと残るかも・・・？ • よくあるパターン − A) 既存アプリは無理に移行しないで新機能だけコンテナで開発 − B) 一旦VMで動かし続けて少しずつ剥がしてコンテナに移行 多くの場合、VM基盤は残さざるをえない状況となる

Copyright 2024 Red Hat K.K. 19 既存の仮想マシン/アプリ移行の問題点 • VM上で動く既存アプリをモダナイゼーションしたいが！ − コンテナ化してk8s上で動かすようなアプリへの再設計は難しい • 移行するにしても時間もコストも掛かってしまう − 業務影響を考えるといきなり切替は無理 − 移行するために人材の育成も必要になってしまう • 移行中は仮想マシン基盤とコンテナ基盤の両方が必要となる − それぞれの基盤ごとに運用コストが掛かってしまう − VMが残り続ける限りこのコストが掛かるが、いつ無くせるか分からない • ひょっとしたらずっと残るかも・・・？ • よくあるパターン − A) 既存アプリは無理に移行しないで新機能だけコンテナで開発 − B) 一旦VMで動かし続けて少しずつ剥がしてコンテナに移行 多くの場合、VM基盤は残さざるをえない状況となる 大丈夫！ それキュブバで できるよ！！

Copyright 2024 Red Hat K.K. 20 既存の仮想マシン/アプリ移行の問題点 • VM上で動く既存アプリをモダナイゼーションしたいが！ − コンテナ化してk8s上で動かすようなアプリへの再設計は難しい • 移行するにしても時間もコストも掛かってしまう − 業務影響を考えるといきなり切替は無理 − 移行するために人材の育成も必要になってしまう • 移行中は仮想マシン基盤とコンテナ基盤の両方が必要となる − それぞれの基盤ごとに運用コストが掛かってしまう − VMが残り続ける限りこのコストが掛かるが、いつ無くせるか分からない • ひょっとしたらずっと残るかも・・・？ • よくあるパターン − A) 既存アプリは無理に移行しないで新機能だけコンテナで開発 − B) 一旦VMで動かし続けて少しずつ剥がしてコンテナに移行 多くの場合、VM基盤は残さざるをえない状況となる キュブバ・・・ （語呂が悪い）

Copyright 2024 Red Hat K.K. 21 KubeVirtがもたらすメリット クラウドネイティブ技術を応用した VM運用のモダナイゼーション ● VMの管理もマニフェストを利用して宣言的に管理できる ● コンテナ運用と同じく VMでもGitOpsを実現可能❗ 仮想マシンとコンテナを統一基盤で運用できる ● 統一基盤なので運用方法も一本化し、シンプルに管理可能 ❗ ● 仮想マシンとコンテナがシームレスに連携できる コストを抑えた現実的な選択肢になりうる ● 基盤を二重で持たなくても良いのでコストも抑えられる ● 運用方法も一本化されるので、人材育成もシンプルに ❗

Copyright 2024 Red Hat K.K. 22 無理をしないペースでの移行を実現！ スピードにおける革新 売上への貢献 開発者のアウトプットの向上 緩慢な進化 増加するコスト 開発者の生産性の限界 従来の仮想化基盤 仮想マシン ワークロードとインフラの モダナイズ 仮想マシン and/or コンテナ Refactor クラウドの柔軟性 + 拡張性 コストの削減 IT 効率と信頼性の向上 インフラのモダナイズ初期 仮想マシン Re- platform Refactor まずはそのままVM移行。あとは徐々にコンテナへ！

Copyright 2024 Red Hat K.K. 23 無理をしないペースでの移行を実現！ スピードにおける革新 売上への貢献 開発者のアウトプットの向上 緩慢な進化 増加するコスト 開発者の生産性の限界 従来の仮想化基盤 仮想マシン ワークロードとインフラの モダナイズ 仮想マシン and/or コンテナ Refactor クラウドの柔軟性 + 拡張性 コストの削減 IT 効率と信頼性の向上 インフラのモダナイズ初期 仮想マシン Re- platform Refactor まずはそのままVM移行。あとは徐々にコンテナへ！ これが小さく始める クラウドネイティブ への第一歩！

24 KubeVirt 技術詳細 24

Copyright 2024 Red Hat K.K. kind: HumanBeings metadata: name: 宇都宮 卓也 spec: group: レッドハット株式会社 title: ソリューションアーキテクト born: 大阪 age: 43歳 favorites: technology: [“ストレージ”, “KubeVirt”] hobby: [“プロレス”, “麻雀”, “将棋”, “スピードキュービング ”, “けん玉”] drink: [“ワイン”, “ビール”, “無糖サワー”] annoyance: [“老眼開始”, “もうずっと疲れが取れない ”] 25 うつぼ @japan_rook https://www.shoeisha.co.jp/book/detail/ 9784798175027 $ whoami

Copyright 2024 Red Hat K.K. 26 インフラの三要素 コンピュート ネットワーク ストレージ

Copyright 2024 Red Hat K.K. 27 やっぱり気になるのはネットワークとストレージ コンピュート ネットワーク ストレージ KVM, QEMU ?? ??

28 ネットワークと ストレージ

Copyright 2024 Red Hat K.K. 29 ● K8s で標準的に使われる Overlay Network ● クラスタ外部から通信する際には Service で公開 ● 仮想マシンで IP アドレス固定はできない Pod Network（masquerade） ● Pod Network と独立してクラスタ内部のみで有効な L2 ネットワークや、クラスタ外部から引き込む L2 ネッ トワークを設定 ● Service を使わずクラスタ外部から直接通信可能 ● Multus 利用 Bridge Network Pod Network Secondary Network KubeVirt における仮想マシンのネットワーク

Copyright 2024 Red Hat K.K. 30 仮想マシンの Pod Network 接続 ● Pod のインタフェースとは別に、 VM 用のインタフェースを持 ち、各々で IP アドレスを持つ。 ○ VM インタフェースはゲスト OS 上でアドレス管理できる が意味はない。 ● VM のインタフェースは外部に出る際に IP マスカレードで Pod の IP アドレスに変換される。 ○ Pod の外から VM インタフェースのアドレスには直接 アクセスできない。 ● 外部から VM にアクセスするには Service リソースを使って 外部公開することが必要。 Node enp1s0 br-int veth br-ex eth0 VM Pod k6t-eth0 tap0 eth0 masquerade

Copyright 2024 Red Hat K.K. Node enp1s0 br-int veth br-ex br enp2s0 veth eth0 eth1 VM Pod br tap veth br tap eth0 31 Bridge Network インタフェースを持つ仮想マシン ● セカンダリネットワークを VM に接続する場合は、 Network Attachment Definition (NAD) を定義する。 ○ 仮想ネットワークスイッチのようなイメージ ○ VM 作成時に定義した NAD を指定した仮想 NIC を接続して 利用 ● Bridge のため VM のアドレスはそのままクラスタ内外に公開 される。 ○ ゲスト OS 側で IP アドレス管理が可能 Network Attachment Definition

Copyright 2024 Red Hat K.K. 32 KubeVirt におけるストレージ ● PersistentVolume を使用 ● 様々なストレージが利用できるが、CSI driver があるストレージ がよい ● VM の Live Migration には accessMode: RWX の PV が必須 ○ ブロックストレージでも RWX ができるものはある ● VirtIO または SCSI コントローラでディスクに接続 ○ VM 定義に依存 ● Boot OrderはVMの定義で変更可能

Copyright 2024 Red Hat K.K. 33 他の仮想化基盤との大きな違い ● 論理ボリューム（LUN, volume等）が PV としてそのまま仮想マシンに接続される。 →　仮想ディスクごとにストレージ側で論理ボリュームが作られる。 vm01.vmdk VM Folder(vm01) Datastore vSphere vm01_2.vmdk vm01 KubeVirt Backend Storage FC / iSCSI / NFS Backend Storage LUN vm01 LUN1 LUN2 FC / iSCSI / NFS PV1 PV2 Storage Class Virtual disk Virtual disk

34 ライブデモ

Copyright 2024 Red Hat K.K. 35 KubeVirtがもたらすメリット クラウドネイティブ技術を応用した VM運用のモダナイゼーション ● VMの管理もマニフェストを利用して宣言的に管理できる ● コンテナ運用と同じく VMでもGitOpsを実現可能❗ 仮想マシンとコンテナを統一基盤で運用できる ● 統一基盤なので運用方法も一本化し、シンプルに管理可能 ❗ ● 仮想マシンとコンテナがシームレスに連携できる コストを抑えた現実的な選択肢になりうる ● 基盤を二重で持たなくても良いのでコストも抑えられる ● 運用方法も一本化されるので、人材育成もシンプルに ❗ 再掲

Copyright 2024 Red Hat K.K. 36 KubeVirtがもたらすメリット 仮想マシンとコンテナを統一基盤で運用できる ● 統一基盤なので運用方法も一本化し、シンプルに管理可能 ❗ ● 仮想マシンとコンテナがシームレスに連携できる コストを抑えた現実的な選択肢になりうる ● 基盤を二重で持たなくても良いのでコストも抑えられる ● 運用方法も一本化されるので、人材育成もシンプルに ❗ クラウドネイティブ技術を応用した VM運用のモダナイゼーション ● VMの管理もマニフェストを利用して宣言的に管理できる ● コンテナ運用と同じく VMでもGitOpsを実現可能 ❗ 再掲 VM で GitOps だと？

Copyright 2024 Red Hat K.K. 37 Kubernetes における GitOps ● Git によるソースコード管理を前提にインフラとアプリを構成管理するプラクティス ● Deployment や Service 等の Kubernetes リソースのマニフェストを Single Source of Truth として Git リポジトリで管理 ● マニフェスト通りの状態になるよう、 Kubernetes クラスタで自動デプロイ ○ 最新コミットのマニフェストを自動でクラスタにデプロイ ○ 手動でリソースを変更しても Gitリポジトリの状態と一致しなければアラートを上げたり、リポジトリ側を正としてリソー スを自動修正 ○ 変更は全てGitで管理されるため、ロールバックが容易 全てを コードで扱う Git 上のコードが Single Source of Truth コードで定義された 状態にデプロイ

Copyright 2024 Red Hat K.K. OpenShift Argo CD（OpenShift GitOps） 1. Argo CD で GitHub リポジトリに接続し、demo-dev namespace に VM をデプロイ ○ Application CR を作成して自動的に実行 ○ default namespace にも base VM を作成 2. GitHub リポジトリに定義を追加し、base VM を元に demo-prod namespace に VM をデプロイ デモ環境 ● 6 ノード OpenShift クラスタ ● GitHub リポジトリ：https://github.com/tutsunom/gitops-virt-ocp 38 デモの概要 Red Hat Enterprise Linux CoreOS Kernel
 Red Hat Enterprise Linux CoreOS Kernel
 Control Plane Node Red Hat Enterprise Linux CoreOS Kernel
 Red Hat Enterprise Linux CoreOS Kernel
 Worker Node GitHub demo-dev demo-prod ② ① default

Copyright 2024 Red Hat K.K. 39 KubeVirtがもたらすメリット クラウドネイティブ技術を応用した VM運用のモダナイゼーション ● VMの管理もマニフェストを利用して宣言的に管理できる ● コンテナ運用と同じく VMでもGitOpsを実現可能❗ 仮想マシンとコンテナを統一基盤で運用できる ● 統一基盤なので運用方法も一本化し、シンプルに管理可能 ❗ ● 仮想マシンとコンテナがシームレスに連携できる コストを抑えた現実的な選択肢になりうる ● 基盤を二重で持たなくても良いのでコストも抑えられる ● 運用方法も一本化されるので、人材育成もシンプルに ❗

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. 40