kubernetes-meetup-tokyo-20210624-kubevirt

3. ©2021 Yahoo Japan Corporation All rights reserved. ⾃⼰紹介 3 相良幸範 2019 – 現在ヤフー。Kubernetes基盤の設計や運⽤、OS性能解析を担当 2008 – 2019 NTTデータ。クラウド基盤・運⽤分野の研究開発、システム設計、運⽤に携わる OpenStack経験は最初期〜 Queensくらいまで通信キャリア向けの⼤規模⾼信頼なOpenStack基盤を設計

6. ©2021 Yahoo Japan Corporation All rights reserved. コンテナ移⾏が困難なレガシーシステムの運⽤ • 利⽤しているミドルがコンテナネイティブでない • カーネルパラメータの調整が必要 • H/Wを直接操作したい • VMイメージで提供されるアプライアンスの利⽤ • (ビジネス上の理由) 移⾏にかかるリソースの捻出が難しい CaaS、PaaSなどの下層でベアメタルを直接使わないケース • Kubernetesスケーラビリティの観点からVM層を挟んだ⽅がリソースを有効活⽤できる IaaSが必要な背景 1. IaaSとKubeVirt 6 数は減っていくがIaaSが必要な場⾯も残り続ける。発展著しいKubernetesを利⽤してVM管理したい

7. ©2021 Yahoo Japan Corporation All rights reserved. • Reconciliation loopでリソース管理するアーキテクチャ etcd の情報が常に真でその状態に収束するよう動作する、という仕組みセルフヒーリングも実現できている。シンプルでトラブル起こりづらい • 拡張性 CRD+カスタムコントローラ Admissionコントローラ(Mutating/Validating webhook)でAPIリクエストの細かい制御が可能 • Kubernetesコミュニティのエコシステムの恩恵を受けれる OpenStackは成熟しているが開発者がだいぶ少なくなっている (最新リリースのレビュー割合: 5割近く Red Hat。イベント参加者ピーク時 7000〜8000 -> 1500〜2000。KubeCon 12000) https://www.stackalytics.com/?release=wallaby OpenStackエンジニアから⾒たKubernetesの利点 1. IaaSとKubeVirt 7

8. ©2021 Yahoo Japan Corporation All rights reserved. 1. IaaSとKubeVirt 8 Kubernetes コンテナでのアプリケーションサービスを効率的に提供するための抽象化〜トップダウン (Ingress、Service、Deployment、ReplicaSet、Pod、・・) コア機能を⼩さく保っている OpenStack データセンターのインフラリソースを抽象化してインターフェースを提供モノへの対応関係が強い〜ボトムアップ (サーバー -> VM、L2 -> 仮想スイッチ、L3 -> 仮想ルーター、・・) ドライバのリファレンス実装だけでも運⽤可能(ノウハウが集まりやすい) マルチテナントも初期から考慮 KubernetesコントロールプレーンでIaaSを実現する際、上記の違いが、つらいポイントになりそう KubernetesとOpenStackの得意領域の違いデータセンターインフラ (サーバー・NW・ストレージ) OS OS CNI CSI CRI VM・NW・ストレージのドライバリファレンス実装

9. ©2021 Yahoo Japan Corporation All rights reserved. 1. IaaSとKubeVirt 9 Kubernetes上で動くクラスタアドオン CRDとカスタムコントローラーで構成。Podと同じWorkerノードでVMを起動 (仕組みは後述) KubeVirt 図の引⽤元: https://github.com/kubevirt/kubevirt/blob/master/docs/architecture-simple.png CNCF Sandbox projects / Apache 2.0 2016 Red Hatが開発開始 2017 OSS化 2021/6 現在の最新バージョン: v0.42.0 ひと⽉に⼀度のペースでリリース最新のlibvirt、QEMUに対応 (libvirt 7.0.0, QEMU 5.2.0) CPU PinningやNUMA、SR-IOVも対応 GPU/vGPUの利⽤も可能

