vSphere IaaS control plane を使用すると、vSphere を、Kubernetes ワークロードをハイパーバイザー レイヤーでネイティブに実行するためのプラットフォームに変換できます。vSphere クラスタで vSphere IaaS control plane を有効にすると、Kubernetes ワークロードを ESXi ホストで直接実行し、専用の名前空間(vSphere 名前空間)内にアップストリーム Kubernetes クラスタを作成する機能が提供されます。

現在のアプリケーション スタックについての課題

現在の分散システムは、一般に多数の Kubernetes ポッドと仮想マシンを実行する複数のマイクロサービスから構成されています。vSphere IaaS control plane に基づかない典型的なスタックは、各仮想マシン内に Kubernetes インフラストラクチャがデプロイされた基盤となる仮想環境と、これらの仮想マシンでそれぞれ実行される Kubernetes ポッドで構成されます。スタックの各部分は、アプリケーション開発者、Kubernetes クラスタ管理者、および vSphere 管理者の 3 種類のロールによって操作されます。

図 1. 現在のアプリケーション スタック
3 つのレイヤー(Kubernetes ワークロード、Kubernetes クラスタ、仮想環境)で構成されるスタック。3 つのロール(開発者、クラスタ管理者、vSphere 管理者)によって管理されます。
各ロールは、互いの環境を可視化または制御できません。
  • アプリケーション開発者は、Kubernetes ポッドの実行と、Kubernetes ベースのアプリケーションのデプロイおよび管理を行うことができます。数百のアプリケーションを実行しているスタック全体は可視化できません。
  • DevOps エンジニアまたはクラスタ管理者は、Kubernetes インフラストラクチャのみを制御することができます。仮想環境を管理または監視することや、リソース関連の問題やその他の問題を解決することはできません。
  • vSphere 管理者は、基盤となる仮想環境を完全に制御できますが、Kubernetes インフラストラクチャ、仮想環境内でのさまざまな Kubernetes オブジェクトの配置、およびそれらのオブジェクトによるリソースの使用を可視化することはできません。

3 つのすべてのロール間の通信が必要になるため、スタック全体の操作は困難になる可能性があります。また、スタックの異なるレイヤーが統合されていないことが問題となる場合もあります。たとえば、Kubernetes スケジューラには vCenter Server インベントリに対する可視性がないため、ポッドをインテリジェントに配置することができません。

vSphere IaaS control plane を使用するメリット

vSphere IaaS control plane は、Kubernetes 制御プレーンをハイパーバイザー レイヤーに直接作成します。vSphere 管理者は、既存の vSphere クラスタで vSphere IaaS control plane を有効にし、このクラスタに含まれている ESXi ホスト内に Kubernetes レイヤーを作成します。vSphere IaaS control plane に対して有効になっている vSphere クラスタは、スーパーバイザー と呼ばれます。

図 2. vSphere IaaS control plane

上部はワークロードを含む IaaS プラットフォーム スタック、下部は仮想環境スタックです。2 つのロール(開発者と vSphere 管理者)によって管理されます。
ハイパーバイザー レイヤーに Kubernetes 制御プレーンがあると、vSphere で次の機能が実現します。
  • vSphere 管理者は、vSphere 名前空間 という スーパーバイザー 上の名前空間を作成し、指定された容量のメモリ、CPU、ストレージを使用して名前空間を構成することができます。構成した vSphere 名前空間 は、DevOps エンジニアに提供します。
  • DevOps エンジニアは、同じプラットフォームの Kubernetes ワークロードを、vSphere 名前空間 内の共有リソース プールで実行できます。Tanzu Kubernetes Grid を使用して作成された複数のアップストリーム Kubernetes クラスタをデプロイおよび管理できます。Kubernetes コンテナは、vSphere ポッド と呼ばれる特別なタイプの仮想マシン内の スーパーバイザー に直接デプロイすることもできます。通常の仮想マシンをデプロイすることもできます。
  • vSphere 管理者は、vSphere Client を使用して、vSphere ポッド、仮想マシン、および Tanzu Kubernetes Grid クラスタを管理および監視できます。
  • vSphere 管理者は、異なる名前空間内で実行されている vSphere ポッド、仮想マシン、Tanzu Kubernetes Grid クラスタ、環境内でのそれらの配置、およびそれらのオブジェクトによるリソースの使用方法を完全に可視化できます。

