10.18. 高级虚拟机管理

10.18.1. 为虚拟机使用资源配额

为虚拟机创建和管理资源配额。

10.18.1.1. 为虚拟机设置资源配额限制

只有使用请求自动用于虚拟机 (VM) 的资源配额。如果您的资源配额使用限制,则必须为虚拟机手动设置资源限值。资源限值必须至少大于资源请求的 100 MiB。

流程

  1. 通过编辑 VirtualMachine 清单来为虚拟机设置限值。例如:

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
      name: with-limits
    spec:
      running: false
      template:
        spec:
          domain:
    # ...
            resources:
              requests:
                memory: 128Mi
              limits:
                memory: 256Mi  1
    1
    这个配置被支持,因为 limits.memory 值至少比 requests.memory 的值大 100Mi
  2. 保存 VirtualMachine 清单。

10.18.1.2. 其他资源

10.18.2. 为虚拟机指定节点

您可以使用节点放置规则将虚拟机放置到特定的节点上。

10.18.2.1. 关于虚拟机的节点放置

要确保虚拟机在适当的节点上运行,您可以配置节点放置规则。如果出现以下情况,您可能需要进行此操作:

  • 您有多台虚拟机。为确保容错,您希望它们在不同节点上运行。
  • 您有两个 chatty 虚拟机。为了避免冗余节点间路由,您希望虚拟机在同一节点上运行。
  • 您的虚拟机需要所有可用节点上不存在的特定硬件功能。
  • 您有一个 pod 可以向节点添加功能,并想将虚拟机放置到该节点上,以便它可以使用这些功能。
注意

虚拟机放置依赖于工作负载的现有节点放置规则。如果组件级别上的特定节点排除工作负载,则虚拟机无法放置在这些节点上。

您可以在 VirtualMachine 清单的 spec 字段中使用以下规则类型:

nodeSelector
允许将虚拟机调度到使用此字段中指定的键值对标记的节点上。节点必须具有与所有列出的对完全匹配的标签。
关联性

这可让您使用更具表达力的语法来设置与虚拟机匹配的规则。例如,您可以指定规则是首选项,而非硬要求,因此在规则不满足时仍然可以调度虚拟机。虚拟机放置支持 Pod 关联性、pod 反关联性和节点关联性。Pod 关联性适用于虚拟机,因为 VirtualMachine 工作负载类型基于 Pod 对象。

注意

关联性规则仅在调度期间应用。如果不再满足限制,OpenShift Container Platform 不会重新调度正在运行的工作负载。

容限(tolerations)
允许将虚拟机调度到具有匹配污点的节点。如果污点应用到某个节点,则该节点只接受容许该污点的虚拟机。

10.18.2.2. 节点放置示例

以下示例 YAML 文件片断使用 nodePlacementaffinitytolerations 字段为虚拟机自定义节点放置。

10.18.2.2.1. 示例:使用 nodeSelector 放置虚拟机节点

在本例中,虚拟机需要一个包含 example-key-1 = example-value-1example-key-2 = example-value-2 标签的元数据的节点。

警告

如果没有节点适合此描述,则不会调度虚拟机。

VM 清单示例

metadata:
  name: example-vm-node-selector
apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  template:
    spec:
      nodeSelector:
        example-key-1: example-value-1
        example-key-2: example-value-2
...

10.18.2.2.2. 示例:使用 pod 关联性和 pod 反关联性的虚拟机节点放置

在本例中,虚拟机必须调度到具有标签 example-key-1 = example-value-1 的正在运行的 pod 的节点上。如果没有在任何节点上运行这样的 pod,则不会调度虚拟机。

如果可能,虚拟机不会调度到具有标签 example-key-2 = example-value-2 的 pod 的节点上。但是,如果所有候选节点都有具有此标签的 pod,调度程序会忽略此约束。

VM 清单示例

metadata:
  name: example-vm-pod-affinity
apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  template:
    spec:
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution: 1
          - labelSelector:
              matchExpressions:
              - key: example-key-1
                operator: In
                values:
                - example-value-1
            topologyKey: kubernetes.io/hostname
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution: 2
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: example-key-2
                  operator: In
                  values:
                  - example-value-2
              topologyKey: kubernetes.io/hostname
# ...

1
如果您使用 requiredDuringSchedulingIgnoredDuringExecution 规则类型,如果没有满足约束,则不会调度虚拟机。
2
如果您使用 preferredDuringSchedulingIgnoredDuringExecution 规则类型,只要满足所有必要的限制,仍会调度虚拟机(如果未满足约束)。
10.18.2.2.3. 示例:使用节点关联性进行虚拟机节点放置

在本例中,虚拟机必须调度到具有标签 example.io/example-key = example-value-1 或标签 example.io/example-key = example-value-2 的节点上。如果节点上只有一个标签,则会满足约束。如果没有标签,则不会调度虚拟机。

若有可能,调度程序会避免具有标签 example-node-label-key = example-node-label-value 的节点。但是,如果所有候选节点都具有此标签,调度程序会忽略此限制。

VM 清单示例

metadata:
  name: example-vm-node-affinity
apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution: 1
            nodeSelectorTerms:
            - matchExpressions:
              - key: example.io/example-key
                operator: In
                values:
                - example-value-1
                - example-value-2
          preferredDuringSchedulingIgnoredDuringExecution: 2
          - weight: 1
            preference:
              matchExpressions:
              - key: example-node-label-key
                operator: In
                values:
                - example-node-label-value
# ...

1
如果您使用 requiredDuringSchedulingIgnoredDuringExecution 规则类型,如果没有满足约束,则不会调度虚拟机。
2
如果您使用 preferredDuringSchedulingIgnoredDuringExecution 规则类型,只要满足所有必要的限制,仍会调度虚拟机(如果未满足约束)。
10.18.2.2.4. 示例:带有容限的虚拟机节点放置

在本例中,为虚拟机保留的节点已使用 key=virtualization:NoSchedule 污点标记。由于此虚拟机具有匹配的容限,它可以调度到污点节点上。

注意

容许污点的虚拟机不需要调度到具有该污点的节点。

VM 清单示例

metadata:
  name: example-vm-tolerations
apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  tolerations:
  - key: "key"
    operator: "Equal"
    value: "virtualization"
    effect: "NoSchedule"
...

10.18.2.3. 其他资源

10.18.3. 配置证书轮转

配置证书轮转参数以替换现有证书。

10.18.3.1. 配置证书轮转

您可以在 web 控制台中的 OpenShift Virtualization 安装过程中,或者在安装 HyperConverged 自定义资源(CR)后完成此操作。

流程

  1. 运行以下命令打开 HyperConverged CR:

    $ oc edit hco -n openshift-cnv kubevirt-hyperconverged
  2. 按照以下示例所示,编辑 spec.certConfig 字段。要避免系统过载,请确保所有值都大于或等于 10 分钟。将所有值显示为符合 golang ParseDuration 格式的字符串

    apiVersion: hco.kubevirt.io/v1beta1
    kind: HyperConverged
    metadata:
     name: kubevirt-hyperconverged
     namespace: openshift-cnv
    spec:
      certConfig:
        ca:
          duration: 48h0m0s
          renewBefore: 24h0m0s 1
        server:
          duration: 24h0m0s  2
          renewBefore: 12h0m0s  3
    1
    ca.renewBefore 的值必须小于或等于 ca.duration 的值。
    2
    server.duration 的值必须小于或等于 ca.duration 的值。
    3
    server.renewBefore 的值必须小于或等于 server.duration 的值。
  3. 将 YAML 文件应用到集群。

10.18.3.2. 证书轮转参数故障排除

删除一个或多个 certConfig 值会导致它们恢复到默认值,除非默认值与以下条件之一冲突:

  • ca.renewBefore 的值必须小于或等于 ca.duration 的值。
  • server.duration 的值必须小于或等于 ca.duration 的值。
  • server.renewBefore 的值必须小于或等于 server.duration 的值。

如果默认值与这些条件冲突,您将收到错误。

如果您删除了以下示例中的 server.duration 值,则默认值 24h0m0s 大于 ca.duration 的值,并与指定条件冲突。

Example

