このドキュメントでは、VMRuntime カスタム リソースを更新するか、bmctl コマンドを実行して、Google Distributed Cloud で VM ランタイムを有効または無効にする方法について説明します。
始める前に
GDC 上の VM ランタイムを有効または無効にするには、次のリソースとツールへのアクセス権限が必要です。
- Google Distributed Cloud バージョン 1.12.0（
anthosBareMetalVersion: 1.12.0）以降のクラスタへのアクセス権。ワークロードを実行可能な、どのクラスタタイプでも使用できます。必要に応じて、Compute Engine 上の Google Distributed Cloud を試すか、クラスタ作成の概要をご覧ください。 bmctlコマンドライン ツール。詳細については、bmctlツールをダウンロードしてインストールするをご覧ください。
GDC 上の VM ランタイムを有効にする
GDC 上の VM ランタイムは、Google Distributed Cloud バージョン 1.10 以降では自動的にインストールされますが、デフォルトでは無効になっています。Google Distributed Cloud で VM リソースを実行するには、その前に GDC 上の VM ランタイムを有効にする必要があります。
bmctl
ランタイムを有効にするには、
bmctlツールを使用します。bmctl enable vmruntime --kubeconfig KUBECONFIG_PATHクラスタの kubeconfig ファイルのパスを指定します。Google Distributed Cloud は、クラスタの作成時に管理ワークステーションに 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-systemNamespace で実行されている Pod を表示します。kubectl get pods --namespace vm-systemvmruntime-controller-managerDeployment に属する Pod のみが Namespace で実行されている場合、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 に何が起こるかを示しています。
| クラスタの状態 | --force パラメータ | vmrumtime-force-disable アノテーション | 動作 |
|---|---|---|---|
| VM はありません | なし | なし | GDC 上の VM ランタイムを無効にします。 |
| 既存の VM | True | True | 実行中のすべての VM と関連リソースを削除します。GDC 上の VM ランタイムを無効にします。 |
| True | False | 実行中のすべての VM と関連リソースを削除します。GDC 上の VM ランタイムを無効にします。 | |
| False | True | 実行中の VM と関連リソースの削除を求めます。実行中の VM をすべて削除したら、GDC 上の VM ランタイムを無効にします。 | |
| False | False | 実行中の既存の 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 ランタイムを有効にする
useEmulation など、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