13.5. 监控虚拟机健康状况
虚拟机实例 (VMI) 可能会变得不健康，原因可能源自连接丢失、死锁或外部依赖项相关问题等临时问题。健康检查使用就绪度和存活度探测的组合定期对 VMI 执行诊断。
13.5.1. 关于就绪度和存活度探测
使用就绪度和存活度探测来检测和处理不健康的虚拟机实例 (VMI)。您可以在 VMI 规格中包含一个或多个探测，以确保流量无法访问未准备好的 VMI，并在 VMI 变得不响应时创建新实例。
就绪度探测决定 VMI 是否准备好接受服务请求。如果探测失败，则 VMI 会从可用端点列表中移除，直到 VMI 就绪为止。
存活度探测决定 VMI 是否响应。如果探测失败，则会删除 VMI 并创建一个新实例来恢复响应性。
您可以通过设置 VirtualMachineInstance 对象的 spec.readinessProbe 和 spec.livenessProbe 字段来配置就绪度和存活度探测。这些字段支持以下测试：
- HTTP GET
- 该探测使用 Web hook 确定 VMI 的健康状况。如果 HTTP 响应代码介于 200 和 399 之间，则测试成功。您可以将 HTTP GET 测试用于在完全初始化时返回 HTTP 状态代码的应用程序。
- TCP 套接字
- 该探测尝试为 VMI 打开一个套接字。只有在探测可以建立连接时，VMI 才被视为健康。对于在初始化完成前不会开始监听的应用程序，可以使用 TCP 套接字测试。
13.5.2. 定义 HTTP 就绪度探测
通过设置虚拟机实例 (VMI) 配置的 spec.readinessProbe.httpGet 字段来定义 HTTP 就绪度探测。
流程
在 VMI 配置文件中包括就绪度探测的详细信息。
使用 HTTP GET 测试就绪度探测示例
# ... 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 请求以连接 VMI。
- 2
- 探测查询的 VMI 端口。在上例中，探测查询端口 1500。
- 3
- 在 HTTP 服务器上访问的路径。在上例中，如果服务器的 /healthz 路径的处理程序返回成功代码，则 VMI 被视为健康。如果处理程序返回失败代码，则 VMI 将从可用端点列表中移除。
- 4
- VMI 启动就绪度探测前的时间（以秒为单位）。
- 5
- 执行探测之间的延迟（以秒为单位）。默认延迟为 10 秒。这个值必须大于
timeoutSeconds。 - 6
- 在不活跃的时间（以秒为单位）超过这个值时探测会超时，且假定 VMI 失败。默认值为 1。这个值必须小于
periodSeconds。 - 7
- 探测允许失败的次数。默认值为 3。在进行了指定数量的尝试后，pod 被标记为
Unready。 - 8
- 在失败后，在探测报告成功的次数达到这个值时才能被视为成功。默认值为 1。
运行以下命令来创建 VMI：
$ oc create -f <file_name>.yaml
13.5.3. 定义 TCP 就绪度探测
通过设置虚拟机实例 (VMI) 配置的 spec.readinessProbe.tcpSocket 字段来定义 TCP 就绪度探测。
流程
在 VMI 配置文件中包括 TCP 就绪探测的详细信息。
使用 TCP 套接字测试的就绪度探测示例
... spec: readinessProbe: initialDelaySeconds: 120 1 periodSeconds: 20 2 tcpSocket: 3 port: 1500 4 timeoutSeconds: 10 5 ...运行以下命令来创建 VMI：
$ oc create -f <file_name>.yaml
13.5.4. 定义 HTTP 存活度探测
通过设置虚拟机实例 (VMI) 配置的 spec.livenessProbe.httpGet 字段来定义 HTTP 存活度探测。您可以按照与就绪度探测相同的方式为存活度探测定义 HTTP 和 TCP 测试。此流程使用 HTTP GET 测试配置示例存活度探测。
流程
在 VMI 配置文件中包括 HTTP 存活度探测的详细信息。
使用 HTTP GET 测试的存活度探测示例
# ... 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 启动存活度探测前的时间（以秒为单位）。
- 2
- 执行探测之间的延迟（以秒为单位）。默认延迟为 10 秒。这个值必须大于
timeoutSeconds。 - 3
- 执行的 HTTP GET 请求以连接 VMI。
- 4
- 探测查询的 VMI 端口。在上例中，探测查询端口 1500。VMI 通过 cloud-init 在端口 1500 上安装并运行最小 HTTP 服务器。
- 5
- 在 HTTP 服务器上访问的路径。在上例中，如果服务器的
/healthz路径的处理程序返回成功代码，则 VMI 被视为健康。如果处理程序返回失败代码，则 VMI 被删除并创建新实例。 - 6
- 在不活跃的时间（以秒为单位）超过这个值时探测会超时，且假定 VMI 失败。默认值为 1。这个值必须小于
periodSeconds。
运行以下命令来创建 VMI：
$ oc create -f <file_name>.yaml
13.5.5. 模板：用于定义健康检查的虚拟机实例配置文件
apiVersion: kubevirt.io/v1
kind: VirtualMachineInstance
metadata:
labels:
special: vmi-fedora
name: vmi-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: 0
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