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

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

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

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

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

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

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

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

2.1.1.2. 容器原生虚拟化支持

重要

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

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

2.1.2. 新增和改变的功能

  • 通过对设计和工作流的改进,管理虚拟机变得更为简单且效率更高。您现在可以:

    • 运行虚拟机向导时减少了页面导航操作。向导现在使用一个完整的页面风格,并在提交前包括一个用于确认配置详情的复查页面。
    • 在导入单个 VMware 虚拟机时减少了页面导航操作。
    • 编辑虚拟机模板以及虚拟机配置。
    • 监控由虚拟机支持的服务的健康状况,就如同监控基于 Pod 的服务一样。
    • 为虚拟机镜像启用持久性本地存储。
    • 添加、编辑和查看附加到虚拟机的虚拟 CD-ROM 设备。
    • 使用图形编辑器添加并查看网络附加定义。

2.1.3. 已解决的问题

  • 以前,当通过 web 控制台中的 Disks 选项卡向虚拟机添加磁盘时,添加的磁盘的 volumeMode 总是 Filesystem,而不论 kubevirt-storage-class-default ConfigMap 中的 volumeMode 设置是什么。这个问题已被解决。(BZ#1753688)
  • 以前,当导航到 Virtual Machines Console 选项卡时,有时不会显示任何内容。这个问题已被解决。(BZ#1753606)
  • 以前,当尝试从浏览器中列出容器原生虚拟化 Operator 的所有实例时,您会遇到 404 (page not found) 错误。这个问题已被解决。(BZ#1757526)
  • 以前,如果虚拟机使用有保证的 CPU,它不会被调度,因为在节点上没有自动设置 cpumanager=true 标签。这个问题已被解决。(BZ#1718944)

2.1.4. 已知问题

  • 如果部署了容器原生虚拟化 2.1.0,在升级 OpenShift Container Platform 前,需要首先将容器原生虚拟化升级到 2.2.0。如果在升级容器原生虚拟化前升级 OpenShift Container Platform,可能会触发虚拟机删除的行为。(BZ#1785661)
  • 虚拟机的 masquerade 绑定方法不能用于包含 RHEL 7 计算节点的集群。(BZ#1741626)
  • 迁移后,会为虚拟机分配一个新的 IP 地址。但是,oc get vmioc describe vmi 命令仍会生成包含过时 IP 地址的输出。(BZ#1686208)

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

      $ oc get pod -o wide
  • 移除容器原生虚拟化时,仍会不当保留某些资源。您必须手动删除这些资源以便重新安装容器原生虚拟化。(BZ#1712429)
  • 没有管理员权限的用户,无法使用虚拟机向导在 L2 网络中的项目中添加网络接口。此问题是由于缺少允许用户加载网络附加定义的权限造成的。(BZ#1743985)

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

      1. 使用以下示例将 ClusterRoleClusterRoleBinding 对象定义到 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 用户,运行以下命令来创建您定义的 ClusterRoleClusterRoleBinding 对象:

        $ 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 型号。
  • 当运行 virtctl image-uploadqcow2 格式上传大型虚拟机磁盘镜像时,在传输数据后可能会报告一个文件终止 (EOF) 错误,即使上传正常或完成。(BZ#1789093)

    运行以下命令,检查指定 PVC 中上传的状态:

    $ oc describe pvc <pvc-name> | grep cdi.kubevirt.io/storage.pod.phase
  • 当尝试使用 Haswell CPU 创建和启动虚拟机时,因为标记为错误的节点,虚拟机的启动可能会失败。这是对容器原生虚拟化之前版本的更改。在以前的版本中,虚拟机可以在 Haswell 主机上成功启动。(BZ#1781497)

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

  • 如果选择了与您的操作系统共享空间的目录,您将有可能耗尽分区中的空间,从而导致节点无法正常工作。反之,创建一个单独的分区,把 hostPath 置备程序指向那个分区,这样它就不会影响到操作系统。(BZ#1793132)
  • 由于 Operator Lifecycle Manager (OLM) 的中断,容器原生虚拟化升级过程偶尔会失败。造成此问题的原因是使用声明性 API 来跟踪容器原生虚拟化 Operator 状态具有局限性。在安装过程中启用自动更新降低了遇到此问题的风险。(BZ#1759612)
  • 容器原生虚拟化无法可靠识别由运行 oc adm drainkubectl drain 触发的节点排空。不要在部署容器原生虚拟化的任何集群节点上运行这些命令。节点上如有虚拟机正在运行,则不会排空。当前解决方案为将节点设置为维护模式。(BZ#1707427)
  • 如果您导航到 OperatorsInstalled Operators 页面上的 Subscription 选项卡,并点击当前升级频道编辑它,则可能没有可见的结果。如果是这种情况,并不代表有不可见的错误。(BZ#1796410)

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

      $ export TARGET_NAMESPACE=openshift-cnv CNV_CHANNEL=2.2 && 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.2 并启用自动更新。


为了尽快向用户提供最新的信息,本文档可能会包括由机器自动从英文原文翻译的内容。如需更多信息,请参阅此说明。