搜索

6.13. 高级虚拟机管理

download PDF

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

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

6.13.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 清单。

6.13.1.2. 其他资源

6.13.2. 为虚拟机指定节点

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

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

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

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

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

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

nodeSelector
允许将虚拟机调度到使用此字段中指定的键值对标记的节点上。节点必须具有与所有列出的对完全匹配的标签。
关联性
这可让您使用更具表达力的语法来设置与虚拟机匹配的规则。例如,您可以指定规则是首选项,而非硬要求,因此在规则不满足时仍然可以调度虚拟机。虚拟机放置支持 Pod 关联性、pod 反关联性和节点关联性。Pod 关联性适用于虚拟机,因为 VirtualMachine 工作负载类型基于 Pod 对象。
容限(tolerations)

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

注意

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

6.13.2.2. 节点放置示例

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

6.13.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
# ...

6.13.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 规则类型,只要满足所有必要的限制,仍会调度虚拟机(如果未满足约束)。
6.13.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 规则类型,只要满足所有必要的限制,仍会调度虚拟机(如果未满足约束)。
6.13.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"
# ...

6.13.2.3. 其他资源

6.13.3. 配置证书轮转

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

6.13.3.1. 配置证书轮转

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

流程

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

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
  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 文件应用到集群。

6.13.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 值。

6.13.4. 配置默认 CPU 型号

使用 HyperConverged 自定义资源 (CR) 中的 defaultCPUModel 设置来定义集群范围的默认 CPU 模型。

虚拟机 (VM) CPU 模型取决于虚拟机和集群中的 CPU 模型的可用性。

  • 如果虚拟机没有定义的 CPU 模型:

    • defaultCPUModel 使用在集群范围级别上定义的 CPU 模型自动设置。
  • 如果虚拟机和集群都有定义的 CPU 模型:

    • 虚拟机的 CPU 模型具有优先权。
  • 如果虚拟机或集群都没有定义的 CPU 模型:

    • host-model 使用主机级别上定义的 CPU 模型自动设置。

6.13.4.1. 配置默认 CPU 型号

通过更新 HyperConverged 自定义资源(CR) 来配置 defaultCPUModel。您可以在 OpenShift Virtualization 运行时更改 defaultCPUModel

注意

defaultCPUModel 是区分大小写的。

先决条件

  • 安装 OpenShift CLI(oc)。

流程

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

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
  2. defaultCPUModel 字段添加到 CR,并将值设置为集群中存在的 CPU 模型的名称:

    apiVersion: hco.kubevirt.io/v1beta1
    kind: HyperConverged
    metadata:
     name: kubevirt-hyperconverged
     namespace: openshift-cnv
    spec:
      defaultCPUModel: "EPYC"
  3. 将 YAML 文件应用到集群。

6.13.5. 为虚拟机使用 UEFI 模式

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

6.13.5.1. 关于虚拟机的 UEFI 模式

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

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

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

6.13.5.3. 启用持久性 EFI

您可以通过在集群级别配置 RWX 存储类并调整虚拟机 EFI 部分中的设置来启用 EFI 持久性。

先决条件

  • 您必须具有集群管理员特权。
  • 您必须有一个支持 RWX 访问模式和 FS 卷模式的存储类。

流程

  • 运行以下命令启用 VMPersistentState 功能门:

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

6.13.5.4. 使用持久性 EFI 配置虚拟机

您可以通过编辑清单文件,将虚拟机配置为启用 EFI 持久性。

先决条件

  • VMPersistentState 功能门启用。

流程

  • 编辑虚拟机清单文件并保存以应用设置。

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
      name: vm
    spec:
      template:
        spec:
          domain:
            firmware:
              bootloader:
                efi:
                  persistent: true
    # ...

6.13.6. 为虚拟机配置 PXE 启动

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

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

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

先决条件

  • 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

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

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

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

    $ virtctl console vmi-pxe-boot

验证

  1. 验证虚拟机上的接口和 MAC 地址,并验证连接到网桥的接口是否具有指定的 MAC 地址。在本例中,我们使用了 eth1 进行 PXE 启动,无需 IP 地址。其他接口 eth0 从 OpenShift Dedicated 获取 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

6.13.6.2. 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)
nmstate 项目引入的 CRD,描述节点上请求的网络配置。您可以通过将 NodeNetworkConfigurationPolicy清单应用到集群来更新节点网络配置,包括添加和删除网络接口 。

6.13.7. 调度虚拟机

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

6.13.7.1. 策略属性

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

策略属性描述

force

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

require

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

optional

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

disable

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

forbid

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

6.13.7.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
    虚拟机的策略属性.

6.13.7.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 模型.

6.13.7.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 模型的虚拟机。

6.13.7.5. 使用自定义调度程序调度虚拟机

您可以使用自定义调度程序在节点上调度虚拟机 (VM)。

先决条件

  • 为集群配置二级调度程序。

流程

  • 通过编辑 VirtualMachine 清单,将自定义调度程序添加到虚拟机配置中。例如:

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
      name: vm-fedora
    spec:
      running: true
      template:
        spec:
          schedulerName: my-scheduler 1
          domain:
            devices:
              disks:
                - name: containerdisk
                  disk:
                    bus: virtio
    # ...
    1
    自定义调度程序的名称。如果 schedulerName 值与现有调度程序不匹配,virt-launcher pod 会一直处于 Pending 状态,直到找到指定的调度程序为止。

验证

  • 通过检查 virt-launcher pod 事件来验证虚拟机是否使用 VirtualMachine 清单中指定的自定义调度程序:

    1. 输入以下命令来查看集群中的 pod 列表:

      $ oc get pods

      输出示例

      NAME                             READY   STATUS    RESTARTS   AGE
      virt-launcher-vm-fedora-dpc87    2/2     Running   0          24m

    2. 运行以下命令以显示 pod 事件:

      $ oc describe pod virt-launcher-vm-fedora-dpc87

      输出中的 From 字段的值验证调度程序名称与 VirtualMachine 清单中指定的自定义调度程序匹配:

      输出示例

      [...]
      Events:
        Type    Reason     Age   From              Message
        ----    ------     ----  ----              -------
        Normal  Scheduled  21m   my-scheduler  Successfully assigned default/virt-launcher-vm-fedora-dpc87 to node01
      [...]

6.13.8. 关于虚拟机的高可用性

您可以通过配置补救节点来为虚拟机(VM)启用高可用性。

您可以通过从 OperatorHub 安装 Self Node Remediation Operator 或 Fence Agents Remediation Operator 来配置补救节点,并启用机器健康检查或节点补救检查。

有关补救、隔离和维护节点的更多信息,请参阅 Workload Availability for Red Hat OpenShift 文档。

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.