支持控制台（Console）开发人员开始试用联系人

12.2. OpenShift Virtualization 集群检查框架

OpenShift Virtualization 包括以下预定义的检查，可用于集群维护和故障排除：

延迟检查
验证附加到二级网络接口的两个虚拟机(VM)之间的网络连接和测量延迟。
DPDK 检查
验证节点是否可以运行具有零数据包丢失的 Data Plane Development Kit (DPDK)工作负载的虚拟机。
重要

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

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

12.2.1. 关于 OpenShift Virtualization 集群检查框架

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

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

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

重要

您必须始终：

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

12.2.1.1. 运行延迟检查

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

您可以执行以下步骤来运行延迟检查：

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

先决条件

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

流程

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

    例 12.1. 角色清单文件示例

    ---
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
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
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.14.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>
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

12.2.1.2. DPDK 检查

使用预定义的检查来验证 OpenShift Container Platform 集群节点是否可以运行带有零数据包丢失的 Data Plane Development Kit (DPDK) 工作负载的虚拟机 (VM)。DPDK 检查在流量生成器和运行测试 DPDK 应用程序的虚拟机之间运行流量。

您可以执行以下步骤来运行 DPDK 检查：

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

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 集群被配置为运行 DPDK 应用程序。
  • 该项目被配置为运行 DPDK 应用程序。

流程

  1. 为 DPDK 检查创建 ServiceAccount、Role 和 RoleBinding 清单：

    例 12.2. 服务帐户、角色和 rolebinding 清单文件示例

    ---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: dpdk-checkup-sa
---
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: dpdk-checkup-sa
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: kiagnose-configmap-access
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: kubevirt-dpdk-checker
rules:
  - apiGroups: [ "kubevirt.io" ]
    resources: [ "virtualmachineinstances" ]
    verbs: [ "create", "get", "delete" ]
  - apiGroups: [ "subresources.kubevirt.io" ]
    resources: [ "virtualmachineinstances/console" ]
    verbs: [ "get" ]
  - apiGroups: [ "" ]
    resources: [ "configmaps" ]
    verbs: [ "create", "delete" ]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kubevirt-dpdk-checker
subjects:
  - kind: ServiceAccount
    name: dpdk-checkup-sa
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: kubevirt-dpdk-checker

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

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

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

    输入配置映射示例

    apiVersion: v1
kind: ConfigMap
metadata:
  name: dpdk-checkup-config
data:
  spec.timeout: 10m
  spec.param.networkAttachmentDefinitionName: <network_name> 1
  spec.param.trafficGenContainerDiskImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-traffic-gen:v0.2.0 2
  spec.param.vmUnderTestContainerDiskImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-vm:v0.2.0" 3

    1
    NetworkAttachmentDefinition 对象的名称。
    2
    流量生成器的容器磁盘镜像。在本例中，镜像是从上游 Project Quay Container Registry 中拉取的。
    3
    测试中的虚拟机的容器磁盘镜像。在本例中，镜像是从上游 Project Quay Container Registry 中拉取的。

  4. 应用目标命名空间中的 ConfigMap 清单： 

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

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

    任务清单示例

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

  6. 应用 Job 清单： 

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

  7. 等待作业完成： 

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

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

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

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

    apiVersion: v1
kind: ConfigMap
metadata:
  name: dpdk-checkup-config
data:
  spec.timeout: 10m
  spec.param.NetworkAttachmentDefinitionName: "dpdk-network-1"
  spec.param.trafficGenContainerDiskImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-traffic-gen:v0.2.0"
  spec.param.vmUnderTestContainerDiskImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-vm:v0.2.0"
  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.trafficGenSentPackets: "480000000" 5
  status.result.trafficGenOutputErrorPackets: "0" 6
  status.result.trafficGenInputErrorPackets: "0" 7
  status.result.trafficGenActualNodeName: worker-dpdk1 8
  status.result.vmUnderTestActualNodeName: worker-dpdk2 9
  status.result.vmUnderTestReceivedPackets: "480000000" 10
  status.result.vmUnderTestRxDroppedPackets: "0" 11
  status.result.vmUnderTestTxDroppedPackets: "0" 12

    1
    指定检查是否成功(true)或不是 (false)。
    2
    检查失败时失败的原因。
    3
    检查启动时的时间，使用 RFC 3339 时间格式。
    4
    检查完成后的时间，使用 RFC 3339 时间格式。
    5
    从流量生成器发送的数据包数量。
    6
    从流量生成器发送的错误数据包数量。
    7
    流量生成器接收的错误数据包数量。
    8
    调度流量生成器虚拟机的节点。
    9
    调度测试过程中虚拟机的节点。
    10
    虚拟机在测试下接收的数据包数量。
    11
    DPDK 应用程序丢弃的入口流量数据包。
    12
    从 DPDK 应用程序丢弃的出口流量数据包。

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

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

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

    $ oc delete -f <dpdk_sa_roles_rolebinding>.yaml
12.2.1.2.1. DPDK 检查配置映射参数

下表显示了在运行集群 DPDK 就绪度检查时，您可以在输入 ConfigMap 清单的 data 小节中设置的强制参数和可选参数：

表 12.1. DPDK 检查配置映射输入参数
参数描述是必须的

spec.timeout

检查失败前的时间（以分钟为单位）。

True

spec.param.networkAttachmentDefinitionName

连接 SR-IOV NIC 的 NetworkAttachmentDefinition 对象的名称。

True

spec.param.trafficGenContainerDiskImage

