Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

14.2. OpenShift Virtualization 集群检查框架

checkup 是一个自动测试工作负载，可让您验证特定的集群功能是否按预期工作。集群检查框架使用原生 Kubernetes 资源来配置和执行检查。

重要

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

有关红帽技术预览功能支持范围的更多信息，请参阅以下链接：

作为开发人员或集群管理员，您可以使用预定义的检查来提高集群可维护性，排除意外行为，最小化错误并节省时间。您可以查看检查结果并与专家分享以进一步分析。供应商可以编写和发布它们所提供的功能或服务的检查，并验证其客户环境是否已正确配置。

14.2.1. 运行预定义的延迟检查
复制链接

您可以使用延迟检查来验证附加到二级网络接口的两个虚拟机(VM)之间的网络连接和测量延迟。预定义的延迟检查使用 ping 程序。

重要

在运行延迟检查前，您必须首先在集群节点上创建一个桥接接口，以便将虚拟机的二级接口连接到节点上的任何接口。如果您没有创建桥接接口，虚拟机不会启动，作业会失败。

在现有命名空间中运行预定义的检查涉及为检查设置服务帐户，为服务帐户创建 Role 和 RoleBinding 对象，启用检查权限，以及创建输入配置映射和检查作业。您可以多次运行检查。

重要

您必须始终：

  • 在应用之前，验证检查镜像是否来自可信源。
  • 在创建 Role 和 RoleBinding 对象前，查看检查权限。

14.2.1.1. 使用 Web 控制台运行延迟检查
复制链接

运行延迟检查以验证网络连接并测量附加到二级网络接口的两个虚拟机之间的延迟。

先决条件

  • 您必须将 NetworkAttachmentDefinition 添加到命名空间。

流程

  1. 在 web 控制台中进入到 Virtualization Checkups。
  2. 点 Network latency 选项卡。
  3. 点 Install permissions。
  4. 点 Run checkup。
  5. 在 Name 字段中输入检查的名称。
  6. 从下拉菜单中选择 NetworkAttachmentDefinition。
  7. 可选：在 Sample duration (seconds) 字段中为延迟示例设置一个持续时间。
  8. 可选：通过启用 Set maximum desired latency (milliseconds) 并定义时间间隔来定义最大延迟时间间隔。
  9. 可选：通过启用 选择节点 并指定源节点和目标节点来针对特定的节点。
  10. 点 Run。

验证

  • 要查看延迟检查的状态，请转至 Latency checkup 选项卡上的 Checkups 列表。点检查的名称以获取更多详细信息。

14.2.1.2. 使用 CLI 运行延迟检查
复制链接

您可以使用 CLI 运行延迟检查。

执行以下步骤：

  1. 创建服务帐户、角色和 rolebindings，以便为延迟检查提供集群访问权限。
  2. 创建配置映射以提供运行检查并存储结果的输入。
  3. 创建用于运行检查的作业。
  4. 查看配置映射中的结果。
  5. 可选： 要重新运行检查，请删除现有的配置映射和作业，然后创建新的配置映射和作业。
  6. 完成后，删除延迟检查资源。

先决条件

  • 已安装 OpenShift CLI（oc）。
  • 集群至少有两个 worker 节点。
  • 为命名空间配置了网络附加定义。

流程

  1. 为延迟检查创建一个 ServiceAccount、Role 和 RoleBinding 清单。

    角色清单文件示例： 

    ---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: vm-latency-checkup-sa
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: kubevirt-vm-latency-checker
rules:
- apiGroups: ["kubevirt.io"]
  resources: ["virtualmachineinstances"]
  verbs: ["get", "create", "delete"]
- apiGroups: ["subresources.kubevirt.io"]
  resources: ["virtualmachineinstances/console"]
  verbs: ["get"]