10. ©2021 Yahoo Japan Corporation All rights reserved. 利⽤状況 • Red Hat OpenShift の⼀機能として製品提供されている OpenShift Container Platform 4.5 / OpenShift Virtualization version 2.4でGA提供(2020/8) • Rancher 社のKubernetesベースの HCI 製品(Rancher Harvester。OSS)の部品 • oVirt という製品からの移⾏ディストリビューション同梱の KVM と OpenStack の間くらいの管理製品。ESX のような細かい制御が可能 -> KubeVirt ⾃体も細かな機能への対応が期待できる • VNF・CNF 基盤としての期待通信キャリアが⾼価なNW専⽤機器を汎⽤サーバーを利⽤してコストダウンする取り組み従来 VM で実現 (VNF) していたものをコンテナベースで実現する取り組みが検討されている -> 企業の継続的なリソース投下を期待できる利⽤事例 • Akamai, Apple, Cisco, Cloudflare, Goldman Sachs, Kubermatic KubeVirt 利⽤状況 1. IaaSとKubeVirt 10 ⼤きな企業で使われているが、表に出ている利⽤事例はまだ数えるほど

12. ©2021 Yahoo Japan Corporation All rights reserved. IaaS基盤の構成要素と、KubeVirtでの実現⽅法全体的に Kubernetes コントロールプレーンの仕組みを上⼿く活⽤するような設計となっている (⽔⾊箇所は次ページでも説明) IaaS基盤の構成要素 2. KubeVirtの仕組み 12 KubeVirt での実現⽅法備考コンピュート KubeVirt 独⾃コンポーネント • スケジューリングは Kubernetes 機能をそのまま利⽤ • VM 起動の仕組みは次ページで説明イメージ CDI or コンテナレジストリ • CDI (Container Data Importer) では HTTP・S3 経由でイメージをダウンロードし、PV に流し込む • コンテナレジストリも利⽤可能だが無駄が多い NW CNI・リソース (Service、NetworkPolicy) • CNI とインテグレーション • バックエンド・フロントエンドという独⾃概念あり • DHCP での IP アドレス設定ストレージ CSI・リソース (PVC、PV) • CSI とインテグレーション VM初期化 ConfigDrive & cloud-init • ログインユーザーの作成。ssh 鍵設定 • cloud-configのデータが書かれたボリュームを接続することで、cloud-init に情報を渡す

13. ©2021 Yahoo Japan Corporation All rights reserved. KubeVirt: VM起動の仕組み 13 kubectl (user commands) Control Plane API Server virt-controller virt-api KubeVirt Kubernetes Worker Node kubelet docker / cri-o (runtime) Pod (DaemonSet) Pod (per VMI) VM virt-handler virt-launcher libvirtd qemu /dev/kvm • VirtualMachineInstance (VMI) リソースを作成すると VM が作成される • VirtualMachineInstance (VMI) の単位に virt-launcher コンテナが起動し、Kubernetes コントロールプレーンと libvirtd を仲介する KubeVirt をインストールすると下記コンポーネントが導⼊される • virt-api • virt-controller • virt-handler

14. ©2021 Yahoo Japan Corporation All rights reserved. VirtualMachineInstance のマニフェスト例 2. KubeVirtの仕組み 14 apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachineInstance metadata: name: testvmi-nocloud spec: domain: resources: requests: memory: 1024M devices: disks: - name: containerdisk disk: bus: virtio - name: cloudinitdisk disk: bus: virtio volumes: - name: containerdisk containerDisk: image: kubevirt/fedora-cloud-container-disk-demo:latest - name: cloudinitdisk cloudInitNoCloud: userData: |- #cloud-config password: fedora chpasswd: { expire: False } <- メモリ指定(任意) <- ディスクボリュームのアタッチ * 2 <- ディスクボリュームの定義 (起動ディスク) Podと⽐べて複雑 <- ディスクボリュームの定義 (ログインユーザー作成のための cloud-init ボリューム)

