13.12. OpenShift Virtualization critical 警报


重要

OpenShift Virtualization Critical 警报只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

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

OpenShift Virtualization 有警报,在出现问题时通知您。Critical 警报需要立即关注。

每个警报都有相应问题的描述,这是发生警报的原因,一种故障排除过程来诊断问题的来源,以及解析警报的步骤。

13.12.1. 网络警报

网络警报提供有关 OpenShift Virtualization Network Operator 的问题的信息。

13.12.1.1. KubeMacPoolDown 警报

描述

KubeMacPool 组件分配 MAC 地址并防止 MAC 地址冲突。

原因

如果 KubeMacPool-manager pod 已关闭,则 VirtualMachine 对象的创建会失败。

故障排除

  1. 确定 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}')"
  2. 检查 Kubemacpool-manager pod 描述和日志,以确定问题的来源。

    $ oc describe pod -n $KMP_NAMESPACE $KMP_NAME
    $ oc logs -n $KMP_NAMESPACE $KMP_NAME

解决方案

创建一个支持问题,并提供故障排除过程中收集的信息。

13.12.2. SSP 警报

SSP 警报提供有关 OpenShift Virtualization SSP Operator 的问题的信息。

13.12.2.1. SSPFailingToReconcile 警报

描述

SSP Operator 的 pod 已启动,但 pod 的协调周期会持续失败。此失败包括无法更新负责部署模板验证器的资源、部署模板验证器或无法部署或更新通用模板的资源失败。

原因

如果 SSP Operator 无法协调,则依赖组件的部署失败,对组件更改的协调会失败,或者两者。另外,对通用模板和模板验证器的更新重置并失败。

故障排除

  1. 检查 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
  2. 验证模板验证器是否已启动。如果模板验证器没有启动,请检查 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.12.2.2. SSPOperatorDown 警报

描述

SSP Operator 部署并协调通用模板和模板验证器。

原因

如果 SSP Operator 已关闭,则依赖组件的部署会失败,对组件更改进行协调会失败,或者两者都失败。另外,对通用模板和模板验证器的更新重置并失败。

故障排除

  1. 检查 ssp-operator 的 pod 命名空间:

    $ export NAMESPACE="$(oc get deployment -A | grep ssp-operator | awk '{print $1}')"
  2. 验证 ssp-operator 的 pod 当前是否已停机。

    $ oc -n $NAMESPACE get pods -l control-plane=ssp-operator
  3. 检查 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.12.2.3. SSPTemplateValidatorDown 警报

描述

模板验证器验证虚拟机(VM)不会违反其分配的模板。

原因

如果每个模板验证器 pod 都关闭,则模板验证器无法根据所分配的模板来验证虚拟机。

故障排除

  1. 检查 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}')"
  2. 验证 virt-template-validator 的 pod 当前是否已关闭。

    $ oc -n $NAMESPACE get pods -l name=virt-template-validator
  3. 检查 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.12.3. virt 警报

virt 警报提供有关 OpenShift Virtualization Virt Operator 的问题的信息。

13.12.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 leadingacquire 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.12.3.2. NoReadyVirtController 警报

描述

virt-controller 监控虚拟机实例(VMI)。virt-controller 还通过创建和管理与 VMI 对象关联的 pod 的生命周期来管理相关的 pod。

VMI 对象始终在其生命周期内与 pod 关联。但是,pod 实例可能会因为 VMI 迁移而变化。

当检查到没有状态为就绪的 virt-controllers 超过五分钟时,会发出此警报。

原因

如果 virt-controller 失败,则虚拟机生命周期管理完全失败。生命周期管理任务包括启动新的 VMI 或关闭现有的 VMI。

故障排除

  1. 检查 virt-controller 的 vdeployment 状态是否有可用的副本和条件。

    $ oc -n $NAMESPACE get deployment virt-controller -o yaml
  2. 检查 virt-controller pod 是否存在并检查其状态。

    get pods -n $NAMESPACE |grep virt-controller
  3. 检查 virt-controller pod 的事件。

    $ oc -n $NAMESPACE describe pods <virt-controller pod>
  4. 检查 virt-controller pod 的日志。

    $ oc -n $NAMESPACE logs <virt-controller pod>
  5. 检查节点是否有问题,如节点是否处于 NotReady 状态。

    $ oc get nodes

解决方案

一些原因可能会造成没有 Ready 状态的 virt-controller pod。确定根本原因并采取适当的操作。

否则,创建一个支持问题,并提供故障排除过程中收集的信息。

13.12.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 不可用不会影响自定义工作负载。

此警报表示集群级别的故障。关键的集群范围的管理功能(如认证轮转、升级和协调)可能临时不可用。

