このブログでは、vSphere 7 の新機能「vSphere with Tanzu」の概要について、実機でのスクリーンショットとあわせてご紹介します。

なお、リリース当初は「vSphere with Kubernetes」と呼ばれていましたが、vSphere 7.0 Update 1 から「vSphere with Tanzu」となりました。それにともない、本稿も2021年3月31日に修正・加筆いたしました。

vSphere 7 が 2020年4月にリリースされました。vSphere Lifecycle Manager や Identity Provider Federation など多くの新機能が追加され、vMotion や vSphere DRS といった従来から活用されていた機能も改善されています。

その一方で、Windows 版の vCenter Server が廃止されて Linux ベースの仮想アプライアンスに、管理 UI でも Flash ベースの「vSphere Web Client」が廃止されて HTML5 ベースの「vSphere Client」に一本化される、といった刷新もされています。

vSphere に限らず、一般的には、リリースされたばかりの製品（いわゆる GA 版）をすぐに本番環境へ導入するケースは少ないと考えられます。しかし vSphere 7 はメジャー アップデートということもあり、システム インテグレータや企業のIT部門では、積極的に情報収集や機能検証が開始されているはずです。

そこで本稿では、vSphere 7 でも特に大きな機能追加である「vSphere with Tanzu」についてご紹介します。これは、VMworld 2019 において発表された当初は「Project Pacific」と呼ばれていたものです。

vSphere with Tanzu とは、vCenter Server と ESXi による仮想化基盤上に、Kubernetes によるコンテナ技術のワークロードを稼働させるソリューションです。まずは、Kubernetes について概要をご説明します。

Kubernetes は、多数のコンテナを起動するための仕組みです。Google によってオープンソースとして公開されたもので、大規模な分散システムのワークロードを管理できるように作られています。

コンテナ技術については、「Docker」が特に有名だと思います。Linux や Windows のような OS に、Docker をはじめとしたコンテナの実行環境を用意して、そこでアプリケーションをパッケージングした「コンテナ」を起動します。

アプリケーションをコンテナにするメリットとして、依存ソフトウェア一式をまとめたパッケージをさまざまな環境で起動できる「可搬性」や、仮想マシンよりもデータ容量や消費リソース面で軽量である、といった特徴があげられます。コンテナ イメージについても、Docker Hub をはじめとするコンテナ レジストリで簡単に管理できます。しかし、多数のホストへのコンテナ展開や、ホストをまたぐようなコンテナ同士のネットワーク接続には課題がありました。

そこで、Kubernetes が開発されました。多数のコンテナを起動するオーケストレーターの役割を持ち、複数のホストをまたぐコンテナの起動を自動化できます。また、障害発生したコンテナの再起動、コンテナのスケールアウトとスケールイン（コンテナ数の増減）、それに伴うネットワークや、ロードバランサの設定などもカバー範囲としています。つまり Kubernetes は、コンテナを起動するホスト（いわゆるコンテナ ホスト）と置き換えられるものではなく、コンテナ ホストをまとめて管理する仕組みです。

Kubernetes 基盤は、制御プレーンと、ワーカーとで構成されます。典型的な（これから解説する vSphere with Tanzu ではない） Kubernetes 基盤では、仮想マシン（または物理マシン）内に Linux OS と Kubernetes を構成するソフトウェアをインストールして、Kubernetes のクラスタを作成します。そしてクラスタを構成するノードの役割としては、制御プレーンとなるサービス（これもコンテナ群）が起動するマスターノードと、本来の目的となるアプリケーションのコンテナを起動するワーカーノードがあります。

また、Kubernetes では、コンテナを「Pod」という単位で管理します。ただし、本稿では Kubernetes の仕組みについては詳しく解説しません。そのため、Kubernetes になじみのない方は、この先の「Pod を起動する」という表現については「コンテナを起動する」というイメージで捉えていただければと思います。

コンテナ基盤のかかえていた課題を Kubernetes の利用によって解決できるとしても、その前提となる Kubernetes 基盤（Kubernetes クラスタ）自体の設計・導入・運用にも課題があります。たとえば、Linux OS やネットワークなど、さらに 土台となるインフラ技術要素を Kubernetes 基盤にあわせて適合させなくてはならない、Kubernetes のソフトウェア アップデート間隔が短い、といった構築・運用面での難しさがありました。

vSphere with Tanzu は、そういった「Kubernetes を利用するまでの課題」をカバーできるものであり、従来の vSphere 管理者のスキルで、Kubernetes 環境を用意できるように工夫されています。vSphere 7 から、vCenter Server には Kubernetes の制御プレーンを用意してリソースを管理する機能が、ESXi にはワーカーとしての機能が組み込まれました。