ハイパーバイザー レイヤーで Kubernetes を実行していると、vSphere 管理者と DevOps チームの両方のロールが同じオブジェクトを操作するため、共同作業も容易になります。

ワークロードについて

vSphere IaaS control plane では、ワークロードとは次のいずれかの方法でデプロイされたアプリケーションを指します。

  • vSphere ポッド 内で実行されているコンテナで構成されるアプリケーション。
  • 仮想マシン サービスを介してプロビジョニングされるワークロード。
  • Tanzu Kubernetes Grid を使用してデプロイされた Tanzu Kubernetes Grid クラスタ。
  • Tanzu Kubernetes Grid クラスタ内で実行されるアプリケーション。

vSphere Zone とは

vSphere Zone は、vSphere IaaS control plane にデプロイされたワークロードのクラスタレベルの障害に対し、高可用性を提供します。vSphere 管理者は、vSphere Client に vSphere Zone を作成してから、vSphere クラスタをゾーンにマッピングします。ゾーンを使用して、vSphere IaaS control plane 環境に スーパーバイザー をデプロイします。

クラスタレベルの高可用性を実現するために、スーパーバイザー を 3 つの vSphere Zone にデプロイできます。または、スーパーバイザー を単一の vSphere クラスタにデプロイすることもできます。これにより、vSphere Zone が自動的に作成され、クラスタにマッピングされます。すでにゾーンにマッピングされているクラスタを使用することもできます。詳細については、『スーパーバイザー アーキテクチャ』および『スーパーバイザー ゾーンおよびクラスタのデプロイ』を参照してください。

Tanzu Kubernetes Grid クラスタについて

Tanzu Kubernetes Grid クラスタは、VMware によってビルド、署名、およびサポートされている Kubernetes の完全なディストリビューションです。Tanzu Kubernetes Grid を使用することで、アップストリーム Tanzu Kubernetes Grid クラスタを スーパーバイザー 上にプロビジョニングして運用することができます。

Tanzu Kubernetes Grid によってプロビジョニングされる Tanzu Kubernetes Grid クラスタには、次の特性があります。
TKG クラスタの特性(左側から右に向かって)- 個人用、緊密な統合、本番環境に対応、完全サポート、Kubernetes による管理。
  • Kubernetes の個人用インストール。Tanzu Kubernetes Grid では、vSphere で Tanzu Kubernetes Grid クラスタをプロビジョニングするために十分に考慮され、最適化されたデフォルト値が提供されています。Tanzu Kubernetes Grid を使用することで、通常エンタープライズ レベルの Kubernetes クラスタをデプロイおよび実行する際に必要になる時間と労力の削減が可能になります。
  • vSphere インフラストラクチャとの統合。Tanzu Kubernetes Grid クラスタは、ストレージ、ネットワーク、認証などを含めて、vSphere Software-Defined Data Center (SDDC) スタックと緊密に統合されています。また、Tanzu Kubernetes Grid クラスタは、vSphere クラスタにマッピングされる スーパーバイザー 上に構築されます。緊密に統合されているため、他の製品と同様な操作方法で Tanzu Kubernetes Grid クラスタを実行することができます。
  • 本番環境に対応。Tanzu Kubernetes Grid は、本番環境に対応した Tanzu Kubernetes Grid クラスタをプロビジョニングします。追加の設定を行う必要なく、本番環境のワークロードを実行できます。また、可用性を確保し、Kubernetes ソフトウェアのローリング アップグレードを可能にし、異なるバージョンの Kubernetes を別々のクラスタで実行することもできます。
  • Kubernetes ワークロードの高可用性。3 つの vSphere Zone で構成される スーパーバイザー にデプロイされた Tanzu Kubernetes Grid クラスタは、vSphere クラスタ レベルの障害から保護されます。Tanzu Kubernetes Grid クラスタのワークロードと制御プレーン ノードは 3 つすべての vSphere Zone に分散されるため、その中で実行されている Kubernetes ワークロードの高可用性が確保されます。1 ゾーンの スーパーバイザー で実行されている Tanzu Kubernetes Grid クラスタは、vSphere HA を介して ESXi ホスト レベルの障害から保護されます。
  • VMware による完全サポート。Tanzu Kubernetes Grid クラスタは、VMware が提供するオープンソースの Linux ベースを使用し、vSphere インフラストラクチャにデプロイされ、ESXi ホストで実行されます。ハイパーバイザーから Kubernetes クラスタに至るまで、スタックのどのレイヤーでも問題が発生した場合は、VMware がお客様のお問い合わせ先となります。
  • Kubernetes による管理。Tanzu Kubernetes Grid クラスタは、Kubernetes クラスタである スーパーバイザー 上に構築されています。Tanzu Kubernetes Grid は、カスタム リソースを使用して vSphere 名前空間 で定義されます。Tanzu Kubernetes Grid クラスタをセルフサービスでプロビジョニングするには、使い慣れた kubectl コマンドと Tanzu CLI を使用します。ツールチェーン全体に整合性があるため、クラスタをプロビジョニングする場合でも、またはワークロードをデプロイする場合でも、同じコマンド、使い慣れた YAML、共通のワークフローを使用できます。

