vSphere IaaS control plane で提供されている仮想マシン サービス機能を使用すると、DevOps エンジニアは一般的な共有 Kubernetes 環境でコンテナに加え、仮想マシンをデプロイして実行することができます。この仮想マシン サービスを使用して、名前空間内の仮想マシンのライフサイクルを管理できます。仮想マシン サービスは、スタンドアローン仮想マシンおよび Tanzu Kubernetes Grid クラスタを構成する仮想マシンを管理します。

仮想マシン サービスは、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 名前空間 にデプロイする仮想マシンの状態を記述するには、仮想マシン クラス、仮想マシン イメージ、ストレージ クラスなどのパラメータを使用します。仮想マシン サービスは、これらの仕様を組み合わせて、スタンドアローン仮想マシンまたは Tanzu Kubernetes Grid クラスタをサポートする仮想マシンを作成します。

仮想マシンの仕様で仮想マシン クラス、仮想マシン イメージ、およびストレージ クラスを組み合わせて、仮想マシンを作成します
VM サービス
仮想マシン サービスは、仮想マシンおよび関連する vSphere リソースを管理するための Kubernetes スタイルの宣言型 API を提供する vSphere IaaS control plane コンポーネントです。仮想マシン サービスを使用すると、vSphere 管理者はリソースを提供し、仮想マシン クラスや仮想マシン イメージなどのテンプレートを Kubernetes に提供できるようになります。DevOps エンジニアは、これらのリソースを使用して、仮想マシンに目標とする状態を記述できます。DevOps エンジニアが仮想マシンの状態を指定すると、仮想マシン サービスは目標とする状態を、バッキング インフラストラクチャ リソースに対して実現された状態に変換します。

仮想マシン サービスを介して作成された仮想マシンを管理するには、kubectl コマンドを使用して Kubernetes 名前空間から管理する必要があります。vSphere 管理者は、仮想マシンを vSphere Client から管理することはできませんが、詳細を表示し、仮想マシンで使用されるリソースを監視することはできます。詳細については、『vSphere IaaS control plane で利用可能な仮想マシンの監視』を参照してください。

VM クラス
仮想マシン クラスは、仮想マシンの一連のリソースの要求に使用可能な仮想マシンの仕様です。仮想マシン クラスは vSphere 管理者によって制御および管理され、仮想 CPU の数、メモリ容量、予約設定などのパラメータを定義します。定義されたパラメータは、 スーパーバイザー の基盤となるインフラストラクチャ リソースによってバッキングされて、保証されます。

vSphere 管理者はカスタムの仮想マシン クラスを作成できます。

また、ワークロード管理には、いくつかのデフォルトの仮想マシン クラスがあります。デフォルトのクラス タイプには、一般に、保証型とベスト エフォート型の 2 つのエディションがあります。保証型のエディションは、仮想マシンの仕様によって要求されるリソースを完全に予約します。ベスト エフォート型のクラス エディションは、リソースの予約を行いません。つまり、リソースのオーバーコミットが可能です。通常、保証型のタイプは本番環境で使用されます。

デフォルトの仮想マシン クラスの例を次に示します。

クラス CPU メモリ (GB) 予約済みの CPU とメモリ
guaranteed-large 4 16 はい
best-effort-large 4 16 なし
guaranteed-small 2 4 はい
best-effort-small 2 4 なし

vSphere 管理者は既存の仮想マシン クラスを任意の数だけ割り当てて、特定の名前空間内で DevOps エンジニアがこれらを使用できるようにします。

仮想マシン クラスを使用すると、DevOps エンジニアの操作環境は簡素化されます。DevOps は、エンジニアが作成する各仮想マシンの構成全体を認識する必要はありません。代わりに、使用可能なオプションから仮想マシン クラスを選択することができ、仮想マシン サービスは仮想マシン構成を管理するようになります。

Kubernetes 側では、仮想マシン クラスが VirtualMachineClass のリソースとして表示されます。

仮想マシン イメージ
仮想マシン イメージは、オペレーティング システム、アプリケーション、データなどのソフトウェア構成が含まれているテンプレートです。

DevOps エンジニアは仮想マシンを作成するときに、名前空間に関連付けられているコンテンツ ライブラリからイメージを選択できます。イメージは DevOps に VirtualMachineImage オブジェクトとして公開されます。

vSphere 管理者は、vSphere IaaS control plane と互換性のある仮想マシン イメージを作成し、コンテンツ ライブラリにアップロードできます。

