11.5. OpenShift Virtualization runbooks
您可以使用这些 runbooks 中的步骤诊断和解决触发 OpenShift Virtualization 警报 的问题。
OpenShift Virtualization 警报显示在 web 控制台的 Virtualization
11.5.1. CDIDataImportCronOutdated
含义
当 DataImportCron
无法轮询或导入最新的磁盘镜像版本时,此警报会触发。
DataImportCron
轮询磁盘镜像,检查最新版本,并将镜像导入为持久性卷声明 (PVC)。此过程可确保 PVC 更新至最新版本,以便它们可以用作虚拟机 (VM) 的可靠克隆源或金级镜像。
对于金级镜像,latest 代表发行版的最新操作系统。对于其他磁盘镜像,latest 指的是可用镜像的最新哈希。
影响
虚拟机可以从过时的磁盘镜像创建。
虚拟机可能无法启动,因为没有源 PVC 用于克隆。
诊断
检查集群是否有默认存储类:
$ oc get sc
输出中显示了默认存储类名称旁边带有
(default)
的存储类。您必须设置默认存储类,可以在集群或DataImportCron
规格中设置默认存储类,以便DataImportCron
轮询和导入金级镜像。如果没有定义存储类,DataVolume 控制器将无法创建 PVC,并显示以下事件:DataVolume.storage spec is missing accessMode and no storageClass to choose profile
。获取
DataImportCron
命名空间和名称:$ oc get dataimportcron -A -o json | jq -r '.items[] | \ select(.status.conditions[] | select(.type == "UpToDate" and \ .status == "False")) | .metadata.namespace + "/" + .metadata.name'
如果集群中没有定义默认存储类,请检查默认存储类的
DataImportCron
规格:$ oc get dataimportcron <dataimportcron> -o yaml | \ grep -B 5 storageClassName
输出示例
url: docker://.../cdi-func-test-tinycore storage: resources: requests: storage: 5Gi storageClassName: rook-ceph-block
获取与
DataImportCron
对象关联的DataVolume
名称:$ oc -n <namespace> get dataimportcron <dataimportcron> -o json | \ jq .status.lastImportedPVC.name
检查
DataVolume
日志中的错误消息:$ oc -n <namespace> get dv <datavolume> -o yaml
设置
CDI_NAMESPACE
环境变量:$ export CDI_NAMESPACE="$(oc get deployment -A | \ grep cdi-operator | awk '{print $1}')"
检查
cdi-deployment
日志是否有错误消息:$ oc logs -n $CDI_NAMESPACE deployment/cdi-deployment
缓解方案
-
在集群或
DataImportCron
规格上设置默认存储类,以轮询和导入金级镜像。更新的 Containerized Data Importer (CDI) 将在几秒钟内解决这个问题。 -
如果问题没有解决,请删除与受影响的
DataImportCron
对象关联的数据卷。CDI 将使用默认存储类重新创建数据卷。 如果您的集群在受限网络环境中安装,请禁用
enableCommonBootImageImport
功能门,以便选择不使用自动更新:$ oc patch hco kubevirt-hyperconverged -n $CDI_NAMESPACE --type json \ -p '[{"op": "replace", "path": \ "/spec/featureGates/enableCommonBootImageImport", "value": false}]'
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.2. CDIDataVolumeUnusualRestartCount
含义
当 DataVolume
对象重启超过三次时,此警报会触发。
影响
数据卷负责在持久性卷声明上导入和创建虚拟机磁盘。如果数据卷重启超过三次,则这些操作不太可能成功。您必须诊断并解决问题。
诊断
查找超过三次重启的 Containerized Data Importer (CDI) pod:
$ oc get pods --all-namespaces -l app=containerized-data-importer -o=jsonpath='{range .items[?(@.status.containerStatuses[0].restartCount>3)]}{.metadata.name}{"/"}{.metadata.namespace}{"\n"}'
获取 pod 的详情:
$ oc -n <namespace> describe pods <pod>
检查 pod 日志中的错误消息:
$ oc -n <namespace> logs <pod>
缓解方案
删除数据卷,解决问题,然后创建新数据卷。
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.3. CDIDefaultStorageClassDegraded
含义
当没有支持智能克隆 (CSI 或基于快照) 或 ReadWriteMany 访问模式的默认存储类时,此警报会触发。
影响
如果默认存储类不支持智能克隆,则默认克隆方法是主机辅助克隆,这效率较低。
如果默认存储类不支持 ReadWriteMany,则虚拟机 (VM) 无法实时迁移。
创建虚拟机磁盘时,默认的 OpenShift Virtualization 存储类优先于默认的 OpenShift Dedicated 存储类。
诊断
运行以下命令,获取默认的 OpenShift Virtualization 存储类:
$ oc get sc -o jsonpath='{.items[?(@.metadata.annotations.storageclass\.kubevirt\.io/is-default-virt-class=="true")].metadata.name}'
如果存在默认的 OpenShift Virtualization 存储类,请运行以下命令检查它是否支持 ReadWriteMany:
$ oc get storageprofile <storage_class> -o json | jq '.status.claimPropertySets'| grep ReadWriteMany
如果没有默认的 OpenShift Virtualization 存储类,请运行以下命令来获取默认的 OpenShift Dedicated 存储类:
$ oc get sc -o jsonpath='{.items[?(@.metadata.annotations.storageclass\.kubevirt\.io/is-default-class=="true")].metadata.name}'
如果存在默认的 OpenShift Dedicated 存储类,请运行以下命令检查它是否支持 ReadWriteMany:
$ oc get storageprofile <storage_class> -o json | jq '.status.claimPropertySets'| grep ReadWriteMany
缓解方案
确保有一个默认存储类 OpenShift Dedicated 或 OpenShift Virtualization,并且默认存储类支持智能克隆和 ReadWriteMany。
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.4. CDIMultipleDefaultVirtStorageClasses
含义
当多个存储类具有注解 storageclass.kubevirt.io/is-default-virt-class: "true"
时,此警报会触发。
影响
storageclass.kubevirt.io/is-default-virt-class: "true"
注解定义了默认的 OpenShift Virtualization 存储类。
如果定义了多个默认 OpenShift Virtualization 存储类,则没有指定存储类的数据卷会接收最近创建的默认存储类。
诊断
运行以下命令,获取默认 OpenShift Virtualization 存储类列表:
$ oc get sc -o jsonpath='{.items[?(@.metadata.annotations.storageclass\.kubevirt\.io/is-default-virt-class=="true")].metadata.name}'
缓解方案
通过从其他存储类中删除注解,确保只定义一个默认 OpenShift Virtualization 存储类。
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.5. CDINoDefaultStorageClass
含义
当没有定义默认的 OpenShift Dedicated 或 OpenShift Virtualization 存储类时,此警报会触发。
影响
如果没有定义默认的 OpenShift Dedicated 或 OpenShift Virtualization 存储类,则请求默认存储类(未指定存储类)的数据卷会处于"pending"状态。
诊断
运行以下命令,检查默认的 OpenShift Dedicated 存储类:
$ oc get sc -o jsonpath='{.items[?(@.metadata.annotations.storageclass\.kubevirt\.io/is-default-class=="true")].metadata.name}'
运行以下命令,检查默认的 OpenShift Virtualization 存储类:
$ oc get sc -o jsonpath='{.items[?(@.metadata.annotations.storageclass\.kubevirt\.io/is-default-virt-class=="true")].metadata.name}'
缓解方案
为 OpenShift Dedicated 或 OpenShift Virtualization 创建默认存储类。
默认 OpenShift Virtualization 存储类优先于默认的 OpenShift Dedicated 存储类来创建虚拟机磁盘镜像。
运行以下命令来创建默认的 OpenShift Dedicated 存储类:
$ oc patch storageclass <storage-class-name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
运行以下命令来创建默认的 OpenShift Virtualization 存储类:
$ oc patch storageclass <storage-class-name> -p '{"metadata": {"annotations":{"storageclass.kubevirt.io/is-default-virt-class":"true"}}}'
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.6. CDINotReady
含义
当 Containerized Data Importer (CDI) 处于降级状态时,此警报会触发:
- Not progressing
- 不可用
影响
CDI 不可用,因此用户无法使用 CDI 数据卷在持久性卷声明 (PVC) 上构建虚拟机磁盘。CDI 组件未就绪,它们停止进入就绪状态。
诊断
设置
CDI_NAMESPACE
环境变量:$ export CDI_NAMESPACE="$(oc get deployment -A | \ grep cdi-operator | awk '{print $1}')"
检查 CDI 部署是否有未就绪的组件:
$ oc -n $CDI_NAMESPACE get deploy -l cdi.kubevirt.io
检查故障 pod 的详情:
$ oc -n $CDI_NAMESPACE describe pods <pod>
检查故障 pod 的日志:
$ oc -n $CDI_NAMESPACE logs <pod>
缓解方案
尝试确定根本原因并解决问题。
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.7. CDIOperatorDown
含义
当 Containerized Data Importer (CDI) Operator 停机时,此警报会触发。CDI Operator 部署并管理 CDI 基础架构组件,如数据卷和持久性卷声明 (PVC) 控制器。这些控制器可帮助用户在 PVC 上构建虚拟机磁盘。
影响
CDI 组件可能无法部署或保持所需状态。CDI 安装可能无法正常工作。
诊断
设置
CDI_NAMESPACE
环境变量:$ export CDI_NAMESPACE="$(oc get deployment -A | grep cdi-operator | \ awk '{print $1}')"
检查
cdi-operator
pod 当前是否正在运行:$ oc -n $CDI_NAMESPACE get pods -l name=cdi-operator
获取
cdi-operator
pod 的详情:$ oc -n $CDI_NAMESPACE describe pods -l name=cdi-operator
检查
cdi-operator
pod 的日志中的错误:$ oc -n $CDI_NAMESPACE logs -l name=cdi-operator
缓解方案
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.8. CDIStorageProfilesIncomplete
含义
当 Containerized Data Importer (CDI) 存储配置集不完整时,此警报会触发。
如果存储配置集不完整,CDI 无法推断持久性卷声明(PVC) 字段,如 volumeMode
和 accessModes
,这是创建虚拟机 (VM) 磁盘所需的。
影响
CDI 无法在 PVC 上创建虚拟机磁盘。
诊断
确定不完整的存储配置集:
$ oc get storageprofile <storage_class>
缓解方案
添加缺少的存储配置集信息,如下例所示:
$ oc patch storageprofile <storage_class> --type=merge -p '{"spec": {"claimPropertySets": [{"accessModes": ["ReadWriteOnce"], "volumeMode": "Filesystem"}]}}'
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.9. CnaoDown
含义
当 Cluster Network Addons Operator (CNAO) 停机时,此警报会触发。CNAO 在集群之上部署额外网络组件。
影响
如果 CNAO 没有运行,集群无法协调对虚拟机组件的更改。因此,更改可能无法生效。
诊断
设置
NAMESPACE
环境变量:$ export NAMESPACE="$(oc get deployment -A | \ grep cluster-network-addons-operator | awk '{print $1}')"
检查
cluster-network-addons-operator
pod 的状态:$ oc -n $NAMESPACE get pods -l name=cluster-network-addons-operator
检查
cluster-network-addons-operator
日志中的错误消息:$ oc -n $NAMESPACE logs -l name=cluster-network-addons-operator
获取
cluster-network-addons-operator
pod 的详情:$ oc -n $NAMESPACE describe pods -l name=cluster-network-addons-operator
缓解方案
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.10. HCOInstallationIncomplete
含义
当 HyperConverged Cluster Operator (HCO) 在没有 HyperConverged
自定义资源 (CR) 的情况下运行超过一小时,此警报会触发。
这个警报的原因如下:
-
在安装过程中,您安装了 HCO,但不会创建
HyperConverged
CR。 -
在卸载过程中,在卸载 HCO 前删除了
HyperConverged
CR,HCO 仍在运行。
缓解方案
缓解措施取决于您是否要安装或卸载 HCO:
使用默认值创建
HyperConverged
CR 来完成安装:$ cat <<EOF | oc apply -f - apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: hco-operatorgroup namespace: kubevirt-hyperconverged spec: {} EOF
- 卸载 HCO。如果卸载过程继续运行,您必须解决这个问题才能取消警报。
11.5.11. HPPNotReady
含义
当 hostpath 置备程序 (HPP) 安装处于降级状态时,此警报会触发。
HPP 动态置备 hostpath 卷,以便为持久性卷声明 (PVC) 提供存储。
影响
HPP 不可用。其组件未就绪,它们没有进入就绪状态。
诊断
设置
HPP_NAMESPACE
环境变量:$ export HPP_NAMESPACE="$(oc get deployment -A | \ grep hostpath-provisioner-operator | awk '{print $1}')"
检查当前未就绪的 HPP 组件:
$ oc -n $HPP_NAMESPACE get all -l k8s-app=hostpath-provisioner
获取故障 pod 的详细信息:
$ oc -n $HPP_NAMESPACE describe pods <pod>
检查故障 pod 的日志:
$ oc -n $HPP_NAMESPACE logs <pod>
缓解方案
根据诊断过程中获取的信息,尝试识别根本原因并解决问题。
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.12. HPPOperatorDown
含义
当 hostpath 置备程序 (HPP) Operator 停机时,此警报会触发。
HPP Operator 部署并管理 HPP 基础架构组件,如置备 hostpath 卷的守护进程集。
影响
HPP 组件可能无法部署或保持在所需状态。因此,HPP 安装可能无法在集群中正常工作。
诊断
配置
HPP_NAMESPACE
环境变量:$ HPP_NAMESPACE="$(oc get deployment -A | grep \ hostpath-provisioner-operator | awk '{print $1}')"
检查
hostpath-provisioner-operator
pod 当前是否正在运行:$ oc -n $HPP_NAMESPACE get pods -l name=hostpath-provisioner-operator
获取
hostpath-provisioner-operator
pod 的详细信息:$ oc -n $HPP_NAMESPACE describe pods -l name=hostpath-provisioner-operator
检查
hostpath-provisioner-operator
pod 的日志中的错误:$ oc -n $HPP_NAMESPACE logs -l name=hostpath-provisioner-operator
缓解方案
根据诊断过程中获取的信息,尝试识别根本原因并解决问题。
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.13. HPPSharingPoolPathWithOS
含义
当 hostpath 置备程序 (HPP) 与其他关键组件(如 kubelet
或操作系统 (OS))共享文件系统时,此警报会触发。
HPP 动态置备 hostpath 卷,以便为持久性卷声明 (PVC) 提供存储。
影响
共享 hostpath 池给节点磁盘带来压力。该节点的性能和稳定性可能会降低。
诊断
配置
HPP_NAMESPACE
环境变量:$ export HPP_NAMESPACE="$(oc get deployment -A | \ grep hostpath-provisioner-operator | awk '{print $1}')"
获取
hostpath-provisioner-csi
守护进程设置 pod 的状态:$ oc -n $HPP_NAMESPACE get pods | grep hostpath-provisioner-csi
检查
hostpath-provisioner-csi
日志,以识别共享池和路径:$ oc -n $HPP_NAMESPACE logs <csi_daemonset> -c hostpath-provisioner
输出示例
I0208 15:21:03.769731 1 utils.go:221] pool (<legacy, csi-data-dir>/csi), shares path with OS which can lead to node disk pressure
缓解方案
使用 Diagnosis 部分中获取的数据,尝试防止池路径与操作系统共享。具体步骤因节点和其它情况而异。
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.14. KubemacpoolDown
含义
KubeMacPool
已关闭。KubeMacPool
负责分配 MAC 地址并防止 MAC 地址冲突。
影响
如果 KubeMacPool
停机,则无法创建 VirtualMachine
对象。
诊断
设置
KMP_NAMESPACE
环境变量:$ export KMP_NAMESPACE="$(oc get pod -A --no-headers -l \ control-plane=mac-controller-manager | awk '{print $1}')"
设置
KMP_NAME
环境变量:$ 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
检查
KubeMacPool-manager
日志中的错误消息:$ oc logs -n $KMP_NAMESPACE $KMP_NAME
缓解方案
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.15. KubeMacPoolDuplicateMacsFound
含义
当 KubeMacPool
检测到重复的 MAC 地址时,此警报会触发。
KubeMacPool
负责分配 MAC 地址并防止 MAC 地址冲突。当 KubeMacPool
启动时,它会为受管命名空间中的虚拟机 (VM) 的 MAC 地址扫描集群。
影响
同一 LAN 上的重复 MAC 地址可能会导致网络问题。
诊断
获取
kubemacpool-mac-controller
pod 的命名空间和名称:$ oc get pod -A -l control-plane=mac-controller-manager --no-headers \ -o custom-columns=":metadata.namespace,:metadata.name"
从
kubemacpool-mac-controller
日志获取重复的 MAC 地址:$ oc logs -n <namespace> <kubemacpool_mac_controller> | \ grep "already allocated"
输出示例
mac address 02:00:ff:ff:ff:ff already allocated to vm/kubemacpool-test/testvm, br1, conflict with: vm/kubemacpool-test/testvm2, br1
缓解方案
- 更新虚拟机以删除重复的 MAC 地址。
重启
kubemacpool-mac-controller
pod:$ oc delete pod -n <namespace> <kubemacpool_mac_controller>
11.5.16. KubeVirtComponentExceedsRequestedCPU
含义
当组件的 CPU 用量超过请求的限制时,此警报会触发。
影响
CPU 资源的使用不是最佳的,节点可能会超载。
诊断
设置
NAMESPACE
环境变量:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
检查组件的 CPU 请求限制:
$ oc -n $NAMESPACE get deployment <component> -o yaml | grep requests: -A 2
使用 PromQL 查询来检查实际 CPU 用量:
node_namespace_pod_container:container_cpu_usage_seconds_total:sum_rate {namespace="$NAMESPACE",container="<component>"}
如需更多信息,请参阅 Prometheus 文档。
缓解方案
更新 HCO
自定义资源中的 CPU 请求限制。
11.5.17. KubeVirtComponentExceedsRequestedMemory
含义
当组件的内存用量超过请求的限制时,此警报会触发。
影响
使用内存资源不是最佳的,节点可能会超载。
诊断
设置
NAMESPACE
环境变量:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
检查组件的内存请求限制:
$ oc -n $NAMESPACE get deployment <component> -o yaml | \ grep requests: -A 2
使用 PromQL 查询来检查实际内存用量:
container_memory_usage_bytes{namespace="$NAMESPACE",container="<component>"}
如需更多信息,请参阅 Prometheus 文档。
缓解方案
更新 HCO
自定义资源中的内存请求限制。
11.5.18. KubeVirtCRModified
含义
当 HyperConverged Cluster Operator (HCO) 的操作对象由 HCO 以外的其他对象更改时,此警报将触发。
HCO 以建议的方式配置 OpenShift Virtualization 及其支持 Operator,并在其出现意外更改时覆盖其操作对象。用户不得直接修改操作对象。HyperConverged
自定义资源是配置的真实来源。
影响
手动更改操作对象会导致集群配置波动,并可能导致不稳定。
诊断
检查警报详情中的
component_name
值,以确定要更改的操作对象类型 (kubevirt
) 和操作对象名称 (kubevirt-kubevirt-hyperconverged
):Labels alertname=KubevirtHyperconvergedClusterOperatorCRModification component_name=kubevirt/kubevirt-kubevirt-hyperconverged severity=warning
缓解方案
不要直接更改 HCO 操作对象。使用 HyperConverged
对象配置集群。
如果没有手动更改操作对象,警报会在 10 分钟后解决。
11.5.19. KubeVirtDeprecatedAPIRequested
含义
当使用已弃用的 KubeVirt
API 时,此警报会触发。
影响
不建议使用已弃用的 API,因为在以后的版本中删除 API 时请求将失败。
诊断
检查警报的 Description 和 Summary 部分,以识别已弃用的 API,如下例所示:
描述
检测到已弃用的 virtualmachines.kubevirt.io/v1alpha3 API 的请求。
概述
在过去 10 分钟内检测到 2 个请求。
缓解方案
使用完全支持的 API。如果没有使用已弃用的 API,警报会在 10 分钟后解决。
11.5.20. KubeVirtNoAvailableNodesToRunVMs
含义
当集群中的节点 CPU 不支持虚拟化或虚拟化扩展时,此警报会触发。
影响
节点必须支持虚拟化,且必须在 BIOS 中启用虚拟化功能来运行虚拟机 (VM)。
诊断
检查节点是否有硬件虚拟化支持:
$ oc get nodes -o json|jq '.items[]|{"name": .metadata.name, "kvm": .status.allocatable["devices.kubevirt.io/kvm"]}'
输出示例
{ "name": "shift-vwpsz-master-0", "kvm": null } { "name": "shift-vwpsz-master-1", "kvm": null } { "name": "shift-vwpsz-master-2", "kvm": null } { "name": "shift-vwpsz-worker-8bxkp", "kvm": "1k" } { "name": "shift-vwpsz-worker-ctgmc", "kvm": "1k" } { "name": "shift-vwpsz-worker-gl5zl", "kvm": "1k" }
带有
"kvm": null
或"kvm": 0
的节点不支持虚拟化扩展。带有
"kvm": "1k"
的节点支持虚拟化扩展。
缓解方案
确保所有节点上启用了硬件和 CPU 虚拟化扩展,并且节点已正确标记。
详情请参阅 OpenShift Virtualization 报告没有可用的节点,无法启动虚拟机。
如果您无法解决这个问题,登录到客户门户网站 并创建一个支持问题单。
11.5.21. KubevirtVmHighMemoryUsage
含义
当托管虚拟机 (VM) 的容器小于 20 MB 可用内存时,此警报将触发。
影响
如果超过容器的内存限值,则容器中运行的虚拟机由运行时终止。
诊断
获取
virt-launcher
pod 详情:$ oc get pod <virt-launcher> -o yaml
在
virt-launcher
pod 中识别具有高内存使用量的计算
容器进程:$ oc exec -it <virt-launcher> -c compute -- top
缓解方案
在
VirtualMachine
规格中增加内存限值,如下例所示:spec: running: false template: metadata: labels: kubevirt.io/vm: vm-name spec: domain: resources: limits: memory: 200Mi requests: memory: 128Mi
11.5.22. KubeVirtVMIExcessiveMigrations
含义
当虚拟机实例 (VMI) 在 24 小时内迁移超过 12 次时,此警报将触发。
这个迁移率通常很高,即使在升级过程中也是如此。此警报可能表示集群基础架构中有问题,如网络中断或资源不足。
影响
迁移经常迁移的虚拟机 (VM) 可能会遇到性能下降,因为内存页面在转换过程中发生了错误。
诊断
验证 worker 节点是否有足够资源:
$ oc get nodes -l node-role.kubernetes.io/worker= -o json | \ jq .items[].status.allocatable
输出示例
{ "cpu": "3500m", "devices.kubevirt.io/kvm": "1k", "devices.kubevirt.io/sev": "0", "devices.kubevirt.io/tun": "1k", "devices.kubevirt.io/vhost-net": "1k", "ephemeral-storage": "38161122446", "hugepages-1Gi": "0", "hugepages-2Mi": "0", "memory": "7000128Ki", "pods": "250" }
检查 worker 节点的状态:
$ oc get nodes -l node-role.kubernetes.io/worker= -o json | \ jq .items[].status.conditions
输出示例
{ "lastHeartbeatTime": "2022-05-26T07:36:01Z", "lastTransitionTime": "2022-05-23T08:12:02Z", "message": "kubelet has sufficient memory available", "reason": "KubeletHasSufficientMemory", "status": "False", "type": "MemoryPressure" }, { "lastHeartbeatTime": "2022-05-26T07:36:01Z", "lastTransitionTime": "2022-05-23T08:12:02Z", "message": "kubelet has no disk pressure", "reason": "KubeletHasNoDiskPressure", "status": "False", "type": "DiskPressure" }, { "lastHeartbeatTime": "2022-05-26T07:36:01Z", "lastTransitionTime": "2022-05-23T08:12:02Z", "message": "kubelet has sufficient PID available", "reason": "KubeletHasSufficientPID", "status": "False", "type": "PIDPressure" }, { "lastHeartbeatTime": "2022-05-26T07:36:01Z", "lastTransitionTime": "2022-05-23T08:24:15Z", "message": "kubelet is posting ready status", "reason": "KubeletReady", "status": "True", "type": "Ready" }
登录到 worker 节点并验证
kubelet
服务是否正在运行:$ systemctl status kubelet
检查
kubelet
日志中的错误信息:$ journalctl -r -u kubelet
缓解方案
确保 worker 节点有足够的资源 (CPU、内存、磁盘) 在不中断的情况下运行虚拟机工作负载。
如果问题仍然存在,请尝试确定根本原因并解决问题。
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.23. LowKVMNodesCount
含义
当集群中少于两个节点具有 KVM 资源时,此警报将触发。
影响
集群必须至少有两个使用 KVM 资源的节点进行实时迁移。
如果没有节点有 KVM 资源,则无法调度或运行虚拟机。
诊断
使用 KVM 资源识别节点:
$ oc get nodes -o jsonpath='{.items[*].status.allocatable}' | \ grep devices.kubevirt.io/kvm
缓解方案
在没有 KVM 资源的节点上安装 KVM。
11.5.24. LowReadyVirtControllersCount
含义
当一个或多个 virt-controller
pod 正在运行时,此警报会触发,但过去 5 分钟没有这些 pod 处于 Ready
状态。
virt-controller
设备监控虚拟机实例 (VMI) 的自定义资源定义 (CRD) 并管理关联的 pod。该设备为 VMI 创建 pod 并管理其生命周期。该设备对于集群范围的虚拟化功能至关重要。
影响
此警报表示可能会出现集群级别的故障。与虚拟机生命周期管理相关的操作(如启动新的 VMI 或关闭现有的 VMI)将失败。
诊断
设置
NAMESPACE
环境变量:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
验证
virt-controller
设备是否可用:$ oc get deployment -n $NAMESPACE virt-controller \ -o jsonpath='{.status.readyReplicas}'
检查
virt-controller
部署的状态:$ oc -n $NAMESPACE get deploy virt-controller -o yaml
获取
virt-controller
部署的详情来检查状态状况,如崩溃 pod 或拉取镜像失败:$ oc -n $NAMESPACE describe deploy virt-controller
检查节点是否出现任何问题。例如,它们可能处于
NotReady
状态:$ oc get nodes
缓解方案
此警报可以有多个原因,包括:
- 集群没有足够的内存。
- 节点已停机。
- API 服务器已过载。例如,调度程序可能负载过重,因此无法完全可用。
- 存在网络问题。
尝试确定根本原因并解决问题。
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.25. LowReadyVirtOperatorsCount
含义
当一个或多个 virt-operator
pod 正在运行时,此警报会触发,但最后 10 分钟没有这些 pod 处于 Ready
状态。
virt-operator
是集群中启动的第一个 Operator。virt-operator
部署有两个 virt-operator
pod 的默认副本。
其主要职责包括:
- 安装、实时迁移和实时迁移集群
-
监控顶层控制器的生命周期,如
virt-controller
、virt-handler
、virt-launcher
,并管理它们的协调 - 某些集群范围的任务,如证书轮转和基础架构管理
影响
可能会出现集群级别的故障。关键的集群范围的管理功能(如认证轮转、升级和协调)可能不可用。这种状态也会触发 NoReadyVirtOperator
警报。
virt-operator
不直接负责集群中的虚拟机 (VM)。因此,它的临时不可用不会影响虚拟机工作负载。
诊断
设置
NAMESPACE
环境变量:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
获取
virt-operator
部署的名称:$ oc -n $NAMESPACE get deploy virt-operator -o yaml
获取
virt-operator
部署的详情:$ oc -n $NAMESPACE describe deploy virt-operator
检查节点问题,如
NotReady
状态:$ oc get nodes
缓解方案
根据诊断过程中获取的信息,尝试识别根本原因并解决问题。
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.26. LowVirtAPICount
含义
此警报在 60 分钟期间仅检测到一个可用的 virt-api
pod,但至少有两个节点可用于调度。
影响
在节点驱除过程中可能会出现 API 调用中断,因为 virt-api
pod 成为单点故障。
诊断
设置
NAMESPACE
环境变量:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
检查可用的
virt-api
pod 数量:$ oc get deployment -n $NAMESPACE virt-api \ -o jsonpath='{.status.readyReplicas}'
检查
virt-api
部署的状态是否有错误条件:$ oc -n $NAMESPACE get deploy virt-api -o yaml
检查节点是否有问题,如处于
NotReady
状态的节点:$ oc get nodes
缓解方案
尝试确定根本原因,并解决此问题。
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.27. LowVirtControllersCount
含义
当检测到少量 virt-controller
pod 时,此警报会触发。至少有一个 virt-controller
pod 必须可用才能保证高可用性。默认副本数为 2。
virt-controller
设备监控虚拟机实例 (VMI) 的自定义资源定义 (CRD) 并管理关联的 pod。设备为 VMI 创建 pod,并管理 pod 的生命周期。该设备对于集群范围的虚拟化功能至关重要。
影响
OpenShift Virtualization 的响应可能会受到负面影响。例如,可能会错过某些请求。
另外,如果另一个 virt-launcher
实例意外终止,OpenShift Virtualization 可能会完全响应。
诊断
设置
NAMESPACE
环境变量:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
验证运行
virt-controller
pod 是否可用:$ oc -n $NAMESPACE get pods -l kubevirt.io=virt-controller
检查
virt-launcher
日志中的错误信息:$ oc -n $NAMESPACE logs <virt-launcher>
获取
virt-launcher
pod 的详情,以检查状态条件,如意外终止或NotReady
状态。$ oc -n $NAMESPACE describe pod/<virt-launcher>
缓解方案
这个警报可能会有各种原因,包括:
- 集群没有足够内存
- 节点已停机
- API 服务器已过载。例如,调度程序可能负载过重,因此无法完全可用。
- 网络问题
确定根本原因,并在可能的情况下修复该原因。
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.28. LowVirtOperatorCount
含义
当过去 60 分钟内只有一个状态为 Ready
的 virt-operator
pod 正在运行时,此警报会触发。
virt-operator
是集群中启动的第一个 Operator。其主要职责包括:
- 安装、实时迁移和实时迁移集群
-
监控顶层控制器的生命周期,如
virt-controller
、virt-handler
、virt-launcher
,并管理它们的协调 - 某些集群范围的任务,如证书轮转和基础架构管理
影响
virt-operator
无法为部署提供高可用性(HA)。HA 需要两个或更多 virt-operator
pod 处于 Ready
状态。默认部署是两个 pod。
virt-operator
不直接负责集群中的虚拟机 (VM)。因此,其可用性的减少不会影响虚拟机工作负载。
诊断
设置
NAMESPACE
环境变量:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
检查
virt-operator
pod 的状态:$ oc -n $NAMESPACE get pods -l kubevirt.io=virt-operator
查看受影响的
virt-operator
pod 的日志:$ oc -n $NAMESPACE logs <virt-operator>
获取受影响的
virt-operator
pod 的详情:$ oc -n $NAMESPACE describe pod <virt-operator>
缓解方案
根据诊断过程中获取的信息,尝试识别根本原因并解决问题。
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.29. NetworkAddonsConfigNotReady
含义
当 Cluster Network Addons Operator (CNAO) 的 NetworkAddonsConfig
自定义资源(CR) 未就绪时,此警报会触发。
CNAO 在集群中部署额外网络组件。此警报表示其中一个部署的组件未就绪。
影响
网络功能会受到影响。
诊断
检查
NetworkAddonsConfig
CR 的状态条件,以识别未就绪的部署或守护进程集:$ oc get networkaddonsconfig \ -o custom-columns="":.status.conditions[*].message
输出示例
DaemonSet "cluster-network-addons/macvtap-cni" update is being processed...
检查组件的 pod 中的错误:
$ oc -n cluster-network-addons get daemonset <pod> -o yaml
检查组件的日志:
$ oc -n cluster-network-addons logs <pod>
检查组件的详情中的错误条件:
$ oc -n cluster-network-addons describe <pod>
缓解方案
尝试确定根本原因并解决问题。
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.30. NoLeadingVirtOperator
含义
当检测到具有领导租期的 virt-operator
pod 达到 10 分钟时,此警报会触发,但 virt-operator
pod 处于 Ready
状态。该警报表示没有领导 pod 可用。
virt-operator
是集群中启动的第一个 Operator。其主要职责包括:
- 安装、实时更新和实时升级集群
-
监控顶层控制器的生命周期,如
virt-controller
、virt-handler
、virt-launcher
,并管理它们的协调 - 某些集群范围的任务,如证书轮转和基础架构管理
virt-operator
部署具有 2 个 pod 的默认副本,一个 pod 包含领导租期。
影响
此警报表示集群级别的故障。因此,关键集群范围的管理功能(如认证轮转、升级和控制器协调)可能不可用。
诊断
设置
NAMESPACE
环境变量:$ export NAMESPACE="$(oc get kubevirt -A -o \ custom-columns="":.metadata.namespace)"
获取
virt-operator
pod 的状态:$ oc -n $NAMESPACE get pods -l kubevirt.io=virt-operator
检查
virt-operator
pod 日志以确定领导状态:$ oc -n $NAMESPACE logs | grep lead
领导 pod 示例:
{"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 示例:
{"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 的详情:$ oc -n $NAMESPACE describe pod <virt-operator>
缓解方案
根据诊断过程中获取的信息,尝试查找根本原因并解决问题。
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.31. NoReadyVirtController
含义
当没有检测到可用的 virt-controller
设备 5 分钟时,此警报将触发。
virt-controller
设备监控虚拟机实例 (VMI) 的自定义资源定义并管理关联的 pod。设备为 VMI 创建 pod,并管理 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 jsonpath='{.status.readyReplicas}'
检查
virt-controller
部署的状态:$ oc -n $NAMESPACE get deploy virt-controller -o yaml
获取
virt-controller
部署的详情,以检查崩溃 pod 或无法拉取镜像的状态条件:$ oc -n $NAMESPACE describe deploy virt-controller
获取
virt-controller
pod 的详情:$ get pods -n $NAMESPACE | grep virt-controller
检查
virt-controller
pod 的日志是否有错误消息:$ oc logs -n $NAMESPACE <virt-controller>
检查节点是否有问题,如
NotReady
状态:$ oc get nodes
缓解方案
根据诊断过程中获取的信息,尝试查找根本原因并解决问题。
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.32. NoReadyVirtOperator
含义
当没有检测到 Ready
状态的 virt-operator
pod 达到 10 分钟时,此警报将触发。
virt-operator
是集群中启动的第一个 Operator。其主要职责包括:
- 安装、实时迁移和实时迁移集群
-
监控顶层控制器的生命周期,如
virt-controller
、virt-handler
、virt-launcher
,并管理它们的协调 - 某些集群范围的任务,如证书轮转和基础架构管理
默认部署是两个 virt-operator
pod。
影响
此警报表示集群级别的失败。关键集群管理功能(如认证轮转、升级和协调)可能不可用。
virt-operator
不直接负责集群中的虚拟机。因此,它的临时不可用不会影响工作负载。
诊断
设置
NAMESPACE
环境变量:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
获取
virt-operator
部署的名称:$ oc -n $NAMESPACE get deploy virt-operator -o yaml
生成
virt-operator
部署的描述:$ oc -n $NAMESPACE describe deploy virt-operator
检查节点问题,如
NotReady
状态:$ oc get nodes
缓解方案
根据诊断过程中获取的信息,尝试识别根本原因并解决问题。
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.33. OrphanedVirtualMachineInstances
含义
当虚拟机实例 (VMI) 或 virt-launcher
pod 在没有运行 virt-handler
pod 的节点上运行时,此警报将触发。这个 VMI 被称为是孤立。
影响
无法管理孤立的 VMI。
诊断
检查
virt-handler
pod 的状态,以查看它们运行的节点:$ oc get pods --all-namespaces -o wide -l kubevirt.io=virt-handler
检查 VMI 的状态,以识别在没有运行
virt-handler
pod 的节点上运行的 VMI:$ oc get vmis --all-namespaces
检查
virt-handler
守护进程的状态:$ oc get daemonset virt-handler --all-namespaces
输出示例
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE ... virt-handler 2 2 2 2 2 ...
如果
Desired
、Ready
和Available
列包含相同的值,守护进程集被视为健康。如果
virt-handler
守护进程集不正常,请检查virt-handler
守护进程集是否有 pod 部署问题:$ oc get daemonset virt-handler --all-namespaces -o yaml | jq .status
检查节点是否有问题,如
NotReady
状态:$ oc get nodes
检查
KubeVirt
自定义资源 (CR) 的spec.workloads
小节,以了解工作负载放置策略:$ oc get kubevirt kubevirt --all-namespaces -o yaml
缓解方案
如果配置了工作负载放置策略,请将带有 VMI 的节点添加到策略中。
从节点中删除 virt-handler
pod 的原因包括更改节点的污点和容限和容限,或 pod 的调度规则。
尝试确定根本原因并解决问题。
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.34. OutdatedVirtualMachineInstanceWorkloads
含义
当在 OpenShift Virtualization control plane 更新后的 24 小时后检测到过时的 virt-launcher
pod 中运行的虚拟机实例 (VMI) 时会触发此警报。
影响
过时的 VMI 可能无法访问新的 OpenShift Virtualization 功能。
过时的 VMI 将不会收到与 virt-launcher
pod 更新相关的安全修复。
诊断
识别过时的 VMI:
$ oc get vmi -l kubevirt.io/outdatedLauncherImage --all-namespaces
检查
KubeVirt
自定义资源 (CR) 以确定workloadUpdateMethods
是否在workloadUpdateStrategy
小节中配置:$ oc get kubevirt --all-namespaces -o yaml
检查每个过时的 VMI,以确定它是否是实时的:
$ oc get vmi <vmi> -o yaml
输出示例
apiVersion: kubevirt.io/v1 kind: VirtualMachineInstance # ... status: conditions: - lastProbeTime: null lastTransitionTime: null message: cannot migrate VMI which does not use masquerade to connect to the pod network reason: InterfaceNotLiveMigratable status: "False" type: LiveMigratable
缓解方案
配置自动工作负载更新
更新 HyperConverged
CR,以启用自动工作负载更新。
停止与非可维护 VMI 关联的虚拟机
如果 VMI 不是可实时迁移的,且在对应的
VirtualMachine
对象中设置了runStrategy: always
,您可以通过手动停止虚拟机 (VM) 来更新 VMI:$ virctl stop --namespace <namespace> <vm>
新的 VMI 在更新的 virt-launcher
pod 中立即启动,以替换已停止的 VMI。这等同于 restart 操作。
手动停止 live-migratable 虚拟机具有破坏性且不推荐,因为它会中断工作负载。
迁移可迁移的VMI
如果 VMI 是可实时迁移的,您可以通过创建一个以特定正在运行的 VMI 的 VirtualMachineInstanceMigration
对象来更新它。VMI 被迁移到更新的 virt-launcher
pod 中。
创建
VirtualMachineInstanceMigration
清单,并将它保存为migration.yaml
:apiVersion: kubevirt.io/v1 kind: VirtualMachineInstanceMigration metadata: name: <migration_name> namespace: <namespace> spec: vmiName: <vmi_name>
创建
VirtualMachineInstanceMigration
对象来触发迁移:$ oc create -f migration.yaml
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.35. SingleStackIPv6Unsupported
含义
当您在单一堆栈 IPv6 集群上安装 OpenShift Virtualization 时,此警报会触发。
影响
您无法创建虚拟机。
诊断
运行以下命令检查集群网络配置:
$ oc get network.config cluster -o yaml
输出中仅显示集群网络的 IPv6 CIDR。
输出示例
apiVersion: config.openshift.io/v1 kind: Network metadata: name: cluster spec: clusterNetwork: - cidr: fd02::/48 hostPrefix: 64
缓解方案
在单一堆栈 IPv4 集群或双堆栈 IPv4/IPv6 集群上安装 OpenShift Virtualization。
11.5.36. SSPCommonTemplatesModificationReverted
含义
当 Scheduling、Scale 和 Performance (SSP) Operator 将更改恢复到其协调流程的一部分时,此警报会触发。
SSP Operator 部署并协调通用模板和 Template Validator。如果用户或脚本更改了通用模板,则 SSP Operator 会恢复更改。
影响
对常见模板的更改会被覆盖。
诊断
设置
NAMESPACE
环境变量:$ export NAMESPACE="$(oc get deployment -A | grep ssp-operator | \ awk '{print $1}')"
检查
ssp-operator
日志是否有带有恢复更改的模板:$ oc -n $NAMESPACE logs --tail=-1 -l control-plane=ssp-operator | \ grep 'common template' -C 3
缓解方案
尝试识别并解决更改的原因。
确保仅对模板的副本进行更改,而不仅限于模板本身。
11.5.37. SSPDown
含义
当所有 Scheduling、Scale 和 Performance (SSP) Operator pod 都停机时,此警报会触发。
SSP Operator 负责部署和协调通用模板和模板验证器。
影响
独立组件可能无法部署。组件的更改可能无法协调。因此,如果模板和/或 Template Validator 失败时,可能无法更新或重置它们。
诊断
设置
NAMESPACE
环境变量:$ 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
检查
ssp-operator
日志中的错误消息:$ oc -n $NAMESPACE logs --tail=-1 -l control-plane=ssp-operator
缓解方案
尝试确定根本原因并解决问题。
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.38. SSPFailingToReconcile
含义
当 Scheduling, Scale and Performance (SSP) Operator 的协调周期重复失败时,此警报会触发,但 SSP Operator 正在运行。
SSP Operator 负责部署和协调通用模板和模板验证器。
影响
独立组件可能无法部署。组件的更改可能无法协调。因此,如果通用模板失败,则可能无法更新或重置通用模板或模板验证器。
诊断
导出
NAMESPACE
环境变量:$ export NAMESPACE="$(oc get deployment -A | grep ssp-operator | \ awk '{print $1}')"
获取
ssp-operator
pod 的详细信息:$ oc -n $NAMESPACE describe pods -l control-plane=ssp-operator
检查
ssp-operator
日志中的错误:$ oc -n $NAMESPACE logs --tail=-1 -l control-plane=ssp-operator
获取
virt-template-validator
pod 的状态:$ oc -n $NAMESPACE get pods -l name=virt-template-validator
获取
virt-template-validator
pod 的详情:$ oc -n $NAMESPACE describe pods -l name=virt-template-validator
检查
virt-template-validator
日志中的错误:$ oc -n $NAMESPACE logs --tail=-1 -l name=virt-template-validator
缓解方案
尝试确定根本原因并解决问题。
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.39. SSPHighRateRejectedVms
含义
当用户或脚本尝试使用无效配置创建或修改大量虚拟机(VM) 时,此警报会触发。
影响
虚拟机不会被创建或修改。因此,环境可能无法如预期的行为。
诊断
导出
NAMESPACE
环境变量:$ export NAMESPACE="$(oc get deployment -A | grep ssp-operator | \ awk '{print $1}')"
检查
virt-template-validator
日志,以了解可能代表原因的错误:$ oc -n $NAMESPACE logs --tail=-1 -l name=virt-template-validator
输出示例
{"component":"kubevirt-template-validator","level":"info","msg":"evalution summary for ubuntu-3166wmdbbfkroku0:\nminimal-required-memory applied: FAIL, value 1073741824 is lower than minimum [2147483648]\n\nsucceeded=false", "pos":"admission.go:25","timestamp":"2021-09-28T17:59:10.934470Z"}
缓解方案
尝试确定根本原因并解决问题。
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.40. SSPTemplateValidatorDown
含义
当所有 Template Validator pod 都停机时,此警报将触发。
Template Validator 检查虚拟机 (VM),以确保它们不会违反其模板。
影响
虚拟机不会根据其模板进行验证。因此,可以使用与对应工作负载不匹配的规格创建虚拟机。
诊断
设置
NAMESPACE
环境变量:$ export NAMESPACE="$(oc get deployment -A | grep ssp-operator | \ awk '{print $1}')"
获取
virt-template-validator
pod 的状态:$ oc -n $NAMESPACE get pods -l name=virt-template-validator
获取
virt-template-validator
pod 的详情:$ oc -n $NAMESPACE describe pods -l name=virt-template-validator
检查
virt-template-validator
日志中的错误消息:$ oc -n $NAMESPACE logs --tail=-1 -l name=virt-template-validator
缓解方案
尝试确定根本原因并解决问题。
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.41. UnsupportedHCOModification
含义
当使用 JSON Patch 注解来更改 HyperConverged Cluster Operator (HCO) 的操作对象时,此警报会触发。
HCO 以建议的方式配置 OpenShift Virtualization 及其支持 Operator,并在其出现意外更改时覆盖其操作对象。用户不得直接修改操作对象。
但是,如果需要更改,并且 HCO API 不支持它,您可以强制 HCO 使用 JSON Patch 注解在 Operator 中设置更改。这些更改不会在其协调过程中被 HCO 恢复。
影响
使用 JSON Patch 注解的错误可能会导致意外的结果或不稳定的环境。
升级具有 JSON Patch 注解的系统是危险的,因为组件自定义资源的结构可能会改变。
诊断
检查警报详情中的
annotation_name
以标识 JSON Patch 注解:Labels alertname=KubevirtHyperconvergedClusterOperatorUSModification annotation_name=kubevirt.kubevirt.io/jsonpatch severity=info
缓解方案
最好使用 HCO API 更改操作对象。但是,如果更改只能通过 JSON Patch 注解进行,请小心操作。
在升级前删除 JSON Patch 注解,以避免潜在的问题。
11.5.42. VirtAPIDown
含义
当所有 API 服务器 pod 都停机时,此警报会触发。
影响
OpenShift Virtualization 对象无法发送 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
检查
virt-api
部署的状态:$ oc -n $NAMESPACE get deploy virt-api -o yaml
检查
virt-api
部署详情,如崩溃 pod 或镜像拉取失败:$ oc -n $NAMESPACE describe deploy virt-api
检查处于
NotReady
状态的问题:$ oc get nodes
缓解方案
尝试确定根本原因并解决问题。
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.43. VirtApiRESTErrorsBurst
含义
在过去 5 分钟内,virt-api
pod 中有超过 80% 的 REST 调用失败。
影响
对 virt-api
的 REST 调用非常高,可能会导致对 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
检查
virt-api
日志中的错误信息:$ oc logs -n $NAMESPACE <virt-api>
获取
virt-api
pod 的详情:$ oc describe -n $NAMESPACE <virt-api>
检查节点是否出现任何问题。例如,它们可能处于
NotReady
状态:$ oc get nodes
检查
virt-api
部署的状态:$ oc -n $NAMESPACE get deploy virt-api -o yaml
获取
virt-api
部署的详情:$ oc -n $NAMESPACE describe deploy virt-api
缓解方案
根据诊断过程中获取的信息,尝试识别根本原因并解决问题。
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.44. VirtApiRESTErrorsHigh
含义
在过去 60 分钟内,virt-api
pod 中超过 5% 的 REST 调用失败。
影响
对 virt-api
的 REST 调用的高速率可能会导致对 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
检查
virt-api
日志:$ oc logs -n $NAMESPACE <virt-api>
获取
virt-api
pod 的详情:$ oc describe -n $NAMESPACE <virt-api>
检查节点是否出现任何问题。例如,它们可能处于
NotReady
状态:$ oc get nodes
检查
virt-api
部署的状态:$ oc -n $NAMESPACE get deploy virt-api -o yaml
获取
virt-api
部署的详情:$ oc -n $NAMESPACE describe deploy virt-api
缓解方案
根据诊断过程中获取的信息,尝试识别根本原因并解决问题。
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.45. VirtControllerDown
含义
5 分钟还没有检测到正在运行的 virt-controller
pod。
影响
与虚拟机 (VM) 生命周期管理相关的任何操作都失败。这值得注意的是,包括启动新虚拟机实例 (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 get logs <virt-controller>
缓解方案
这个警报可能会有各种原因,包括:
- 节点资源耗尽
- 集群没有足够内存
- 节点已停机
- API 服务器已过载。例如,调度程序可能负载过重,因此无法完全可用。
- 网络问题
确定根本原因,并在可能的情况下修复该原因。
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.46. VirtControllerRESTErrorsBurst
含义
virt-controller
pod 中超过 80% 的 REST 调用在最后 5 分钟内失败。
virt-controller
可能无法完全丢失与 API 服务器的连接。
这个错误通常是由以下问题之一造成的:
- API 服务器过载,从而导致超时。要验证是否是这种情况,请检查 API 服务器的指标,并查看其响应时间和总体调用。
-
virt-controller
pod 无法访问 API 服务器。这通常是由节点上的 DNS 问题以及网络连接问题造成的。
影响
状态更新不会被传播,迁移等操作无法发生。但是,运行的工作负载不会受到影响。
诊断
设置
NAMESPACE
环境变量:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
列出可用的
virt-controller
pod:$ oc get pods -n $NAMESPACE -l=kubevirt.io=virt-controller
在连接到 API 服务器时检查
virt-controller
日志中的错误消息:$ oc logs -n $NAMESPACE <virt-controller>
缓解方案
如果
virt-controller
pod 无法连接到 API 服务器,请删除 pod 来强制重启:$ oc delete -n $NAMESPACE <virt-controller>
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.47. VirtControllerRESTErrorsHigh
含义
在过去 60 分钟内,virt-controller
中超过 5% 的 REST 调用会失败。
这很可能是因为 virt-controller
丢失了与 API 服务器的连接。
这个错误通常是由以下问题之一造成的:
- API 服务器过载,从而导致超时。要验证是否是这种情况,请检查 API 服务器的指标,并查看其响应时间和总体调用。
-
virt-controller
pod 无法访问 API 服务器。这通常是由节点上的 DNS 问题以及网络连接问题造成的。
影响
节点相关的操作(如启动和停止虚拟机)会延迟。运行工作负载不会受到影响,但报告其当前状态可能会延迟。
诊断
设置
NAMESPACE
环境变量:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
列出可用的
virt-controller
pod:$ oc get pods -n $NAMESPACE -l=kubevirt.io=virt-controller
在连接到 API 服务器时检查
virt-controller
日志中的错误消息:$ oc logs -n $NAMESPACE <virt-controller>
缓解方案
如果
virt-controller
pod 无法连接到 API 服务器,请删除 pod 来强制重启:$ oc delete -n $NAMESPACE <virt-controller>
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.48. VirtHandlerDaemonSetRolloutFailing
含义
virt-handler
守护进程集在 15 分钟后无法在一个或多个 worker 节点上部署。
影响
这个警报是一个警告。它不表示所有 virt-handler
守护进程集都无法部署。因此,除非集群过载,虚拟机的一般生命周期不会受到影响。
诊断
识别没有正在运行的 virt-handler
pod 的 worker 节点:
导出
NAMESPACE
环境变量:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
检查
virt-handler
pod 的状态,以识别尚未部署的 pod:$ oc get pods -n $NAMESPACE -l=kubevirt.io=virt-handler
获取
virt-handler
pod 的 worker 节点的名称:$ oc -n $NAMESPACE get pod <virt-handler> -o jsonpath='{.spec.nodeName}'
缓解方案
如果因为资源不足而无法部署 virt-handler
pod,您可以删除受影响 worker 节点上的其他 pod。
11.5.49. VirtHandlerRESTErrorsBurst
含义
在过去 5 分钟内,virt-handler
中超过 80% 的 REST 调用会失败。此警报通常表示 virt-handler
Pod 无法连接到 API 服务器。
这个错误通常是由以下问题之一造成的:
- API 服务器过载,从而导致超时。要验证是否是这种情况,请检查 API 服务器的指标,并查看其响应时间和总体调用。
-
virt-handler
pod 无法访问 API 服务器。这通常是由节点上的 DNS 问题以及网络连接问题造成的。
影响
状态更新不会传播,节点相关的操作(如迁移)会失败。但是,在受影响节点上运行的工作负载不会受到影响。
诊断
设置
NAMESPACE
环境变量:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
检查
virt-handler
pod 的状态:$ oc get pods -n $NAMESPACE -l=kubevirt.io=virt-handler
在连接到 API 服务器时检查
virt-handler
日志是否有错误消息:$ oc logs -n $NAMESPACE <virt-handler>
缓解方案
如果
virt-handler
无法连接到 API 服务器,请删除 pod 以强制重启:$ oc delete -n $NAMESPACE <virt-handler>
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.50. VirtHandlerRESTErrorsHigh
含义
在过去 60 分钟内,virt-handler
中超过 5% 的 REST 调用会失败。此警报通常表示 virt-handler
pod 已部分丢失与 API 服务器的连接。
这个错误通常是由以下问题之一造成的:
- API 服务器过载,从而导致超时。要验证是否是这种情况,请检查 API 服务器的指标,并查看其响应时间和总体调用。
-
virt-handler
pod 无法访问 API 服务器。这通常是由节点上的 DNS 问题以及网络连接问题造成的。
影响
在运行 virt-handler
的节点上,与节点相关的操作(如开始和迁移工作负载)会延迟。运行工作负载不会受到影响,但报告其当前状态可能会延迟。
诊断
设置
NAMESPACE
环境变量:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
列出可用的
virt-handler
pod,以识别失败的virt-handler
pod:$ oc get pods -n $NAMESPACE -l=kubevirt.io=virt-handler
检查失败的
virt-handler
pod 日志是否有 API 服务器连接错误:$ oc logs -n $NAMESPACE <virt-handler>
错误消息示例:
{"component":"virt-handler","level":"error","msg":"Can't patch node my-node","pos":"heartbeat.go:96","reason":"the server has received too many API requests and has asked us to try again later","timestamp":"2023-11-06T11:11:41.099883Z","uid":"132c50c2-8d82-4e49-8857-dc737adcd6cc"}
缓解方案
删除 pod 以强制重启:
$ oc delete -n $NAMESPACE <virt-handler>
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.51. VirtOperatorDown
含义
当没有检测到 Running
状态的 virt-operator
pod 达到 10 分钟时,此警报将触发。
virt-operator
是集群中启动的第一个 Operator。其主要职责包括:
- 安装、实时迁移和实时迁移集群
-
监控顶层控制器的生命周期,如
virt-controller
、virt-handler
、virt-launcher
,并管理它们的协调 - 某些集群范围的任务,如证书轮转和基础架构管理
virt-operator
部署具有 2 个 pod 的默认副本。
影响
此警报表示集群级别的故障。关键集群范围的管理功能(如认证轮转、升级和控制器协调)可能不可用。
virt-operator
不直接负责集群中的虚拟机 (VM)。因此,它的临时不可用不会影响虚拟机工作负载。
诊断
设置
NAMESPACE
环境变量:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
检查
virt-operator
部署的状态:$ oc -n $NAMESPACE get deploy virt-operator -o yaml
获取
virt-operator
部署的详情:$ oc -n $NAMESPACE describe deploy virt-operator
检查
virt-operator
pod 的状态:$ oc get pods -n $NAMESPACE -l=kubevirt.io=virt-operator
检查节点问题,如
NotReady
状态:$ oc get nodes
缓解方案
根据诊断过程中获取的信息,尝试查找根本原因并解决问题。
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.52. VirtOperatorRESTErrorsBurst
含义
当 virt-operator
pod 中超过 80% 的 REST 调用在最后 5 分钟内失败时触发此警报。这通常表示 virt-operator
pod 无法连接到 API 服务器。
这个错误通常是由以下问题之一造成的:
- API 服务器过载,从而导致超时。要验证是否是这种情况,请检查 API 服务器的指标,并查看其响应时间和总体调用。
-
virt-operator
pod 无法访问 API 服务器。这通常是由节点上的 DNS 问题以及网络连接问题造成的。
影响
升级和控制器协调等集群级别操作可能不可用。
但是,虚拟机 (VM) 和虚拟机实例 (VMI) 等工作负载可能不受影响。
诊断
设置
NAMESPACE
环境变量:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
检查
virt-operator
pod 的状态:$ oc -n $NAMESPACE get pods -l kubevirt.io=virt-operator
在连接到 API 服务器时检查
virt-operator
日志是否有错误消息:$ oc -n $NAMESPACE logs <virt-operator>
获取
virt-operator
pod 的详情:$ oc -n $NAMESPACE describe pod <virt-operator>
缓解方案
如果
virt-operator
pod 无法连接到 API 服务器,请删除 pod 来强制重启:$ oc delete -n $NAMESPACE <virt-operator>
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.53. VirtOperatorRESTErrorsHigh
含义
当 virt-operator
pod 在最近的 60 分钟内有 5% 的 REST 调用失败时,此警报会触发。这通常表示 virt-operator
pod 无法连接到 API 服务器。
这个错误通常是由以下问题之一造成的:
- API 服务器过载,从而导致超时。要验证是否是这种情况,请检查 API 服务器的指标,并查看其响应时间和总体调用。
-
virt-operator
pod 无法访问 API 服务器。这通常是由节点上的 DNS 问题以及网络连接问题造成的。
影响
集群级别的操作(如升级和控制器协调)可能会延迟。
但是,虚拟机 (VM) 和虚拟机实例 (VMI) 等工作负载可能不受影响。
诊断
设置
NAMESPACE
环境变量:$ export NAMESPACE="$(oc get kubevirt -A \ -o custom-columns="":.metadata.namespace)"
检查
virt-operator
pod 的状态:$ oc -n $NAMESPACE get pods -l kubevirt.io=virt-operator
在连接到 API 服务器时检查
virt-operator
日志是否有错误消息:$ oc -n $NAMESPACE logs <virt-operator>
获取
virt-operator
pod 的详情:$ oc -n $NAMESPACE describe pod <virt-operator>
缓解方案
如果
virt-operator
pod 无法连接到 API 服务器,请删除 pod 来强制重启:$ oc delete -n $NAMESPACE <virt-operator>
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。
11.5.54. VMCannotBeEvicted
含义
当虚拟机 (VM) 的驱除策略被设置为 LiveMigration
时,此警报会触发,但虚拟机不可修改。
影响
不可缓解的虚拟机会阻止节点驱除。此条件会影响节点排空和更新等操作。
诊断
检查 VMI 配置,以确定
evictionStrategy
的值是否为LiveMigrate
:$ oc get vmis -o yaml
检查
LIVE-MIGRATABLE
列中的False
状态,以识别不可避免的 VMI:$ oc get vmis -o wide
获取 VMI 的详情,并检查
spec.conditions
来识别问题:$ oc get vmi <vmi> -o yaml
输出示例
status: conditions: - lastProbeTime: null lastTransitionTime: null message: cannot migrate VMI which does not use masquerade to connect to the pod network reason: InterfaceNotLiveMigratable status: "False" type: LiveMigratable
缓解方案
将 VMI 的 evictionStrategy
设置为 None
,或解决阻止 VMI 迁移的问题。在节点排空和 pod 驱除时,无
开始关闭虚拟机。
11.5.55. VMStorageClassWarning
含义
当存储类配置不正确时,此警报会触发。在不同进程或线程间写入和读取数据时,系统范围内的共享 dummy 页面会导致 CRC 错误。
影响
大量 CRC 错误可能会导致集群显示严重的性能降级。
诊断
-
在 web 控制台中进入到 Observe
Metrics。 运行以下 PromQL 查询来获取带有错误配置的存储类的虚拟机列表:
kubevirt_ssp_vm_rbd_volume{rxbounce_enabled="false", volume_mode="Block"} == 1
输出显示使用没有
rxbounce_enabled
的存储类的虚拟机列表。输出示例
kubevirt_ssp_vm_rbd_volume{name="testvmi-gwgdqp22k7", namespace="test_ns", pv_name="testvmi-gwgdqp22k7", rxbounce_enabled="false", volume_mode="Block"} 1
运行以下命令来获取存储类名称:
$ oc get pv <pv_name> -o=jsonpath='{.spec.storageClassName}'
缓解方案
使用 krbd:rxbounce
映射选项创建默认的 OpenShift Virtualization 存储类。详情请参阅为 Windows 虚拟机优化 ODF PersistentVolume。
如果您无法解决这个问题,登录到客户门户网站并创建一个支持问题单,附加诊断过程中收集的工件。