なお、vSphere with Tanzu は、実際には vSphere のみで完結するソリューションではなく、追加でNSX-T 3.0 を必要としており、本稿の執筆時点においては、製品体系（SKU）のうえでは VMware Cloud Foundation 4.0 が前提とされています。また、vSAN との親和性が高いソリューションではありますが、VMFS や NFS といった vSAN 以外のデータストアでも利用可能です。

※2021年3月29日 追記
なお、vSphere 7.0 Update 1以降では、NSX-T と VMware Cloud Foundationが必須ではなくなりました。本稿ではリリース当初の NSX-T 利用を前提としております。ちなみに NSX-T を利用しない場合は、NSX-T が担当していたネットワークの準備は手作業となり、ロードバランサ機能は代替として HAProxy（vSphere 7.0 Update 1 以降） もしくは NSX Advanced Load Balancer（vSphere 7.0 Update 2 以降）いずれかを利用します。

ここからは、vSphere Client の画面も交えながら、vSphere with Tanzu の実際を紹介していきます。

vSphere with Tanzu では、これまでも vSphere で構成していたクラスタを、Kubernetes ワークロードに対応した「スーパーバイザー クラスタ」に機能拡張します。これにより、vSphere のクラスタで DRS や vSphere HA を利用しながら、Kubernetes 基盤としても利用できるようになります。

スーパーバイザー クラスタは、vSphere 7 から追加された、「ワークロード管理」メニューから有効化できます。なお、スーパーバイザー クラスタでは、vSphere DRS、vSphere HA、そして NSX-T の利用を前提としており、これら要件を満たしていないと、有効化できない（設定のためのウィザードが進められない）ようになっています。

vSphere Client の「ワークロード管理」メニューでは、スーパーバイザー クラスタとなっている（「ワークロード管理」が有効化されている）様子を確認できます。

スーパーバイザー クラスタでは、Kubernetes の制御プレーンとなる Supervisor Control Plane VM（3台）が自動デプロイされ、ESXi がワーカーノードの役割をもちます。ESXi には、アップストリーム Kubernetes の「kubelet」にあたる「Spherelet（スフィアレット）」サービスが起動されます。

スーパーバイザー クラスタ では、あらたに「名前空間」オブジェクトを作成して、そこに Kubernetes ワークロードを展開できます。vSphere での「名前空間」は、そのまま Kubernetes の名前空間（Namespace リソース）として利用できます。

スーパーバイザー クラスタ では、じつは 2種類の Kubernetes 基盤で Pod を起動させることができます。

1つめは、スーパーバイザー クラスタで ESXi ネイティブな Pod を起動する方法で、これは「vSphere Pod」と呼ばれます。もうひとつは、「Tanzu Kubernetes クラスタ」という、スーパーバイザー クラスタ上に、さらに Kubernetes 基盤を用意して、そこで Pod を起動する方法です。これらは、vSphere Client からは下図のように見えます。

それでは、「vSphere Pod」と「Tanzu Kubernetes クラスタ」について、それぞれ紹介していきます。

ここからは、スーパーバイザー クラスタで起動される vSphere Pod について説明します。

スーパーバイザー クラスタの ESXi では、Kubernetes の Pod をネイティブに起動でき、これは「vSphere Pod」と呼ばれ、VMware 独自の「CRX」というコンテナ ランタイムが利用されています。VMware から vSphere with Tanzu の発表時に紹介された「物理マシンによる Kubernetes 基盤よりも性能向上が見られた」といったメリットや、vSphere Client での視認性向上が見込めるというのは、主にこの vSphere Pod を起動する方式にあたります。

vSphere Pod を vSphere Client のインベントリで確認すると、これまでの vSphere には存在しなかった Pod オブジェクトとして表示されています。この実体は「特殊な仮想マシン」であり、従来からある vSphere のリソース管理機能などが活用できます。そして、Pod などのリソースが vSphere Client でもひとつのアイコンとして表示されるので、vSphere 管理者にとっては Kubernetes ワークロードの把握がしやすくなるはずです。

ただし、Pod の作成・起動や削除については vSphere Client から実施することはできません。Pod をはじめとする vSphere での「名前空間」配下のオブジェクト管理には、Kubernetes のクライアント ツールとしておなじみの「kubectl」を利用することになります。

ほかにもセキュリティ強化のため、コンテナ ホストのデバイス操作をするような、特権モード（Privileged Mode）での Pod 起動が制限されていたりします。