故障排除

  1. 检查 virt-operator 的部署状态以获取可用副本和条件。

    $ oc -n $NAMESPACE get deployment virt-operator -o yaml
  2. 检查 virt-controller pod 的事件。

    $ oc -n $NAMESPACE describe pods <virt-operator pod>
  3. 检查 virt-operator pod 的日志。

    $ oc -n $NAMESPACE logs <virt-operator pod>
  4. 检查 control plane 和 master 节点是否存在问题,如它们是否处于 NotReady 状态。

    $ oc get nodes

解决方案

一些原因可能会造成没有 Ready 状态的 virt-operator pod。确定根本原因并采取适当的操作。

否则,创建一个支持问题,并提供故障排除过程中收集的信息。

13.12.3.4. VirtAPIDown 警报

描述

所有 OpenShift Container Platform API 服务器都停机。

原因

如果所有 OpenShift Container Platform API 服务器都停机,则不会对 OpenShift Container Platform 实体进行 API 调用。

故障排除

  1. 修改环境变量 NAMESPACE

    $ export NAMESPACE="$(oc get kubevirt -A -o custom-columns="":.metadata.namespace)"
  2. 验证是否有正在运行的 virt-api pod。

    $ oc -n $NAMESPACE get pods -l kubevirt.io=virt-api
  3. 使用 oc logsoc describe 来查看 pod 的日志。
  4. 检查 virt-api 部署的状态。使用这些命令了解相关的事件,并演示拉取镜像、崩溃 pod 或其他类似问题时是否存在任何问题。

    $ oc -n $NAMESPACE get deployment virt-api -o yaml
    $ oc -n $NAMESPACE describe deployment virt-api
  5. 检查节点是否有问题,如节点是否处于 NotReady 状态。

    $ oc get nodes

解决方案

virt-api pod 可能会因为以下原因而停机。确定根本原因并采取适当的操作。

否则,创建一个支持问题,并提供故障排除过程中收集的信息。

13.12.3.5. VirtApiRESTErrorsBurst 警报

描述

在过去五分钟内,virt-api 中超过 80% 的 REST 调用会失败。

原因

对 virt-api 的 REST 调用非常高,导致对 API 调用速度缓慢、速度较慢的 API 调用,甚至完全没有 API 调用。

故障排除

  1. 修改环境变量 NAMESPACE

    $ export NAMESPACE="$(oc get kubevirt -A -o custom-columns="":.metadata.namespace)"
  2. 检查存在多少个运行 virt-api pod。

    $ oc -n $NAMESPACE get pods -l kubevirt.io=virt-api
  3. 使用 oc logsoc describe 来查看 pod 的日志。
  4. 检查 virt-api 部署的状态,以查找更多信息。这些命令提供相关的事件,并显示拉取镜像或崩溃 pod 是否存在任何问题。

    $ oc -n $NAMESPACE get deployment virt-api -o yaml
    $ oc -n $NAMESPACE describe deployment virt-api
  5. 检查节点是否有问题,例如节点是否已过载或未处于 NotReady 状态。

    $ oc get nodes

解决方案

一些原因会造成高的 REST 调用故障率。确定根本原因并采取适当的操作。

  • 节点资源耗尽
  • 集群没有足够内存
  • 节点已停机
  • API 服务器过载,如调度程序没有 100%可用)
  • 网络问题

否则,创建一个支持问题,并提供故障排除过程中收集的信息。

13.12.3.6. VirtControllerDown 警报

描述

如果过去五分钟中没有对 virt-controller 的检测,则 virt-controller 部署具有两个 pod 的默认副本。

原因

如果 virt-controller 失败,则虚拟机生命周期管理任务(如启动新的 VMI 或关闭现有 VMI)完全失败。

故障排除

  1. 修改环境变量 NAMESPACE

    $ export NAMESPACE="$(oc get kubevirt -A -o custom-columns="":.metadata.namespace)"
  2. 检查 virt-controller 部署的状态。

    $ oc get deployment -n $NAMESPACE virt-controller -o yaml
  3. 检查 virt-controller pod 的事件。

    $ oc -n $NAMESPACE describe pods <virt-controller pod>
  4. 检查 virt-controller pod 的日志。

    $ oc -n $NAMESPACE logs <virt-controller pod>
  5. 检查 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.12.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.12.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.12.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 不可用不会影响自定义工作负载。

此警报表示集群级别的故障。关键的集群范围的管理功能(如认证轮转、升级和协调)可能临时不可用。

故障排除

  1. 修改环境变量 NAMESPACE

    $ export NAMESPACE="$(oc get kubevirt -A -o custom-columns="":.metadata.namespace)"
  2. 检查 virt-operator 部署的状态。

    $ oc get deployment -n $NAMESPACE virt-operator -o yaml
  3. 检查 virt-operator pod 的事件。

    $ oc -n $NAMESPACE describe pods <virt-operator pod>
  4. 检查 virt-operator pod 的日志。

    $ oc -n $NAMESPACE logs <virt-operator pod>
  5. 检查 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.12.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 问题相关。确定根本原因并采取适当的操作。

否则,创建一个支持问题,并提供故障排除过程中收集的信息。

13.12.4. 其他资源

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.