16. ©2021 Yahoo Japan Corporation All rights reserved. システム設計のポイント • マルチテナントと Kubernetes クラスタの単位 • CNI プラグイン選定システム設計の検討項⽬・その他 (-> 時間あれば説明) • KubeVirt クラスタのスケーラビリティ • 利⽤者向けにケアが必要なポイント・基盤管理者視点でのコメントシステム設計の検討項⽬・ポイント 3. システム設計の検討項⽬・ポイント 16

18. ©2021 Yahoo Japan Corporation All rights reserved. Kubernetes 基盤を設計する際、テナンシーの確保⽅法が様々な設計箇所に影響してくる下記の2つの⽅式が存在 (次ページ以降でそれぞれ説明) • a. テナント単位に Kubernetes クラスタを払い出し • b. テナント単位に Namespace を払い出しヤフーの既存 IaaS 基盤は OpenStack クラスタが⼤量にあり、コントロールプレーンの運⽤負荷が⾼い (既存の IaaS 環境は 200 クラスタ以上の OpenStack を運⽤) コントロールプレーンを減らして運⽤負荷を削減したいマルチテナントと Kubernetes クラスタの単位 3. システム設計の検討項⽬・ポイント 18 b.「テナント単位に Namespace 払い出し」で問題なく運⽤できるか

19. ©2021 Yahoo Japan Corporation All rights reserved. テナントへの払い出し単位の差によるメリット・デメリット 3. システム設計の検討項⽬・ポイント 19 テナントへの払い出し単位 a. テナント単位に Kubernetes クラスタを払い出し b. テナント単位に Namespace を払い出しメリット • Kubernetesでテナンシーの考慮が不要 • 障害時の影響範囲を最⼩化できる • 複数テナントを1クラスタに集約可能なため、コントロールプレーンの数を減らすことができ、運⽤負荷を⼤幅に削減可 • サーバーの利⽤効率が⾼いデメリット (懸念点) • コントロールプレーンの運⽤負荷が⾼い(メンテナンス作業) • サーバーの利⽤効率が低い -> コントロールプレーンだけVMにして集約するなどの対策は可能 • Kubernetesコントロールプレーンのテナント間のリソース隔離を検討する必要あり -> SIGでまとめている確認項⽬・チェックツールが利⽤できる Multi-Tenancy Benchmarks: https://github.com/kubernetes-sigs/multi-tenancy/tree/master/benchmarks • コントロールプレーンへのAPI負荷集中 (etcd の events が膨らみやすい) -> 下記対策を実施可 eventsレートリミット設定 (EventRateLimit) events保存先の分離(--etcd-servers-overrides=/events#http://xxx) • VMの性能⾯の隔離 -> 性能を気にする利⽤者には PodNodeSelector 機能でテナント専有の Workerノードを割り当て可能 b. 「テナント単位に Namespace を払い出し」案で運⽤できそう(懸念点については対策可)

20. ©2021 Yahoo Japan Corporation All rights reserved. システム設計のポイント • マルチテナントと Kubernetes クラスタの単位 • CNI プラグイン選定システム設計の検討項⽬・その他 • KubeVirt クラスタのスケーラビリティ (-> 参考資料に記載) • 利⽤者向けにケアが必要なポイント・基盤管理者視点でのコメント (-> 参考資料に記載) システム設計の検討項⽬・ポイント 3. システム設計の検討項⽬・ポイント 20