vSphere with Tanzu での 2つめの Kubernetes は、「Tanzu Kubernetes クラスタ」です。

「Tanzu」とは、VMware によるクラウド ネイティブ アプリケーション関連の製品ポートフォリオです。VMware では Tanzu にかかわるソフトウェアなどを Github で公開しているので、リポジトリを眺めてみるとイメージがつかめるのではないでしょうか。具体的な商用製品としては、Kubernetes ディストリビューションである「Tanzu Kubernetes Grid」や、パブリック クラウドやオンプレミスを問わず多種の Kubernetes を集中管理する「Tanzu Mission Control」などが存在します。

このうち、Tanzu Kubernetes Grid （略称は TKG）という Kubernetes ディストリビューションを利用しているのが、vSphere with Tanzu の「Tanzu Kubernetes クラスタ」です。TKG は、vSphere とは独立している製品ですが、それが vSphere 7 のスーパーバイザー クラスタで利用しやすい形式として提供されています。

また、スーパーバイザー クラスタの Kubernetes が VMware 独自のものであることに対して、TKG をもとにしている Tanzu Kubernetes クラスタでは、オープンソース コミュニティで開発・メンテナンスされている「アップストリームの」Kubernetes が利用されています。つまり Tanzu Kubernetes クラスタは、典型的な Kubernetes のクラスタを、VMware による仮想化基盤で利用しやすく提供している製品といえます。

Tanzu Kubernetes クラスタは、先にご紹介した vSphere Pod と同様、vSphere の「名前空間」のうえに作成されます。vSphere Pod が ESXi をワーカー ノードとして起動されるのに対して、Tanzu Kubernetes クラスタでは、名前空間に仮想マシンを起動して、その上の Linux ゲスト OS で Kubernetes クラスタを作成します。そのため「ゲスト クラスタ」と呼ばれることもあります。なお、Kubernetes ノードとなる仮想マシンについては、VMware Photon OS をベースとした OVF テンプレートが用意されています。

ESXi がワーカーノードになる vSphere Pod とは異なり、vSphere Client からは、Tanzu Kubernetes クラスタのノードになる仮想マシンまでが視認できます。そして、そのなかで起動された Pod は一般的な仮想マシン上で起動するコンテナと同様であり、vSphere Client にアイコン表示されたりしません。

つまり、Tanzu Kubernetes クラスタは、Kubernetes 基盤としては「Linux 仮想マシンに、手作業でアップストリームの Kubernetes をインストールしてクラスタを構築」したものと同等です。そして、構築手順やアクセス制御設定などが、vSphere にあわせて簡略化されています。

もう少し具体的な話をすると、TKG では、Kubernetes クラスタのライフサイクルを（アプリケーション展開などと同様に） Kubernetes と同様の API で管理する「Cluster API」を利用しています。そのため、Kubernetes ノードとなる仮想マシンのデプロイやクラスタの構築を、コンテナの展開と同じように kubectl と YAML 形式のマニュフェストで実施します。

また、スーパーバイザー クラスタでの名前空間とあわせて、従来の vSphere Client での権限設定と同じアカウントで、Tanzu Kubernetes クラスタへのアクセス制御ができたりもします。

3.4. vSphere Pod と Tanzu Kubernetes クラスタ それぞれの用途は？

ここで、それぞれの Kubernetes 基盤の用途について考えてみます。

さきほどの「スーパーバイザー クラスタと Tanzu Kubernetes クラスタの関係」のイメージ図を再掲します。ここまでにご紹介したとおり、vSphere with Tanzu では、2種類の方式で Pod を起動できます。

• スーパーバイザー クラスタ の ESXi のうえで vSphere Pod を起動する。
• （スーパーバイザー クラスタ で管理されている）Tanzu Kubernetes クラスタのうえで従来どおりの Pod を起動する。

どちらの方式でも、OCI（Open Container Initiative）コンテナ イメージを Pod として起動できるので、これまで Linux で起動していた「Docker のコンテナ」のコンテナ イメージが、基本的にはそのまま利用できると捉えてください。

vSphere Pod と Tanzu Kubernetes クラスタには、それぞれ次のような特徴、用途があげられます。

まず、スーパーバイザー クラスタに直接 vSphere Pod を起動する方式では、Pod などのリソースが vSphere Client で可視化され、vSphere 管理者にとっては Kubernetes ワークロードを把握しやすいはずです。そのかわりアップストリーム Kubernetes と比較すると、セキュリティ上の制限があったり、Kubernetes API のバージョンが少し古かったりといった面もあります。

