1.4. 已知问题

如果使用 OpenShift 沙盒容器，您可能会在访问 Red Hat OpenShift 集群中从 hostPath 卷挂载的文件或目录时收到 SELinux 拒绝。即使运行特权沙盒容器，这些拒绝也会发生，因为特权沙盒容器不会禁用 SELinux 检查。

在主机中遵循 SELinux 策略可保证主机文件系统默认与沙盒工作负载完全隔离。这还对 virtiofsd 守护进程或 QEMU 中潜在的安全漏洞提供更强的保护。

如果挂载的文件或目录在主机上没有特定的 SELinux 要求，您可以使用本地持久性卷作为替代方案。文件会自动重新标记为 container_file_t，遵循 SELinux 容器运行时。请参阅使用本地卷的持久性存储

挂载文件或目录时，自动重新标记不是选项，则主机上应该具有特定的 SELinux 标签。相反，您可以在主机上设置自定义 SELinux 规则，以允许 virtiofsd 守护进程访问这些特定标签。(KATA-469)

一些 OpenShift 沙盒容器 Operator pod 使用容器 CPU 资源限制来增加 pod 的可用 CPU 数量。这些 pod 可能会收到比请求的 CPU 少。如果功能在容器内可用，您可以使用 oc rsh <pod> 访问 pod 并运行 lscpu 命令诊断 CPU 资源问题：

$ lscpu

CPU(s):                          16
On-line CPU(s) list:             0-12,14,15
Off-line CPU(s) list:            13

离线 CPU 列表可能会不可预测地从 run 改为 run。

作为临时解决方案，您可以使用 pod 注解来请求额外 CPU 而不是设置 CPU 限值。使用 pod 注解的 CPU 请求不受此问题的影响，因为处理器分配方法不同。以下注解必须添加到 pod 的元数据中，而不是设置 CPU 限制：

metadata:
  annotations:
    io.katacontainers.config.hypervisor.default_vcpus: "16"

(KATA-1376)

运行时安装的进度显示在 kataConfig 自定义资源 (CR) 的 status 部分中。但是，如果所有以下条件都满足，则不会显示进度：

在这种情况下，安装会在 control plane 节点上启动，因为 Operator 假设节点具有 control plane 和 worker 角色。kataConfig CR 的 status 部分在安装过程中不会更新。(KATA-1017)

当您在容器的安全上下文中设置 SELinux Multi-Category Security (MCS)标签时，pod 不会启动并抛出以下错误：

Error: CreateContainer failed: EACCES: Permission denied: unknown

在创建沙盒容器时，运行时无法访问容器的安全上下文。这意味着 virtiofsd 没有使用适当的 SELinux 标签运行，且无法访问容器的主机文件。因此，您无法依赖 MCS 标签来基于每个容器隔离沙盒容器中的文件。这意味着所有容器都可以访问沙盒容器中的所有文件。目前，这个问题还没有临时解决方案。

(KATA-1875)

在停止沙盒容器工作负载时，以下 QEMU 错误消息会记录到 worker 节点系统日志中：

qemu-kvm: Failed to write msg.
qemu-kvm: Failed to set msg fds.
qemu-kvm: vhost VQ 0 ring restore failed
qqemu-kvm: vhost_set_vring_call failed

这些错误无害，可以被忽略。

有关如何访问系统日志日志的更多信息，请参阅为红帽支持收集 OpenShift 沙盒容器数据。

(KATA-2133)

当使用 Web 控制台安装 OpenShift 沙盒容器 Operator 时，UI 可能会在点 Install 后显示不正确的 Operator 版本。

安装窗口中不正确的版本会出现在灰色文本中，如下所示：

由红帽提供的 <version number>。

已安装正确的 Operator。您可以进入到 Operators Installed Operators，以查看 OpenShift 沙盒容器 Operator 下列出的正确版本。

(KATA-2161)

将对等 pod 与 OpenShift 沙盒容器搭配使用时，在创建 KataConfig CR 时会创建 kata-remote-cc 运行时类，并将 enablePeerPods 字段设置为 true。因此，用户除了 kata 运行时类外，用户还应看到 KataConfig CR 中的 kata-remote-cc 运行时类，用户还应能够在同一集群中同时运行标准 Kata pod 和 peer-pod Kata pod。

作为集群管理员，当检查 KataConfig CR 时，您仅在 Status.runtimeClass 字段中找到 kata。运行时类 kata-remote-cc 不会出现。目前，这个问题还没有临时解决方案。

(KATA-2164)