certConfig:
   ca:
     duration: 4h0m0s
     renewBefore: 1h0m0s
   server:
     duration: 4h0m0s
     renewBefore: 4h0m0s

这会生成以下出错信息:

error: hyperconvergeds.hco.kubevirt.io "kubevirt-hyperconverged" could not be patched: admission webhook "validate-hco.kubevirt.io" denied the request: spec.certConfig: ca.duration is smaller than server.duration

错误消息仅提及第一个冲突。在继续操作前,查看所有 certConfig 值。

10.18.4. 为虚拟机使用 UEFI 模式

您可以使用统一可扩展固件接口(UEFI)模式引导虚拟机(VM)。

10.18.4.1. 关于虚拟机的 UEFI 模式

像旧的 BIOS 一样,统一可扩展固件接口(UEFI)在计算机启动时初始化硬件组件和操作系统镜像文件。与 BIOS 相比,UEFI 支持更现代的功能和自定义选项,从而加快启动速度。

它将初始化和启动的所有信息保存在带有 .efi 扩展的文件中,该扩展被保存在名为 EFI 系统分区(ESP)的特殊分区中。ESP 还包含安装在计算机上的操作系统的引导装载程序程序。

10.18.4.2. 在 UEFI 模式中引导虚拟机

您可以通过编辑 VirtualMachine 清单,将虚拟机配置为在 UEFI 模式中引导。

先决条件

  • 安装 OpenShift CLI (oc) 。

流程

  1. 编辑或创建 VirtualMachine 清单文件。使用 spec.firmware.bootloader 小节来配置 UEFI 模式:

    使用安全引导活跃在 UEFI 模式中引导

    apiversion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
      labels:
        special: vm-secureboot
      name: vm-secureboot
    spec:
      template:
        metadata:
          labels:
            special: vm-secureboot
        spec:
          domain:
            devices:
              disks:
              - disk:
                  bus: virtio
                name: containerdisk
            features:
              acpi: {}
              smm:
                enabled: true 1
            firmware:
              bootloader:
                efi:
                  secureBoot: true 2
    ...

    1
    OpenShift Virtualization 需要为 UEFI 模式的安全引导启用系统管理模式(SMM)。
    2
    使用 UEFI 模式时,OpenShift Virtualization 支持带有或不进行安全引导的虚拟机。如果启用了安全引导,则需要 UEFI 模式。但是,可以在不使用安全引导的情况下启用 UEFI 模式。
  2. 运行以下命令,将清单应用到集群:

    $ oc create -f <file_name>.yaml

10.18.5. 为虚拟机配置 PXE 启动

OpenShift Virtualization 中提供 PXE 启动或网络启动。网络启动支持计算机启动和加载操作系统或其他程序,无需本地连接的存储设备。例如,在部署新主机时,您可使用 PXE 启动从 PXE 服务器中选择所需操作系统镜像。

10.18.5.1. 先决条件

  • Linux 网桥必须已连接
  • PXE 服务器必须作为网桥连接至相同 VLAN。

10.18.5.2. 使用指定的 MAC 地址的 PXE 引导

作为管理员,您可首先为您的 PXE 网络创建 NetworkAttachmentDefinition 对象,以此通过网络引导客户端。然后在启动虚拟机实例前,在您的虚拟机实例配置文件中引用网络附加定义。如果 PXE 服务器需要,您还可在虚拟机实例配置文件中指定 MAC 地址。

先决条件

  • 必须已连接 Linux 网桥。
  • PXE 服务器必须作为网桥连接至相同 VLAN。

流程

  1. 在集群上配置 PXE 网络:

    1. 为 PXE 网络 pxe-net-conf 创建网络附加定义文件:

      apiVersion: "k8s.cni.cncf.io/v1"
      kind: NetworkAttachmentDefinition
      metadata:
        name: pxe-net-conf
      spec:
        config: '{
          "cniVersion": "0.3.1",
          "name": "pxe-net-conf",
          "plugins": [
            {
              "type": "cnv-bridge",
              "bridge": "br1",
              "vlan": 1 1
            },
            {
              "type": "cnv-tuning" 2
            }
          ]
        }'
      1
      可选: VLAN 标签。
      2
      cnv-tuning 插件为自定义 MAC 地址提供支持。
      注意

      虚拟机实例将通过所请求的 VLAN 的访问端口附加到网桥 br1

  2. 使用您在上一步中创建的文件创建网络附加定义:

    $ oc create -f pxe-net-conf.yaml
  3. 编辑虚拟机实例配置文件以包括接口和网络的详情。

    1. 如果 PXE 服务器需要,请指定网络和 MAC 地址。如果未指定 MAC 地址,则会自动分配一个值。

      请确保 bootOrder 设置为 1,以便该接口先启动。在本例中,该接口连接到了名为 <pxe-net> 的网络中:

      interfaces:
      - masquerade: {}
        name: default
      - bridge: {}
        name: pxe-net
        macAddress: de:00:00:00:00:de
        bootOrder: 1
      注意

      启动顺序对于接口和磁盘全局通用。

    2. 为磁盘分配一个启动设备号,以确保置备操作系统后能够正确启动。

      将磁盘 bootOrder 值设置为 2

      devices:
        disks:
        - disk:
            bus: virtio
          name: containerdisk
          bootOrder: 2
    3. 指定网络连接到之前创建的网络附加定义。在这种情况下,<pxe-net> 连接到名为 <pxe-net-conf> 的网络附加定义:

      networks:
      - name: default
        pod: {}
      - name: pxe-net
        multus:
          networkName: pxe-net-conf
  4. 创建虚拟机实例:

    $ oc create -f vmi-pxe-boot.yaml

输出示例

  virtualmachineinstance.kubevirt.io "vmi-pxe-boot" created

  1. 等待虚拟机实例运行:

    $ oc get vmi vmi-pxe-boot -o yaml | grep -i phase
      phase: Running
  2. 使用 VNC 查看虚拟机实例:

    $ virtctl vnc vmi-pxe-boot
  3. 查看启动屏幕,验证 PXE 启动是否成功。
  4. 登录虚拟机实例:

    $ virtctl console vmi-pxe-boot
  5. 验证虚拟机上的接口和 MAC 地址,并验证连接到网桥的接口是否具有指定的 MAC 地址。在本例中,我们使用了 eth1 进行 PXE 启动,无需 IP 地址。另一接口 eth0 从 OpenShift Container Platform 获取 IP 地址。

    $ ip addr

输出示例

...
3. eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
   link/ether de:00:00:00:00:de brd ff:ff:ff:ff:ff:ff

10.18.5.3. OpenShift Virtualization 术语表

OpenShift Virtualization 使用自定义资源和插件提供高级联网功能。

以下是整个 OpenShift Virtualization 文档中使用的术语:

Container Network Interface (CNI)
一个 Cloud Native Computing Foundation 项目,侧重容器网络连接。OpenShift Virtualization 使用 CNI 插件基于基本 Kubernetes 网络功能进行构建。
Multus
一个“meta”CNI 插件,支持多个 CNI 共存,以便 pod 或虚拟机可使用其所需的接口。
自定义资源定义(CRD)
一种 Kubernetes API 资源,用于定义自定义资源,或使用 CRD API 资源定义的对象。
网络附加定义(NAD)
由 Multus 项目引入的 CRD,允许您将 Pod、虚拟机和虚拟机实例附加到一个或多个网络。
节点网络配置策略(NNCP)
节点上请求的网络配置的描述。您可以通过将 NodeNetworkConfigurationPolicy清单应用到集群来更新节点网络配置,包括添加和删除网络接口 。
预启动执行环境 (PXE)
一种接口,让管理员能够通过网络从服务器启动客户端机器。网络启动可用于为客户端远程加载操作系统和其他软件。

10.18.6. 在虚拟机中使用巨页

您可以使用巨页作为集群中虚拟机的后备内存。

10.18.6.1. 先决条件

10.18.6.2. 巨页的作用

