このドキュメントでは、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 vmruntime
VMRuntime
カスタム リソースの詳細には、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-system
vmruntime-controller-manager
Deployment に属する 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
コマンドを実行するか、VMRuntimePreflightCheck
YAML マニフェストを適用することで、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