スーパーバイザー クラスタの用途は、単純に （Kubernetes の機能拡張を利用せずに） Pod を起動する、性能にシビアな Pod を起動する、といったケースが考えられます。また、Tanzu Kubernetes クラスタの管理クラスタ（Cluster API における Management Cluster）としての役割も担当します。

一方、Tanzu Kubernetes クラスタで Pod を起動する方式では、vSphere 管理者にとっては Kubernetes ノードまでしか可視化されない（ワーカーノードの中の Pod までは見えない）状態となります。そのかわりアップストリーム Kubernetes と Cluster API を利用するので、Kubernetes クラスタ自体の構成変更について自由度が高く、Kubernetes クラスタの頻繁な追加・削除・アップデートにも対応できます。つまり、スーパーバイザー クラスタでそのまま vSphere Pod を起動する方式よりも、Kubernetes 基盤に対する柔軟性があるといえます。

たとえば、新しいバージョンの Kubernetes を利用したい場合や、Helm でのアプリケーション管理、Custom Resource Definition（CRD）でクラスタに機能拡張する場合などには、Tanzu Kubernetes クラスタを利用できます。クラスタでの自由度が高いため、Kubernetes 活用の度合いが高いほど、こちらの方式が利用されることになるのではないかと考えられます。

ここからは、Kubernetes に関わるであろう利用者像をもとに、vSphere with Tanzu が、これまで vSphere を扱ってきたインフラ技術者にとってどのような影響があるかをご紹介します。

DevOps のような開発・運用チームでの協力体制のあるケースも考えられますが、ここでは Kubernetes 基盤の利用者を、以下の3つに分けてご説明します。

• アプリケーション開発者： 開発したアプリケーションのコンテナを、Kubernetes 基盤に展開します。Kubernetes リソース（Pod、ロードバランサなど）の操作には kubectl を利用します。
• Kubernetes クラスタの管理者： Kubernetes クラスタの構築やアップグレードを担当します。
• vSphere の管理者 ： これまで vCenter Server / ESXi / 仮想マシンなどを担当していた、インフラ技術者にあたります。（そして、vSphere に限らずネットワーク、サーバ、OS なども担当しているはずです）

Kubernetes 基盤を用意するにあたり、vSphere クラスタでの「ワークロード管理」の有効化でスーパーバイザー クラスタを用意したあとで、「名前空間」の作成、開発者へのアクセス権限の割り当て、リソース調整など実施します。そして、Kubernetes クラスタの管理者や、開発者に引き渡します。これらは、従来から仮想化インフラの管理で使用していた vSphere Client での設定作業をすることになります。

基盤構築において、当然ながら、従来どおり ESXi、vCenter Server、NSX-T のセットアップは必要です。しかし、アップストリーム Kubernetes をゼロから設計・構築するよりは技術的な難易度が下がります。

なお、NSX-T が Kubernetes と連携して自動的に Pod ネットワークやロードバランサを提供していますが、 その初期構築、障害対応、バージョンアップといったメンテナンスについては、ここでの例の利用者のうちでは vSphere 管理者が担当するはずです。

これまで、パブリック クラウドでの Kubernetes 基盤の準備と比較すると、オンプレミスで Kubernetes 基盤を提供することは、構築スキルや、ソフトウェア更新頻度などさまざまな面で難しいものです。たとえば、Linux にさまざまな設定をしたうえで kubeadm のようなブートストラップ（Kubernetes クラスタ作成）ツールを実行して・・・といった「ただ Kubernetes クラスタを作成する」手順にも、その前後に多くの検討事項や設計あります。

vSphere with Tanzu の仕組みにのることで、スーパーバイザー クラスタであれば「あらかじめ ESXi に組み込まれたもの」として、Tanzu Kubernetes クラスタであれば「Cluster API でメンテナンスを効率化したもの」として、vSphere に統合された Kubernetes 基盤を用意して、アプリケーション開発者に提供できるようになります。

そして、「たんにコンテナのアプリケーションを展開できればよい」といった場合には、vSphere Pod が利用できます。一方、開発環境や CI / CD パイプラインとして複数のKubernetes（しかも短命のもの）を用意したい、Kubernetes クラスタ自体に自由なカスタマイズをしたい（Helm によるアプリケーション管理や、CRD / Operator のインストールなど）、といった場合には、Tanzu Kubernetes クラスタが利用できます。

