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

第 2 章 容器原生虚拟化发行注记

2.1. 容器原生虚拟化发行注记

2.1.1. 关于容器原生虚拟化 2.3

2.1.1.1. 容器原生虚拟化的作用

容器原生虚拟化（container-native virtualization）是 OpenShift Container Platform 的一个附加组件，可用于运行和管理虚拟机工作负载以及容器工作负载。

容器原生虚拟化通过 Kubernetes 自定义资源添加新对象至 OpenShift Container Platform 集群中，以启用虚拟化任务。这些任务包括：

  • 创建和管理 Linux 和 Windows 虚拟机
  • 通过各种控制台和 CLI 工具连接至虚拟机
  • 导入和克隆现有虚拟机
  • 管理虚拟机上附加的网络接口控制器和存储磁盘
  • 在节点间实时迁移虚拟机

增强版 web 控制台提供了一个图形化的门户界面 来管理虚拟化资源以及 OpenShift Container Platform 集群容器和基础架构。

您可以将容器原生虚拟化用于 OVN-Kubernetes 或 OpenShiftSDN 网络供应商。

2.1.1.2. 容器原生虚拟化支持

重要

容器原生虚拟化仅是一项技术预览功能。技术预览功能不被红帽产品服务等级协议 (SLA) 支持，且可能在功能方面有缺陷。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的详情，请参阅 https://access.redhat.com/support/offerings/techpreview/。

2.1.2. 新增和改变的功能

  • Microsoft 的 Windows 服务器虚拟化验证程序 (SVVP) 中认证的容器原生虚拟化可运行 Windows 服务器工作负载。

    • SVVP 认证适用于 Intel 和 AMD CPU。
    • SVVP Certificate Red Hat Enterprise Linux CoreOS 8 worker 的名称为 Red Hat OpenShift Container Platform 4 on RHEL CoreOS 8。
  • 提供了与 Microsoft Windows 10 兼容的新模板。

2.1.2.1. 网络

  • 现在，您可以使用容器原生虚拟化用于 OVN-Kubernetes 或 OpenShiftSDN 网络供应商。

  • 容器原生虚拟化使用 nmstate 来报告并配置节点网络的状态。这样就可以通过将单个配置清单应用到集群来修改网络策略配置，例如在所有节点上创建或删除 Linux 网桥、绑定和 VLAN 设备。

    • 如需更多信息，请参阅 节点网络中的内容。

2.1.2.2. 存储

  • 现在，您可以将虚拟机磁盘导入、上传并克隆到命名空间中，这可能受 CPU 和内存资源限制。
  • virtctl 工具现在可以异步监控服务器端上传后处理，并更准确地报告虚拟机磁盘上传的状态。

2.1.2.3. Web 控制台

  • 现在，您可以在 web 控制台中查看状态为 Paused 的虚拟机。Web 控制台在 Virtual Machines 仪表板和 Virtual Machine Details 页面中显示这个状态。
注意

您还可以使用 oc CLI 查看状态为 Pause 的虚拟机 : 

$ oc get vmi testvm -o=jsonpath='{.status.conditions[?(@.type=="Paused")].message}'
  • 如果虚拟机的状态为 Paused，您现在可 从 web 控制台取消暂停它。
  • 您可以查看和管理独立于虚拟机列表中的虚拟机的虚拟机实例。
  • 容器原生虚拟化允许您在虚拟机向导中配置光盘。您可以从下拉列表中选择 CD-ROM 配置类型： Container、URL 或 Attach Disk。您可以在 Virtual Machine Details 页中编辑 CD-ROM 配置。
  • 引导顺序列表现在包括在 Virtual Machine Details 中。您可以添加项目，删除项目，并修改引导顺序列表。
  • 虚拟机和虚拟机模板向导现在为不同的操作系统验证 CPU 和内存大小，以及磁盘总线要求。如果您试图创建不满足特定操作系统要求的虚拟机或虚拟机模板，向导会发出资源警告。
  • 现在，您可以在 Virtual Machine Details 页中查看并配置虚拟机专用资源。当您启用专用资源时，请确保您的虚拟机工作负载在没有被其他进程使用的 CPU 上运行。这可以提高虚拟机的性能以及延迟预测的准确性。