内存在块(称为页)中进行管理。在大多数系统中,页的大小为 4Ki。1Mi 内存相当于 256 个页,1Gi 内存相当于 256,000 个页。CPU 有内置的内存管理单元,可在硬件中管理这些页的列表。Translation Lookaside Buffer (TLB) 是虚拟页到物理页映射的小型硬件缓存。如果在硬件指令中包括的虚拟地址可以在 TLB 中找到,则其映射信息可以被快速获得。如果没有包括在 TLN 中,则称为 TLB miss。系统将会使用基于软件的,速度较慢的地址转换机制,从而出现性能降低的问题。因为 TLB 的大小是固定的,因此降低 TLB miss 的唯一方法是增加页的大小。

巨页指一个大于 4Ki 的内存页。在 x86_64 构架中,有两个常见的巨页大小: 2Mi 和 1Gi。在其它构架上的大小会有所不同。要使用巨页,必须写相应的代码以便应用程序了解它们。Transparent Huge Pages(THP)试图在应用程序不需要了解的情况下自动管理巨页,但这个技术有一定的限制。特别是,它的页大小会被限为 2Mi。当有较高的内存使用率时,THP 可能会导致节点性能下降,或出现大量内存碎片(因为 THP 的碎片处理)导致内存页被锁定。因此,有些应用程序可能更适用于(或推荐)使用预先分配的巨页,而不是 THP。

在 OpenShift Virtualization 中,可将虚拟机配置为消耗预先分配的巨页。

10.18.6.3. 为虚拟机配置巨页

您可以在虚拟机配置中包括 memory.hugepages.pageSizeresources.requests.memory 参数来配置虚拟机来使用预分配的巨页。

内存请求必须按页大小分离。例如,您不能对大小为 1Gi 的页请求 500Mi 内存。

注意

主机的内存布局和客户端操作系统不相关。虚拟机清单中请求的巨页适用于 QEMU。客户端中的巨页只能根据虚拟机实例的可用内存量来配置。

如果您编辑了正在运行的虚拟机,则必须重启虚拟机才能使更改生效。

先决条件

  • 节点必须配置预先分配的巨页。

流程

  1. 在虚拟机配置中,把 resources.requests.memorymemory.hugepages.pageSize 参数添加到 spec.domain。以下配置片段适用于请求总计 4Gi 内存的虚拟机,页面大小为 1Gi:

    kind: VirtualMachine
    ...
    spec:
      domain:
        resources:
          requests:
            memory: "4Gi" 1
        memory:
          hugepages:
            pageSize: "1Gi" 2
    ...
    1
    为虚拟机请求的总内存量。这个值必须可以被按页大小整除。
    2
    每个巨页的大小。x86_64 架构的有效值为 1Gi2Mi。页面大小必须小于请求的内存。
  2. 应用虚拟机配置:

    $ oc apply -f <virtual_machine>.yaml

10.18.7. 为虚拟机启用专用资源

要提高性能,您可以将节点的资源(如 CPU)专用于特定的一个虚拟机。

10.18.7.1. 关于专用资源

当为您的虚拟机启用专用资源时,您的工作负载将会在不会被其他进程使用的 CPU 上调度。通过使用专用资源,您可以提高虚拟机性能以及延迟预测的准确性。

10.18.7.2. 先决条件

  • 节点上必须配置 CPU Manager。在调度虚拟机工作负载前,请确认节点具有 cpumanager = true 标签。
  • 虚拟机必须关机。

10.18.7.3. 为虚拟机启用专用资源

您可以在 Details 选项卡中为虚拟机启用专用资源。从红帽模板创建的虚拟机可以使用专用资源进行配置。

流程

  1. 在 OpenShift Container Platform 控制台中,从侧边菜单中点 VirtualizationVirtualMachines
  2. 选择虚拟机以打开 VirtualMachine 详情页面。
  3. Scheduling 选项卡中,点 Dedicated Resources 旁边的铅笔图标。
  4. 选择 Schedule this workload with dedicated resources (guaranteed policy)
  5. Save

10.18.8. 调度虚拟机

在确保虚拟机的 CPU 模型和策略属性与节点支持的 CPU 模型和策略属性兼容的情况下,可在节点上调度虚拟机(VM)。

10.18.8.1. 策略属性

您可以指定策略属性和在虚拟机调度到节点上时匹配的 CPU 功能来调度虚拟机(VM)。为虚拟机指定的策略属性决定了如何在节点上调度该虚拟机。

策略属性描述

force

VM 被强制调度到某个节点上。即使主机 CPU 不支持虚拟机的 CPU,也是如此。

require

在虚拟机没有使用特定 CPU 模型和功能规格配置时,应用于虚拟机的默认策略。如果节点没有配置为支持使用此默认策略属性或其他策略属性的 CPU 节点发现,则虚拟机不会调度到该节点上。主机 CPU 必须支持虚拟机的 CPU,或者虚拟机监控程序必须可以模拟支持的 CPU 模型。

optional

如果主机物理机器 CPU 支持该虚拟机,则虚拟机会被添加到节点。

disable

无法通过 CPU 节点发现调度虚拟机。

forbid

即使主机 CPU 支持该功能,且启用了 CPU 节点发现,也不会调度虚拟机。

10.18.8.2. 设置策略属性和 CPU 功能

您可以为每个虚拟机(VM)设置策略属性和 CPU 功能,以确保根据策略和功能在节点上调度该功能。验证您设置的 CPU 功能以确保主机 CPU 支持或者虚拟机监控程序模拟该功能。

流程

  • 编辑虚拟机配置文件的 domain spec。以下示例设置虚拟机 (VM) 的 CPU 功能和 require 策略:

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
      name: myvm
    spec:
      template:
        spec:
          domain:
            cpu:
              features:
                - name: apic 1
                  policy: require 2
    1
    虚拟机的 CPU 功能名称。
    2
    虚拟机的策略属性.

10.18.8.3. 使用支持的 CPU 型号调度虚拟机

您可以为虚拟机 (VM) 配置 CPU 模型,将其调度到支持其 CPU 模型的节点。

流程

  • 编辑虚拟机配置文件的 domain spec。以下示例显示了为虚拟机定义的特定 CPU 模型:

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
      name: myvm
    spec:
      template:
        spec:
          domain:
            cpu:
              model: Conroe 1
    1
    虚拟机的 CPU 模型.

10.18.8.4. 使用主机模型调度虚拟机

当将虚拟机(VM)的 CPU 模型设置为 host-model 时,虚拟机会继承调度节点的 CPU 模型。

流程

  • 编辑虚拟机配置文件的 domain spec。以下示例演示了为虚拟机指定 host-model

    apiVersion: kubevirt/v1alpha3
    kind: VirtualMachine
    metadata:
      name: myvm
    spec:
      template:
        spec:
          domain:
            cpu:
              model: host-model 1
    1
    继承调度节点的 CPU 模型的虚拟机。

10.18.9. 配置 PCI 透传

借助 Peripheral Component Interconnect(PCI)透传功能,您可以从虚拟机访问和管理硬件设备。配置 PCI 透传后,PCI 设备的功能就如同它们实际上附加到客户机操作系统上一样。

集群管理员可以使用 oc CLI 来公开和管理集群中允许在集群中使用的主机设备。

10.18.9.1. 关于为 PCI 透传准备主机设备

要使用 CLI 为 PCI 透传准备主机设备,请创建一个 MachineConfig 对象并添加内核参数,以启用输入输出内存管理单元(IOMMU)。将 PCI 设备绑定到虚拟功能 I/O(VFIO)驱动程序,然后通过编辑 HyperConverged 自定义资源(CR)的 allowedHostDevices 字段在集群中公开它。首次安装 OpenShift Virtualization Operator 时,allowedHostDevices 列表为空。

要使用 CLI 从集群中删除 PCI 主机设备,可从 HyperConverged CR 中删除 PCI 设备信息。

10.18.9.1.1. 添加内核参数以启用 IOMMU 驱动程序

要在内核中启用 IOMMU(Input-Output Memory Management Unit)驱动程序,请创建 MachineConfig 对象并添加内核参数。

先决条件

  • 正常运行的 OpenShift 容器平台集群的管理特权。
  • Intel 或 AMD CPU 硬件。
  • 启用用于直接 I/O 扩展的 Intel 虚拟化技术或 BIOS 中的 AMD IOMMU(基本输入/输出系统)。