詳細については、Tanzu Kubernetes Grid のアーキテクチャとコンポーネントおよび『vSphere IaaS 制御プレーンでの TKG サービスの使用』を参照してください。

vSphere ポッド について

vSphere IaaS control plane では、Kubernetes ポッドに相当する vSphere ポッド と呼ばれる構造が導入されています。vSphere ポッド は、1 つ以上の Linux コンテナを実行する占有量の小さい仮想マシンです。各 vSphere ポッド は、格納するワークロードに応じて正確にサイズ調整され、そのワークロードに対して明示的なリソース予約を保持します。これにより、ワークロードの実行に必要な量のストレージ、メモリ、および CPU リソースが正確に割り当てられます。vSphere ポッド は、ネットワーク スタックとして NSX を使用して構成された スーパーバイザー でのみサポートされます。

図 3. vSphere ポッド
2 つの vSphere Pod ボックスを含む ESXi ホスト。各 vSphere Pod の内部ではコンテナが実行されており、Linux カーネル、メモリ、CPU、およびストレージ リソースがあります。
vSphere ポッドvCenter Server 内のオブジェクトであり、ワークロードに対して次の機能を実現します。
  • 高レベルの隔離。vSphere ポッド は、仮想マシンと同じ方法で隔離されます。各 vSphere ポッド には、Photon OS で使用されるカーネルに基づく独自の Linux カーネルがあります。vSphere ポッド では、ベアメタル構成と異なり、多くのコンテナでカーネルを共有することはありません。コンテナごとに一意の Linux カーネルがあります
  • リソース管理。vSphere DRS により、スーパーバイザー 上の vSphere ポッド の配置が処理されます。
  • 高パフォーマンス。vSphere ポッド では、仮想マシンと同じレベルのリソース隔離が実現するため、高速な起動時間と、コンテナの低オーバーヘッドを維持しながら、ノイジー ネイバー問題を回避できます。
  • 診断。vSphere 管理者は、ワークロード上の vSphere で使用可能なすべての監視ツールおよびイントロスペクション ツールを使用できます。
vSphere ポッド は Open Container Initiative (OCI) と互換性があり、任意のオペレーティング システムのコンテナを実行できます(コンテナも OCI 互換の場合に限る)。
図 4. vSphere ポッド ネットワークおよびストレージ
内部にコンテナ、コンテナ エンジン、ポッド エンジンを含む vSphere Pod。この Pod は、コンテナ イメージ、ストレージ、NSX スイッチ、Spherelet、および hostd に接続します。

vSphere ポッド では、格納するオブジェクトに応じて、短期 VMDK、パーシステント ボリューム VMDK、およびコンテナ イメージ VMDK の 3 種類のストレージを使用します。vSphere 管理者は、スーパーバイザー レベルでコンテナ イメージ キャッシュと短期 VMDK を配置するためのストレージ ポリシーを構成します。vSphere 名前空間 レベルでは、パーシステント ボリュームを配置するためのストレージ ポリシーを構成します。vSphere IaaS control plane におけるストレージの要件と概念の詳細については、ワークロードのパーシステント ストレージを参照してください。

ネットワークについては、vSphere ポッドTanzu Kubernetes Grid クラスタの仮想マシンは、NSX によって提供されるトポロジを使用します。詳細については、スーパーバイザー ネットワークを参照してください。

Spherelet は、各ホストで作成される追加のプロセスです。このプロセスは、ESXi に対してネイティブに移植された kubelet であり、このプロセスによって ESXi ホストは Kubernetes クラスタのメンバーになることができます。