21. ©2021 Yahoo Japan Corporation All rights reserved. Kubernetes NWは、CNIとServiceリソースなどで構成される CNIによって利⽤可能なアクセラレーションが異なったり、独⾃拡張機能の有無があったりするまたCNI同⼠の組み合わせ(チェイニング)が可能だったり、Service type LoadBalancer で MetalLB 使う際の組み合わせなどでも⼀部影響がある CNI プラグイン選定 3. システム設計の検討項⽬・ポイント 21 観点 Flannel Calico Cilium Antrea Pod 接続⽅式 LinuxBridge TAP + ルーティング eBPF OVS アクセラレーション Service (ClusterIP) なし eBPF (tc) eBPF (XDP) OVS (ovs-tc) Service (NodePort) なし eBPF (tc) eBPF (XDP) なし NetworkPolicy なし eBPF (tc) eBPF (XDP) OVS (ovs-tc) その他機能 BGPでPod IPアドレスを経路広告なし対応ベータ対応なし IP予約/割り当て IPPool/FloatingIP

22. ©2021 Yahoo Japan Corporation All rights reserved. 様々なサービスが動作することを想定して設計が必要。IaaS環境向けに下記の要件を重視 • 要件1: クラスタ外からVMに到達するためのIPの確保/固定・L4でのサービス公開外部システムやNW機能との連携で、IPの固定が必要になる IaaS上で稼働するサービスはHTTP以外でサービス提供するものも多数 • 要件2: ⼤規模トラフィック対応 (100Gbpsレベルのトラフィック) NWのスループット向上 NW処理のオフロードによるサーバーCPUの利⽤率向上 CNI プラグイン選定: ヤフー環境で重視した要件 3. システム設計の検討項⽬・ポイント 22 CNI プラグインは Flannel, Calico, Cilium, (VMware Tanzuで利⽤されている) Antrea を検討

23. ©2021 Yahoo Japan Corporation All rights reserved. 案1: BGPでVMのIPアドレスを経路広告 (+ IP 予約/割り当て機能) • BGP に対応した CNI プラグインに限られる • 複数テナントで同じKubernetesクラスタを共有する場合、外部システムとの連携⽤に申請しているIPをテナント内で予約したい (VMの⽣成/消滅のライフサイクルとは別で管理したい) テナント単位の IP 予約/割り当て機能があるかは CNI 次第案2: LBのIP経由 (外部LB + NodePort、DSRでないLB) • NodePort はポート数制限が厳しい (--service-node-port-range=30000-32768) テナント単位に Namespace で払い出すため、多テナントの環境でつらいまた値の範囲は変更可能なものの、他への影響を計りきれない案3: LBのIP経由 (Service type LoadBalancer (SLB) 、DSRでないLB) • 社内の既存 LB とのインテグレーション、または MetalLB など考えられる SLB の運⽤も必要になる CNI プラグイン選定: 要件1. クラスタ外からVMに到達するためのIPの確保/固定・L4でのサービス公開 3. システム設計の検討項⽬・ポイント 23 案1の BGP を利⽤する⽅式で検討 Calico or Cilium ︖

24. ©2021 Yahoo Japan Corporation All rights reserved. 下記を実現するため SmartNIC を活⽤したい • NWのスループット向上 • NW処理のオフロードによるサーバーCPUの利⽤率向上 OpenStack では Open vSwitch (OVS) が⼀般的なため「SmartNIC (OVS)」のノウハウがチームにある SmartNIC (OVS) を活⽤したいが、、 • 対応する CNI プラグインが限られる (今回⾒た中では Antrea のみ) • (検討後に kube-ovn というプラグインも⾒つけたが実績不明) CNI プラグイン選定: 要件2. ⼤規模トラフィック対応 3. システム設計の検討項⽬・ポイント 24 Antrea はBGPに対応していないため、(クラスタ外からVMに到達するための) IPの固定が難しい SmartNIC (OVS) の活⽤は断念 SmartNIC (OVS) • OVS の内部処理をオフロードできるH/W機能を持つ • OVS を利⽤する CNI プラグインであれば、透過的に利⽤できる • LinuxカーネルのTraffic Control の層からハードウェアにオフロードできる (ovs-tc)