流程

  1. 创建用于标识内核参数的 MachineConfig 对象。以下示例显示了 Intel CPU 的内核参数。

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker 1
      name: 100-worker-iommu 2
    spec:
      config:
        ignition:
          version: 3.2.0
      kernelArguments:
          - intel_iommu=on 3
    ...
    1
    仅将新内核参数应用到 worker 节点。
    2
    name 表示此内核参数(100)在机器配置及其目的中的排名。如果您有 AMD CPU,请将内核参数指定为 amd_iommu=on
    3
    将内核参数标识为 Intel CPU 的 intel_iommu
  2. 创建新的 MachineConfig 对象:

    $ oc create -f 100-worker-kernel-arg-iommu.yaml

验证

  • 验证是否添加了新的 MachineConfig 对象。

    $ oc get MachineConfig
10.18.9.1.2. 将 PCI 设备绑定到 VFIO 驱动程序

要将 PCI 设备绑定到 VFIO(虚拟功能 I/O)驱动程序,请从每个设备获取 vendor-IDdevice-ID 的值,并创建值的列表。将这个列表添加到 MachineConfig 对象。MachineConfig Operator 在带有 PCI 设备的节点上生成 /etc/modprobe.d/vfio.conf,并将 PCI 设备绑定到 VFIO 驱动程序。

先决条件

  • 您添加了内核参数来为 CPU 启用 IOMMU。

流程

  1. 运行 lspci 命令,以获取 PCI 设备的 vendor-IDdevice-ID

    $ lspci -nnv | grep -i nvidia

    输出示例

    02:01.0 3D controller [0302]: NVIDIA Corporation GV100GL [Tesla V100 PCIe 32GB] [10de:1eb8] (rev a1)

  2. 创建 Butane 配置文件 100-worker-vfiopci.bu,将 PCI 设备绑定到 VFIO 驱动程序。

    注意

    有关 Butane 的信息,请参阅"使用 Butane 创建机器配置"。

    Example

    variant: openshift
    version: 4.12.0
    metadata:
      name: 100-worker-vfiopci
      labels:
        machineconfiguration.openshift.io/role: worker 1
    storage:
      files:
      - path: /etc/modprobe.d/vfio.conf
        mode: 0644
        overwrite: true
        contents:
          inline: |
            options vfio-pci ids=10de:1eb8 2
      - path: /etc/modules-load.d/vfio-pci.conf 3
        mode: 0644
        overwrite: true
        contents:
          inline: vfio-pci

    1
    仅将新内核参数应用到 worker 节点。
    2
    指定之前确定的 vendor-ID 值(10de)和 device-ID 值(1eb8)来将单个设备绑定到 VFIO 驱动程序。您可以使用其供应商和设备信息添加多个设备列表。
    3
    在 worker 节点上载入 vfio-pci 内核模块的文件。
  3. 使用 Butane 生成 MachineConfig 对象文件 100-worker-vfiopci.yaml,包含要发送到 worker 节点的配置:

    $ butane 100-worker-vfiopci.bu -o 100-worker-vfiopci.yaml
  4. MachineConfig 对象应用到 worker 节点:

    $ oc apply -f 100-worker-vfiopci.yaml
  5. 验证 MachineConfig 对象是否已添加。

    $ oc get MachineConfig

    输出示例

    NAME                             GENERATEDBYCONTROLLER                      IGNITIONVERSION  AGE
    00-master                        d3da910bfa9f4b599af4ed7f5ac270d55950a3a1   3.2.0            25h
    00-worker                        d3da910bfa9f4b599af4ed7f5ac270d55950a3a1   3.2.0            25h
    01-master-container-runtime      d3da910bfa9f4b599af4ed7f5ac270d55950a3a1   3.2.0            25h
    01-master-kubelet                d3da910bfa9f4b599af4ed7f5ac270d55950a3a1   3.2.0            25h
    01-worker-container-runtime      d3da910bfa9f4b599af4ed7f5ac270d55950a3a1   3.2.0            25h
    01-worker-kubelet                d3da910bfa9f4b599af4ed7f5ac270d55950a3a1   3.2.0            25h
    100-worker-iommu                                                            3.2.0            30s
    100-worker-vfiopci-configuration                                            3.2.0            30s

验证

  • 验证是否已加载 VFIO 驱动程序。

    $ lspci -nnk -d 10de:

    输出确认使用了 VFIO 驱动程序。

    输出示例

    04:00.0 3D controller [0302]: NVIDIA Corporation GP102GL [Tesla P40] [10de:1eb8] (rev a1)
            Subsystem: NVIDIA Corporation Device [10de:1eb8]
            Kernel driver in use: vfio-pci
            Kernel modules: nouveau

10.18.9.1.3. 使用 CLI 在集群中公开 PCI 主机设备

要在集群中公开 PCI 主机设备,将 PCI 设备的详细信息添加到 HyperConverged 自定义资源(CR)的 spec.permittedHostDevices.pciHostDevices 数组中。

流程

  1. 运行以下命令,在默认编辑器中编辑 HyperConverged CR:

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
  2. 将 PCI 设备信息添加到 spec.percommitHostDevices.pciHostDevices 数组。例如:

    配置文件示例

    apiVersion: hco.kubevirt.io/v1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
      namespace: openshift-cnv
    spec:
      permittedHostDevices: 1
        pciHostDevices: 2
        - pciDeviceSelector: "10DE:1DB6" 3
          resourceName: "nvidia.com/GV100GL_Tesla_V100" 4
        - pciDeviceSelector: "10DE:1EB8"
          resourceName: "nvidia.com/TU104GL_Tesla_T4"
        - pciDeviceSelector: "8086:6F54"
          resourceName: "intel.com/qat"
          externalResourceProvider: true 5
    ...

    1
    允许在集群中使用的主机设备。
    2
    节点上可用的 PCI 设备列表。
    3
    标识 PCI 设备所需的 vendor-IDdevice-ID
    4
    PCI 主机设备的名称。
    5
    可选:将此字段设置为 true 表示资源由外部设备插件提供。OpenShift Virtualization 允许在集群中使用这个设备,但会把分配和监控留给外部设备插件。
    注意

    上例代码片段显示有两个 PCI 主机设备,名为 nvidia.com/GV100GL_Tesla_V100nvidia.com/TU104GL_Tesla_Tesla_T4。它们被添加到 HyperConverged CR 中的允许主机设备列表中。这些设备已经过测试和验证以用于 OpenShift Virtualization。

  3. 保存更改并退出编辑器。

验证

  • 运行以下命令,验证 PCI 主机设备是否已添加到节点。示例输出显示,每个设备都与 nvidia.com/GV100GL_Tesla_V100nvidia.com/TU104GL_Tesla_T4intel.com/qat 资源名称关联。

    $ oc describe node <node_name>

    输出示例

    Capacity:
      cpu:                            64
      devices.kubevirt.io/kvm:        110
      devices.kubevirt.io/tun:        110
      devices.kubevirt.io/vhost-net:  110
      ephemeral-storage:              915128Mi
      hugepages-1Gi:                  0
      hugepages-2Mi:                  0
      memory:                         131395264Ki
      nvidia.com/GV100GL_Tesla_V100   1
      nvidia.com/TU104GL_Tesla_T4     1
      intel.com/qat:                  1
      pods:                           250
    Allocatable:
      cpu:                            63500m
      devices.kubevirt.io/kvm:        110
      devices.kubevirt.io/tun:        110
      devices.kubevirt.io/vhost-net:  110
      ephemeral-storage:              863623130526
      hugepages-1Gi:                  0
      hugepages-2Mi:                  0
      memory:                         130244288Ki
      nvidia.com/GV100GL_Tesla_V100   1
      nvidia.com/TU104GL_Tesla_T4     1
      intel.com/qat:                  1
      pods:                           250

10.18.9.1.4. 使用 CLI 从集群中删除 PCI 主机设备

要从集群中删除 PCI 主机设备,请从 HyperConverged 自定义资源(CR)中删除该设备的信息。

