コンテナと VM の違いは何ですか?存在しない

ハイパーバイザー テクノロジーは、クラウド コンピューティングの誕生以来、その基礎の 1 つとなっています。しかし、近年のコンテナ技術の爆発的な増加により、この仮想化技術は従来の方法と見なされ始めています。コンテナの人気が仮想マシンに脅威を与えていると多くの人が考えており、そのため初期の頃はコンテナと仮想マシンの間で論争がありました。

数年にわたる技術開発と大規模な実践を経て、多くの企業が仮想マシンベースのアプリケーションをコンテナに移行していますが、実際にはデータセンターやパブリッククラウドでは仮想マシンが依然として普及しています。一方で、コンテナは仮想マシンを完全に置き換えたわけではありません。一方、仮想マシンもコンテナを積極的にサポートしており、両者の共存が一般的になりつつあります。

今日は、仮想マシンとコンテナの違い、この 2 つが共存する理由、そして将来的にどこに向かうのかについてお話しします。

仮想マシンとコンテナにはそれぞれ独自の利点がある

仮想マシンとコンテナの作成の本来の目的は、リソースの使用率を向上させることですが、両者の違いは、仮想マシンはオペレーティング システム レベルでのリソース分離であるのに対し、コンテナは基本的にプロセス レベルでのリソース分離である点です。

仮想マシンは、ソフトウェアによってシミュレートされ、完全なハードウェア システム機能を備え、完全に分離された環境で実行される完全なコンピュータ システムです。各仮想マシンには独立した CMOS、ハードディスク、オペレーティング システムがあり、物理マシンのように操作できます。

仮想マシンの動作は、ハイパーバイザと切り離すことはできません。ハイパーバイザは、基本的な物理サーバーとオペレーティング システムの間で実行される中間ソフトウェア レイヤーであり、複数のオペレーティング システムとアプリケーションがハードウェアを共有できるようにします。

簡単に言えば、サーバー ハードウェア、ハイパーバイザー、仮想マシンの関係は、各仮想マシンに完全なオペレーティング システムがあり、仮想マシンに展開されたアプリケーションはオペレーティング システム全体のリソースを使用できるというものです。

仮想マシンの出現により、物理サーバーへのアプリケーションの初期の展開によって生じたリソース割り当ての問題が解決されましたが、アプリケーションのリソース境界を定義できませんでした。

ただし、仮想化を一定期間使用すると、いくつかの問題があることがわかります。例えば、仮想マシンのシステム層は物理マシンのリソースをより多く占有することになり、サーバーのリソース使用率をさらに向上させる必要があります。仮想マシン サービス プログラムを移行する必要がある場合、仮想マシン全体を移行する必要があり、移行プロセスが複雑になります。

これらの問題を解決するために、コンテナが登場しました。

コンテナ技術は、軽量な仮想化技術であるオペレーティング システム仮想化技術として理解できます。カーネルは、異なるプロセス (コンテナー) を分離するために、複数の仮想オペレーティング システム インスタンス (カーネルとライブラリ) を作成します。異なるインスタンスは互いに分離されており、お互いをまったく認識しません。コンテナは、プロセス レベルの分離を提供するプロセス サンドボックスであると簡単に理解できます。

仮想マシンと比較すると、コンテナには独自のオペレーティング システムがありません。代わりに、コンテナ エンジンを介してホスト オペレーティング システム カーネルを共有するため、複数のオペレーティング システムを実行する際のオーバーヘッドが削減されます。

標準ソフトウェア ユニットとして、コンテナーはアプリケーションの展開に必要なコードと依存関係をイメージにパッケージ化し、コンピューティング環境間で迅速かつ確実に実行できるようにします。

したがって、コンテナの大きな利点は、数秒で非常に速く起動でき、リソースの利用率が高いことです。たとえば、ホストは数千の Docker コンテナを同時に実行できます。さらに、占有するスペースも非常に小さいです。仮想マシンでは通常、数 GB から数十 GB の容量が必要ですが、コンテナーでは MB または KB しか必要ありません。

一般に、コンテナと VM はリソースの分離と割り当てに関して同様の利点がありますが、機能は異なります。コンテナはハードウェアではなくオペレーティング システムを仮想化するため、コンテナはより軽量で効率的です。しかし、ユーザーが異なるオペレーティング システムで実行される異なるアプリケーションを使用する必要がある場合、仮想マシンは信頼性の高いソリューションとより優れたセキュリティを提供できます。

したがって、現在最も効果的で一般的な戦略は、1 台の物理マシンに複数の仮想マシンを用意し、各仮想マシンに複数のコンテナを配置することです。コンテナと仮想マシンを併用すると、アプリケーションの展開と管理に大きな柔軟性が得られます。

仮想マシンとK8の統合

コンテナと仮想マシンは互いに置き換わるのではなく、統合された状態にあることがわかります。これにより、仮想マシンとコンテナ技術を同時に管理する方法という新たな問題も生じ、これは企業の共通の要求となっています。

仮想化技術の主な推進者として、VMware は非常に早い段階で対応しました。これまで、VMware は仮想化プラットフォームに PKS (Pivotal と VMware が共同で立ち上げた K8s プラットフォーム) をプラグインすることで、仮想マシンとコンテナの同時管理を実現していました。しかし、結局のところプラグインであり、効率性や管理の利便性に欠点があります。

