SB C&Sの最新技術情報 発信サイト

C&S ENGINEER VOICE

vSphere 7 の新機能「vSphere with Kubernetes」とは?

仮想化
2020.06.30

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

はじめに

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」に一本化されたり、といった刷新もされています。

vsk8s-01.PNG

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

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

vSphere with Kubernetes とは

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

Kubernetes とは

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

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

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

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

vsk8s-02.PNG

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

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

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 を必要としており、本稿の執筆時点においては、製品体系(SKU)のうえでは VMware Cloud Foundation 4.0 が前提とされています。また、vSAN との親和性が高いソリューションではありますが、VMFS や NFS といった vSAN 以外のデータストアでも利用可能です。

Supervisor Cluster による「ワークロード管理」

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

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 の利用を前提としており、この要件を満たしていないと、有効化できない(設定のためのウィザードが開けない)ようになっています。

vSphere Client の「ワークロード管理」メニューでは、Supervisor Cluster となっている(「ワークロード管理」が有効化されている)様子を確認できます。

vsk8s-03.PNG

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

vsk8s-04.PNG

Supervisor Cluster では、あらたに「名前空間」オブジェクトを作成して、そこに Kubernetes ワークロードを展開できます。vSphere での「名前空間」は、そのまま Kubernetes の名前空間(Namespace リソース)として利用できます。

vsk8s-05.PNG

Supervisor Cluster では、じつは 2種類の Kubernetes 基盤で Pod を起動させることができます。

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

vsk8s-06.PNG

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

vSphere Pod とは

ここからは、Supervisor Cluster で起動される 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」を利用することになります。

vsk8s-07.PNG

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

Tanzu Kubernetes Cluster とは

vSphere with Kubernetes での 2つめの Kubernetes は、「Tanzu Kubernetes Cluster」です。

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

このうち、Tanzu Kubernetes Grid (略称は TKG)という Kubernetes ディストリビューションを利用しているのが、vSphere with Kubernetes の「Tanzu Kubernetes Cluster」です。TKG は、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 にあわせて簡略化されています。

vsk8s-08.PNG

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

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

vsk8s-09.PNG

vSphere Pod と Tanzu Kubernetes Cluster それぞれの用途は?

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

さきほどの「Supervisor Cluster と 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 のコンテナ」のコンテナ イメージが、基本的にはそのまま利用できると捉えてください。

vsk8s-06.PNG

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 活用の度合いが高いほど、こちらの方式が利用されることになるのではないかと考えられます。

利用者にとっての vSphere with Kubernetes

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

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

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

vsk8s-10.PNG

vSphere 管理者にとって

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

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

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

Kubernetes クラスタの管理者にとって

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

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

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

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

アプリケーション開発者にとって

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

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

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

おわりに

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

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

【補足として】
本稿ではふれませんでしたが、vSphere with Kubernetes には、NSX-T によるロードバランサ機能(Service / Ingress / NetworkPolicy)、クラウド ネイティブ ストレージによるストレージ永続化、Harbor によるコンテナ レジストリなど、さまざまな機能が組み込まれており、自社導入やお客様への提案において機能検証が重要になると考えられます。今後、弊社でも PoC 検証にむけた環境構築手順などの公開を予定しています。

【参考情報】

関連資料はこちら

著者紹介

SB C&S株式会社
ICT事業本部 販売推進・技術本部 技術統括部 第1技術部 1課
渡辺 剛 - Go Watanabe -

VMware vExpert