11.4. 虚拟机健康检查


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

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

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

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

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

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

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

11.4.1.1. 定义 HTTP 就绪度探测

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

流程

  1. 在虚拟机配置文件中包括就绪度探测的详细信息。

    使用 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。
  2. 运行以下命令来创建虚拟机:

    $ oc create -f <file_name>.yaml

11.4.1.2. 定义 TCP 就绪度探测

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

流程

  1. 在虚拟机配置文件中包括 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
  2. 运行以下命令来创建虚拟机:

    $ oc create -f <file_name>.yaml

11.4.1.3. 定义 HTTP 存活度探测

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

流程

  1. 在虚拟机配置文件中包括 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
  2. 运行以下命令来创建虚拟机:

    $ oc create -f <file_name>.yaml

11.4.2. 定义 watchdog

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

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

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

  • poweroff :虚拟机立即关闭。如果 spec.running 设为 truespec.runStrategy 没有设置为 manual,则虚拟机将重启。
  • reset :虚拟机重新启动,客户机操作系统无法响应。

    注意

    重启时间可能会导致存活度探测超时。如果集群级别的保护检测到失败的存活度探测,则虚拟机可能会被强制重新调度,从而增加重启时间。

  • shutdown :通过停止所有服务来正常关闭虚拟机。
注意

watchdog 不适用于 Windows 虚拟机。

11.4.2.1. 为虚拟机配置 watchdog 设备

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

先决条件

  • 虚拟机必须具有对 i6300esb watchdog 设备的内核支持。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
    指定 poweroff, reset, 或 shutdown.

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

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

  2. 运行以下命令,将 YAML 文件应用到集群:

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

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

  1. 运行以下命令来验证虚拟机是否已连接到 watchdog 设备:

    $ lspci | grep watchdog -i
  2. 运行以下命令之一以确认 watchdog 处于活跃状态:

    • 触发内核 panic:

      # echo c > /proc/sysrq-trigger
    • 停止 watchdog 服务:

      # pkill -9 watchdog

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

您可以在客户机上安装 watchdog 代理并启动 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

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.