14.7. 仮想マシンの正常性のモニタリング
仮想マシンインスタンス (VMI) は、接続の損失、デッドロック、または外部の依存関係に関する問題など、一時的な問題が原因で正常でなくなることがあります。ヘルスチェックは、readiness および liveness プローブの組み合わせを使用して VMI で診断を定期的に実行します。
14.7.1. readiness および liveness プローブについて
readiness および liveness プローブを使用して、正常でない仮想マシンインスタンス (VMI) を検出して処理します。VMI の仕様に 1 つ以上のプローブを追加して、トラフィックが準備状態にない VMI に到達せず、VMI が応答不能になると新規インスタンスが作成されるようにすることができます。
readiness プローブ は、VMI がサービス要求を受け入れることができるかどうかを判別します。プローブに失敗すると、VMI は準備状態になるまで、利用可能なエンドポイントのリストから削除されます。
liveness プローブは、VMI が応答しているかどうかを判断します。プローブに失敗すると、VMI が削除され、新規インスタンスが作成されて応答性を復元します。
VirtualMachineInstance オブジェクトの spec.readinessProbe と spec.livenessProbe フィールドを設定して、readiness および liveness プローブを設定できます。これらのフィールドは、以下のテストをサポートします。
- HTTP GET
- プローブは Web フックを使用して VMI の正常性を判別します。このテストは、HTTP の応答コードが 200 から 399 までの値の場合に正常と見なされます。完全に初期化されている場合に、HTTP ステータスコードを返すアプリケーションで HTTP GET テストを使用できます。
- TCP ソケット
- プローブは、VMI に対してソケットを開くことを試行します。VMI はプローブで接続を確立できる場合にのみ正常であるとみなされます。TCP ソケットテストは、初期化が完了するまでリスニングを開始しないアプリケーションで使用できます。
- ゲストエージェントの ping
-
プローブは、
guest-pingコマンドを使用して、QEMU ゲストエージェントが仮想マシンで実行されているかどうかを判断します。
14.7.2. HTTP readiness プローブの定義
仮想マシンインスタンス (VMI) 設定の spec.readinessProbe.httpGet フィールドを設定して HTTP readiness プローブを定義します。
手順
VMI 設定ファイルに readiness プローブの詳細を追加します。
HTTP GET テストを使用した readiness プローブの例
# ... 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
- VMI への接続に使用する HTTP GET 要求。
- 2
- プローブがクエリーする VMI のポート。上記の例では、プローブはポート 1500 をクエリーします。
- 3
- HTTP サーバーでアクセスするパス。上記の例では、サーバーの /healthz パスのハンドラーが成功コードを返す場合に、VMI は正常であるとみなされます。ハンドラーが失敗コードを返すと、VMI は利用可能なエンドポイントのリストから削除されます。
- 4
- VMI が起動してから readiness プローブが開始されるまでの時間 (秒単位)。
- 5
- プローブの実行間の遅延 (秒単位)。デフォルトの遅延は 10 秒です。この値は
timeoutSecondsよりも大きくなければなりません。 - 6
- プローブがタイムアウトし、VMI が失敗したと想定されてから非アクティブになるまでの時間 (秒数)。デフォルト値は 1 です。この値は
periodSeconds未満である必要があります。 - 7
- プローブが失敗できる回数。デフォルトは 3 です。指定された試行回数になると、Pod には
Unreadyというマークが付けられます。 - 8
- 成功とみなされるまでにプローブが失敗後に成功を報告する必要のある回数。デフォルトでは 1 回です。
以下のコマンドを実行して VMI を作成します。
$ oc create -f <file_name>.yaml
14.7.3. TCP readiness プローブの定義
仮想マシンインスタンス (VMI) 設定の spec.readinessProbe.tcpSocket フィールドを設定して TCP readiness プローブを定義します。
手順
TCP readiness プローブの詳細を VMI 設定ファイルに追加します。
TCP ソケットテストを含む readiness プローブの例
... spec: readinessProbe: initialDelaySeconds: 120 1 periodSeconds: 20 2 tcpSocket: 3 port: 1500 4 timeoutSeconds: 10 5 ...以下のコマンドを実行して VMI を作成します。
$ oc create -f <file_name>.yaml
14.7.4. HTTP liveness プローブの定義
仮想マシンインスタンス (VMI) 設定の spec.livenessProbe.httpGet フィールドを設定して HTTP liveness プローブを定義します。readiness プローブと同様に、liveness プローブの HTTP および TCP テストの両方を定義できます。この手順では、HTTP GET テストを使用して liveness プローブのサンプルを設定します。
手順
HTTP liveness プローブの詳細を VMI 設定ファイルに追加します。
HTTP GET テストを使用した liveness プローブの例
# ... 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
- VMI が起動してから liveness プローブが開始されるまでの時間 (秒単位)。
- 2
- プローブの実行間の遅延 (秒単位)。デフォルトの遅延は 10 秒です。この値は
timeoutSecondsよりも大きくなければなりません。 - 3
- VMI への接続に使用する HTTP GET 要求。
- 4
- プローブがクエリーする VMI のポート。上記の例では、プローブはポート 1500 をクエリーします。VMI は、cloud-init 経由でポート 1500 に最小限の HTTP サーバーをインストールし、実行します。
- 5
- HTTP サーバーでアクセスするパス。上記の例では、サーバーの
/healthzパスのハンドラーが成功コードを返す場合に、VMI は正常であるとみなされます。ハンドラーが失敗コードを返すと、VMI が削除され、新規インスタンスが作成されます。 - 6
- プローブがタイムアウトし、VMI が失敗したと想定されてから非アクティブになるまでの時間 (秒数)。デフォルト値は 1 です。この値は
periodSeconds未満である必要があります。
以下のコマンドを実行して VMI を作成します。
$ oc create -f <file_name>.yaml
14.7.5. ゲストエージェントの ping プローブの定義
仮想マシンインスタンス (VMI) 設定の spec.readinessProbe.guestAgentPing フィールドを設定して、ゲストエージェント ping プローブを定義します。
ゲストエージェント ping プローブは、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
前提条件
- 仮想マシンに QEMU ゲストエージェントをインストールして有効にする必要があります。
手順
ゲストエージェント ping プローブの詳細を VMI 設定ファイルに含めます。以下に例を示します。
ゲストエージェント ping プローブの例
# ... spec: readinessProbe: guestAgentPing: {} 1 initialDelaySeconds: 120 2 periodSeconds: 20 3 timeoutSeconds: 10 4 failureThreshold: 3 5 successThreshold: 3 6 # ...- 1
- VMI に接続するためのゲストエージェント ping プローブ。
- 2
- オプション: VMI が開始してからゲストエージェントプローブが開始されるまでの時間 (秒単位)。
- 3
- オプション: プローブを実行する間の遅延 (秒単位)。デフォルトの遅延は 10 秒です。この値は
timeoutSecondsよりも大きくなければなりません。 - 4
- オプション: プローブがタイムアウトし、VMI が失敗したと想定されてから非アクティブになるまでの時間 (秒数)。デフォルト値は 1 です。この値は
periodSeconds未満である必要があります。 - 5
- オプション: プローブが失敗できる回数。デフォルトは 3 です。指定された試行回数になると、Pod には
Unreadyというマークが付けられます。 - 6
- オプション: 成功とみなされるまでにプローブが失敗後に成功を報告する必要のある回数。デフォルトでは 1 回です。
以下のコマンドを実行して VMI を作成します。
$ oc create -f <file_name>.yaml
14.7.6. テンプレート: ヘルスチェックを定義するための仮想マシンの設定ファイル
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
labels:
special: vm-fedora
name: vm-fedora
spec:
template:
metadata:
labels:
special: vm-fedora
spec:
domain:
devices:
disks:
- disk:
bus: virtio
name: containerdisk
- disk:
bus: virtio
name: cloudinitdisk
resources:
requests:
memory: 1024M
readinessProbe:
httpGet:
port: 1500
initialDelaySeconds: 120
periodSeconds: 20
timeoutSeconds: 10
failureThreshold: 3
successThreshold: 3
terminationGracePeriodSeconds: 180
volumes:
- name: containerdisk
containerDisk:
image: kubevirt/fedora-cloud-registry-disk-demo
- cloudInitNoCloud:
userData: |-
#cloud-config
password: fedora
chpasswd: { expire: False }
bootcmd:
- setenforce 0
- dnf install -y nmap-ncat
- systemd-run --unit=httpserver nc -klp 1500 -e '/usr/bin/echo -e HTTP/1.1 200 OK\\n\\nHello World!'
name: cloudinitdisk