25. ©2021 Yahoo Japan Corporation All rights reserved. 要件1・要件2の両⽅を満たせるCNIプラグインは (今回の検討候補には) ない • 「要件1: クラスタ外からVMに到達するためのIPの確保/固定・L4でのサービス公開」は実現可能 😊 • 「要件2: ⼤規模トラフィック対応」は断念 😥 CNI プラグイン選定: 検討結果 3. システム設計の検討項⽬・ポイント 25 BGP対応・実績・IP予約機能を総合的に考え Calico を選択 IaaS 基盤向けにすべての要件を実現する CNI プラグインは今回⾒つけられず最初の表に書いたように検討観点も様々。通常のコンテナ基盤でもCNI選定は難しい IaaS基盤だと重視するポイントも異なり、なおさら難しい

26. ©2021 Yahoo Japan Corporation All rights reserved. • BGPで(Pod/VMでなく)ServiceのIPアドレスを経路広告。ServiceリソースでIP予約 • Serviceリソースの ClusterIP でIP予約可能であれば、Calico 独⾃拡張のIP Pool/Floating IP機能までは不要で、CNI選定の幅も広がる︖ • SmartNIC (eBPF) (eBPF オフロード対応の SmartNIC) • Calico の最近のバージョンで eBPF による⾼速化に対応 (Calico 3.16 (2020/8) で GA) • eBPF オフロード機能を提供する SmartNIC と組み合わせると⼤規模トラフィック対応可能︖ • Introducing the Calico eBPF dataplane – Project Calico https://www.projectcalico.org/introducing-the-calico-ebpf-dataplane/ • About eBPF – Project Calico https://docs.projectcalico.org/about/about-ebpf • Service type LoadBalancer • 社内の既存 LB とのインテグレーション、または MetalLB の利⽤ CNI プラグイン選定: 今回検討・評価できていない部分 3. システム設計の検討項⽬・ポイント 26 • 今回の検討は時間制約が厳しく検討できなかった箇所が多い • これら考慮するとCNI選定はまた違う答えになるかも

28. ©2021 Yahoo Japan Corporation All rights reserved. 既存のIaaS (OpenStack) 環境 • 200以上のクラスタを運⽤ • コントロールプレーンの運⽤負荷⾼い新規にIaaS基盤を検討する際、既存のIaaS環境の問題点を解決できる基盤にしたい KubeVirt クラスタのスケーラビリティ 3. システム設計の検討項⽬・ポイント 28 KubernetesコントロールプレーンのKubeVirt クラスタをOpenStackと⽐べた際にスケーラビリティの観点で問題がないかコントロールプレーンの数を減らしたいため、1つのKubeVirtクラスタで扱えるノード数が⼗分か確認

29. ©2021 Yahoo Japan Corporation All rights reserved. KubeCon US 2018の「Kubernetes Scalability: A Multi-Dimensional Analysis」のデータを参考に試算 https://kccna18.sched.com/event/GrXy/kubernetes-scalability-a-multi-dimensional-analysis-maciek-rozacki-google-shyam-jeedigunta クラスタあたりの限界ノード数の⾒積もり 3. システム設計の検討項⽬・ポイント 29 元データは、Podあたりのコンテナ数2以下の条件で 1つの Kubernetes クラスタあたり • ノードあたりのPod 数が 110 の場合、1300 ノードが限界 -> kubeletがオーバーロード • ノードあたりのPod 数が 30 の場合、5000 ノードが限界 -> apiserverがオーバーロード KubeVirt に当てはめて検討 1 VM あたり virt-launcher コンテナが 1 つ起動 (1 VM ≒ 1 コンテナ) -> 1つの Kubernetes クラスタあたり 1ノードに 110 VM 起動しても 2600 ノード程度は管理可能 CPUオーバーコミット率 5 倍で考慮すると、520 ノード程度は管理可能通常のOpenStackは1クラスタあたり 200 〜 400 ノード(HV)程度管理可能と考えられている OpenStack と同等以上のノード数に対応可能。スケーラビリティ観点では問題ない

