VMwareが“Kubernetes対応”した「VMware Cloud Foundation with Tanzu」とは何か、技術的な側面からまとめてみた：ITインフラ管理者と開発チームの関係は（1/2 ページ）

VMware vSphere 7およびVMware Cloud Foundation 4が2020年4月初めに一般提供開始となった。この2製品におけるKubernetes対応とは具体的にどのようなものなのか。技術面から探る。

　VMwareが2020年3月に行ったKubernetes関連の発表のうち、「VMware Tanzu Kubernetes Grid」は、純粋なKubernetesディストリビューションだ。一方、「VMware vSphere 7 with Tanzu」「VMware Cloud Foundation 4 with Tanzu」は、Tanzu Kubernetes Gridを“組み込んだ”製品（ちなみにCloud Foundationは、vSphereに、ソフトウェアストレージの「VMware vSAN」とネットワーク仮想化の「VMware NSX」を統合したソフトウェアによるITインフラ基盤製品のこと）。

　この2製品、特にCloud Foundation with Tanzuは、次の2つの点でユニークだ。

　第1に、Cloud Foundation with Tanzuでは、サーバ仮想化環境上でコンテナを動かすこともできるが、それだけではない。ハイパーバイザー上で動かすことができる。このため、仮想マシンとコンテナを単一基盤上に並列で稼働し、双方を混在させられる。その意味で、サーバ仮想化環境とコンテナ環境を“融合”している。第2に、これら2つの管理を統合しながら、開発プロジェクト／チームと ITインフラ運用担当部署の間で“役割分担”ができるようにしている。

　第1の点に関しては、Cloud Foundation with Tanzuにより、サーバ仮想化環境とKubernetesによるコンテナ環境を、単一のハイパーコンバージドインフラ（HCI）としてターンキー的に提供できる。Cloud Foundationでサーバ仮想化環境を運用していれば、コンテナ環境のために新たな基盤を構築したり、調達したりする必要はない。再構築などなしに、後からこのサーバ仮想化環境をサーバ仮想化／コンテナ混在環境へと即座に切り替えることができる（ただしCloud Foundation with Tanzuのライセンスは必要）。

　そして第2の点は、ユーザー部門が情報システム部門に対して抱きがちな、「足を引っぱるばかりの存在」というイメージの払しょくにつながる可能性がある。Kubernetesの利用に口出しをされることがないからだ。

　本記事では、VMwareのCloud Foundation担当者が2020年3月にTech Field Dayで行ったプレゼンテーションの録画、「Introducing VMware Cloud Foundation 4 featuring vSphere 7 with Kubernetes」「VMware Cloud Foundation 4: Accelerate Kubernetes Infrastructure Deployment」を基に、サーバ仮想化とコンテナの“融合環境”としてのCloud Foundation、および開発プロジェクト／チームとITインフラ管理者の間の役割分担について、技術的な側面を紹介する。

サーバ仮想化とコンテナの“融合環境”としてのCloud Foundation

　Cloud Foundation with TanzuでVMwareは、「ハイパーバイザー上でコンテナが直接動くため、物理サーバ上でコンテナを動かすのに近い環境が実現できる」としている。正確に表現すれば、薄いLinuxカーネルとコンテナエンジンが乗った特殊なPodがハイパーバイザー上で動き、この上で複数のコンテナが動作するという。だが、VMwareは一般的な物理サーバ上のコンテナに比べ、こちらの方がパフォーマンスは8％高いとしている。ハイパーバイザーによるCPUスケジューリングの性能が優れているからだという。

　そこでVMwareでは、例えば通信事業者におけるNFV（ネットワーク機能仮想化）のように、「仮想マシンのオーバーヘッドが気になる」という場合にも対応できるとしている。また、サーバ仮想化のために導入される物理サーバは潤沢な通常、CPU／メインメモリを備えているため、これらをフル活用すれば、単一のサーバで多数のコンテナを稼働することができる。

　同じESXiは、当然ながら従来通り仮想マシンを動かす基盤としても機能する。このため、コンテナと仮想マシンは同一サーバ上に混在する形で、並列動作する。

　また、ESXiにはKubernetesのKubeletが埋め込まれ、各物理サーバはKubernetesのワーカーノード（管理対象ノード）として機能する。これにより、後はKubernetesのマスターノードを仮想マシンとして立ち上げることで、Kubernetesによるコンテナオーケストレーションが行えるようになる。

　加えて、Cloud FoundationのKubernetesコントロールプレーンでは、「Operators」というKubernetes拡張機能を利用することで、コンテナに加えて仮想マシンも管理できるようにしている。従って開発プロジェクト／チームは、Kubernetesの管理ツールを使って、コンテナ／仮想マシン混在のアプリケーションを管理・運用できる（ただし、仮想マシンをデプロイするためのOperatorは。執筆時点では未提供）。

開発チームはKubectlを通じて、コンテナ／仮想マシン混在のアプリケーションを管理・運用できる

　一方、Cloud FoundationのKubernetes API Serverは、vSphere／Cloud FoundationのvCenterと同期するため、Cloud FoundationとKubernetesによる“二重管理”ができるようになっている。

　後述するが、これが開発プロジェクト／チームと情シス／ITインフラ運用担当者の間の役割分担のベースとなっている。開発プロジェクト／チームと情シス／ITインフラ運用担当者の双方がそれぞれの立場で、コンテナ、仮想マシン、ストレージやネットワークといったITリソースを統合的に扱える。

　これまで紹介したCloud Foundation上のKubernetesは、特殊なPodを動かすため、完全準拠のKubernetesとは言えないという。一方でVMwareは、純粋なKubernetesディストリビューションであるTanzu Kubernetes Gridを、上記の枠組みの中で開発プロジェクト／チームが立ち上げられる選択肢も提供しているとしている。

開発プロジェクト／チームとITインフラ管理者の間の役割分担

　次に、開発プロジェクト／チームとITインフラ管理者の間の役割分担について紹介する。

　企業内の開発チームや事業部門がコンテナ環境やパブリッククラウドを使いたくなる動機は複数あるが、その1つには「社内の情シスあるいはITインフラ運用担当部署が、自分たちのニーズについてこられない」ということがある。新たなITリソースを使いたいとき、ITインフラ運用部署におうかがいを立て、ITリソースの払い出しを必要とする理由をその都度詳しく説明して了解を得たのち、1週間以上してからようやく使い始めることができるといったスピード感のなさに我慢ができない。