13.13. OpenShift Virtualization critical 警报
OpenShift Virtualization 有警报，在出现问题时通知您。Critical 警报需要立即关注。
每个警报都有相应问题的描述，这是发生警报的原因，一种故障排除过程来诊断问题的来源，以及解析警报的步骤。
13.13.1. 网络警报
网络警报提供有关 OpenShift Virtualization Network Operator 的问题的信息。
13.13.1.1. KubeMacPoolDown 警报
描述
KubeMacPool 组件分配 MAC 地址并防止 MAC 地址冲突。
原因
如果 KubeMacPool-manager pod 已关闭，则 VirtualMachine 对象的创建会失败。
故障排除
确定 Kubemacpool-manager pod 命名空间和名称。
$ export KMP_NAMESPACE="$(oc get pod -A --no-headers -l control-plane=mac-controller-manager | awk '{print $1}')"$ export KMP_NAME="$(oc get pod -A --no-headers -l control-plane=mac-controller-manager | awk '{print $2}')"检查 Kubemacpool-manager pod 描述和日志，以确定问题的来源。
$ oc describe pod -n $KMP_NAMESPACE $KMP_NAME
$ oc logs -n $KMP_NAMESPACE $KMP_NAME
解决方案
创建一个支持问题，并提供故障排除过程中收集的信息。
13.13.2. SSP 警报
SSP 警报提供有关 OpenShift Virtualization SSP Operator 的问题的信息。
13.13.2.1. SSPFailingToReconcile 警报
描述
SSP Operator 的 pod 已启动，但 pod 的协调周期会持续失败。此失败包括无法更新负责部署模板验证器的资源、部署模板验证器或无法部署或更新通用模板的资源失败。
原因
如果 SSP Operator 无法协调，则依赖组件的部署失败，对组件更改的协调会失败，或者两者。另外，对通用模板和模板验证器的更新重置并失败。
故障排除
检查 ssp-operator pod 的日志中的错误：
$ export NAMESPACE="$(oc get deployment -A | grep ssp-operator | awk '{print $1}')"$ oc -n $NAMESPACE describe pods -l control-plane=ssp-operator
$ oc -n $NAMESPACE logs --tail=-1 -l control-plane=ssp-operator
验证模板验证器是否已启动。如果模板验证器没有启动，请检查 pod 的日志中的错误。
$ export NAMESPACE="$($ oc get deployment -A | grep ssp-operator | awk '{print $1}')"$ oc -n $NAMESPACE get pods -l name=virt-template-validator
$ oc -n $NAMESPACE describe pods -l name=virt-template-validator
$ oc -n $NAMESPACE logs --tail=-1 -l name=virt-template-validator
解决方案
创建一个支持问题，并提供故障排除过程中收集的信息。
13.13.2.2. SSPOperatorDown 警报
描述
SSP Operator 部署并协调通用模板和模板验证器。
原因
如果 SSP Operator 已关闭，则依赖组件的部署会失败，对组件更改进行协调会失败，或者两者都失败。另外，对通用模板和模板验证器的更新重置并失败。
故障排除
检查 ssp-operator 的 pod 命名空间：
$ export NAMESPACE="$(oc get deployment -A | grep ssp-operator | awk '{print $1}')"验证 ssp-operator 的 pod 当前是否已停机。
$ oc -n $NAMESPACE get pods -l control-plane=ssp-operator
检查 ssp-operator 的 pod 描述和日志。
$ oc -n $NAMESPACE describe pods -l control-plane=ssp-operator
$ oc -n $NAMESPACE logs --tail=-1 -l control-plane=ssp-operator
解决方案
创建一个支持问题，并提供故障排除过程中收集的信息。
13.13.2.3. SSPTemplateValidatorDown 警报
描述
模板验证器验证虚拟机(VM)不会违反其分配的模板。
原因
如果每个模板验证器 pod 都关闭，则模板验证器无法根据所分配的模板来验证虚拟机。
故障排除
检查 ssp-operator pod 和 virt-template-validator pod 的命名空间。
$ export NAMESPACE_SSP="$(oc get deployment -A | grep ssp-operator | awk '{print $1}')"$ export NAMESPACE="$(oc get deployment -A | grep virt-template-validator | awk '{print $1}')"验证 virt-template-validator 的 pod 当前是否已关闭。
$ oc -n $NAMESPACE get pods -l name=virt-template-validator
检查 ssp-operator 和 virt-template-validator 的 pod 描述和日志。
$ oc -n $NAMESPACE_SSP describe pods -l name=ssp-operator
$ oc -n $NAMESPACE_SSP logs --tail=-1 -l name=ssp-operator
$ oc -n $NAMESPACE describe pods -l name=virt-template-validator
$ oc -n $NAMESPACE logs --tail=-1 -l name=virt-template-validator
解决方案
创建一个支持问题，并提供故障排除过程中收集的信息。
13.13.3. virt 警报
virt 警报提供有关 OpenShift Virtualization Virt Operator 的问题的信息。
13.13.3.1. NoLeadingVirtOperator 警报
描述
在过去 10 分钟内，没有 virt-operator pod 有领导租期，尽管一个或多个 virt-operator pod 处于 Ready 状态。该警报指明没有正常工作的 virt-operator pod。
原因
virt-operator 是 OpenShift Container Platform 集群中活跃的第一个 Kubernetes Operator。其主要职责包括：
- 安装
- 实时更新
- 集群的实时升级
- 监控顶层控制器的生命周期，如 virt-controller、virt-handler 和 virt-launcher
- 管理顶层控制器的协调
另外，virt-operator 负责集群范围的任务，如证书轮转和一些基础架构管理。
virt-operator 部署具有两个 pod 的默认副本，一个领导 pod 保存领导租期，代表一个操作 virt-operator pod。
此警报表示集群级别的故障。关键的集群范围的管理功能（如认证轮转、升级和协调）可能临时不可用。
故障排除
从 pod 日志中确定 virt-operator pod 的领导状态。包含 Started leading 和 acquire leader 的日志消息指示给定 virt-operator pod 的领导状态。
另外，使用以下命令检查是否有正在运行的 virt-operator pod 和 pod 的状态：
$ export NAMESPACE="$(oc get kubevirt -A -o custom-columns="":.metadata.namespace)"
$ oc -n $NAMESPACE get pods -l kubevirt.io=virt-operator
$ oc -n $NAMESPACE logs <pod-name>
$ oc -n $NAMESPACE describe pod <pod-name>
领导 pod 示例：
$ oc -n $NAMESPACE logs <pod-name> |grep lead
输出示例
{"component":"virt-operator","level":"info","msg":"Attempting to acquire leader status","pos":"application.go:400","timestamp":"2021-11-30T12:15:18.635387Z"}
I1130 12:15:18.635452 1 leaderelection.go:243] attempting to acquire leader lease <namespace>/virt-operator...
I1130 12:15:19.216582 1 leaderelection.go:253] successfully acquired lease <namespace>/virt-operator
{"component":"virt-operator","level":"info","msg":"Started leading","pos":"application.go:385","timestamp":"2021-11-30T12:15:19.216836Z"}非领导 pod 示例：
$ oc -n $NAMESPACE logs <pod-name> |grep lead
输出示例
{"component":"virt-operator","level":"info","msg":"Attempting to acquire leader status","pos":"application.go:400","timestamp":"2021-11-30T12:15:20.533696Z"}
I1130 12:15:20.533792 1 leaderelection.go:243] attempting to acquire leader lease <namespace>/virt-operator...
解决方案
因为一些原因，没有 virt-operator pod 有领导租期，尽管一个或多个 virt-operator pod 处于 Ready 状态。确定根本原因并采取适当的操作。
否则，创建一个支持问题，并提供故障排除过程中收集的信息。
13.13.3.2. NoReadyVirtController 警报
描述
virt-controller 监控虚拟机实例(VMI)。virt-controller 还通过创建和管理与 VMI 对象关联的 pod 的生命周期来管理相关的 pod。
VMI 对象始终在其生命周期内与 pod 关联。但是，pod 实例可能会因为 VMI 迁移而变化。
当检查到没有状态为就绪的 virt-controllers 超过五分钟时，会发出此警报。
原因
如果 virt-controller 失败，则虚拟机生命周期管理完全失败。生命周期管理任务包括启动新的 VMI 或关闭现有的 VMI。
故障排除
检查 virt-controller 的 vdeployment 状态是否有可用的副本和条件。
$ oc -n $NAMESPACE get deployment virt-controller -o yaml
检查 virt-controller pod 是否存在并检查其状态。
get pods -n $NAMESPACE |grep virt-controller
检查 virt-controller pod 的事件。
$ oc -n $NAMESPACE describe pods <virt-controller pod>
检查 virt-controller pod 的日志。
$ oc -n $NAMESPACE logs <virt-controller pod>
检查节点是否有问题，如节点是否处于
NotReady状态。$ oc get nodes
解决方案
一些原因可能会造成没有 Ready 状态的 virt-controller pod。确定根本原因并采取适当的操作。
否则，创建一个支持问题，并提供故障排除过程中收集的信息。
13.13.3.3. NoReadyVirtOperator 警报
描述
在过去 10 分钟内，没有检查到处于 Ready 状态的 virt-operator pod。virt-operator 部署有两个 pod 的默认副本。
原因
virt-operator 是 OpenShift Container Platform 集群中活跃的第一个 Kubernetes Operator。其主要职责包括：
- 安装
- 实时更新
- 集群的实时升级
- 监控顶层控制器的生命周期，如 virt-controller、virt-handler 和 virt-launcher
- 管理顶层控制器的协调
另外，virt-operator 负责集群范围的任务，如证书轮转和一些基础架构管理。
virt-operator 不直接负责集群中的虚拟机。virt-operator 不可用不会影响自定义工作负载。
此警报表示集群级别的故障。关键的集群范围的管理功能（如认证轮转、升级和协调）可能临时不可用。
故障排除
检查 virt-operator 的部署状态以获取可用副本和条件。
$ oc -n $NAMESPACE get deployment virt-operator -o yaml
检查 virt-controller pod 的事件。
$ oc -n $NAMESPACE describe pods <virt-operator pod>
检查 virt-operator pod 的日志。
$ oc -n $NAMESPACE logs <virt-operator pod>
检查 control plane 和 master 节点是否存在问题，如它们是否处于
NotReady状态。$ oc get nodes
解决方案
一些原因可能会造成没有 Ready 状态的 virt-operator pod。确定根本原因并采取适当的操作。
否则，创建一个支持问题，并提供故障排除过程中收集的信息。
13.13.3.4. VirtAPIDown 警报
描述
所有 OpenShift Container Platform API 服务器都停机。
原因
如果所有 OpenShift Container Platform API 服务器都停机，则不会对 OpenShift Container Platform 实体进行 API 调用。
故障排除
修改环境变量
NAMESPACE。$ export NAMESPACE="$(oc get kubevirt -A -o custom-columns="":.metadata.namespace)"
验证是否有正在运行的 virt-api pod。
$ oc -n $NAMESPACE get pods -l kubevirt.io=virt-api
-
使用
oc logs和oc describe来查看 pod 的日志。 检查 virt-api 部署的状态。使用这些命令了解相关的事件，并演示拉取镜像、崩溃 pod 或其他类似问题时是否存在任何问题。
$ oc -n $NAMESPACE get deployment virt-api -o yaml
$ oc -n $NAMESPACE describe deployment virt-api
检查节点是否有问题，如节点是否处于
NotReady状态。$ oc get nodes
解决方案
virt-api pod 可能会因为以下原因而停机。确定根本原因并采取适当的操作。
否则，创建一个支持问题，并提供故障排除过程中收集的信息。
13.13.3.5. VirtApiRESTErrorsBurst 警报
描述
在过去五分钟内，virt-api 中超过 80% 的 REST 调用会失败。
原因
对 virt-api 的 REST 调用非常高，导致对 API 调用速度缓慢、速度较慢的 API 调用，甚至完全没有 API 调用。
故障排除
修改环境变量
NAMESPACE。$ export NAMESPACE="$(oc get kubevirt -A -o custom-columns="":.metadata.namespace)"
检查存在多少个运行 virt-api pod。
$ oc -n $NAMESPACE get pods -l kubevirt.io=virt-api
-
使用
oc logs和oc describe来查看 pod 的日志。 检查 virt-api 部署的状态，以查找更多信息。这些命令提供相关的事件，并显示拉取镜像或崩溃 pod 是否存在任何问题。
$ oc -n $NAMESPACE get deployment virt-api -o yaml
$ oc -n $NAMESPACE describe deployment virt-api
检查节点是否有问题，例如节点是否已过载或未处于
NotReady状态。$ oc get nodes
解决方案
一些原因会造成高的 REST 调用故障率。确定根本原因并采取适当的操作。
- 节点资源耗尽
- 集群没有足够内存
- 节点已停机
- API 服务器过载，如调度程序没有 100%可用）
- 网络问题
否则，创建一个支持问题，并提供故障排除过程中收集的信息。
13.13.3.6. VirtControllerDown 警报
描述
如果过去五分钟中没有对 virt-controller 的检测，则 virt-controller 部署具有两个 pod 的默认副本。
原因
如果 virt-controller 失败，则虚拟机生命周期管理任务（如启动新的 VMI 或关闭现有 VMI）完全失败。
故障排除
修改环境变量
NAMESPACE。$ export NAMESPACE="$(oc get kubevirt -A -o custom-columns="":.metadata.namespace)"
检查 virt-controller 部署的状态。
$ oc get deployment -n $NAMESPACE virt-controller -o yaml
检查 virt-controller pod 的事件。
$ oc -n $NAMESPACE describe pods <virt-controller pod>
检查 virt-controller pod 的日志。
$ oc -n $NAMESPACE logs <virt-controller pod>
检查 manager pod 的日志，以确定创建 virt-controller pod 为何会失败。
$ oc get logs <virt-controller-pod>
日志中 virt-controller pod 名称的例子是 virt-controller-7888c64d66-dzc9p。但是，可能会有多个运行 virt-controller 的 pod。
解决方案
一些原因可以造成检查没有运行的 virt-controller 发生。从可能的原因列表中找出根本原因，并采取适当的操作。
- 节点资源耗尽
- 集群没有足够内存
- 节点已停机
- API 服务器过载，如调度程序没有 100%可用）
- 网络问题
否则，创建一个支持问题，并提供故障排除过程中收集的信息。
13.13.3.7. VirtControllerRESTErrorsBurst 警报
描述
在过去五分钟内，virt-controller 中已有超过 80% 的 REST 调用失败。
原因
virt-controller 可能已完全丢失与 API 服务器的连接。这个丢失不会影响运行的工作负载，但会传播状态更新和迁移等操作。
故障排除
与 virt-controller REST 调用失败有关的两个常见错误类型：
- API 服务器过载，从而导致超时。检查 API 服务器指标和详情，如响应时间和总体调用。
virt-controller pod 无法访问 API 服务器。常见原因包括：
- 节点上的 DNS 问题
- 网络连接问题
解决方案
检查 virt-controller 日志，以确定 virt-controller pod 是否无法连接到 API 服务器。如果是，请删除 pod 来强制重启。
另外，验证节点资源耗尽或者集群中没有足够的内存会导致连接失败。
这个问题通常与此警报范围以外的 DNS 或 CNI 问题相关。
否则，创建一个支持问题，并提供故障排除过程中收集的信息。
13.13.3.8. VirtHandlerRESTErrorsBurst 警报
描述
在过去五分钟内，virt-handler 中已有超过 80% 的 REST 调用失败。
原因
virt-handler 丢失与 API 服务器的连接。在受影响节点上运行的工作负载仍在运行，但状态更新无法传播，迁移等操作无法进行。
故障排除
与 virt-operator REST 调用失败有关的两个常见错误类型：
- API 服务器过载，从而导致超时。检查 API 服务器指标和详情，如响应时间和总体调用。
virt-operator pod 无法访问 API 服务器。常见原因包括：
- 节点上的 DNS 问题
- 网络连接问题
解决方案
如果 virt-handler 无法连接 API 服务器，请删除该 Pod 以强制重启。这个问题通常与此警报范围以外的 DNS 或 CNI 问题相关。确定根本原因并采取适当的操作。
否则，创建一个支持问题，并提供故障排除过程中收集的信息。
13.13.3.9. VirtOperatorDown 警报
描述
过去 10 分钟内没有 virt-operator pod 处于 Running 状态时发生此警报。virt-operator 部署有两个 pod 的默认副本。
原因
virt-operator 是 OpenShift Container Platform 集群中活跃的第一个 Kubernetes Operator。其主要职责包括：
- 安装
- 实时更新
- 集群的实时升级
- 监控顶层控制器的生命周期，如 virt-controller、virt-handler 和 virt-launcher
- 管理顶层控制器的协调
另外，virt-operator 负责集群范围的任务，如证书轮转和一些基础架构管理。
virt-operator 不直接负责集群中的虚拟机。virt-operator 不可用不会影响自定义工作负载。
此警报表示集群级别的故障。关键的集群范围的管理功能（如认证轮转、升级和协调）可能临时不可用。
故障排除
修改环境变量
NAMESPACE。$ export NAMESPACE="$(oc get kubevirt -A -o custom-columns="":.metadata.namespace)"
检查 virt-operator 部署的状态。
$ oc get deployment -n $NAMESPACE virt-operator -o yaml
检查 virt-operator pod 的事件。
$ oc -n $NAMESPACE describe pods <virt-operator pod>
检查 virt-operator pod 的日志。
$ oc -n $NAMESPACE logs <virt-operator pod>
检查 manager pod 的日志，以确定创建 virt-operator pod 为何会失败。
$ oc get logs <virt-operator-pod>
日志中 virt-operator pod 名称的例子是 virt-operator-7888c64d66-dzc9p。但是，可能会有多个运行 virt-operator 的 pod。
解决方案
一些原因可以造成检查没有运行的 virt-operator 发生。从可能的原因列表中找出根本原因，并采取适当的操作。
- 节点资源耗尽
- 集群没有足够内存
- 节点已停机
- API 服务器过载，如调度程序没有 100%可用）
- 网络问题
否则，创建一个支持问题，并提供故障排除过程中收集的信息。
13.13.3.10. VirtOperatorRESTErrorsBurst 警报
描述
在过去五分钟内，virt-operator 中有超过 80% 的 REST 调用会失败。
原因
virt-operator 丢失与 API 服务器的连接。升级和控制器协调等集群级别操作无法正常工作。对客户工作负载（如虚拟机和 VMI）没有影响。
故障排除
与 virt-operator REST 调用失败有关的两个常见错误类型：
- API 服务器过载，从而导致超时。检查 API 服务器指标和详情，如响应时间和总体调用。
virt-operator pod 无法访问 API 服务器。常见原因是节点上的网络连接问题和 DNS 问题。检查 virt-operator 日志，以验证 pod 是否可以连接到 API 服务器。
$ export NAMESPACE="$(oc get kubevirt -A -o custom-columns="":.metadata.namespace)"
$ oc -n $NAMESPACE get pods -l kubevirt.io=virt-operator
$ oc -n $NAMESPACE logs <pod-name>
$ oc -n $NAMESPACE describe pod <pod-name>
解决方案
如果 virt-operator 无法连接到 API 服务器，请删除 pod 来强制重启。这个问题通常与此警报范围以外的 DNS 或 CNI 问题相关。确定根本原因并采取适当的操作。
否则，创建一个支持问题，并提供故障排除过程中收集的信息。