31. ©2021 Yahoo Japan Corporation All rights reserved. 利⽤者向けにケアが必要なポイント • VM 作成時の KubeVirt のマニフェスト記載が⼤変 • OpenStack とは操作感が異なり VM 作成時の敷居が⾼い • OpenStack ユーザーは VM 作成時にマニフェストを記載する⽅法に慣れていない Heat というオーケストレーション機能あるものの、コマンドラインの逐次操作 or GUI での利⽤がほとんど • Pod の最⼩のテンプレートはシンプル、KubeVirt の最⼩の VM テンプレートは複雑 (前述のテンプレート) • UX 観点でユーザー提供に⼯夫が必要 • 代表的な構成のテンプレート群を⽤意する • kubectl run --image xxx のようなジェネレーターCLIを⽤意する • パブリッククラウドのようなWeb UIを⽤意する基盤管理者視点でのコメント • IaaS と CaaS、いずれか⼀⽅でも複雑なのに両⽅扱うのは範囲が広すぎる対応可能なメンバーが限られるのでは利⽤者向けにケアが必要なポイント・基盤管理者視点でのコメント 3. システム設計の検討項⽬・ポイント 31

32. ©2021 Yahoo Japan Corporation All rights reserved. KubeVirt • Kubernetesの仕組みを上⼿く利⽤できるように作られている (CRD、カスタムコントローラ、スケジューラ、認証・認可、CNI、CSI、..) システム設計のポイント • マルチテナントをどう実現するかがポイント。Namespace 単位でもテナント隔離のために様々な機能を利⽤できる • IaaS ⽤途では、クラスタ外からVMに到達するためのIPの確保⽅法がポイントとなる • SmartNIC など H/W オフロードを活⽤したい場合は、eBPF のオフロードを検討した⽅が良い • CNI 選定は複雑で検討期間も⻑く必要 KubeVirtでのIaaS管理に関する全体的な印象 • Kubernetesコントロールプレーン + KubeVirtで、IaaS基盤を提供可能 • ただし、OpenStackのようにきめ細かな機能はない。要件次第な部分もある汎⽤的なIaaS基盤としてOpenStackからマイグレーションするには、まだ機能・実績の少なさに不安を覚える • v1.0 がリリースされ様々実績が出てくれば、より安⼼して使える技術になりそうまとめ 32

34. ©2021 Yahoo Japan Corporation All rights reserved. 利⽤状況 • Red Hat OpenShift の⼀機能として製品提供されている OpenShift Container Platform 4.5 / OpenShift Virtualization version 2.4でGA提供(2020/8) https://www.openshift.com/blog/openshift-virtualization-2.4-is-now-generally-available • Rancher 社のKubernetesベースの HCI 製品(Rancher Harvester。OSS)の部品 https://github.com/harvester/harvester • oVirt という製品からの移⾏ https://www.ovirt.org/develop/release-management/features/virt/vm-lifecycle-with-kubevirt.html • VNF・CNF 基盤としての期待 https://events19.linuxfoundation.org/wp-content/uploads/2017/11/2018-OSSNA-CNF-Journey-in-Telecom- Seminar.pdf KubeVirt 利⽤状況参考資料 34

35. ©2021 Yahoo Japan Corporation All rights reserved. • インストール⽅法 virt-operator とカスタムリソースで⾃動化されている • アップデート⽅法無停⽌アップデートに対応実⾏中のライブマイグレーションがキャンセルされるのとコンソールが途切れるくらい (詳細は KubeVirt Summit の “Zero downtime KubeVirt updates” の発表を参照) • Alert Runbook 最近コミュニティで整備が始まった https://groups.google.com/g/kubevirt-dev/c/cxeyfw2ESV4 KubeVirt 運⽤関連の情報参考資料 35

