このドキュメントでは、VMRuntime カスタム リソースを更新するか、bmctl コマンドを実行して、Google Distributed Cloud で VM ランタイムを有効または無効にする方法について説明します。
準備
GDC 上の VM ランタイムを有効または無効にするには、次のリソースとツールへのアクセス権限が必要です。
- GKE on Bare Metal バージョン 1.12.0（
anthosBareMetalVersion: 1.12.0）以降のクラスタへのアクセス権。ワークロードを実行可能な、どのクラスタタイプでも使用できます。必要に応じて、Compute Engine の GKE on Bare Metal を試すか、クラスタ作成の概要をご覧ください。 bmctlコマンドライン ツール 詳細については、bmctlツールをダウンロードしてインストールするをご覧ください。
GDC 上の VM ランタイムを有効にする
GDC 上の VM ランタイムは、GKE on Bare Metal バージョン 1.10 以降では自動的にインストールされますが、デフォルトでは無効になっています。GKE on Bare Metal で VM リソースを実行するには、その前に GDC 上の VM ランタイムを有効にする必要があります。
bmctl
ランタイムを有効にするには、
bmctlツールを使用します。bmctl enable vmruntime --kubeconfig KUBECONFIG_PATHクラスタの kubeconfig ファイルへのパスを指定します。GKE on Bare Metal は、クラスタの作成時に管理ワークステーションに kubeconfig ファイルを生成します。デフォルトでは、パスは
bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfigです。GDC 上の VM ランタイムがすでに有効になっている場合、このコマンドはエラーを返します。
エミュレーションやイメージ形式などの追加設定は、VMRuntime カスタム リソースを編集することで構成できます。
カスタム リソース
ランタイムを有効にするには、VMRuntime カスタム リソースを更新します。このカスタム リソースはデフォルトでインストールされます。
VMRuntimeカスタム リソースを編集します。kubectl edit vmruntime仕様に
enabled:trueを設定します。apiVersion: vm.cluster.gke.io/v1 kind: VMRuntime metadata: name: vmruntime spec: enabled: true # useEmulation defaults to "false" if not set. useEmulation: true # vmImageFormat defaults to "qcow2" if not set. vmImageFormat: qcow2前述の
specセクションでは、次の値を設定できます。enabled: true に設定して GDC 上の VM ランタイムを有効にするuseEmulation: ノードがハードウェア仮想化をサポートしていない場合や、それが不明な場合は、値を true に設定します。使用可能な場合、ハードウェア仮想化は、ソフトウェア エミュレーションよりもパフォーマンスが優れています。指定しない場合、useEmulationフィールドはデフォルトでfalseになります。vmImageFormat:rawとqcow2の 2 つのディスク イメージ形式値をサポートします。vmImageFormatを設定しない場合、GDC 上の VM ランタイムはrawディスク イメージ形式を使用して VM を作成します。raw形式によって、書き込み形式のコピーであるqcow2よりもパフォーマンスが向上しますが、より多くのディスクを使用する場合があります。VM のイメージ形式の詳細については、QEMU ドキュメントのディスク イメージのファイル形式をご覧ください。
カスタム リソースをエディタに保存します。
VMRuntimeカスタム リソースが有効であることを確認します。kubectl describe vmruntime vmruntimeVMRuntimeカスタム リソースの詳細には、Statusセクションが含まれています。VMRuntime.Status.Readyがtrueとして表示されていれば、GDC 上の VM ランタイムが有効になり、機能します。
GDC 上の VM ランタイムを無効にする
GDC 上の VM ランタイムを使用する必要がなくなった場合は、この機能を無効にできます。
bmctl
ランタイムを無効にするには、
bmctlツールを使用します。bmctl disable vmruntime --kubeconfig KUBECONFIG_PATH \ --force=trueクラスタの kubeconfig ファイルへのパスと次の構成オプションの値を指定します。
--force:trueに設定して、既存の VM リソースを削除することを確定します。デフォルト値はfalseです。
カスタム リソース
ランタイムを無効にするには、VMRuntime カスタム リソースを更新します。
VMRuntimeカスタム リソースを編集します。kubectl edit vmruntime仕様に
enabled:falseを設定します。apiVersion: vm.cluster.gke.io/v1` kind: VMRuntime metadata: name: vmruntime spec: enabled: false useEmulation: true vmImageFormat: qcow2更新したカスタム リソース仕様をエディタに保存します。
VMRuntimeカスタム リソースが無効になっていることを確認するには、vm-system名前空間で実行されている Pod を表示します。kubectl get pods --namespace vm-systemvmruntime-controller-managerDeployment に属する Pod のみが名前空間で実行されている場合、GDC 上の VM ランタイムが無効になります。
VM の実行の動作について理解する
baremetal.cluster.gke.io/vmrumtime-force-disable アノテーションを GDC 上の VM ランタイム リソースで使用すると、クラスタ内で VM が実行されている間にランタイムが無効になっている場合の動作を定義できます。
次の例は、このアノテーションの値がデフォルトで false に設定されていることを示しています。
// VM runtime yaml file
apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
annotations:
baremetal.cluster.gke.io/vmrumtime-force-disable: "false"
name: vmruntime
[...]
このアノテーションが false に設定されている場合、GDC 上の VM ランタイムは実行中の VM の保護を試みます。GDC 上の VM ランタイムを無効にする前に、実行中のすべての VM を削除するか、前のセクションで示すように bmctl disable vmruntime コマンドで --force=true パラメータを指定します。
次の表は、このアノテーションが true または false に設定されているときに、--force=true パラメータを指定している場合としていない場合に、実行中の VM に何が起こるかを示しています。
| Cluster State | --force parameter | vmrumtime-force-disable アノテーション | 動作 |
|---|---|---|---|
| VM はありません | なし | なし | GDC 上の VM ランタイムを無効にします。 |
| 既存の VM | 正しい | 正しい | 実行中のすべての VM と関連リソースを削除します。GDC 上の VM ランタイムを無効にします。 |
| 正しい | 誤り | 実行中のすべての VM と関連リソースを削除します。GDC 上の VM ランタイムを無効にします。 | |
| 誤り | 正しい | 実行中の VM と関連リソースの削除を求めます。実行中の VM をすべて削除したら、GDC 上の VM ランタイムを無効にします。 | |
| 誤り | 誤り | 実行中のいかなる既存の VM も削除しないでください。GDC 上の VM ランタイムを無効にしないでください。bmctl コマンドは、エラーを返します。 |
GDC 上の VM ランタイムのプリフライト チェック
GDC 上の VM ランタイムのプリフライト チェックは、GDC と VM で VM ランタイムを使用する前に、マシンの環境で一連の前提条件を検証します。GDC 上の VM ランタイムのプリフライト チェックが失敗すると、VM の作成はブロックされます。spec.enabled が true に設定されている場合、GDC 上の VM ランタイムのプリフライト チェックは自動的に実行されます。
kubectl label nodes NODE_NAME "kubevm.io/VM-SkipSchedule"= --kubeconfig KUBECONFIG_PATH
GDC 上の VM ランタイムのプリフライト チェックは、次のいずれかの操作を行うと実行されます。
GDC 上の VM ランタイムを有効にする
useEulation など、GDC 上の VM ランタイムの機能を有効にする
クラスタをアップグレードする
ノードで
kubevm.io/VM-SkipScheduleラベルを削除するbmctl check vmruntimepfc --kubeconfig KUBECONFIG_PATHコマンドを実行するか、VMRuntimePreflightCheckYAML マニフェストを適用することで、GDC 上の VM ランタイムのプリフライト チェック オブジェクトを個別に作成します。
GDC 上の VM ランタイムの最後のプリフライト チェックが正常に完了したら、VM を起動できます。プリフライト チェックに失敗した場合、VM の作成はブロックされ、プリフライト チェックのエラーが発生します。
プリフライト チェックが成功したことの確認
プリフライト チェックが成功したかどうかを確認するには、次のコマンドを実行します。
最後に実行されたプリフライト チェックを確認します。
kubectl get vmruntimepfc -n vm-system --kubeconfig KUBECONFIG_PATH出力は次のサンプルようになります。
NAME PASS AGE vmruntime-preflight-check-6ee61513-ea5d-4340-9374-90396cac129e false 42s vmruntime-preflight-check-f8d71751-a01c-471e-bab5-3370fc2addd5 true 21sプリフライト チェックのステータスを確認するには、次のコマンドを実行します。
kubectl get vmruntime vmruntime -o yaml --kubeconfig KUBECONFIG_PATH... preflightCheckSummary: preflightCheckSummary: featureStatuses: CPU: passed: true KVM: passed: true preflightCheckName: vmruntime-preflight-check-f8d71751-a01c-471e-bab5-3370fc2addd5 preflightCheckPassed: true ...
プリフライト チェックの失敗をデバッグする
プリフライト チェックに失敗した場合は、次の手順でデバッグします。
最後に実行されたプリフライト チェックを探します。
kubectl get vmruntimepfc -n vm-systemプリフライト チェックのステータスで詳細を確認します。
kubectl get vmruntimepfc -n vm-system \ vmruntime-preflight-check-6ee61513-ea5d-4340-9374-90396cac129e -o yaml \ --kubeconfig KUBECONFIG_PATH... status: checks: worker-0--52229ee15841099-22c41577139a7b8c.lab.anthos: passed: false results: - checkName: CPU passed: true - checkName: KVM message: | command terminated with exit code 1 ls: /mnt/dev/kvm: No such file or directory passed: false ...問題を修正し、GDC 上の VM ランタイムのプリフライト チェックを再度実行します。VMRuntimePreflightCheck YAML マニフェストの例を次に示します。
apiVersion: vm.cluster.gke.io/v1 kind: VMRuntimePreflightCheck metadata: name: vmruntime-preflight-check-manual namespace: vm-system