コンテンツ ライブラリ
DevOps エンジニアは、仮想マシンを作成するためのイメージ ソースとしてコンテンツ ライブラリを使用します。vSphere 管理者は、仮想マシン クラスと同様に、既存のコンテンツ ライブラリを名前空間またはクラスタに割り当てて、DevOps エンジニアがこれらを使用できるようにします。vSphere 管理者は、名前空間のコンテンツ ライブラリを書き込み可能にすることもできます。この追加の権限があることで、DevOps ユーザーはイメージをライブラリに公開することができます。
ストレージ クラス
仮想マシン サービスはストレージ クラスを使用して仮想ディスクを配置し、パーシステント ボリュームを動的に接続します。ストレージ クラスの詳細については、 vSphere IaaS control plane の スーパーバイザー ワークロードでのパーシステント ストレージの使用を参照してください。
仮想マシンの仕様
DevOps エンジニアは、仮想マシン イメージ、仮想マシン クラス、およびストレージ クラスをまとめて記述する YAML ファイルで、仮想マシンの目標とする状態を記述します。
Kubernetes の仮想マシン オペレータ
仮想マシン オペレータでは、Kubernetes 形式の宣言型 API を使用して仮想マシンを管理できます。
vSphere 8.0 Update 3 リリース以降、 vSphere IaaS control plane では仮想マシン オペレータ v1alpha2 がサポートされます。その他のメリットとして、このバージョンには次の特徴があります。
  • インライン Cloud-Init および Windows のサポートを含むブートストラップ プロバイダのサポートを強化。
  • ゲスト ネットワーク構成の強化。
  • ステータス機能の強化。
  • ユーザー定義の準備ゲートのサポート。
  • 新しい VirtualMachineWebConsoleRequest API。

v1alpha2 に固有の新しい API の変更を除き、v1alpha2 の他のほとんどの API は v1alpha1 と同等に機能します。仮想マシン仕様のほとんどのフィールドは、v1alpha1 との下位互換性があります。

v1alpha2 のリリース後も、v1alpha1 オブジェクトを引き続き使用できます。すべての v1alpha1 オブジェクトは、仮想マシン オペレータに組み込まれた変換 Webhook を使用して v1alpha2 に自動的に変換されます。

仮想マシン オペレータ v1alpha2 とサポートされるフィールドについては、https://vm-operator.readthedocs.io/en/stable/ref/api/v1alpha2/ を参照してください。

ネットワーク
仮想マシン サービスには特定の要件が設定されていないため、 vSphere IaaS control plane で使用可能なネットワーク構成を利用します。仮想マシン サービスは、vSphere ネットワークと NSX の両方のタイプのネットワークをサポートします。仮想マシンが展開されると、使用可能なネットワーク プロバイダは仮想マシンに固定 IP アドレスを割り当てます。詳細については、『 vSphere IaaS 制御プレーンの概念と計画』ドキュメントの スーパーバイザー ネットワークの説明を参照してください。

vSphere ゾーンを使用した仮想マシン サービスと スーパーバイザー

3 つのゾーンの スーパーバイザー に仮想マシンを作成すると、仮想マシン インスタンスがすべての使用可能なゾーンに複製されます。YAML ファイルを使用して仮想マシンの配置を制御するために、DevOps チームは Kubernetes ラベル topology.kubernetes.io/zone を使用できます。たとえば、 topology.kubernetes.io/zone: zone-a02 です。

仮想マシンのプロビジョニングと監視のワークフロー

vSphere 管理者は仮想マシンのポリシーとガバナンスの保護を設定し、仮想マシン クラスや仮想マシン テンプレートなどの仮想マシン リソースを DevOps エンジニアに提供します。仮想マシンのデプロイ後は、vSphere Client を使用して仮想マシンを監視できます。

手順 実行者 説明
1 vSphere 管理者 コンテンツ ライブラリを作成し、名前空間または スーパーバイザー に割り当てます
2 vSphere 管理者 仮想マシン クラスを作成し、名前空間に割り当てます

NVIDIA vGPU を使用するには、仮想マシン クラスで PCI デバイスを構成します。vSphere IaaS control plane での vGPU および他の PCI デバイスを含む仮想マシンのデプロイを参照してください。
3 DevOp エンジニア Kubernetes 名前空間で仮想マシンをプロビジョニングします

Tanzu Kubernetes Grid クラスタの仮想マシンの場合は、vSphere IaaS 制御プレーンでの TKG サービスの使用を参照してください。
4 vSphere 管理者 デプロイされた仮想マシンを監視します
5 DevOps エンジニア 仮想マシン イメージをコンテンツ ライブラリに公開します