- apiGroups: ["k8s.cni.cncf.io"]
  resources: ["network-attachment-definitions"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kubevirt-vm-latency-checker
subjects:
- kind: ServiceAccount
  name: vm-latency-checkup-sa
roleRef:
  kind: Role
  name: kubevirt-vm-latency-checker
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: kiagnose-configmap-access
rules:
- apiGroups: [ "" ]
  resources: [ "configmaps" ]
  verbs: ["get", "update"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kiagnose-configmap-access
subjects:
- kind: ServiceAccount
  name: vm-latency-checkup-sa
roleRef:
  kind: Role
  name: kiagnose-configmap-access
  apiGroup: rbac.authorization.k8s.io

  2. 应用 ServiceAccount、Role 和 RoleBinding 清单： 

    $ oc apply -n <target_namespace> -f <latency_sa_roles_rolebinding>.yaml
    1
    1
    <target_namespace> 是要运行检查的命名空间。这必须是 NetworkAttachmentDefinition 对象所在的现有命名空间。

  3. 创建包含检查的输入参数的 ConfigMap 清单。

    输入配置映射示例： 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: kubevirt-vm-latency-checkup-config
  labels:
    kiagnose/checkup-type: kubevirt-vm-latency
data:
  spec.timeout: 5m
  spec.param.networkAttachmentDefinitionNamespace: <target_namespace>
  spec.param.networkAttachmentDefinitionName: "blue-network"
    1 
    
  spec.param.maxDesiredLatencyMilliseconds: "10"
    2 
    
  spec.param.sampleDurationSeconds: "5"
    3 
    
  spec.param.sourceNode: "worker1"
    4 
    
  spec.param.targetNode: "worker2"
    5
    1
    NetworkAttachmentDefinition 对象的名称。
    2
    可选：虚拟机之间所需最大延迟（以毫秒为单位）。如果测量的延迟超过这个值，则检查会失败。
    3
    可选：延迟检查的持续时间，以秒为单位。
    4
    可选：指定时，延迟从此节点测量到目标节点。如果指定了源节点，spec.param.targetNode 字段将无法为空。
    5
    可选：指定时，延迟从源节点测量到这个节点。

  4. 应用目标命名空间中的配置映射清单： 

    $ oc apply -n <target_namespace> -f <latency_config_map>.yaml

  5. 创建一个 Job 清单以运行检查。

    任务清单示例： 

    apiVersion: batch/v1
kind: Job
metadata:
  name: kubevirt-vm-latency-checkup
  labels:
    kiagnose/checkup-type: kubevirt-vm-latency
spec:
  backoffLimit: 0
  template:
    spec:
      serviceAccountName: vm-latency-checkup-sa
      restartPolicy: Never
      containers:
        - name: vm-latency-checkup
          image: registry.redhat.io/container-native-virtualization/vm-network-latency-checkup-rhel9:v4.20.0
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop: ["ALL"]
            runAsNonRoot: true
            seccompProfile:
              type: "RuntimeDefault"
          env:
            - name: CONFIGMAP_NAMESPACE
              value: <target_namespace>
            - name: CONFIGMAP_NAME
              value: kubevirt-vm-latency-checkup-config
            - name: POD_UID
              valueFrom:
                fieldRef:
                  fieldPath: metadata.uid

  6. 应用 Job 清单： 

    $ oc apply -n <target_namespace> -f <latency_job>.yaml

  7. 等待作业完成： 

    $ oc wait job kubevirt-vm-latency-checkup -n <target_namespace> --for condition=complete --timeout 6m

  8. 运行以下命令，检查延迟检查的结果。如果测量的最大延迟大于 spec.param.maxDesiredLatencyMilliseconds 属性的值，则检查会失败并返回错误。 

    $ oc get configmap kubevirt-vm-latency-checkup-config -n <target_namespace> -o yaml

    输出配置映射（成功）示例： 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: kubevirt-vm-latency-checkup-config
  namespace: <target_namespace>
  labels:
    kiagnose/checkup-type: kubevirt-vm-latency
data:
  spec.timeout: 5m
  spec.param.networkAttachmentDefinitionNamespace: <target_namespace>
  spec.param.networkAttachmentDefinitionName: "blue-network"
  spec.param.maxDesiredLatencyMilliseconds: "10"
  spec.param.sampleDurationSeconds: "5"
  spec.param.sourceNode: "worker1"
  spec.param.targetNode: "worker2"
  status.succeeded: "true"
  status.failureReason: ""
  status.completionTimestamp: "2022-01-01T09:00:00Z"
  status.startTimestamp: "2022-01-01T09:00:07Z"
  status.result.avgLatencyNanoSec: "177000"
  status.result.maxLatencyNanoSec: "244000"
    1 
    
  status.result.measurementDurationSec: "5"
  status.result.minLatencyNanoSec: "135000"
  status.result.sourceNode: "worker1"
  status.result.targetNode: "worker2"
    1
    以纳秒为单位的最大测量延迟。

  9. 可选： 要在检查失败时查看详细作业日志，请使用以下命令： 

    $ oc logs job.batch/kubevirt-vm-latency-checkup -n <target_namespace>

  10. 运行以下命令删除之前创建的作业和配置映射： 

    $ oc delete job -n <target_namespace> kubevirt-vm-latency-checkup
     
    $ oc delete config-map -n <target_namespace> kubevirt-vm-latency-checkup-config

  11. 可选：如果您不计划运行另一个检查，请删除角色清单： 

    $ oc delete -f <latency_sa_roles_rolebinding>.yaml

14.2.2. 运行预定义的存储检查
复制链接

您可以使用存储检查来验证 OpenShift Virtualization 的最佳配置集群存储。

在现有命名空间中运行预定义的检查涉及为检查设置服务帐户，为服务帐户创建 Role 和 RoleBinding 对象，启用检查权限，以及创建输入配置映射和检查作业。您可以多次运行检查。

重要

您必须始终：

  • 在应用之前，验证检查镜像是否来自可信源。
  • 在创建 Role 和 RoleBinding 对象前，查看检查权限。

14.2.2.1. 为存储检查保留资源以进行故障排除
复制链接

预定义的存储检查包括 skipTeardown 配置选项，该选项可在存储检查运行后控制资源清理。默认情况下，skipTeardown 字段值为 Never，这意味着检查总是执行 teardown 步骤，并在检查运行后删除所有资源。

您可以通过将 skipTeardown 字段设置为 onfailure 来保留资源以便在失败时进一步检查。

先决条件

  • 已安装 OpenShift CLI（oc）。

流程

  1. 运行以下命令来编辑 storage-checkup-config 配置映射： 

    $ oc edit configmap storage-checkup-config -n <checkup_namespace>

  2. 将 skipTeardown 字段配置为使用 onfailure 值。您可以通过修改 storage-checkup-config 配置映射，存储在 storage_checkup.yaml 文件中： 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: storage-checkup-config
  namespace: <checkup_namespace>
data:
  spec.param.skipTeardown: onfailure
# ...

  3. 运行以下命令重新应用 storage-checkup-config 配置映射： 

    $ oc apply -f storage_checkup.yaml -n <checkup_namespace>

14.2.2.2. 使用 Web 控制台运行存储检查
复制链接

您可以运行存储检查，以验证存储是否为虚拟机正常工作。

流程

  1. 在 web 控制台中进入到 Virtualization Checkups。
  2. 点 Storage 选项卡。
  3. 点 Install permissions。
  4. 点 Run checkup。
  5. 在 Name 字段中输入检查的名称。
  6. 在 Timeout (minutes) 字段中输入检查的超时值。
  7. 点 Run。

结果

您可以在 Storage 选项卡的 Checkups 列表中查看存储检查的状态。点检查的名称以获取更多详细信息。

14.2.2.3. 使用 CLI 运行存储检查
复制链接

使用预定义的检查来验证 OpenShift Container Platform 集群存储是否配置为运行 OpenShift Virtualization 工作负载。

先决条件

  • 已安装 OpenShift CLI(oc)。

  • 集群管理员为存储检查服务帐户和命名空间创建了所需的 cluster-reader 权限，如下例所示： 

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kubevirt-storage-checkup-clustereader
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-reader
subjects:
- kind: ServiceAccount
  name: storage-checkup-sa
  namespace: <target_namespace>
    1
    1
    运行检查的命名空间。

流程

  1. 为存储检查创建一个 ServiceAccount、Role 和 RoleBinding 清单文件。

    服务帐户、角色和 rolebinding 清单示例： 

    ---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: storage-checkup-sa
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: storage-checkup-role
rules:
  - apiGroups: [ "" ]
    resources: [ "configmaps" ]
    verbs: ["get", "update"]
  - apiGroups: [ "kubevirt.io" ]
    resources: [ "virtualmachines" ]
    verbs: [ "create", "delete" ]
  - apiGroups: [ "kubevirt.io" ]
    resources: [ "virtualmachineinstances" ]
    verbs: [ "get" ]
  - apiGroups: [ "subresources.kubevirt.io" ]
    resources: [ "virtualmachineinstances/addvolume", "virtualmachineinstances/removevolume" ]
    verbs: [ "update" ]
  - apiGroups: [ "kubevirt.io" ]
    resources: [ "virtualmachineinstancemigrations" ]
    verbs: [ "create" ]
  - apiGroups: [ "cdi.kubevirt.io" ]
    resources: [ "datavolumes" ]
    verbs: [ "create", "delete" ]
  - apiGroups: [ "" ]
    resources: [ "persistentvolumeclaims" ]
    verbs: [ "delete" ]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: storage-checkup-role
subjects:
  - kind: ServiceAccount
    name: storage-checkup-sa
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: storage-checkup-role

  2. 在目标命名空间中应用 ServiceAccount、Role 和 RoleBinding 清单： 

    $ oc apply -n <target_namespace> -f <storage_sa_roles_rolebinding>.yaml

  3. 创建 ConfigMap 和 Job 清单文件。配置映射包含检查作业的输入参数。

    输入配置映射和作业清单示例： 

    ---
apiVersion: v1
kind: ConfigMap
metadata:
  name: storage-checkup-config
  namespace: $CHECKUP_NAMESPACE
data:
  spec.timeout: 10m
  spec.param.storageClass: ocs-storagecluster-ceph-rbd-virtualization
  spec.param.vmiTimeout: 3m
---
apiVersion: batch/v1
kind: Job
metadata:
  name: storage-checkup
  namespace: $CHECKUP_NAMESPACE
spec:
  backoffLimit: 0
  template:
    spec:
      serviceAccount: storage-checkup-sa
      restartPolicy: Never
      containers:
        - name: storage-checkup
          image: quay.io/kiagnose/kubevirt-storage-checkup:main
          imagePullPolicy: Always
          env:
            - name: CONFIGMAP_NAMESPACE
              value: $CHECKUP_NAMESPACE
            - name: CONFIGMAP_NAME
              value: storage-checkup-config

  4. 应用目标命名空间中的 ConfigMap 和 Job 清单文件来运行检查： 

    $ oc apply -n <target_namespace> -f <storage_configmap_job>.yaml

  5. 等待作业完成： 

    $ oc wait job storage-checkup -n <target_namespace> --for condition=complete --timeout 10m

  6. 运行以下命令，查看检查的结果： 

    $ oc get configmap storage-checkup-config -n <target_namespace> -o yaml

    输出配置映射（成功）示例： 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: storage-checkup-config
  labels:
    kiagnose/checkup-type: kubevirt-storage
data:
  spec.timeout: 10m
  status.succeeded: "true"
    1 
    
  status.failureReason: ""
    2 
    
  status.startTimestamp: "2023-07-31T13:14:38Z"
    3 
    
  status.completionTimestamp: "2023-07-31T13:19:41Z"
    4 
    
  status.result.cnvVersion: 4.20.2
    5 
    
  status.result.defaultStorageClass: trident-nfs
    6 
    
  status.result.goldenImagesNoDataSource: <data_import_cron_list>
    7 
    
  status.result.goldenImagesNotUpToDate: <data_import_cron_list>
    8 
    
  status.result.ocpVersion: 4.20.0
    9 
    
  status.result.pvcBound: "true"
    10 
    
  status.result.storageProfileMissingVolumeSnapshotClass: <storage_class_list>
    11 
    
  status.result.storageProfilesWithEmptyClaimPropertySets: <storage_profile_list>
    12 
    
  status.result.storageProfilesWithSmartClone: <storage_profile_list>
    13 
    
  status.result.storageProfilesWithSpecClaimPropertySets: <storage_profile_list>
    14 
    
  status.result.storageProfilesWithRWX: |-
    ocs-storagecluster-ceph-rbd
    ocs-storagecluster-ceph-rbd-virtualization
    ocs-storagecluster-cephfs
    trident-iscsi
    trident-minio
    trident-nfs
    windows-vms
  status.result.vmBootFromGoldenImage: VMI "vmi-under-test-dhkb8" successfully booted
  status.result.vmHotplugVolume: |-
    VMI "vmi-under-test-dhkb8" hotplug volume ready
    VMI "vmi-under-test-dhkb8" hotplug volume removed
  status.result.vmLiveMigration: VMI "vmi-under-test-dhkb8" migration completed
  status.result.vmVolumeClone: 'DV cloneType: "csi-clone"'
  status.result.vmsWithNonVirtRbdStorageClass: <vm_list>
    15 
    
  status.result.vmsWithUnsetEfsStorageClass: <vm_list>
    16
    1
    指定检查是否成功(true)或不是 (false)。
    2
    检查失败时失败的原因。
    3
    检查启动时的时间，使用 RFC 3339 时间格式。
    4
    检查完成后的时间，使用 RFC 3339 时间格式。
    5
    OpenShift Virtualization 版本。
    6
    指定是否有默认存储类。
    7
    其数据源未就绪的金级镜像列表。
    8
    数据导入 cron 不是最新的金级镜像列表。
    9
    OpenShift Container Platform 版本。
    10
    指定置备程序是否创建并绑定了 10Mi 的 PVC。
    11
    使用基于快照的克隆的存储配置集列表，但缺少 VolumeSnapshotClass。
    12
    带有未知置备程序的存储配置集列表。
    13
    带有智能克隆支持的存储配置文件列表(CSI/snapshot)。
    14
    存储配置集 spec-overriden claimPropertySets 列表。
    15
    当虚拟化存储类存在时，使用 Ceph RBD 存储类的虚拟机列表。
    16
    使用 Elastic File Store (EFS) 存储类的虚拟机列表，其中 GID 和 UID 没有在存储类中设置。

  7. 运行以下命令删除之前创建的作业和配置映射： 

    $ oc delete job -n <target_namespace> storage-checkup
     
    $ oc delete config-map -n <target_namespace> storage-checkup-config

  8. 可选：如果您不计划运行另一个检查，请删除 ServiceAccount、Role 和 RoleBinding 清单： 

    $ oc delete -f <storage_sa_roles_rolebinding>.yaml

14.2.2.4. 对失败的存储检查进行故障排除
复制链接

如果存储检查失败，您可以采取一些步骤来识别失败的原因。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 您已下载了 must-gather 工具提供的目录。

流程

  1. 运行以下命令并查看 storage-checkup-config 配置映射中的 status.failureReason 字段： 

    $ oc get configmap storage-checkup-config -n <namespace> -o yaml

    输出配置映射示例： 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: storage-checkup-config
  labels:
    kiagnose/checkup-type: kubevirt-storage
data:
  spec.timeout: 10m
  status.succeeded: "false"
    1 
    
  status.failureReason: "ErrNoDefaultStorageClass"
    2 
    
# ...
    1
    如果检查失败，status.succeeded 值为 false。
    2
    如果检查失败，status.failureReason 字段包含错误消息。在本例中，ErrNoDefaultStorageClass 错误消息表示没有配置默认存储类。
  2. 搜索 must-gather 工具提供的目录，以获取与 data.status.failureReason 字段中错误相关的日志、事件或术语。

14.2.2.5. 存储检查错误代码
复制链接

在存储检查失败后，以下错误代码可能会出现在 storage-checkup-config 配置映射中。

Expand
错误代码含义

ErrNoDefaultStorageClass

没有配置默认存储类。

ErrPvcNotBound

一个或多个持久性卷声明(PVC)无法绑定。

ErrMultipleDefaultStorageClasses

配置了多个默认存储类。

ErrEmptyClaimPropertySets

有包含空 ClaimPropertySets specs 的 StorageProfile 对象。

ErrVMsWithUnsetEfsStorageClass

有一些使用弹性文件系统(EFS)存储类的虚拟机，其中 GID 和 UID 不在 StorageClass 对象中设置。

ErrGoldenImagesNotUpToDate

一个或多个金级镜像具有非最新的 DataImportCron 对象，或者具有未就绪的 DataSource 对象。

ErrGoldenImageNoDataSource

金级镜像的 DataSource 对象没有配置 PVC 或没有配置快照源。

ErrBootFailedOnSomeVMs

有些虚拟机无法在预期时间引导。

Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2026 Red Hat返回顶部