スーパーバイザーvSphere ポッド を使用する方法については、『vSphere IaaS 制御プレーンのサービスとワークロード』ドキュメントのvSphere ポッドへのワークロードのデプロイを参照してください。

vSphere IaaS control plane での仮想マシンの使用

vSphere IaaS control plane で提供されている仮想マシン サービス機能を使用すると、DevOps エンジニアは一般的な共有 Kubernetes 環境でコンテナに加え、仮想マシンをデプロイして実行することができます。コンテナと仮想マシンの両方が同じ vSphere 名前空間 リソースを共有するため、単一の vSphere IaaS control plane インターフェイスを通して管理することができます。

仮想マシン サービスは、Kubernetes を使用する DevOps チームのニーズに対応しますが、既存の仮想マシン ベースのワークロードには容易にコンテナ化できないものがあります。仮想マシン サービスを使用することで、コンテナ プラットフォームと一緒に Kubernetes 以外のプラットフォームを管理する場合のオーバーヘッドを削減することもできます。Kubernetes プラットフォーム上でコンテナと仮想マシンを実行する場合、DevOps チームはワークロードの占有量を 1 つのプラットフォームに統合できます。

注: 仮想マシン サービスは、スタンドアローン仮想マシンのほか、 Tanzu Kubernetes Grid クラスタを構成する仮想マシンも管理します。クラスタの詳細については、『 vSphere IaaS 制御プレーンでの TKG サービスの使用』ドキュメントを参照してください。
この図は、スタンドアローン仮想マシンと Tanzu Kubernetes Grid クラスタを構成する仮想マシンを管理する、スーパーバイザー コンポーネントとしての仮想マシン サービスを示しています。

仮想マシン サービスを使用してデプロイされた各仮想マシンは、vSphere IaaS control plane インフラストラクチャ上で、独自のオペレーティング システムを含むすべてのコンポーネントを実行する完全なマシンとして機能します。仮想マシンは、スーパーバイザー が提供するネットワークおよびストレージにアクセスすることができ、標準の Kubernetes コマンド kubectl を使用して管理されます。仮想マシンは完全に隔離されたシステムとして動作し、Kubernetes 環境内の他の仮想マシンまたはワークロードからの干渉を受けません。

Kubernetes プラットフォームで仮想マシンを使用する場合

一般に、コンテナと仮想マシンのどちらでワークロードを実行するかは、ビジネス ニーズおよび目標に応じて決まります。仮想マシンを使用する理由には、次のようなものがあります。

  • アプリケーションのコンテナ化ができません。
  • アプリケーションが、カスタム カーネルまたはカスタム オペレーティング システム用に設計されています。
  • アプリケーションが、仮想マシンで実行するのに適しています。
  • 一貫性のある Kubernetes 環境により、オーバーヘッドを回避することを検討しています。Kubernetes 以外のプラットフォームとコンテナ プラットフォームにインフラストラクチャ セットを個別に実行するのではなく、これらのスタックを統合し、使い慣れた kubectl コマンドを使用して管理することができます。

スーパーバイザー でのスタンドアローン仮想マシンのデプロイと管理については、『vSphere IaaS 制御プレーンのサービスとワークロード』ドキュメントの仮想マシンのデプロイと管理を参照してください。

vSphere IaaS control planeスーパーバイザー サービス

スーパーバイザー サービス は、Infrastructure-as-a-Service コンポーネントと緊密に統合された独立系ソフトウェア ベンダー サービスを開発者に提供する vSphere 認定の Kubernetes オペレータです。vSphere IaaS control plane 環境に スーパーバイザー サービス をインストールして管理し、Kubernetes ワークロードで使用可能にすることができます。スーパーバイザー サービススーパーバイザー にインストールされている場合、DevOps エンジニアはサービス API を使用して、ユーザー名前空間内の スーパーバイザー にインスタンスを作成できます。これらのインスタンスは、vSphere ポッド および Tanzu Kubernetes Grid クラスタで使用できます。

サポートされているスーパーバイザー サービスの詳細と、サービス YAML ファイルのダウンロード方法については、http://vmware.com/go/supervisor-serviceを参照してください。

スーパーバイザー サービスの使用方法については、『vSphere IaaS 制御プレーンのサービスとワークロード』ドキュメントの「スーパーバイザー サービスの管理」を参照してください。