1.4. 已知问题

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

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

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

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

一些 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)

当在 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)

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

使用以下命令升级 kataMonitor 镜像：

$ oc patch kataconfig example-kataconfig --type merge --patch '{"spec":{"kataMonitorImage":"registry.redhat.io/openshift-sandboxed-containers/osc-monitor-rhel8:1.3.0"}}'

您还可以通过在 web 控制台中编辑 KataConfig YAML 来升级 kataMonitor 镜像。

(KATA-1650)