VMware “Project Pacific”
前回のブログでコンテナと仮想マシン（VM）の共存について書きました。コンテナとVMは相反する存在で、コンテナの普及によりVMが不要になる、という見方も根強い中、両者の共存の可能性とその利点を解説する内容でした。単純に言うと、VM内にコンテナを実現すれば、ホストから切り離されたVMの安定したセキュリティをコンテナで享受できる点が両者共存の最大の利点です。すでにVMを活用している企業が、既存のインフラにそのままコンテナを導入できるという現実的な側面もあります。
ただし、この共存論では、コンテナ オーケストレーション ツールの存在が省かれています。存在しないと仮定したわけではなく、コンテナがVMに内包されるのなら、コンテナ オーケストレーションも当然VM内部で通常どおり機能するわけで、その存在に特に言及する必要がなかったのです。それは、あくまで、コンテナ オーケストレーション ツールの役割は複数コンテナの起動を調整すること、と仮定した場合です。
現実には、Kubernetesをはじめとするオーケストレーション ツールにはそれ以上の働きがあります。たとえば、アプリケーション全体の「あるべき状態（desired state）」がIaC（infrastructure as code）のように記録され、それを自動的に実現する仕組みはCI/CD（継続的インテグレーション／継続的デリバリーまたはディプロイメント）をサポートする重要な機能で、コンテナ環境が「クラウド ネイティブ」と同義になっている所以です。
また、KubernetesをVM内に留めたのでは、ノードをまたがるオーケストレーションというより大きな柔軟性と拡張性が発揮されず、マイクロサービスが有効にサポートされていないという声もあります。
つまり、前回のコンテナVM共存論は、個々のワークロードを独立させて整合性や互換性の問題と切り離すというコンテナそのものの利点は活用できるものの、マイクロサービスとCI/CDをサポートするクラウド ネイティブの視点が省かれています。そして、クラウド ネイティブでないコンテナなんて、コンテナである意味がない！という指摘もあるでしょう。
VMwareの最新のコンテナVM共存論は、それに見事に応えています。コンテナをVMに内包させるのではなく、KubernetesにコンテナもVMもオーケストレーションさせるアイデアです。KubernetesがESXiホスト上でワークロードを調整管理できるようにvSphereの設計を見直し、Kubenetesクラスタをハイパーバイザー上 で実現させて（Supervisor Cluster）、VMとコンテナの両方に対してKubernetesの機能を発揮させる仕組みです。
クラウド ネイティブ アーキテクチャをサポートする上でのKubernetesの重要性を認め、これまで築き上げた仮想環境のエコシステムにKubernetesを組み込む決断をしたVMwareの強い意志が感じられます。Project Pacificと呼ばれるこの取り組みは、今後IT業界の市場動向を大きく左右するものかもしれません。
RSSフィードを取得する