昨年の VMworld カンファレンスで、VMware は Tanzu ブランド プランを立ち上げ、仮想化技術におけるコンテナ技術のネイティブ サポートを提供することを発表しました。 VMware の Tanzu は、仮想マシンと K8s を組み合わせて、仮想マシン、コンテナ、物理マシンの管理を統合します。物理マシン、仮想マシン、内部データセンター、複数のクラウドにわたるアプリケーションを管理できるため、ワークロードの統一されたサポートが提供されます。

Tanzu は今年 3 月に正式に発表され、VMware の最新世代の仮想化プラットフォーム vSphere 7 が一般にリリースされました。 vSphere 7 は、過去 10 年間で最も大きな変化の 1 つをもたらしました。 VMware は vSphere をリファクタリングし、K8s を vSphere のコントロール プレーンに組み込み、K8s ネイティブ プラットフォームにして、ネイティブに K8s をサポートしました。

これにより、従来の VMware ユーザーは仮想マシンと K8s コンテナ環境のどちらかを選択する必要がなくなり、テクノロジ、ツール、スキルセットへの既存の投資を引き続き活用しながら、vSphere 上で最新のアプリケーションを自由に開発および運用できるようになります。

一方、コンテナベンダーも仮想化の客観的な存在を認識し、仮想化技術を採用し始めています。 Kubevirt はこの目的のために立ち上げられました。

Kubevirt は、コンテナ モードで仮想マシンを実行する Red Hat オープン ソース プロジェクトです。コンテナのイメージ レジストリを使用して仮想マシンを作成し、仮想マシンのライフサイクル管理を提供します。 4月下旬に開催されたRed Hatの年次技術カンファレンス「Red Hat Summit 2020」において、Red HatはKubeVirtオープンソースプロジェクトから派生したOpenShift仮想化のテクニカルプレビューの開始を発表しました。この機能により、企業はクラウドネイティブと従来のワークロードを統合する OpenShift 上で、仮想マシン、コンテナ、サーバーレス アプリケーションで構成されるアプリケーションを開発、展開、管理できるようになります。

VMware と Red Hat は出発点は異なりますが、目標は同じであり、その原動力となっているのは企業の真のニーズです。ユーザーにとって、彼らの行動は間違いなく歓迎すべきものである。これにより、企業の不安が軽減され、二者択一の選択をする必要がなくなります。コンテナを仮想マシンにデプロイするかベアメタルにデプロイするかを心配する必要がなくなり、将来的にさまざまなアプリケーションをより柔軟にサポートできるようになります。

仮想マシンとK8の未来

現在では、仮想マシンとコンテナ技術の組み合わせが現実のものとなっています。それだけでなく、仮想マシンもクラウドネイティブ アーキテクチャの一部になりつつあります。これがコンテナネイティブ仮想化です。 K8s に代表されるコンテナは仮想マシンベースのインフラストラクチャ上で実行され、仮想マシンベースのワークロードは依然として IT ポートフォリオの重要な部分を占めています。

仮想マシンと K8s の統合は将来どのようなトレンドを生み出すでしょうか?

K8sはマイクロVM（Kata Containers、Firecracker、gVisorなど）をオーケストレーションします。

マイクロ VM は、従来の仮想化のように完全な「マシン」を提供するのではなく、アプリケーション コンテナーまたは機能を正常に実行するのに十分な VM を提供することに重点を置いています。したがって、マイクロ VM は、従来の VM のコールド スタート時間とパフォーマンスの弱点を最小限に抑えながら、標準の Linux コンテナーに比べてハードな分離を提供するように設計されています。

一部のユーザーの場合、より強力なマルチテナント分離が必要になる場合があります。したがって、このアプローチにより、信頼できないワークロードに対してより厳密なマルチテナント分離を提供できます。

K8sは標準的な仮想マシンをオーケストレーションする

以前は、仮想化スタックは K8s やクラウド ネイティブとは完全に別の島であり、ワークフロー、ツール、チームなどが別々でした。コンテナ ネイティブ仮想化の概念により、仮想マシンは K8s のコンテナ ベースのアプリケーションと同じワークフローに従うことができます。

現在、KubeVirt などのオープンソース プロジェクトにより、コンテナ ネイティブの仮想化が可能になります。 K8s オーケストレーション エンジンは、クラウドまたは仮想化プラットフォーム上で実行されている標準の仮想マシンを管理するために使用できます。 K8s により、コンテナと仮想マシンのハイブリッドな運用と保守が可能になります。

ベアメタル上の K8s (VM なし)

現在、ほとんどの K8s プラットフォームは VM ベースのインフラストラクチャに導入されていますが、コンテナは実行に VM に依存せず、ベアメタル上で K8s とコンテナを実行する慣行は増加し続けています。

K8s をベアメタル上で実行すると、アプリケーションは基盤となるハードウェアを最大限に活用できるようになります。これは、より多くのマシンとパフォーマンスが重視されるアプリケーションを K8s に導入するユーザーにとって重要です。 K8s とコンテナをベアメタル上で実行すると、VM の無秩序な増加を減らし、操作を簡素化することもできます。これは仮想マシンにとって良いニュースではありません。

一般的に、仮想マシンとコンテナにはそれぞれ独自の利点があります。アプリケーション シナリオには一部重複がありますが、主なアプリケーション シナリオは異なります。たとえば、仮想マシンは複数のオペレーティング システムのリソースと機能を実行するのに適していますが、コンテナーはより少ないサーバー上でより多くのアプリケーションを実行するのに適しています。

ほとんどの場合、ほとんどの企業は、特にほとんどの企業がすでに仮想化テクノロジを広く導入していることを考慮すると、VM とコンテナの両方を使用します。これを考慮すると、コンテナと仮想化は今後しばらく共存するはずです。