12.5. 虚拟机健康检查

您可以通过在 VirtualMachine 资源中定义就绪度和存活度探测来配置虚拟机 (VM) 健康检查。

12.5.1. 关于就绪度和存活度探测

使用就绪度和存活度探测来检测和处理不健康的虚拟机 (VM)。您可以在虚拟机规格中包含一个或多个探测，以确保流量无法访问未就绪的虚拟机，并在虚拟机变得无响应时创建新虚拟机。

就绪度探测决定 VMI 是否准备好接受服务请求。如果探测失败，则 VMI 会从可用端点列表中移除，直到 VMI 就绪为止。

存活度探测决定 VMI 是否响应。如果探测失败，则会删除虚拟机并创建一个新的虚拟机来恢复响应性。

您可以通过设置 VirtualMachine 对象的 spec.readinessProbe 和 spec.livenessProbe 字段来配置就绪度和存活度探测。这些字段支持以下测试：

HTTP GET: 该探测使用 Web hook 确定 VMI 的健康状况。如果 HTTP 响应代码介于 200 和 399 之间，则测试成功。您可以将 HTTP GET 测试用于在完全初始化时返回 HTTP 状态代码的应用程序。
TCP 套接字: 该探测尝试为 VMI 打开一个套接字。只有在探测可以建立连接时，VMI 才被视为健康。对于在初始化完成前不会开始监听的应用程序，可以使用 TCP 套接字测试。
客户机代理 ping: 该探测使用 guest-ping 命令来确定 QEMU 客户机代理是否在虚拟机上运行。

12.5.1.1. 定义 HTTP 就绪度探测

通过设置虚拟机配置的 spec.readinessProbe.httpGet 字段来定义 HTTP 就绪度探测。

流程

在虚拟机配置文件中包括就绪度探测的详细信息。
使用 HTTP GET 测试就绪度探测示例
```
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
执行的 HTTP GET 请求以连接 VM。
2
探测查询的虚拟机端口。在上例中，探测查询端口 1500。
3
在 HTTP 服务器上访问的路径。在上例中，如果服务器的 /healthz 路径的处理程序返回成功代码，则 VMI 被视为健康。如果处理程序返回失败代码，则虚拟机将从可用端点列表中移除。
4
虚拟机启动就绪度探测前的时间（以秒为单位）。
5
执行探测之间的延迟（以秒为单位）。默认延迟为 10 秒。这个值必须大于 timeoutSeconds。
6
在不活跃的时间（以秒为单位）超过这个值时探测会超时，且假定 VM 失败。默认值为 1。这个值必须小于 periodSeconds。
7
探测允许失败的次数。默认值为 3。在进行了指定数量的尝试后，pod 被标记为 Unready。
8
在失败后，在探测报告成功的次数达到这个值时才能被视为成功。默认值为 1。
运行以下命令来创建虚拟机：
```
$ oc create -f <file_name>.yaml
```

12.5.1.2. 定义 TCP 就绪度探测

通过设置虚拟机 (VM) 配置的 spec.readinessProbe.tcpSocket 字段来定义 TCP 就绪度探测。

流程

在虚拟机配置文件中包括 TCP 就绪度探测的详细信息。
使用 TCP 套接字测试的就绪度探测示例
```
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
虚拟机启动就绪度探测前的时间（以秒为单位）。
2
执行探测之间的延迟（以秒为单位）。默认延迟为 10 秒。这个值必须大于 timeoutSeconds。
3
要执行的 TCP 操作。
4
探测查询的虚拟机端口。
5
在不活跃的时间（以秒为单位）超过这个值时探测会超时，且假定 VM 失败。默认值为 1。这个值必须小于 periodSeconds。
运行以下命令来创建虚拟机：
```
$ oc create -f <file_name>.yaml
```

12.5.1.3. 定义 HTTP 存活度探测

通过设置虚拟机 (VM) 配置的 spec.livenessProbe.httpGet 字段来定义 HTTP 存活度探测。您可以按照与就绪度探测相同的方式为存活度探测定义 HTTP 和 TCP 测试。此流程使用 HTTP GET 测试配置示例存活度探测。

流程

在虚拟机配置文件中包括 HTTP 存活度探测的详细信息。
使用 HTTP GET 测试的存活度探测示例
```
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
虚拟机启动存活度探测前的时间（以秒为单位）。
2
执行探测之间的延迟（以秒为单位）。默认延迟为 10 秒。这个值必须大于 timeoutSeconds。
3
执行的 HTTP GET 请求以连接 VM。
4
探测查询的虚拟机端口。在上例中，探测查询端口 1500。VM 通过 cloud-init 在端口 1500 上安装并运行最小 HTTP 服务器。
5
在 HTTP 服务器上访问的路径。在上例中，如果服务器的 /healthz 路径的处理程序返回成功代码，则 VMI 被视为健康。如果处理程序返回失败代码，则会删除虚拟机并创建新虚拟机。
6
在不活跃的时间（以秒为单位）超过这个值时探测会超时，且假定 VM 失败。默认值为 1。这个值必须小于 periodSeconds。
运行以下命令来创建虚拟机：
```
$ oc create -f <file_name>.yaml
```

12.5.2. 定义 watchdog

您可以通过执行以下步骤来定义 watchdog 来监控客户端操作系统的健康状态：

为虚拟机配置 watchdog 设备。
在客户机上安装 watchdog 代理。

watchdog 设备监控代理，并在客户机操作系统不响应时执行以下操作之一：

poweroff ：虚拟机立即关闭。如果 spec.running 设为 true 或 spec.runStrategy 没有设置为 manual，则虚拟机将重启。
reset ：虚拟机重新启动，客户机操作系统无法响应。
注意
重启时间可能会导致存活度探测超时。如果集群级别的保护检测到失败的存活度探测，则虚拟机可能会被强制重新调度，从而增加重启时间。
shutdown ：通过停止所有服务来正常关闭虚拟机。

注意

watchdog 不适用于 Windows 虚拟机。

12.5.2.1. 为虚拟机配置 watchdog 设备

您可以为虚拟机配置 watchdog 设备。

先决条件

虚拟机必须具有对 i6300esb watchdog 设备的内核支持。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.

上面的示例使用 poweroff 操作配置 RHEL8 虚拟机上的 i6300esb watchdog 设备，并将设备公开为 /dev/watchdog。

现在，watchdog 二进制文件可以使用这个设备。

运行以下命令，将 YAML 文件应用到集群：
```
$ oc apply -f <file_name>.yaml
```

重要

此流程仅用于测试 watchdog 功能，且不得在生产环境中运行。

运行以下命令来验证虚拟机是否已连接到 watchdog 设备：
```
$ lspci | grep watchdog -i
```
运行以下命令之一以确认 watchdog 处于活跃状态：
- 触发内核 panic：
```
# echo c > /proc/sysrq-trigger
```
- 停止 watchdog 服务：
```
# pkill -9 watchdog
```

12.5.2.2. 在客户机上安装 watchdog 代理

您可以在客户机上安装 watchdog 代理并启动 watchdog 服务。

流程

以 root 用户身份登录虚拟机。
安装 watchdog 软件包及其依赖项：
```
# yum install watchdog
```
在 /etc/watchdog.conf 文件中取消注释以下行并保存更改：
```
#watchdog-device = /dev/watchdog
```

在引导时启用 watchdog 服务：

# systemctl enable --now watchdog.service

12.5.3. 定义客户机代理 ping 探测

通过设置虚拟机 (VM) 配置的 spec.readinessProbe.guestAgentPing 字段来定义客户机代理 ping 探测。

重要

客户机代理 ping 探测只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。