レガシーワークロードがクラウドネイティブ環境への移行を妨げていませんか？クラウドネイティブ環境で仮想マシンを実行するための 4 つのソリューションをご紹介します。

多くのITプロフェッショナルはクラウドネイティブ環境への移行を望んでいます。しかし、モノリスなど、仮想マシンでしか実行できない従来のワークロードを抱えている場合もあります。

クラウドネイティブワークロードとレガシーワークロードを別々の環境として維持することは可能ですが、仮想マシンをクラウドネイティブ環境に統合し、シームレスに管理できる方法があれば、さらに良いのではないでしょうか。

幸いなことに、そのような方法は存在します。この記事では、最小限の再構成や調整でクラウドネイティブ環境で仮想マシンを実行するための4つのオープンソースソリューションを紹介します。

クラウドネイティブ環境で仮想マシンを実行する理由は何ですか?

これらのツールを検討する前に、まず、コンテナー化された疎結合のクラウド ネイティブ ワークロードで構成された環境で仮想マシンを実行できることがなぜ重要なのかを見てみましょう。

主な理由は単純です。レガシー ワークロードをホストする仮想マシンは消えることはありませんが、それらを実行するための個別の管理環境を維持するのは負担になります。

同時に、レガシーワークロードをクラウドネイティブ標準に適合させる必要がある場合もあります。理論上は、レガシーワークロードをリファクタリングしてクラウドネイティブ環境でネイティブに実行できるようにするための時間とエンジニアリングリソースは十分に確保できますが、現実には必ずしもそれが可能とは限りません。

したがって、従来の仮想マシン ワークロードとクラウド ネイティブ ワークロードを問題なく共存させるには、以下に説明する 4 つのオープン ソース ソリューションのいずれかなどのツールが必要です。

1. KubeVirtを使用して仮想マシンを実行する

クラウド ネイティブ環境に仮想マシンを展開するための最も一般的なソリューションは、おそらく KubeVirt です。

KubeVirtは、Kubernetesポッド内で仮想マシンを実行することで機能します。コンテナと並行して仮想マシンを実行したい場合は、既存のKubernetesクラスターにKubeVirtをインストールするだけで、以下の機能が追加されます。

 エクスポートリリース= v0.35.0
 # KubeVirt オペレーターをデプロイする
kubectl apply -f https://github.com/kubevirt/kubevirt/releases/download/${RELEASE}/kubevirt-operator.yaml
 # 実際のインストールをトリガーするKubeVirt CR ( インスタンスデプロイメントリクエスト) を作成します
kubectl apply -f https://github.com/kubevirt/kubevirt/releases/download/${RELEASE}/kubevirt-cr.yaml
 # すべてのKubeVirt コンポーネントが起動するまで待機します
kubectl - n kubevirt wait kv kubevirt -- 条件= 利用可能

次に、実行する各仮想マシンを記述したYAMLファイルが作成され、適用されます。KubeVirtは各マシンをコンテナ内で実行するため、Kubernetesの観点から見ると、VMは通常のポッドと変わりません（ただし、いくつかの制限事項があり、これについては次のセクションで説明します）。ただし、従来の仮想マシンと同様に、仮想マシンイメージ、永続ストレージ、固定のCPUおよびメモリ割り当ては引き続き利用できます。

つまり、KubeVirt は基本的に仮想マシンに変更を加える必要がありません。KubeVirt をインストールし、仮想マシンのデプロイメントを作成し、ポッドとして実行するだけです。

2. ヴィルトレ法

仮想マシンをポッドのように扱いたい場合は、Mirantis のオープンソース ツールである Virtlet が適しているかもしれません。

VirtletはKubeVirtに似ており、Kubernetesポッド内で仮想マシンを実行できます。2つのツールの主な違いは、Virtletが仮想マシンをKubernetesポッド仕様にさらに深く統合していることです。つまり、Virtletを使用すると、デーモンセットやレプリカセットの一部として仮想マシンを管理するといったことが可能です。これはネイティブのKubeVirtでは不可能です（KubeVirtにも同じ機能がありますが、Kubernetesのネイティブ機能ではなくアドオンです）。

ミランティスはまた、Virtlet は一般的に KubeVirt よりも優れたネットワーク パフォーマンスを提供するが、ネットワーク構成に関係する変数が多すぎるため確実に知ることは難しいと述べています。

3. ISIOの仮想マシンのサポート

仮想マシンをコンテナとして管理したくない場合はどうすればよいでしょうか？仮想マシンのように扱いながら、マイクロサービスと簡単に統合できるようにしたい場合はどうすればよいでしょうか？

おそらく最善の解決策は、仮想マシンをオープンソースのサービスメッシュであるIstioに接続することです。このアプローチにより、標準的な仮想マシンツールを使用して仮想マシンをデプロイおよび管理しながら、ネットワーク、負荷分散などをIstio経由で管理できます。

残念ながら、仮想マシンをIstioに接続するのは比較的面倒なプロセスであり、現時点では自動化が困難です。つまり、接続する各仮想マシンにIstioをインストールし、それぞれの名前空間を設定し、各仮想マシンをIstioに接続するということになります。

4. コンテナと仮想マシンはOpenStackと並んで存在する

これまで私たちが研究してきた技術には、Kubernetes や Istio などのクラウドネイティブ プラットフォームを採用し、そこに仮想マシン サポートを追加することが含まれています。

もう 1 つのアプローチは、クラウド ネイティブではないプラットフォームを使用して仮想マシンを実行し、そのプラットフォームにクラウド ネイティブ ツールを移植することです。

これは、OpenStack上でVMとコンテナの両方を実行した場合の結果です。OpenStackはもともと、プライベートクラウドを構築するために仮想マシン（およびその他の種類のリソース）をデプロイするために設計されました。しかし、現在ではOpenStackはKubernetesもホストできるようになりました。

そのため、OpenStackを使用して仮想マシンをデプロイ・管理しながら、Kubernetesを介してOpenStack上でクラウドネイティブなコンテナ化されたワークロードを同時に実行できます。最終的には、基盤となるOpenStackインストールとKubernetes環境という2つのオーケストレーションレイヤーが存在するため、管理の観点から見るとこのアプローチはより複雑になります。

しかし、Kubernetesの最大の利点は、仮想マシンがKubernetesの一部ではないため、仮想マシンとコンテナを比較的独立して管理できることです。また、仮想マシンの管理にKubernetesツールを使用する必要もありません。仮想マシンを標準的な仮想マシンとして、コンテナを標準的なコンテナとして扱うことができます。

結論は

オープンソースのエコシステムは、仮想マシンとクラウドネイティブのワークロードを共存させるための様々な方法を提供しています。最適なソリューションは、Kubernetes中心のアプローチ（KubeVirtまたはVirtletが最適な選択肢）を望むか、緊密な統合なしに仮想マシンとコンテナを共存させたい（OpenStackが最も理にかなっている）かによって異なります。オーケストレーションレベルではなくネットワークレベルでの統合のみを望む場合は、仮想マシンをIstioサービスメッシュに接続することを検討してください。

元のリンク: https://www.itprotoday.com/cloud-native/4-open-source-tools-running-vms-cloud-native-environment