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 プローブを定義します。

手順

  1. 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 回です。
  2. 次のコマンドを実行して VM を作成します。

    $ oc create -f <file_name>.yaml

11.4.1.2. TCP readiness プローブの定義

仮想マシン (VM) 設定の spec.readinessProbe.tcpSocket フィールドを設定して、TCP readiness プローブを定義します。

手順

  1. 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
    # ...

    1
    VM が起動してから準備プローブが開始されるまでの時間 (秒単位)。
    2
    プローブの実行間の遅延 (秒単位)。デフォルトの遅延は 10 秒です。この値は timeoutSeconds よりも大きくなければなりません。
    3
    実行する TCP アクション。
    4
    プローブがクエリーする VM のポート。
    5
    プローブがタイムアウトになり、VM が失敗したと見なされるまでの非アクティブな秒数。デフォルト値は 1 です。この値は periodSeconds 未満である必要があります。
  2. 次のコマンドを実行して 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 プローブのサンプルを設定します。

手順

  1. 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 未満である必要があります。
  2. 次のコマンドを実行して VM を作成します。

    $ oc create -f <file_name>.yaml

11.4.2. ウォッチドッグの定義

次の手順を実行して、ゲスト OS の正常性を監視するウォッチドッグを定義できます。

  1. 仮想マシン (VM) のウォッチドッグデバイスを設定します。
  2. ゲストにウォッチドッグエージェントをインストールします。

ウォッチドッグデバイスはエージェントを監視し、ゲストオペレーティングシステムが応答しない場合、次のいずれかのアクションを実行します。

  • poweroff: VM の電源がすぐにオフになります。spec.runningtrue に設定されているか、spec.runStrategymanual に設定されていない場合、VM は再起動します。
  • reset: VM はその場で再起動し、ゲストオペレーティングシステムは反応できません。

    注記

    再起動時間が原因で liveness プローブがタイムアウトする場合があります。クラスターレベルの保護が liveness プローブの失敗を検出すると、VM が強制的に再スケジュールされ、再起動時間が長くなる可能性があります。

  • shutdown: すべてのサービスを停止することで、VM の電源を正常にオフにします。
注記

ウォッチドッグは、Windows VM では使用できません。

11.4.2.1. 仮想マシンのウォッチドッグデバイスの設定

仮想マシン (VM) のウォッチドッグデバイスを設定するとします。

前提条件

  • VM には、i6300esb ウォッチドッグデバイスのカーネルサポートが必要です。Red Hat Enterprise Linux(RHEL) イメージが、i6300esb をサポートしている。

手順

  1. 次の内容で 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
    poweroffreset、または shutdown を指定します。

    上記の例では、電源オフアクションを使用して、RHEL8 VM で i6300esb ウォッチドッグデバイスを設定し、デバイスを /dev/watchdog として公開します。

    このデバイスは、ウォッチドッグバイナリーで使用できるようになりました。

  2. 以下のコマンドを実行して、YAML ファイルをクラスターに適用します。

    $ oc apply -f <file_name>.yaml
重要

この手順は、ウォッチドッグ機能をテストするためにのみ提供されており、実稼働マシンでは実行しないでください。

  1. 以下のコマンドを実行して、VM がウォッチドッグデバイスに接続されていることを確認します。

    $ lspci | grep watchdog -i
  2. 以下のコマンドのいずれかを実行して、ウォッチドッグがアクティブであることを確認します。

    • カーネルパニックをトリガーします。

      # echo c > /proc/sysrq-trigger
    • ウォッチドッグサービスを停止します。

      # pkill -9 watchdog

11.4.2.2. ゲストへのウォッチドッグエージェントのインストール

ゲストにウォッチドッグエージェントをインストールし、watchdog サービスを開始します。

手順

  1. root ユーザーとして仮想マシンにログインします。
  2. watchdog ドッグパッケージとその依存関係をインストールします。

    # yum install watchdog
  3. /etc/watchdog.conf ファイルの次の行のコメントを外し、変更を保存します。

    #watchdog-device = /dev/watchdog
  4. 起動時に watchdog サービスを開始できるようにします。

    # systemctl enable --now watchdog.service
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.