在以前的版本中，升级 OpenShift 沙盒容器不会自动更新现有的 KataConfig CR。因此，监控来自以前部署的 pod 不会被重启，并继续使用过时的 kataMonitor 镜像运行。

从版本 1.3.2 开始，kataMonitorImage 已从 KataConfig CR 中删除，所有监控 pod 的升级都由 Operator 内部处理。

(KATA-1650)

在以前的版本中，用户无法在断开连接的集群中安装 OpenShift 沙盒容器。kata-monitor 容器镜像的拉取规格使用标签而不是摘要。这导致镜像无法使用 ImageContentSourcePolicy 资源进行镜像。

在这个版本中，CSV spec.relatedImages 部分已被更新，以确保包含 OpenShift 沙盒容器 Operator 中的所有容器镜像。因此，所有容器 pull 规格现在都使用摘要而不是标签，从而在断开连接的环境中启用 OpenShift 沙盒容器安装。

(KATA-2038)

如果使用 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)

当在 OpenShift 沙盒容器中使用 Buildah 工具的旧版本时，构建会失败并显示以下错误：

process exited with error: fork/exec /bin/sh: no such file or directory

subprocess exited with status 1

您必须使用最新版本的 Buildah，位于 quay.io。

(KATA-1278)