2.1.3. 主要的技术变化

  • 您需要在一个名为 openshift-cnv 的单一命名空间中服务容器原生虚拟化。如果不存在，现在会在部署过程中自动创建 openshift-cnv 命名空间。
  • 为防止错误，您无法重命名在容器原生虚拟化部署过程中创建的 CNV Operator Deployment 自定义资源。如果您尝试创建名称不是 kubevirt-hyperconverged（默认名称） 的自定义资源，则创建将失败，并在 web 控制台中显示错误消息。

  • 为了防止无意中的数据丢失，如果集群定义了虚拟机或 DataVolume，则无法再卸载容器原生虚拟化。

    • 您必须手动删除所有 虚拟机 (VM)、虚拟机实例 (VMI) 和 DataVolume (DV)，然后才能卸载容器原生虚拟化。

    • 当尝试卸载容器原生虚拟化时，如果存在 VM、VMI 或 DV 对象，则卸载过程不会完成，直到删除了所有剩余对象。

      注意

      要确认因为待处理对象而导致卸载暂停，请查看 Events 选项卡。

2.1.4. 已知问题

  • KubeMacPool 在 container-native virtualization 2.3 中被禁用。这意味着，Pod 或虚拟机的辅助接口获得随机生成的 MAC 地址，而不是池中的唯一 MAC 地址。虽然这种情况会非常少，但随机分配的 MAC 地址可能会存在冲突。(BZ#1816971)

  • 有时，在 web 控制台中编辑 Container-native virtualization Operator 的订阅频道时，点击 Subscription Overview 的 Channel 按钮会导致 JavaScript 错误。(BZ#1796410)

    • 作为临时解决方案，通过运行以下 oc patch 命令，从 CLI 触发容器原生虚拟化 2.3 的升级过程： 

      $ export TARGET_NAMESPACE=openshift-cnv CNV_CHANNEL=2.3 && oc patch -n "${TARGET_NAMESPACE}" $(oc get subscription -n ${TARGET_NAMESPACE} --no-headers -o name) --type='json' -p='[{"op": "replace", "path": "/spec/channel", "value":"'${CNV_CHANNEL}'"}, {"op": "replace", "path": "/spec/installPlanApproval", "value":"Automatic"}]'

      这个命令将您的订阅指向升级频道 2.3 并启用自动更新。

  • 在虚拟机和虚拟机模板向导中，virtIO 是附加一个 CD-ROM 时的默认接口。但是，virtIO CD-ROM 无法通过虚拟机的验证过程，因此不能被创建。(BZ#1817394)

    • 作为临时解决方案，在创建虚拟机和虚拟机模板时，选择 SATA 作为 CD-ROM 接口。

  • Containerized Data Importer (CDI) 不总是使用 CDIConfig 对象中的 scratchSpaceStorageClass 设置来导入和上传操作。相反，CDI 使用默认存储类来分配暂存空间。(BZ#1828198)

    • 这个问题的一个解决方案是，确保您为集群定义了一个默认存储类。以下命令可用于应用所需的注解： 

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

  • 如果在部署早期版本的容器原生虚拟化时重命名了 Operator 部署自定义资源，则无法直接升级到容器原生虚拟化 2.3。自定义资源必须命名为 kubevirt-hyperconverged，这是默认名称。(BZ#1822266)

    • 作为临时解决方案，您可以：

      • 将现有自定义资源重命名为 kubevirt-hyperconverged。
      • 创建一个新的、名为 kubevirt-hyperconverged（默认名称）的自定义资源。然后，删除名称不是 kubevirt-hyperconverged 的 的自定义资源。
  • 当您向虚拟机中添加 NIC 时，OpenShift Container Platform 4.4 web 控制台包含了 slirp 作为选项，但 slirp 不是有效的 NIC 类型。在向虚拟机中添加 NIC 时，不要选择 slirp 。(BZ#1828744)

  • 迁移后，会为虚拟机分配一个新的 IP 地址。但是，oc get vmi 和 oc describe vmi 命令仍会生成包含过时 IP 地址的输出。(BZ#1686208)

    • 作为临时解决方案，请运行以下命令来查看正确的 IP 地址： 

      $ oc get pod -o wide

  • 没有管理员权限的用户，无法使用虚拟机向导在 L2 网络中的项目中添加网络接口。此问题是由于缺少允许用户加载网络附加定义的权限造成的。(BZ#1743985)

    • 作为临时解决方案，请为用户提供加载网络附加定义的权限。

      1. 使用以下示例将 ClusterRole 和 ClusterRoleBinding 对象定义到 YAML 配置文件： 

        apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 name: cni-resources
rules:
- apiGroups: ["k8s.cni.cncf.io"]
 resources: ["*"]
 verbs: ["*"]
        apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: <role-binding-name>
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cni-resources
subjects:
- kind: User
  name: <user to grant the role to>
  namespace: <namespace of the user>

      2. 作为 cluster-admin 用户，运行以下命令来创建您定义的 ClusterRole 和 ClusterRoleBinding 对象： 

        $ oc create -f <filename>.yaml

  • 当节点具有不同的 CPU 型号时，实时迁移会失败。即使节点具有相同的物理 CPU 型号，微代码更新引入的差异也会产生同样的问题。这是因为默认设置触发了主机 CPU 透传行为，这与实时迁移不兼容。(BZ#1760028)

    • 作为临时解决方案，请在 kubevirt-config ConfigMap 中设置默认 CPU 型号，如下例所示：

      注意

      您必须在启动支持实时迁移的虚拟机前进行此更改。

      1. 运行以下命令，打开 kubevirt-config ConfigMap 以进行编辑： 

        $ oc edit configmap kubevirt-config -n openshift-cnv

      2. 编辑 ConfigMap： 

        kind: ConfigMap
metadata:
  name: kubevirt-config
data:
  default-cpu-model: "<cpu-model>" 1
        1
        将 <cpu-model> 替换为实际 CPU 型号值。要确定此值，您可以为所有节点运行 oc describe node <node> 并查看 cpu-model-<name> 标签。选择所有节点上出现的 CPU 型号。

  • 当尝试使用 Haswell CPU 创建和启动虚拟机时，因为标记为错误的节点，虚拟机的启动可能会失败。这是对容器原生虚拟化之前版本的更改。在以前的版本中，虚拟机可以在 Haswell 主机上成功启动。(BZ#1781497)

    作为临时解决方案，在可能的情况下选择不同的 CPU 模型。

  • 由于 Operator Lifecycle Manager (OLM) 的中断，容器原生虚拟化升级过程偶尔会失败。造成此问题的原因是使用声明性 API 来跟踪容器原生虚拟化 Operator 状态具有局限性。在安装过程中启用自动更新降低了遇到此问题的风险。(BZ#1759612)
  • 容器原生虚拟化无法可靠识别由运行 oc adm drain 或 kubectl drain 触发的节点排空。不要在部署容器原生虚拟化的任何集群节点上运行这些命令。节点上如有虚拟机正在运行，则不会排空。当前解决方案为将节点设置为维护模式。(BZ#1707427)

  • 如果您导航到 Operators Installed Operators 页面上的 Subscription 选项卡，并点击当前升级频道编辑它，则可能没有可见的结果。如果是这种情况，并不代表有不可见的错误。(BZ#1796410)

    • 作为临时解决方案，通过运行以下 oc patch 命令，从 CLI 触发容器原生虚拟化 2.3 的升级过程： 

      $ export TARGET_NAMESPACE=openshift-cnv CNV_CHANNEL=2.3 && oc patch -n "${TARGET_NAMESPACE}" $(oc get subscription -n ${TARGET_NAMESPACE} --no-headers -o name) --type='json' -p='[{"op": "replace", "path": "/spec/channel", "value":"'${CNV_CHANNEL}'"}, {"op": "replace", "path": "/spec/installPlanApproval", "value":"Automatic"}]'

      这个命令将您的订阅指向升级频道 2.3 并启用自动更新。

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.