36. ©2021 Yahoo Japan Corporation All rights reserved. VirtualMachineInstance (VMI) というカスタムリソースが最⼩単位このリソースを create するとVMが作成される (関連リソースに VirtualMachine、VirtualMachineInstanceReplicaSet がある) VMに対応するカスタムリソース参考資料 36 VirtualMachineInstanceReplicaSet VirtualMachineInstance VirtualMachine レプリカ数の指定 VMの基本リソースボリュームテンプレートの指定 RunStrategy (起動状態の管理) • Deployment ない • PodDisruptionBudget に相当するものもない • VMI も所々Podと使い勝⼿異なる。Pod を単純VMに置き換えている形ではない

37. ©2021 Yahoo Japan Corporation All rights reserved. CNI の仕組みを活⽤して VM に NW 接続を提供 KubeVirt では下の2つの機能を組み合わせて実現バックエンド • CNI と連携して NW を⽤意。複数 NIC への対応フロントエンド • バックエンドから提供される NW を VM に接続 • (CNI はホスト NIC 〜コンテナ NIC までを準備。その先のコンテナ NIC 〜 VM までの接続を実施) KubeVirt NW接続参考資料 37

38. ©2021 Yahoo Japan Corporation All rights reserved. KubeVirt NW接続: バックエンド参考資料 38 図の引⽤元: https://www.cncf.io/wp-content/uploads/2020/08/Fast_Packet_Processing_v1.pdf VMへのNWの提供⽅法 ”pod” • Kubernetesの default NW を VM に接続。Service リソースを利⽤できる VM単位に⼀つだけ “pod” タイプを指定できる “multus” • CNIメタプラグインの Multus 機能経由で複数のNWをVMに接続 NIC単位にCNIを指定 • Serviceリソースを利⽤できない https://github.com/k8snetworkplumbingwg/multus-cni/issues/466 • IPアドレス管理(IPAM)を⾏う必要がある CNI機能や接続先NW機能を利⽤

39. ©2021 Yahoo Japan Corporation All rights reserved. 参考資料 39 VMのNICへの接続(配管)⽅式 ”masquerade” • コンテナ NIC 〜 VM NIC の接続 • iptablesで中継する • 通常の推奨の接続⽅式 ”bridge” • コンテナ NIC 〜 VM NIC の接続 • ライブマイグレーションできない。sidecarできない https://github.com/kubevirt/kubevirt/pull/2537 ”sriov” ホスト NIC 〜 VM NIC の接続 (本⽇の説明では省略) KubeVirt NW接続: フロントエンド図の引⽤元: https://kubevirt.io/2018/KubeVirt-Network-Deep-Dive.html masqueradeフロントエンド

41. ©2021 Yahoo Japan Corporation All rights reserved. コンテナイメージのフォーマットを利⽤できるよう、VMイメージのバイナリを薄くラップするイメージデータの流し込み: コンテナディスク⽅式参考資料 41 cat << END > Dockerfile FROM scratch ADD fedora25.qcow2 /disk/fedora25.qcow2 END docker build -t vmidisks/fedora25:latest . docker push vmidisks/fedora25:latest レイヤー構造を利⽤する仕組みは今のところなく、無駄が多い

42. ©2021 Yahoo Japan Corporation All rights reserved. • KubeVirt のサブプロジェクト • クラスタアドオン • HTTP、S3 などの外部データをインポートし、PV に書き込み (内部のストア機能はない) • VMI作成時に CDI を利⽤して、PVC で確保する PV に⾃動でイメージを書き込む DataVolume リソースが⽤意されているイメージデータの流し込み: CDI (Container Data Importer) 参考資料 42 図の引⽤元: https://github.com/kubevirt/containerized-data-importer/blob/main/doc/diagrams/cdi-controller.png PersistenceVolumeClaim DataVolume

kubernetes-meetup-tokyo-20210624-kubevirt

kubernetes-meetup-tokyo-20210624-kubevirt

Recommended

More Related Content

What's hot

What's hot(20)

Similar to kubernetes-meetup-tokyo-20210624-kubevirt

Similar to kubernetes-meetup-tokyo-20210624-kubevirt(20)

Recently uploaded

Recently uploaded(20)

kubernetes-meetup-tokyo-20210624-kubevirt