11.4. 仮想マシンのヘルスチェック
VirtualMachine
リソースで readiness プローブと liveness プローブを定義することにより、仮想マシン (VM) のヘルスチェックを設定できます。
11.4.1. readiness および liveness プローブについて
readiness プローブと liveness プローブを使用して、異常な仮想マシン (VM) を検出および処理します。VM の仕様に 1 つ以上のプローブを含めて、準備ができていない VM にトラフィックが到達しないようにし、VM が応答しなくなったときに新しい VM が作成されるようにすることができます。
readiness プローブ は、VM がサービス要求を受け入れることができるかどうかを判断します。プローブが失敗すると、VM は、準備状態になるまで、利用可能なエンドポイントのリストから削除されます。
liveness プローブ は、VM が応答しているかどうかを判断します。プローブが失敗すると、VM は削除され、応答性を復元するために、新しい VM が作成されます。
VirtualMachine
オブジェクトの spec.readinessProbe
フィールドと spec.livenessProbe
フィールドを設定することで、readiness プローブと liveness プローブを設定できます。これらのフィールドは、以下のテストをサポートします。
- HTTP GET
- プローブは、Web フックを使用して VM の正常性を判断します。このテストは、HTTP の応答コードが 200 から 399 までの値の場合に正常と見なされます。完全に初期化されている場合に、HTTP ステータスコードを返すアプリケーションで HTTP GET テストを使用できます。
- TCP ソケット
- プローブは、VM へのソケットを開こうとします。プローブが接続を確立できる場合のみ、VM は正常であると見なされます。TCP ソケットテストは、初期化が完了するまでリスニングを開始しないアプリケーションで使用できます。
- ゲストエージェントの ping
-
プローブは、
guest-ping
コマンドを使用して、QEMU ゲストエージェントが仮想マシンで実行されているかどうかを判断します。
11.4.1.1. HTTP readiness プローブの定義
仮想マシン (VM) 設定の spec.readinessProbe.httpGet
フィールドを設定して、HTTP readiness プローブを定義します。
手順
VM 設定ファイルに readiness プローブの詳細を含めます。
HTTP GET テストを使用した readiness プローブの例
apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: annotations: name: fedora-vm namespace: example-namespace # ... spec: template: spec: readinessProbe: httpGet: 1 port: 1500 2 path: /healthz 3 httpHeaders: - name: Custom-Header value: Awesome initialDelaySeconds: 120 4 periodSeconds: 20 5 timeoutSeconds: 10 6 failureThreshold: 3 7 successThreshold: 3 8 # ...
- 1
- VM に接続するために実行する HTTP GET 要求。
- 2
- プローブがクエリーする VM のポート。上記の例では、プローブはポート 1500 をクエリーします。
- 3
- HTTP サーバーでアクセスするパス。上記の例では、サーバーの /healthz パスのハンドラーが成功コードを返した場合、VM は正常であると見なされます。ハンドラーが失敗コードを返した場合、VM は使用可能なエンドポイントのリストから削除されます。
- 4
- VM が起動してから準備プローブが開始されるまでの時間 (秒単位)。
- 5
- プローブの実行間の遅延 (秒単位)。デフォルトの遅延は 10 秒です。この値は
timeoutSeconds
よりも大きくなければなりません。 - 6
- プローブがタイムアウトになり、VM が失敗したと見なされるまでの非アクティブな秒数。デフォルト値は 1 です。この値は
periodSeconds
未満である必要があります。 - 7
- プローブが失敗できる回数。デフォルトは 3 です。指定された試行回数になると、Pod には
Unready
というマークが付けられます。 - 8
- 成功とみなされるまでにプローブが失敗後に成功を報告する必要のある回数。デフォルトでは 1 回です。
次のコマンドを実行して VM を作成します。
$ oc create -f <file_name>.yaml
11.4.1.2. TCP readiness プローブの定義
仮想マシン (VM) 設定の spec.readinessProbe.tcpSocket
フィールドを設定して、TCP readiness プローブを定義します。
手順
TCP readiness プローブの詳細を VM 設定ファイルに追加します。
TCP ソケットテストを含む readiness プローブの例
apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: annotations: name: fedora-vm namespace: example-namespace # ... spec: template: spec: readinessProbe: initialDelaySeconds: 120 1 periodSeconds: 20 2 tcpSocket: 3 port: 1500 4 timeoutSeconds: 10 5 # ...
次のコマンドを実行して VM を作成します。
$ oc create -f <file_name>.yaml
11.4.1.3. HTTP liveness プローブの定義
仮想マシン (VM) 設定の spec.livenessProbe.httpGet
フィールドを設定して、HTTP liveness プローブを定義します。readiness プローブと同様に、liveness プローブの HTTP および TCP テストの両方を定義できます。この手順では、HTTP GET テストを使用して liveness プローブのサンプルを設定します。
手順
VM 設定ファイルに HTTP liveness プローブの詳細を含めます。
HTTP GET テストを使用した liveness プローブの例
apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: annotations: name: fedora-vm namespace: example-namespace # ... spec: template: spec: livenessProbe: initialDelaySeconds: 120 1 periodSeconds: 20 2 httpGet: 3 port: 1500 4 path: /healthz 5 httpHeaders: - name: Custom-Header value: Awesome timeoutSeconds: 10 6 # ...
- 1
- VM が起動してから liveness プローブが開始されるまでの時間 (秒単位)。
- 2
- プローブの実行間の遅延 (秒単位)。デフォルトの遅延は 10 秒です。この値は
timeoutSeconds
よりも大きくなければなりません。 - 3
- VM に接続するために実行する HTTP GET 要求。
- 4
- プローブがクエリーする VM のポート。上記の例では、プローブはポート 1500 をクエリーします。VM は、cloud-init を介してポート 1500 に最小限の HTTP サーバーをインストールして実行します。
- 5
- HTTP サーバーでアクセスするパス。上記の例では、サーバーの
/healthz
パスのハンドラーが成功コードを返した場合、VM は正常であると見なされます。ハンドラーが失敗コードを返した場合、VM は削除され、新しい VM が作成されます。 - 6
- プローブがタイムアウトになり、VM が失敗したと見なされるまでの非アクティブな秒数。デフォルト値は 1 です。この値は
periodSeconds
未満である必要があります。
次のコマンドを実行して VM を作成します。
$ oc create -f <file_name>.yaml
11.4.2. ウォッチドッグの定義
次の手順を実行して、ゲスト OS の正常性を監視するウォッチドッグを定義できます。
- 仮想マシン (VM) のウォッチドッグデバイスを設定します。
- ゲストにウォッチドッグエージェントをインストールします。
ウォッチドッグデバイスはエージェントを監視し、ゲストオペレーティングシステムが応答しない場合、次のいずれかのアクションを実行します。
-
poweroff
: VM の電源がすぐにオフになります。spec.running
がtrue
に設定されているか、spec.runStrategy
がmanual
に設定されていない場合、VM は再起動します。 reset
: VM はその場で再起動し、ゲストオペレーティングシステムは反応できません。注記再起動時間が原因で liveness プローブがタイムアウトする場合があります。クラスターレベルの保護が liveness プローブの失敗を検出すると、VM が強制的に再スケジュールされ、再起動時間が長くなる可能性があります。
-
shutdown
: すべてのサービスを停止することで、VM の電源を正常にオフにします。
ウォッチドッグは、Windows VM では使用できません。
11.4.2.1. 仮想マシンのウォッチドッグデバイスの設定
仮想マシン (VM) のウォッチドッグデバイスを設定するとします。
前提条件
-
VM には、
i6300esb
ウォッチドッグデバイスのカーネルサポートが必要です。Red Hat Enterprise Linux(RHEL) イメージが、i6300esb
をサポートしている。
手順
次の内容で
YAML
ファイルを作成します。apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: labels: kubevirt.io/vm: vm2-rhel84-watchdog name: <vm-name> spec: running: false template: metadata: labels: kubevirt.io/vm: vm2-rhel84-watchdog spec: domain: devices: watchdog: name: <watchdog> i6300esb: action: "poweroff" 1 # ...
- 1
poweroff
、reset
、またはshutdown
を指定します。
上記の例では、電源オフアクションを使用して、RHEL8 VM で
i6300esb
ウォッチドッグデバイスを設定し、デバイスを/dev/watchdog
として公開します。このデバイスは、ウォッチドッグバイナリーで使用できるようになりました。
以下のコマンドを実行して、YAML ファイルをクラスターに適用します。
$ oc apply -f <file_name>.yaml
この手順は、ウォッチドッグ機能をテストするためにのみ提供されており、実稼働マシンでは実行しないでください。
以下のコマンドを実行して、VM がウォッチドッグデバイスに接続されていることを確認します。
$ lspci | grep watchdog -i
以下のコマンドのいずれかを実行して、ウォッチドッグがアクティブであることを確認します。
カーネルパニックをトリガーします。
# echo c > /proc/sysrq-trigger
ウォッチドッグサービスを停止します。
# pkill -9 watchdog
11.4.2.2. ゲストへのウォッチドッグエージェントのインストール
ゲストにウォッチドッグエージェントをインストールし、watchdog
サービスを開始します。
手順
- root ユーザーとして仮想マシンにログインします。
watchdog
ドッグパッケージとその依存関係をインストールします。# yum install watchdog
/etc/watchdog.conf
ファイルの次の行のコメントを外し、変更を保存します。#watchdog-device = /dev/watchdog
起動時に
watchdog
サービスを開始できるようにします。# systemctl enable --now watchdog.service