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

[三木泉，＠IT]

　Kubernetesは、開発者あるいは開発チームに属するインフラ担当者が、リソースを自分たちで思うように利用するためのツールとして歓迎されている側面がある。

　ただし、より大規模な組織では、Kubernetesによるコンテナ環境をマルチテナント構成で利用している。

　組織全体で利用するKubernetes環境の運用は、（Kubernetesにおける）「クラスタ管理者」と呼ばれる人が担う。このクラスタ管理者は、全体的なITリソースから一部を切り出して、各開発プロジェクト／チームに割り当てる。この際には割り当てリソース上限を、「Namespaces」と呼ばれる管理単位に定義し、これを開発プロジェクト／チームに渡す形で行われる。開発プロジェクト／チームは、クラスタ管理者からNamespaceをもらい、割り当てられたリソースを（Kubernetesの管理ツールやAPI経由で）セルフサービス的に利用して、コンテナベースのアプリケーション開発や運用を行う。

　Cloud Foundation with Tanzuでは、上記のKubernetesにおけるクラスタ管理者と開発プロジェクト／チームの関係をなぞっており、クラスタ管理者の役割をvSphere／Cloud Foundationの運用担当者が担えるようにしている。ITインフラ運用担当者は、このためにKubernetesやそのツールの使い方を学習する必要がない。vSphere／Cloud Foundationの管理ツールを用い、ウィザード形式でKubernetesのクラスタを構築し、Namespaceを定義・作成できるからだ。

　一方、個々の開発プロジェクト／チームにとっては、パブリッククラウド上のKubernetesサービスを使っているのと使い勝手に変わりがない。開発プロジェクト／チームは、Kubernetesの管理ツール／APIを使い、渡されたNamespace内にセルフサービスでPodを作成し、その上でコンテナを走らせることができる。

Cloud Foundationを運用するITインフラ管理者は、ITリソース／サービスを定義して開発チームに提供、開発チームはこれをセルフサービスで活用できる

　上記はKubernetes環境の利用に閉じた説明だが、実際にはCloud Foundationの管理者は「ワークロードドメイン」としてコンピュート／ストレージ／ネットワークなどのリソースを切り出し、Namespaceに割り当てて提供できる。

　このため開発プロジェクト／チームは、渡されたNamespace内にコンテナだけでなく仮想マシンやサーバレス環境を作成し、コンテナ／仮想マシン／サーバレス混在アプリケーションをデプロイできるようになるという。

　なお、VMwareは「vSphere／Cloud Foundation with Tanzuの管理者がアプリケーション指向のITインフラ管理を進められる」としている。これは「開発プロジェクト＝アプリケーション」と考えれば、vSphere／Cloud Foundation側で管理者がITリソース割り当てやサービスレベルなどのポリシーを用意し、Namespaceを通じてこれを個々のアプリケーションの開発・運用を行うチームに渡せることを意味している。

　例えばストレージでは、vSANの永続ストレージに関して利用上限や暗号化などのポリシーをNamespace経由で開発プロジェクトに提供し、開発プロジェクト側はこの中から自ら動的に必要量を切り出してプロビジョニングができる。プロジェクト側が作成したボリュームは、ITインフラ管理者もvSphere／Cloud Foundationのツールでモニターでき、トラブルが発生した場合には物理ディスクにまでたどって事象を確認するなどができるという。

特集：一般企業とサーバ仮想化、コンテナの関係はどう変わるか

コンテナへの注目が高まっている。一般企業はこれをどう、自社のITインフラ基盤に組み込んでいけばいいのか。そもそも、デジタルトランスフォーメーションにおいて、情報システム部門は、ビジネス部門とどのような関係を構築できるのか。そしてサーバ仮想化プラットフォームが多数の大規模組織に使われてきたVMwareは、こうしたニーズにどう対応しようとしているのだろうか。

特集：一般企業とサーバ仮想化、コンテナの関係はどう変わるか