こちらのPublickeyの記事だけ見て中身がよくわかってなさそうな人がちらほらいたので、KubeVirtを使うことの意味についてちょっと書いてみようと思う。
ただのちっちゃなVM基盤が欲しい場合は、ほぼ不要なもの
勉強目的などを除き、仮想マシンの数が10に到底届かないような仕組みでKubeVirtを動かす場合、かなり勿体無いので採用する意味はあまりないと思う。Kubernetesを動かすことによるオーバーヘッドがかなり大きいし、正直物理的な冗長性が十分無視できるくらいの規模と言わざるを得ないので仮想化基盤としてKubeVirtを採用するメリットは薄い。EC2とかESXiとかProxmoxとか既存の仕組みを使えばいいんじゃない？と思う。
採用に値するであろうメリット1: IaaSを作りたい場合
KubeVirtの本質は、「KubernetesのAPIを使って仮想マシンのライフサイクルを管理できる」という点だ。仮想化を知ってる人間向けの言葉を使うと、KVMのコントロールプレーンがKubernetesになる、という言い方ができる。OpenStack APIやAmazon EC2を操作するためのAWS API、あるいはvCenterのAPIなどを操作する代わりに、KubernetesとYAMLファイルを使って仮想マシンが管理できる、ということだ。そこにコンテナのようなプロセスは登場しない。
apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: testvm spec: running: false template: metadata: labels: kubevirt.io/size: small kubevirt.io/domain: testvm spec: domain: devices: disks: - name: containerdisk disk: bus: virtio - name: cloudinitdisk disk: bus: virtio interfaces: - name: default masquerade: {} resources: requests: memory: 64M networks: - name: default pod: {} volumes: - name: containerdisk containerDisk: image: quay.io/kubevirt/cirros-container-disk-demo - name: cloudinitdisk cloudInitNoCloud: userDataBase64: SGkuXG4=
なので、ディスクやメモリCPUなどのリソースのほか、どのようなネットワークに所属させるかなどといった定義をソフトウェアで完結できるのが強みだ。そのため、手動オペレーションが根強く残っている組織文化でこの技術を採用するのはかなり挑戦的かもしれない。また、採用においてはイメージレジストリやネットワーク定義など、数多くの準備が必要になるし、ライブマイグレーションやバックアップリストアなど既存のオペレーションから完全に解放されるわけではないため、そこの考慮も十分に行う必要があるだろう。
採用に値するであろうメリット2: コンテナとVMのネットワーク空間を揃えたい場合
Kubernetesの仕組みとして提供されるCSI、CNIなどが統一的に使えることから、KubernetesのPod、Serviceが存在するネットワークとVMのネットワークの疎通がローカルで完結できるのは大きなメリットと言える。ただ、（パブリックにせよプライベートにせよ）クラウドのSDNとKubernetesのネットワークが既に統合されている場合はこの限りではない。あくまでもServiceのレベルで見た時にKubernetesのリソースと同じ感覚でVMが扱えるということだ。Multusの恩恵に預かることでBridge networkやオンプレネイティブなネットワークのvNICを生やすこともできるので、そのへんをSoftware Definedにニョキニョキ生やせるのは便利だが、物理NICのキャパシティに関しては完全に物理構成依存になるため、やはりそこの設計から逃れることはできないと言う注意点もある。
ざっくり思いつくのはこんな感じだが、他にもあれば誰か書いてほしい。
今日はこのへんで。