ほかの Kubernetes 基盤にはない要素として NSX-T の技術習得を懸念されることがありますが、Kubernetes クラスタの管理者やアプリケーション開発者にとっては、NSX-T の操作は必須ではありません。これは、Kubernetes クラスタの作成や、アプリケーションの展開（のマニュフェスト）にあわせて、NSX-T によるネットワーク設定が自動反映されるためです。

vSphere with Tanzu は、現状では「Pod の起動を GUI 化」するようなソリューションではないため、アプリケーション開発者による Pod 起動など Kubernetes でのワークロード展開には、これまでどおりの方法で Kubernetes API を利用することになります。たとえば、ここまでに例示したように、スーパーバイザー クラスタ上の Kubernetes リソース（たとえば vSphere Pod）の管理と、Tanzu Kubernetes クラスタ上のリソース管理では、どちらも kubectl を利用します。

つまりアプリケーション開発者は、ひきつづき YAML によるマニフェストの書き方や kubectl 操作方法を理解する必要があります。しかしこれは、以前からパブリック クラウドなどの Kubernetes 基盤に Pod を展開してきたアプリケーション開発者にとっては、vSphere with Tanzu のために、新たなツールの利用方法を習得する必要がないということです。

なお、kubectl については vSphere 専用のプラグインが用意されています。スーパーバイザー クラスタ制御プレーンの IP アドレス宛に「kubectl vsphere login」といったコマンドが実行できるようになっていますが、それ以外は一般的な kubectl と変わりません。kubectl vsphere login のログインでは vSphere Client で（vSphere 管理者が）権限付与したアカウントを利用するため、Active Directory や LDAP といった、従来の vSphere Client ログインで使用していた ID ソースも利用できるはずです。（ただ、この vSphere Client での権限設定は vSphere 管理者が担当することになります。）

vSphere をあつかってきたインフラ技術者にとって、vSphere with Tanzu によって Kubernetes 環境構築を身近なものに、そして Kubernetes を利用してきたアプリケーション寄りの技術者にとっては、これまでのツールで操作ができます。アプリケーション展開作業には、これまでどおり kubectl のような Kubernetes ならではのツールが必要になりますが、特にオンプレミスへの Kubernetes 基盤導入のハードルを下げられるはずです。

最近では、メーカーやコミュニティが提供するソフトウェア パッケージが、コンテナイメージや、Kubernetes で展開することを前提とした形式で提供されるケースもみられるようになりました。また、Tanzu Kubernetes Grid（TKG）のノードが利用例であるように、コンテナだけでなく vSphere の仮想マシンについても Kubernetes で管理できるようになっていきます。もともと Kubernetes は、Google のような分散システムにむけて開発されていましたが、今後は企業インフラにおいても本番・開発・検証などの環境を問わず Kubernetes 基盤へのアプリケーション展開が必要となる状況も増えていくと考えられます。そういったケースでも、vSphere with Tanzu が活用できるのではないでしょうか。

【補足として】
本稿ではふれませんでしたが、vSphere with Tanzu には、NSX-T によるロードバランサ機能（Service / Ingress / NetworkPolicy）、クラウド ネイティブ ストレージによるストレージ永続化、Harbor によるコンテナ レジストリなど、さまざまな機能が組み込まれており、自社導入やお客様への提案において機能検証が重要になると考えられます。

【参考情報】

• Introducing vSphere 7: Modern Applications & Kubernetes
  https://blogs.vmware.com/vsphere/2020/03/vsphere-7-kubernetes-tanzu.html
• How to Get vSphere with Kubernetes
  https://blogs.vmware.com/vsphere/2020/04/how-to-get-vsphere-with-kubernetes.html
• vSphere 7 - Introduction to Kubernetes Namespaces
  https://blogs.vmware.com/vsphere/2020/04/vsphere-7-kubernetes-namespaces.html
• vSphere 7 - vSphere Pods Explained
  https://blogs.vmware.com/vsphere/2020/05/vsphere-7-vsphere-pods-explained.html
• vSphere 7 - Introduction to Tanzu Kubernetes Grid Clusters
  https://blogs.vmware.com/vsphere/2020/03/vsphere-7-tanzu-kubernetes-clusters.html
• 製品ドキュメント： vSphere with Kubernetesの設定と管理
  日本語 https://docs.vmware.com/jp/VMware-vSphere/7.0/vmware-vsphere-with-kubernetes/GUID-152BE7D2-E227-4DAA-B527-557B564D9718.html
  英語 https://docs.vmware.com/en/VMware-vSphere/7.0/vmware-vsphere-with-kubernetes/GUID-152BE7D2-E227-4DAA-B527-557B564D9718.html