流程

  1. 运行以下命令,在默认编辑器中编辑 HyperConverged CR:

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
  2. 通过删除相应设备的 pciDeviceSelectorresourceNameexternalResourceProvider(如果适用)字段来从 spec.permittedHostDevices.pciHostDevices 阵列中删除 PCI 设备信息。在本例中,intel.com/qat 资源已被删除。

    配置文件示例

    apiVersion: hco.kubevirt.io/v1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
      namespace: openshift-cnv
    spec:
      permittedHostDevices:
        pciHostDevices:
        - pciDeviceSelector: "10DE:1DB6"
          resourceName: "nvidia.com/GV100GL_Tesla_V100"
        - pciDeviceSelector: "10DE:1EB8"
          resourceName: "nvidia.com/TU104GL_Tesla_T4"
    ...

  3. 保存更改并退出编辑器。

验证

  • 运行以下命令,验证 PCI 主机设备已从节点移除。示例输出显示,与 intel.com/qat 资源名称关联的设备为零。

    $ oc describe node <node_name>

    输出示例

    Capacity:
      cpu:                            64
      devices.kubevirt.io/kvm:        110
      devices.kubevirt.io/tun:        110
      devices.kubevirt.io/vhost-net:  110
      ephemeral-storage:              915128Mi
      hugepages-1Gi:                  0
      hugepages-2Mi:                  0
      memory:                         131395264Ki
      nvidia.com/GV100GL_Tesla_V100   1
      nvidia.com/TU104GL_Tesla_T4     1
      intel.com/qat:                  0
      pods:                           250
    Allocatable:
      cpu:                            63500m
      devices.kubevirt.io/kvm:        110
      devices.kubevirt.io/tun:        110
      devices.kubevirt.io/vhost-net:  110
      ephemeral-storage:              863623130526
      hugepages-1Gi:                  0
      hugepages-2Mi:                  0
      memory:                         130244288Ki
      nvidia.com/GV100GL_Tesla_V100   1
      nvidia.com/TU104GL_Tesla_T4     1
      intel.com/qat:                  0
      pods:                           250

10.18.9.2. 为 PCI 透传配置虚拟机

将 PCI 设备添加到集群中后,您可以将它们分配到虚拟机。PCI 设备现在可用。就像它们被物理地连接到虚拟机一样。

10.18.9.2.1. 为虚拟机分配 PCI 设备

当集群中有 PCI 设备时,您可以将其分配到虚拟机并启用 PCI 透传。

流程

  • 将 PCI 设备分配到虚拟机作为主机设备。

    Example

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    spec:
      domain:
        devices:
          hostDevices:
          - deviceName: nvidia.com/TU104GL_Tesla_T4 1
            name: hostdevices1

    1
    集群中作为主机设备允许的 PCI 设备的名称。虚拟机可以访问此主机设备。

验证

  • 使用以下命令,验证主机设备可从虚拟机使用。

    $ lspci -nnk | grep NVIDIA

    输出示例

    $ 02:01.0 3D controller [0302]: NVIDIA Corporation GV100GL [Tesla V100 PCIe 32GB] [10de:1eb8] (rev a1)

10.18.9.3. 其他资源

10.18.10. 配置 vGPU 透传

您的虚拟机可以访问虚拟 GPU(vGPU)硬件。通过为虚拟机分配 vGPU,您可以执行以下操作:

  • 访问底层硬件的 GPU 以达到虚拟机中的高性能优势。
  • 简化资源密集型 I/O 操作。
重要

vGPU 透传只能分配给连接到裸机环境中运行的集群的设备。

10.18.10.1. 为虚拟机分配 vGPU 透传设备

使用 OpenShift Container Platform web 控制台为虚拟机分配 vGPU 透传设备。

先决条件

  • 必须停止虚拟机。

流程

  1. 在 OpenShift Container Platform web 控制台中,从侧边菜单中点 Virtualization → VirtualMachines
  2. 选择您要为其分配该设备的虚拟机。
  3. Details 标签页中,点 GPU 设备

    如果将 vGPU 设备添加为主机设备,则无法使用 VNC 控制台访问该设备。

  4. Add GPU 设备,输入名称并从设备名称列表中选择 设备
  5. 点击 Save
  6. YAML 选项卡,验证 hostDevices 部分中的新设备是否已添加到集群配置中。
注意

您可以将硬件设备添加到从自定义模板或 YAML 文件创建的虚拟机中。您不能将设备添加到特定操作系统的预先提供的引导源模板,如 Windows 10 或 RHEL 7。

要显示连接到集群的资源,请从侧边菜单中点 ComputeHardware Devices

10.18.10.2. 其他资源

10.18.11. 配置介质设备

如果您在 HyperConverged 自定义资源(CR)中提供设备列表,OpenShift Virtualization 会自动创建介质设备,如虚拟 GPU(vGPU)。

重要

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

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

10.18.11.1. 关于使用 NVIDIA GPU Operator

NVIDIA GPU Operator 在 OpenShift Container Platform 集群中管理 NVIDIA GPU 资源,并自动执行与引导 GPU 节点相关的任务。由于 GPU 是集群中的一个特殊资源,因此您必须在将应用程序工作负载部署到 GPU 之前安装一些组件。这些组件包括 NVIDIA 驱动程序,启用计算统一设备架构(CUDA)、Kubernetes 设备插件、容器运行时等,如自动节点标签、监控等。

注意

NVIDIA GPU Operator 仅支持 NVIDIA。有关从 NVIDIA 获取支持的更多信息,请参阅 NVIDIA 支持

使用 OpenShift Container Platform OpenShift Virtualization 启用 GPU 有两种方法:这里介绍了 OpenShift Container Platform 原生方法,并使用 NVIDIA GPU Operator。

NVIDIA GPU Operator 是一个 Kubernetes Operator,它允许 OpenShift Container Platform OpenShift Virtualization 将 GPU 公开给在 OpenShift Container Platform 上运行的虚拟化工作负载。它允许用户轻松调配和管理启用了 GPU 的虚拟机,使他们能够在与其他工作负载相同的平台上运行复杂的人工智能/机器学习(AI/ML)工作负载。它还提供了一种简单的方式来扩展其基础架构的 GPU 容量,从而可以快速增长基于 GPU 的工作负载。

有关使用 NVIDIA GPU Operator 为运行 GPU 加速虚拟机置备 worker 节点的更多信息,请参阅使用 OpenShift Virtualization 的 NVIDIA GPU Operator

10.18.11.2. 关于在 OpenShift Virtualization 中使用虚拟 GPU

有些图形处理单元(GPU)卡支持创建虚拟 GPU(vGPU)。如果管理员在 HyperConverged 自定义资源(CR)中提供配置详情,则 OpenShift Virtualization 可以自动创建 vGPU 和其他介质设备。这个自动化对大型集群特别有用。

注意

有关功能和支持详情,请参考您的硬件供应商文档。

介质设备
划分为一个或多个虚拟设备的物理设备。vGPU 是一个介质设备(mdev)类型,物理 GPU 的性能会被划分到各个虚拟设备中。您可以将介质设备分配给一个或多个虚拟机(VM),但客户机数量必须与您的 GPU 兼容。有些 GPU 不支持多个虚拟机。
10.18.11.2.1. 先决条件
  • 如果您的硬件厂商提供驱动程序,您可以在要创建介质设备的节点上安装它们。

10.18.11.2.2. 配置概述

在配置介质设备时,管理员必须完成以下任务:

  • 创建介质设备。
  • 在集群中公开介质设备。

HyperConverged CR 包含可以实现这两个任务的 API。

创建介质设备

...
spec:
  mediatedDevicesConfiguration:
    mediatedDevicesTypes: 1
    - <device_type>
    nodeMediatedDeviceTypes: 2
    - mediatedDevicesTypes: 3
      - <device_type>
      nodeSelector: 4
        <node_selector_key>: <node_selector_value>
...

1
必需:为集群配置全局设置。
2
可选:覆盖特定节点或一组节点的全局配置。必须与全局 mediatedDevicesTypes 配置一起使用。
3
使用 nodeMediatedDeviceTypes 时需要此项。覆盖指定节点的全局 mediatedDevicesTypes 配置。
4
使用 nodeMediatedDeviceTypes 时需要此项。必须包含一个 key:value 对。

在集群中公开介质设备

...
  permittedHostDevices:
    mediatedDevices:
    - mdevNameSelector: GRID T4-2Q 1
      resourceName: nvidia.com/GRID_T4-2Q 2
...

