KubeVirtとは？従来仮想基盤の代わりになるのか？？

先日OpenShift4.4が発表され、OpenShift Virtualizationの機能がテックプレビューで追加されました。OpenShift Virtualizationは、Virtual Machine（VM）をOpenShift上で操作する機能です。こちらの動画ではOpenShift上にWindows VMを起動しています。

「OpenShift Virtualizationによって従来の仮想基盤は不要になるのか？」という疑問を抱いたため、ベースの技術であるKubeVirtについて調査しました。KubeVirtを紐解くことで、OpenShift Virtualizationを知る近道になるはず。

  • KubeVirtとは？
    • KubeVirtの概要
      • 従来仮想基盤との違い
      • コンテナとの違い
    • KubeVirtの構成
  • KubeVirtのメリット/デメリットは？
    • コンテナと比較したメリット
    • コンテナと比較したデメリット
    • 従来の仮想基盤と比較したメリット
    • 従来の仮想基盤と比較したデメリット
  • KubeVirtは従来の仮想基盤の代わりになるのか？

KubeVirtとは？

KubeVirtの概要

KubeVirtは、Kubernetes上でVMをコンテナとして操作するインタフェースです。Kubernetes上でVMを従来通り動かすのが目的ではなく、コンテナ化が難しい従来のVMをKubernete上のワークロードに適用しやすくすることが目的で作られました。

従来仮想基盤との違い

図の通りKubernetes上でVMがコンテナとして動きます。

従来の仮想基盤と大きく異なる点は、VMがKubernetesのワークロードとして稼働する点です。従って、スケジューリングやHWリソースの割り当ての方法が大きく変わります。レプリカセットやサービスなどのリソースと組み合わせて使うことができるようになる一方で、これまでのHWリソース割り当てができなくなる可能性があります。改修が必要なVMアプリケーションも今後出てくることが考えられます。

コンテナとの違い

コンテナと大きく異なる点は、イメージです。通常コンテナイメージでコンテナアプリケーションを実行しますが、KubeVirtではVMイメージから実行します。

ちなみにKubeVirtがサポートするイメージは現状以下のみになります。コンテナが再起動する度にデータが削除されてしまうので、通常はPVCにイメージを書き込んでディスクから起動します。

  • .img
  • .iso
  • .qcow2
  • 上記イメージの圧縮ファイル（ .tar, .gz,  .xz ）

引用元）https://kubevirt.io/user-guide/#/installation/image-upload

KubeVirtは、コンテナの中でlibvirtdがVMのライフサイクルを管理しています。だからこそVMのイメージでアプリケーションが起動しますし、コンテナなのに起動・停止・再起動ができるのです。

KubeVirtの構成

KubeVirtの構成についても調査しました。KubeVirtをデプロイすると以下のコンポーネントが配置されます。

  •  
    • virt-controller

VMのPodを作成します。kubeletによってPodがスケジュールされると、virt-handlerにCRDであるVM情報を連携します。

    • virt-handler

CRDであるVM情報が更新されたことを検知すると、そのVM情報をvirt-launcherに指示します。

    • virt-launcher

virt-handlerからCRDであるVM情報を受け取ると、それを基にlibvirtdを介してVMを起動します。

    • libvirtd

VMライフサイクルを管理します。

KubeVirtのメリット/デメリットとは？

思いつくメリット/デメリットを書き出してみました。もちろんこれ以外にもあると思いますので、参考程度に読んでいただければ幸いです。

コンテナと比較したメリット

サーバー型アプリケーションのコンテナ化が容易

サーバー型アプリケーションのコンテナ化が容易であることが挙げられます。これは1番の強みと言っても過言ではないと思います。
サーバー型アプリケーションをコンテナ化するには、必要なファイルを洗い出してベースイメージの仕様に合わせる必要があります。更には、アプリケーションやジョブクライアントなど、仕様を大きく変更しなければならない箇所も多く出てきます。一方、KubeVirtはサーバーイメージからOSごとコンテナ化できますので、そういった作業を比較的少なくすることができます。

アプリケーションがカーネルを共有しない

カーネルを共有しないという点もメリットとして挙げられます。厳密に言えば共有していますが、アプリケーションが直接利用するカーネルを他のアプリケーションが利用することがありません。
カーネルを独占することによってセキュリティをコンテナよりも担保し易くなるというメリットがあります。

VMの起動・停止・ライブマーグレーションが可能

メリットになるか賛否両論あると思いますが、コンテナなのに起動・停止・再起動・ライブマイグレーションが可能であることで、アプリケーションによってはメリットになると思います。

コンテナと比較したデメリット

資源効率が悪い

資源効率が悪いということがデメリットとして挙げられます。コンテナは必要最低限のモジュールのみインストールすればアプリケーションが実行できます。それと比較すると、KubeVirtはOSのイメージを利用するため、容量を多く使います。更にVMの数が増えるほど、VM間におけるOSモジュールの重複や不要なOSモジュールが増えてしまいます。このような観点でコンテナと比較すると資源効率は悪いです。

従来の仮想基盤と比較したメリット

複製・自動化が容易

複製・自動化が容易であることがメリットとして挙げられます。Kubernetes上でコンテナとして動くので、HPAやReplicaSetのようなリソースを使って運用の自動化ができます。

開発スピードの向上

開発スピードの向上が期待できます。これまで開発者はシステム管理者にサーバー作成を依頼していました。VMアプリケーションを開発者が自律的に作成できるようになるため、そのリードタイムを短縮できます。

VMとコンテナの連携が容易

Kubernetes上のコンテナとVMの連携が容易であることも挙げられます。通常のVMだと当然ながらKubernetesの外にいます。従って、コンテナと通信するにはコンテナを外部に公開する設定が必要でした。更にはKubernetes内で定義した名前をVMで扱うことができませんでした。Kubernetes内にVMを構築できることで、これらの考慮が不要になり、コンテナとの連携が比較的容易になります。

従来の仮想基盤と比較したデメリット

OSの設定変更が煩雑

KubeVirtでVMデプロイ後にOSの設定を変更しても、障害などで再作成された時に設定が消えてしまいます。設定変更にはイメージを編集し、VMを再度起動する必要があります。Immutableな性質によるメリットの裏返しです。但し、これは永続ボリュームを使うことで回避できますのでデメリットにはならないことが多いです。

KubeVirtは従来の仮想基盤の代わりになるのか？

結論から言うと、単純なマイグレーションつまり従来と同じ用途では代替ツールにはならないと思います。VMのライフサイクルがKubernetesで管理されるので、今までと作成方法や管理方法が異なります。様々な管理が自動化できる一方で、従来仮想基盤でできたことができなくなることも今後見つかってくると思います。だからこそ、今までと同じと考えるのは非常に危険です。

繰り返しになりますが、KubeVirtは従来の仮想基盤の代わりを目指している訳ではありません。従来のワークロードにImmutableな性質を持たせ、よりスケーラブルで柔軟なシステムにすることを目的としています。従来の仮想基盤から移行する場合は、運用の発想も大きく変える必要があるということがわかりました。