vSphere 7 が 2020年04月にリリースされている。
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 with Kubernetes とは
vSphere with Kubernetes とは、vCenter Server と ESXi による仮想化基盤上に、Kubernetes によるコンテナ技術のワークロードを稼働させるソリューション。
vSphere with Kubernetes とは
コンテナ基盤のかかえていた課題を Kubernetes の利用によって解決できるとしても、その前提となる Kubernetes 基盤自体（Kubernetes クラスタ）の設計・導入・運用にも課題がある。たとえば、Linux OS やネットワークなど、さらに 土台となるインフラ技術要素を Kubernetes 基盤にあわせて適合させなくてはならない、Kubernetes のソフトウェア アップデート間隔が短い、といった構築・運用面での困難があった。
vSphere with Kubernetes は、そういった、「Kubernetes を利用するまでの課題」をカバーできるものであり、従来の vSphere 管理者のスキルで、Kubernetes 環境を用意できるように工夫されているのが特徴。vSphere 7 から、vCenter Server には Kubernetes の制御プレーンを用意してリソースを管理する機能が、ESXi にはワーカーとしての機能が組み込まれまれている。
なお、vSphere with Kubernetes は、実際には vSphere のみで完結するソリューションではなく、追加でNSX-T 3.0 を必要としており、VMware Cloud Foundation 4.0 が前提とされている。また、vSAN との親和性が高いソリューションではあるが、VMFS や NFS といった vSAN 以外のデータストアでも利用可能となっている。これは、3rd Party製ストレージベンダーに配慮しているのか、それとも親会社の製品を無視できないのか・・・。
Supervisor Cluster による「ワークロード管理」
Supervisor Cluster とは
vSphere with Kubernetes では、これまでも vSphere で構成していたクラスタを、Kubernetes ワークロードに対応した「Supervisor Cluster」に機能拡張する。これにより、vSphere のクラスタで DRS や vSphere HA を利用しながら、Kubernetes 基盤としても利用できるようになる。
Supervisor Cluster は、vSphere 7 から追加された、「ワークロード管理」メニューから有効化可能。なお、Supervisor Cluster では、vSphere DRS、vSphere HA、そして NSX-T の利用を前提としており、この要件を満たしていないと、有効化できない（設定のためのウィザードが開けない）ようになっている。DRSは、システム管理が煩雑になるということで、忌避される方も多いと思うが、HAならオッケーだと思う。
Supervisor Cluster では、Kubernetes の制御プレーンとなる Supervisor Control Plane VM（3台）が自動デプロイされ、ESXi がワーカーノードの役割を持つ。ESXi には、アップストリーム Kubernetes の「kubelet」にあたる「Spherelet」サービスが起動されます。
Supervisor Cluster では、あらたに「名前空間」オブジェクトを作成して、そこに Kubernetes ワークロードを展開できます。vSphere での「名前空間」は、そのまま Kubernetes の名前空間（Namespace リソース）として利用可能。
Supervisor Cluster では、2種類の Kubernetes 基盤で Pod を起動させることが可能となっている。
1つめは Supervisor Cluster で ESXi ネイティブな Pod を起動する方法で、これは「vSphere Pod」と呼ばれる。もうひとつは、「Tanzu Kubernetes Cluster」という、Supervisor Cluster 上に、さらに Kubernetes 基盤を用意して、そこで Pod を起動する方法。
vSphere Pod とは
Supervisor Cluster の ESXi では、Kubernetes の Pod をネイティブに起動でき、これは「vSphere Pod」と呼ばれ、VMware 独自の「CRX」というコンテナ ランタイムが利用されている。VMware から vSphere with Kubernetes の発表時に紹介された「物理マシンによる Kubernetes 基盤よりも性能向上が見られた」といったメリットや、vSphere Client での視認性向上が見込めるというのは、主にこの vSphere Pod を起動する方式にあたる。
vSphere Pod を vSphere Client のインベントリで確認すると、これまでの vSphere には存在しなかった Pod オブジェクトとして表示されている。この実体は「特殊な仮想マシン」であり、従来からある vSphere のリソース管理機能などが活用可能。そして、Pod などのリソースが vSphere Client でもひとつのアイコンとして表示されるので、vSphere 管理者にとっては Kubernetes ワークロードの把握がしやすくなるはず。
ただし、Pod の作成・起動や削除については vSphere Client から実施することはできず、Pod をはじめとする vSphere での「名前空間」配下のオブジェクト管理には、Kubernetes のクライアント ツールとしておなじみの「kubectl」を利用することになる。
ほかにもセキュリティ強化のため、コンテナ ホストのデバイス操作をするような、特権モードでの Pod 起動が制限されていたりする。
Tanzu Kubernetes Cluster とは
vSphere with Kubernetes での 2つめの Kubernetes は、「Tanzu Kubernetes Cluster」です。
「Tanzu」とは、VMware によるクラウド ネイティブ アプリケーション関連の製品ポートフォリオです。VMware では Tanzu にかかわるソフトウェアなどを Github で公開しているので、リポジトリを眺めてみるとイメージがつかめると思う。おそらくは、以前のPivotal資産を継承しているのではないか。具体的な商用製品としては、Kubernetes ディストリビューションである「Tanzu Kubernetes Grid」や、パブリック クラウドやオンプレミスを問わず多種の Kubernetes を集中管理する「Tanzu Mission Control」などが存在している。
このうち、Tanzu Kubernetes Grid （略称は TKG）という Kubernetes ディストリビューションを利用しているのが、vSphere with Kubernetes の「Tanzu Kubernetes Cluster」で、vSphere とは独立している製品ですが、それが vSphere 7 の Supervisor Cluster で利用しやすい形式として提供されている。
また、Supervisor Cluster の Kubernetes が VMware 独自のものであることに対して、TKG をもとにしている Tanzu Kubernetes Cluster では、オープンソース コミュニティで開発・メンテナンスされている「アップストリームの」Kubernetes が利用されている。つまり Tanzu Kubernetes Cluster は、典型的な Kubernetes のクラスタを、VMware による仮想化基盤で利用しやすく提供している製品といえる。
Tanzu Kubernetes Cluster は、先にご紹介した vSphere Pod と同様、vSphere の「名前空間」のうえに作成される。vSphere Pod が ESXi をワーカー ノードとして起動されるのに対して、Tanzu Kubernetes Cluster では、名前空間に仮想マシンを起動して、その上の Linux ゲスト OS で Kubernetes クラスタを作成します。そのため「Guest Cluster」と呼ばれることもある。なお、Kubernetes ノードとなる仮想マシンについては、VMware Photon OS をベースとした OVF テンプレートが用意されている。
ESXi がワーカーノードになる vSphere Pod とは異なり、vSphere Client からは、Tanzu Kubernetes Cluster のノードになる仮想マシンまでが視認できる。そして、そのなかで起動された Pod は一般的な仮想マシン上で起動するコンテナと同様であり、vSphere Client にアイコン表示されない。
つまり、Tanzu Kubernetes Cluster は、Kubernetes 基盤としては「Linux 仮想マシンに、手作業でアップストリームの Kubernetes をインストールしてクラスタを構築」したものと同等。そして、構築手順やアクセス制御設定などが、vSphere にあわせて簡略化されている。
TKG では、Kubernetes クラスタのライフサイクルを（アプリケーション展開などと同様に） Kubernetes と同様の API で管理する「Cluster API」を利用しているため、Kubernetes ノードとなる仮想マシンのデプロイやクラスタの構築を、コンテナの展開と同じように kubectl と YAML 形式のマニュフェストで実施する。
また Supervisor Cluster での名前空間とあわせて、従来の vSphere Client での権限設定と同じアカウントで、Tanzu Kubernetes Cluster へのアクセス制御ができる。
vSphere Pod と Tanzu Kubernetes Cluster それぞれの用途は？
vSphere with Kubernetes では、2種類の方式で Pod を起動できる。
- Supervisor Cluster の ESXi のうえで vSphere Pod を起動する。
- （Supervisor Cluster で管理されている）Tanzu Kubernetes Cluster のうえで従来どおりの Pod を起動する。
どちらの方式でも、OCI（Open Container Initiative）コンテナ イメージを Pod として起動できるので、これまで Linux で起動していた「Docker のコンテナ」のコンテナ イメージが、基本的にはそのまま利用できる。
vSphere Pod と Tanzu Kubernetes Cluster には、それぞれ次のような特徴、用途があげられる。
まず、Supervisor Cluster に直接 vSphere Pod を起動する方式では、Pod などのリソースが vSphere Client で可視化され、vSphere 管理者にとっては Kubernetes ワークロードを把握しやすい。そのかわりアップストリーム Kubernetes と比較すると、セキュリティ上の制限があったり、Kubernetes API のバージョンが少し古かったりする。
Supervisor Cluster の用途は、 （Kubernetes の機能拡張を利用せずに） Pod を起動する、性能にシビアな Pod を起動する、といったケースが考えられる。また、Tanzu Kubernetes Cluster の管理クラスタ（Cluster API における Management Cluster）としての役割も担当する。
一方、Tanzu Kubernetes Cluster で Pod を起動する方式では、vSphere 管理者にとっては Kubernetes ノードまでしか可視化されない（ワーカーノードの中の Pod までは見えない）状態となる。そのかわりアップストリーム Kubernetes と Cluster API を利用するので、Kubernetes クラスタ自体の構成変更について自由度が高く、Kubernetes クラスタの頻繁な追加・削除・アップデートにも対応できる。つまり Supervisor Cluster でそのまま vSphere Pod を起動する方式よりも、Kubernetes 基盤に対する柔軟性がある。
たとえば、新しいバージョンの Kubernetes を利用したい場合や、Helm でのアプリケーション管理、Custom Resource Definition（CRD）によるクラスタへの機能拡張をする場合などには、Tanzu Kubernetes Cluster を利用できる。クラスタでの自由度が高いため、Kubernetes 活用の度合いが高いほど、こちらの方式が利用されることになるのではないかと考えられる。