1
公开映射到主机上这个值的介质设备。
注意

您可以通过 /sys/bus/pci/devices/<slot>:<bus>:<domain>.<function>/mdev_supported_types/<type>/name(使用您的具体系统信息替换相关部分)查看您的设备支持的介质设备类型。

例如,nvidia-231 类型的名称文件包含选择器字符串 GRID T4-2Q。使用 GRID T4-2Q 作为 mdevNameSelector 值,允许节点使用 nvidia-231 类型。

2
resourceName 应该与节点上分配的匹配。使用以下命令查找 resourceName
$ oc get $NODE -o json \
  | jq '.status.allocatable \
    | with_entries(select(.key | startswith("nvidia.com/"))) \
    | with_entries(select(.value != "0"))'
10.18.11.2.3. vGPU 如何分配给节点

对于每个物理设备,OpenShift Virtualization 配置以下值:

  • 单个 mdev 类型。
  • 所选 mdev 类型的最大实例数量。

集群架构会影响创建设备并分配到节点的方式。

每个节点具有多个卡的大型集群

在支持多个 vGPU 类型的节点上,以轮循方式创建相关设备类型。例如:

...
mediatedDevicesConfiguration:
  mediatedDevicesTypes:
  - nvidia-222
  - nvidia-228
  - nvidia-105
  - nvidia-108
...

在这种情况下,每个节点有两个卡,它们支持以下 vGPU 类型:

nvidia-105
...
nvidia-108
nvidia-217
nvidia-299
...

在每个节点上,OpenShift Virtualization 会创建以下 vGPU:

  • 在第一个卡上,16 个类型为 nvidia-105 的 vGPU。
  • 第二卡上的 2 个类型为 nvidia-108 的 vGPU。
一个节点有一个卡,它支持多个请求的 vGPU 类型

OpenShift Virtualization 使用最先在 mediatedDevicesTypes 列表中提供的支持类型。

例如,节点卡中的卡支持 nvidia-223nvidia-224。以下 mediatedDevicesTypes 列表已配置:

...
mediatedDevicesConfiguration:
  mediatedDevicesTypes:
  - nvidia-22
  - nvidia-223
  - nvidia-224
...

在本例中,OpenShift Virtualization 使用 nvidia-223 类型。

10.18.11.2.4. 关于更改和删除介质设备

集群的介质设备配置可使用 OpenShift Virtualization 更新:

  • 编辑 HyperConverged CR 并更改 mediatedDevicesTypes 小节的内容。
  • 更改与 nodeMediatedDeviceTypes 节点选择器匹配的节点标签。
  • HyperConverged CR 的 spec.mediatedDevicesConfigurationspec.permittedHostDevices 小节中删除设备信息。

    注意

    如果您在 spec.permittedHostDevices 小节中删除设备信息,且没有将其从 spec.mediatedDevicesConfiguration 小节中移除,则无法在同一节点上创建新的介质设备类型。要正确删除介质设备,请从两个段中删除设备信息。

根据具体更改,这些操作会导致 OpenShift Virtualization 重新配置介质设备或从集群节点中删除它们。

10.18.11.2.5. 为介质设备准备主机

在配置介质设备前,您必须启用输入输出内存管理单元 (IOMMU) 驱动程序。

10.18.11.2.5.1. 添加内核参数以启用 IOMMU 驱动程序

要在内核中启用 IOMMU(Input-Output Memory Management Unit)驱动程序,请创建 MachineConfig 对象并添加内核参数。

先决条件

  • 正常运行的 OpenShift 容器平台集群的管理特权。
  • Intel 或 AMD CPU 硬件。
  • 启用用于直接 I/O 扩展的 Intel 虚拟化技术或 BIOS 中的 AMD IOMMU(基本输入/输出系统)。

流程

  1. 创建用于标识内核参数的 MachineConfig 对象。以下示例显示了 Intel CPU 的内核参数。

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker 1
      name: 100-worker-iommu 2
    spec:
      config:
        ignition:
          version: 3.2.0
      kernelArguments:
          - intel_iommu=on 3
    ...
    1
    仅将新内核参数应用到 worker 节点。
    2
    name 表示此内核参数(100)在机器配置及其目的中的排名。如果您有 AMD CPU,请将内核参数指定为 amd_iommu=on
    3
    将内核参数标识为 Intel CPU 的 intel_iommu
  2. 创建新的 MachineConfig 对象:

    $ oc create -f 100-worker-kernel-arg-iommu.yaml

验证

  • 验证是否添加了新的 MachineConfig 对象。

    $ oc get MachineConfig
10.18.11.2.6. 添加和删除介质设备

您可以添加或删除介质设备。

10.18.11.2.6.1. 创建并公开介质设备

您可以通过编辑 HyperConverged 自定义资源(CR)来公开和创建介质设备,如虚拟 GPU(vGPU)。

先决条件

  • 已启用 IOMMU(Input-Output Memory Management Unit)驱动程序。

流程

  1. 运行以下命令,在默认编辑器中编辑 HyperConverged CR:

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
  2. 将介质设备信息添加到 HyperConverged CR spec 中,确保包含 mediatedDevicesConfiguration 和 allowed HostDevices 小节。例如:

    配置文件示例

    apiVersion: hco.kubevirt.io/v1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
      namespace: openshift-cnv
    spec:
      mediatedDevicesConfiguration: <.>
        mediatedDevicesTypes: <.>
        - nvidia-231
        nodeMediatedDeviceTypes: <.>
        - mediatedDevicesTypes: <.>
          - nvidia-233
          nodeSelector:
            kubernetes.io/hostname: node-11.redhat.com
      permittedHostDevices: <.>
        mediatedDevices:
        - mdevNameSelector: GRID T4-2Q
          resourceName: nvidia.com/GRID_T4-2Q
        - mdevNameSelector: GRID T4-8Q
          resourceName: nvidia.com/GRID_T4-8Q
    ...

    <.> 创建介质设备。<.> 必需: 全局 mediatedDevicesTypes 配置。<.> 可选:覆盖特定节点的全局配置。<.> 如果使用 nodeMediatedDeviceTypes 是必需的。<.> 向集群公开介质设备。

  3. 保存更改并退出编辑器。

验证

  • 您可以运行以下命令来验证设备是否已添加到特定节点:

    $ oc describe node <node_name>
10.18.11.2.6.2. 使用 CLI 从集群中删除介质设备

要从集群中删除介质设备,请从 HyperConverged 自定义资源(CR)中删除该设备的信息。

流程

  1. 运行以下命令,在默认编辑器中编辑 HyperConverged CR:

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
  2. HyperConverged CR 的 spec.mediatedDevicesConfigurationspec.permittedHostDevices 小节中删除设备信息。删除这两个条目可确保您稍后在同一节点上创建新的介质设备类型。例如:

    配置文件示例

    apiVersion: hco.kubevirt.io/v1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
      namespace: openshift-cnv
    spec:
      mediatedDevicesConfiguration:
        mediatedDevicesTypes: 1
          - nvidia-231
      permittedHostDevices:
        mediatedDevices: 2
        - mdevNameSelector: GRID T4-2Q
          resourceName: nvidia.com/GRID_T4-2Q

    1
    要删除 nvidia-231 设备类型,请从 mediatedDevicesTypes 阵列中删除它。
    2
    要删除 GRID T4-2Q 设备,请删除 mdevNameSelector 字段及其对应的 resourceName 字段。
  3. 保存更改并退出编辑器。

10.18.11.3. 使用介质设备

vGPU 是介质设备的类型;物理 GPU 的性能被划分到虚拟设备中。您可以将介质设备分配给一个或多个虚拟机。

10.18.11.3.1. 为虚拟机分配介质设备

为虚拟机分配介质设备,如虚拟 GPU(vGPU)。

先决条件

  • 介质设备在 HyperConverged 自定义资源中配置。

流程

  • 通过编辑 VirtualMachine 清单的 spec.domain.devices.gpus 小节,将介质设备分配给虚拟机(VM):

    虚拟机清单示例

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    spec:
      domain:
        devices:
          gpus:
          - deviceName: nvidia.com/TU104GL_Tesla_T4 1
            name: gpu1 2
          - deviceName: nvidia.com/GRID_T4-1Q
            name: gpu2

    1
    与介质设备关联的资源名称。
    2
    用于标识虚拟机上设备的名称。