流量生成器的容器磁盘镜像。默认值为 quay.io/kiagnose/kubevirt-dpdk-checkup-traffic-gen:main。

False

spec.param.trafficGenTargetNodeName

在其中调度流量生成器虚拟机的节点。节点应配置为允许 DPDK 流量。

False

spec.param.trafficGenPacketsPerSecond

每秒数据包数量，单位为(k)或500万(m)。默认值为 8m。

False

spec.param.vmUnderTestContainerDiskImage

测试中的虚拟机的容器磁盘镜像。默认值为 quay.io/kiagnose/kubevirt-dpdk-checkup-vm:main。

False

spec.param.vmUnderTestTargetNodeName

在其中调度测试虚拟机的节点。节点应配置为允许 DPDK 流量。

False

spec.param.testDuration

流量生成器运行的持续时间（以分钟为单位）。默认值为 5 分钟。

False

spec.param.portBandwidthGbps

SR-IOV NIC 的最大带宽。默认值为 10Gbps。

False

spec.param.verbose

当设置为 true 时，它会增加检查日志的详细程度。默认值为 false。

False

12.2.1.2.2. 为 RHEL 虚拟机构建容器磁盘镜像

您可以使用 qcow2 格式构建自定义 Red Hat Enterprise Linux (RHEL) 8 OS 镜像，并使用它来创建容器磁盘镜像。您可以将容器磁盘镜像存储在集群中可访问的 registry 中，并在 DPDK 检查配置映射的 spec.param.vmContainerDiskImage 属性中指定镜像位置。

要构建容器镜像，您必须创建一个镜像构建器虚拟机 (VM)。镜像构建器虚拟机 是一个 RHEL 8 虚拟机，可用于构建自定义 RHEL 镜像。

先决条件

  • 镜像构建器虚拟机必须运行 RHEL 8.7，且必须至少在 /var 目录中有 2 个 CPU 内核、4 GiB RAM 和 20 GB 的可用空间。
  • 您已在虚拟机上安装了镜像构建器工具及其 CLI (composer-cli)。

  • 已安装 virt-customize 工具： 

    # dnf install libguestfs-tools
  • 已安装 Podman CLI 工具 (podman)。

流程

  1. 验证您可以构建 RHEL 8.7 镜像： 

    # composer-cli distros list
    注意

    要以非 root 身份运行 composer-cli 命令，请将您的用户添加到 weldr 或 root 组中： 

    # usermod -a -G weldr user
    $ newgrp weldr

  2. 输入以下命令以 TOML 格式创建镜像蓝图文件，其中包含要安装的软件包、内核自定义和服务，以及在引导时要禁用的服务： 

    $ cat << EOF > dpdk-vm.toml
name = "dpdk_image"
description = "Image to use with the DPDK checkup"
version = "0.0.1"
distro = "rhel-87"

[[packages]]
name = "dpdk"

[[packages]]
name = "dpdk-tools"

[[packages]]
name = "driverctl"

[[packages]]
name = "tuned-profiles-cpu-partitioning"

[customizations.kernel]
append = "default_hugepagesz=1GB hugepagesz=1G hugepages=8 isolcpus=2-7"

[customizations.services]
disabled = ["NetworkManager-wait-online", "sshd"]
EOF

  3. 运行以下命令，将蓝图文件推送到镜像构建器工具中： 

    # composer-cli blueprints push dpdk-vm.toml

  4. 通过指定蓝图名称和输出文件格式来生成系统镜像。在开始 compose 过程时，会显示镜像的通用唯一标识符(UUID)。 

    # composer-cli compose start dpdk_image qcow2

  5. 等待 compose 进程完成。compose 状态必须先显示 FINISHED，然后才能继续下一步。 

    # composer-cli compose status

  6. 输入以下命令通过指定其 UUID 来下载 qcow2 镜像文件： 

    # composer-cli compose image <UUID>

  7. 运行以下命令来创建自定义脚本： 

    $ cat <<EOF >customize-vm
echo  isolated_cores=2-7 > /etc/tuned/cpu-partitioning-variables.conf
tuned-adm profile cpu-partitioning
echo "options vfio enable_unsafe_noiommu_mode=1" > /etc/modprobe.d/vfio-noiommu.conf
EOF
    $ cat <<EOF >first-boot
driverctl set-override 0000:06:00.0 vfio-pci
driverctl set-override 0000:07:00.0 vfio-pci

mkdir /mnt/huge
mount /mnt/huge --source nodev -t hugetlbfs -o pagesize=1GB
EOF

  8. 使用 virt-customize 工具自定义镜像构建器工具生成的镜像： 

    $ virt-customize -a <UUID>.qcow2 --run=customize-vm --firstboot=first-boot --selinux-relabel

  9. 要创建包含构建容器镜像的所有命令的 Dockerfile，请输入以下命令： 

    $ cat << EOF > Dockerfile
FROM scratch
COPY <uuid>-disk.qcow2 /disk/
EOF

    其中：

    <uuid>-disk.qcow2
    以 qcow2 格式指定自定义镜像的名称。

  10. 运行以下命令构建并标记容器： 

    $ podman build . -t dpdk-rhel:latest

  11. 运行以下命令，将容器磁盘镜像推送到集群可访问的 registry： 

    $ podman push dpdk-rhel:latest
  12. 在 DPDK 检查配置映射中的 spec.param.vmContainerDiskImage 属性中提供容器磁盘镜像的链接。

12.2.2. 其他资源

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.