验证

  • 要验证该设备在虚拟机中可用,运行以下命令,将 <device_name> 替换为 VirtualMachine 清单中的 deviceName 值:

    $ lspci -nnk | grep <device_name>

10.18.11.4. 其他资源

10.18.12. 配置 watchdog

通过为 watchdog 设备配置虚拟机(VM)、安装 watchdog 并启动 watchdog 服务来公开 watchdog。

10.18.12.1. 先决条件

  • 虚拟机必须具有对 i6300esb watchdog 设备的内核支持。Red Hat Enterprise Linux (RHEL) 镜像支持 i6300esb

10.18.12.2. 定义 watchdog 设备

定义在操作系统(OS)没有响应时 watchdog 如何进行处理。

表 10.4. 可能的操作

poweroff

虚拟机(VM)立即关闭。如果 spec.running 设为 true,或者 spec.runStrategy 没有设置为 manual,则 VM 会重启。

reset

虚拟机将进行重启,客户机操作系统无法响应。由于客户机操作系统重启所需一定的时间完成,可能会导致存活度探测超时,因此不建议使用这个选项。如果集群级别的保护发现存活度探测失败并强制重新调度存活度探测,则此超时可以延长虚拟机重启所需的时间。

shutdown

虚拟机通过停止所有服务来正常关闭电源。

步骤

  1. 创建包含以下内容的 YAML 文件:

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
      labels:
        kubevirt.io/vm: vm2-rhel84-watchdog
      name: <vm-name>
    spec:
      running: false
      template:
        metadata:
         labels:
            kubevirt.io/vm: vm2-rhel84-watchdog
        spec:
          domain:
            devices:
              watchdog:
                name: <watchdog>
                i6300esb:
                  action: "poweroff" 1
    ...
    1
    指定 watchdog 操作(poweroffresetshutdown)。

    上面的示例使用 poweroff 操作配置 RHEL8 虚拟机上的 i6300esb watchdog 设备,并将设备公开为 /dev/watchdog

    现在,watchdog 二进制文件可以使用这个设备。

  2. 运行以下命令,将 YAML 文件应用到集群:

    $ oc apply -f <file_name>.yaml
重要

此流程仅用于测试 watchdog 功能,且不得在生产环境中运行。

  1. 运行以下命令来验证虚拟机是否已连接到 watchdog 设备:

    $ lspci | grep watchdog -i
  2. 运行以下命令之一以确认 watchdog 处于活跃状态:

    • 触发内核 panic:

      # echo c > /proc/sysrq-trigger
    • 终止 watchdog 服务:

      # pkill -9 watchdog

10.18.12.3. 安装 watchdog 设备

在虚拟机上安装 watchdog 软件包,再启动 watchdog 服务。

步骤

  1. 作为 root 用户,安装 watchdog 软件包和依赖项:

    # yum install watchdog
  2. /etc/watchdog.conf 文件中取消注释以下行,并保存更改:

    #watchdog-device = /dev/watchdog
  3. 在引导时启用 watchdog 服务:

    # systemctl enable --now watchdog.service

10.18.12.4. 其他资源

10.18.13. 自动导入和更新预定义的引导源

您可以使用 系统定义的 引导源(包括在 OpenShift Virtualization 中),或使用您自己创建的用户定义的引导源。系统定义的引导源导入和更新由产品功能门控制。您可以使用功能门启用、禁用或重新启用更新。用户定义的引导源不受产品功能门控制,需要单独管理自动导入和更新。

重要

自版本 4.10 起,OpenShift Virtualization 会自动导入和更新引导源,除非您手动选择或不设置默认存储类。

如果升级到 4.10,则必须手动为来自 4.9 或更早版本的引导源启用自动导入和更新。

10.18.13.1. 启用自动引导源更新

如果您有 OpenShift Virtualization 4.9 或更早版本的引导源,您必须手动为这些引导源打开自动更新。OpenShift Virtualization 4.10 及更新的版本中的所有引导源都会被默认自动更新。

要启用自动引导源导入和更新,请为您要自动更新的每个引导源将 cdi.kubevirt.io/dataImportCron 字段设置为 true

步骤

  • 要为引导源打开自动更新,请使用以下命令将 dataImportCron 标签应用到数据源:

    $ oc label --overwrite DataSource rhel8 -n openshift-virtualization-os-images cdi.kubevirt.io/dataImportCron=true 1
    1
    指定 true 可打开 rhel8 引导源的自动更新。

10.18.13.2. 禁用自动引导源更新

禁用自动引导源导入和更新有助于减少断开连接的环境中的日志数量或减少资源使用量。

要禁用自动引导源导入和更新,请将 HyperConverged 自定义资源 (CR) 中的 spec.featureGates.enableCommonBootImageImport 字段设置为 false

注意

用户定义的引导源不受此设置的影响。

步骤

  • 使用以下命令禁用自动引导源更新:

    $ oc patch hco kubevirt-hyperconverged -n openshift-cnv \
     --type json -p '[{"op": "replace", "path": "/spec/featureGates/enableCommonBootImageImport", \
     "value": false}]'

10.18.13.3. 重新启用自动引导源更新

如果您之前禁用了自动引导源更新,您必须手动重新启用该功能。将 HyperConverged 自定义资源(CR)中的 spec.featureGates.enableCommonBootImageImport 字段设置为 true

步骤

  • 使用以下命令重新启用自动更新:

    $ oc patch hco kubevirt-hyperconverged -n openshift-cnv --type json -p '[{"op": "replace", "path": "/spec/featureGates/enableCommonBootImageImport", "value": true}]'

10.18.13.4. 为用户定义的项目更新配置存储类

您可以配置存储类,允许自动导入和更新用户定义的引导源。

步骤

  1. 通过编辑 HyperConverged 自定义资源(CR) 来定义新的 storageClassName

    apiVersion: hco.kubevirt.io/v1beta1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
    spec:
      dataImportCronTemplates:
      - metadata:
          name: rhel8-image-cron
        spec:
          template:
            spec:
              storageClassName: <appropriate_class_name>
    ...
  2. 运行以下命令设置新的默认存储类:

    $ oc patch storageclass <current_default_storage_class> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
    $ oc patch storageclass <appropriate_storage_class> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

10.18.13.5. 为用户定义的引导源启用自动更新

OpenShift Virtualization 默认自动更新系统定义的引导源,但不会自动更新用户定义的引导源。您必须通过编辑 HyperConverged 自定义资源 (CR) 在用户定义的引导源上手动启用自动导入和更新。

步骤

  1. 使用以下命令打开 HyperConverged CR 进行编辑:

    $ oc edit -n openshift-cnv HyperConverged
  2. 编辑 HyperConverged CR,在 dataImportCronTemplates 部分添加适当的模板和引导源。例如:

    CentOS 7 中的示例

    apiVersion: hco.kubevirt.io/v1beta1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
    spec:
      dataImportCronTemplates:
      - metadata:
          name: centos7-image-cron
          annotations:
            cdi.kubevirt.io/storage.bind.immediate.requested: "true" 1
        spec:
          schedule: "0 */12 * * *" 2
          template:
            spec:
              source:
                registry: 3
                  url: docker://quay.io/containerdisks/centos:7-2009
              storage:
                resources:
                  requests:
                    storage: 10Gi
          managedDataSource: centos7 4
          retentionPolicy: "None" 5

    1
    对于将 volumeBindingMode 设置为 WaitForFirstConsumer 的存储类来说,这个注解是必需的。
    2
    以 cron 格式指定的作业调度计划。
    3
    用于从 registry 源创建数据卷。使用默认 pod pullMethod 而不是 节点 pullMethod,这基于 节点 docker 缓存。当 registry 镜像通过 Container.Image 可用时,节点 docker 缓存很有用,但 CDI 导入程序没有授权访问它。
    4
    要使自定义镜像被检测到为可用的引导源,镜像的 managedDataSource 的名称必须与模板的 DataSource 的名称匹配,它在 VM 模板 YAML 文件中的 spec.dataVolumeTemplates.spec.sourceRef.name 下找到。
    5
    在删除 cron 作业时,使用 All 来保留数据卷和数据源。删除 cron 作业时,使用 None 删除数据卷和数据源。

10.18.13.6. 为系统定义或用户定义的引导源禁用自动更新

您可以为用户定义的引导源和系统定义的引导源禁用自动导入和更新。

因为用户定义的引导源在 HyperConverged 自定义资源 (CR) 的 spec.dataImportCronTemplates 中不会被列出,所以您必须添加引导源并禁用自动导入和更新。

步骤

  • 要禁用用户定义的引导源的自动导入和更新,请从自定义资源列表中的 spec.dataImportCronTemplates 字段删除引导源。
  • 要禁用系统定义的引导源的自动导入和更新:

    • 编辑 HyperConverged CR,并将引导源添加到 spec.dataImportCronTemplates 中。
    • 通过将 dataimportcrontemplate.kubevirt.io/enable 注解设置为 false 来禁用自动导入和更新。例如:

      apiVersion: hco.kubevirt.io/v1beta1
      kind: HyperConverged
      metadata:
        name: kubevirt-hyperconverged
      spec:
        dataImportCronTemplates:
        - metadata:
            annotations:
              dataimportcrontemplate.kubevirt.io/enable: false
            name: rhel8-image-cron
      ...

10.18.13.7. 验证引导源的状态

您可以验证引导源是否为系统定义或用户定义的。

HyperConverged CR 的 status.dataImportChronTemplates 字段中列出的每个引导源的 status 部分代表引导源的类型。例如,commonTemplate: true 代表系统定义的 (commonTemplate) 引导源,status: {} 代表用户定义的引导源。

步骤

  1. 使用 oc get 命令列出 HyperConverged CR 中的 dataImportChronTemplates
  2. 验证引导源的状态。

    输出示例

    ...
    apiVersion: hco.kubevirt.io/v1beta1
    kind: HyperConverged
    ...
    spec:
      ...
    status: 1
      ...
      dataImportCronTemplates: 2
      - metadata:
          annotations:
            cdi.kubevirt.io/storage.bind.immediate.requested: "true"
          name: centos-7-image-cron
        spec:
          garbageCollect: Outdated
          managedDataSource: centos7
          schedule: 55 8/12 * * *
          template:
            metadata: {}
            spec:
              source:
                registry:
                  url: docker://quay.io/containerdisks/centos:7-2009
              storage:
                resources:
                  requests:
                    storage: 30Gi
            status: {}
        status:
          commonTemplate: true 3
        ...
      - metadata:
          annotations:
            cdi.kubevirt.io/storage.bind.immediate.requested: "true"
          name: user-defined-dic
        spec:
          garbageCollect: Outdated
          managedDataSource: user-defined-centos-stream8
          schedule: 55 8/12 * * *
          template:
            metadata: {}
            spec:
              source:
                registry:
                  pullMethod: node
                  url: docker://quay.io/containerdisks/centos-stream:8
              storage:
                resources:
                  requests:
                    storage: 30Gi
            status: {}
        status: {} 4
    ...

    1
    HyperConverged CR 的 status 字段。
    2
    dataImportCronTemplates 字段,它列出所有定义的引导源。
    3
    表示系统定义的引导源。
    4
    表示用户定义的引导源。

10.18.14. 在虚拟机上启用 descheduler 驱除

您可以使用 descheduler 来驱除 pod,以便可将 pod 重新调度到更合适的节点上。如果 pod 是虚拟机,pod 驱除会导致虚拟机实时迁移到另一节点。

重要

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

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

10.18.14.1. Descheduler 配置集

使用技术预览 DevPreviewLifecycle 配置集为虚拟机启用 descheduler。这是当前可用于 OpenShift Virtualization 的 descheduler 配置集。为确保正确调度,请创建带有 CPU 和内存请求的虚拟机用于预期的负载。

DevPreviewLongLifecycle

此配置集在节点间平衡资源使用量并启用以下策略:

  • RemovePodsHavingTooManyRestarts :删除其容器重启次数太多的 pod,以及其中所有容器(包括 Init 容器)重启的总数超过 100 的 pod。重启虚拟机客户端操作系统不会增加这个计数。
  • LowNodeUtilization :在存在没有被充分利用的节点时,将 pod 从过度使用的节点上驱除。被驱除的 pod 的目标节点将由调度程序决定。

    • 如果节点的用量低于 20%(CPU、内存和 pod 的数量),则该节点将被视为使用率不足。
    • 如果节点的用量超过 50%(CPU、内存和 pod 的数量),则该节点将被视为过量使用。

10.18.14.2. 安装 descheduler

在默认情况下,不提供 descheduler。要启用 descheduler,您必须从 OperatorHub 安装 Kube Descheduler Operator,并启用一个或多个 descheduler 配置集。

默认情况下,descheduler 以预测模式运行,这意味着它只模拟 pod 驱除。您必须将 descheduler 的模式更改为自动进行 pod 驱除。

重要

如果您在集群中启用了托管的 control plane,设置自定义优先级阈值,以降低托管 control plane 命名空间中的 pod 被驱除。将优先级阈值类名称设置为 hypershift-control-plane,因为它有托管的 control plane 优先级类的最低优先级值(100000000)。

先决条件

  • 必须具有集群管理员权限。
  • 访问 OpenShift Container Platform Web 控制台。

流程

  1. 登陆到 OpenShift Container Platform Web 控制台。
  2. 为 Kube Descheduler Operator 创建所需的命名空间。

    1. 进行 AdministrationNamespaces,点 Create Namespace
    2. Name 字段中输入 openshift-kube-descheduler-operator,在 Labels 字段中输入 openshift.io/cluster-monitoring=true 来启用 descheduler 指标,然后点击 Create
  3. 安装 Kube Descheduler Operator。

    1. 进入 OperatorsOperatorHub
    2. 在过滤框中输入 Kube Descheduler Operator
    3. 选择 Kube Descheduler Operator 并点 Install
    4. Install Operator 页面中,选择 A specific namespace on the cluster。从下拉菜单中选择 openshift-kube-descheduler-operator
    5. Update ChannelApproval Strategy 的值调整为所需的值。
    6. 点击 Install
  4. 创建 descheduler 实例。

    1. OperatorsInstalled Operators 页面中,点 Kube Descheduler Operator
    2. 选择 Kube Descheduler 标签页并点 Create KubeDescheduler
    3. 根据需要编辑设置。

      1. 要驱除 pod 而不是模拟驱除,请将 Mode 字段更改为 Automatic
      2. 展开 Profiles 部分,再选择 DevPreviewLongLifecycleAffinityAndTaints 配置集默认为启用。

        重要

        当前仅适用于 OpenShift Virtualization 的配置集是 DevPreviewLongLifecycle

您还可以稍后使用 OpenShift CLI(oc)为 descheduler 配置配置集和设置。

10.18.14.3. 在虚拟机(VM)上启用 descheduler 驱除

安装 descheduler 后,您可以通过在 VirtualMachine 自定义资源(CR)中添加注解来在虚拟机上启用 descheduler 驱除。

先决条件

  • 在 OpenShift Container Platform Web 控制台或 OpenShift CLI(oc)中安装 descheduler。
  • 确保虚拟机没有运行。

流程

  1. 在启动虚拟机前,将 descheduler.alpha.kubernetes.io/evict 注解添加到 VirtualMachine CR:

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    spec:
      template:
        metadata:
          annotations:
            descheduler.alpha.kubernetes.io/evict: "true"
  2. 如果您还没有在安装过程中在 web 控制台中设置 DevPreviewLongLifecycle 配置集,请在 KubeDescheduler 对象的 spec.profile 部分指定 DevPreviewLongLifecycle

    apiVersion: operator.openshift.io/v1
    kind: KubeDescheduler
    metadata:
      name: cluster
      namespace: openshift-kube-descheduler-operator
    spec:
      deschedulingIntervalSeconds: 3600
      profiles:
      - DevPreviewLongLifecycle
      mode: Predictive 1
    1
    默认情况下,descheduler 不会驱除 pod。要驱除 pod,请将 mode 设置为 Automatic

现在在虚拟机上启用了 descheduler。

10.18.14.4. 其他资源