1.4. 已知问题

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

在默认情况下，主机上的 SELinux 策略会保证主机文件系统完全与沙盒工作负载隔离，并提供对 virtiofsd 守护进程或 QEMU 中潜在的安全漏洞的更强的保护。

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

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

您可能会遇到 Machine Config Operator (MCO) pod 变为 CrashLoopBackOff 状态的问题，pod 的 openshift.io/scc 注解会显示 sandboxed-containers-operator-scc 而不是默认的 hostmount-anyuid 值。

如果发生了这种情况，将 sandboxed-containers-operator-scc SCC 中的 seLinuxOptions 策略临时改为不太严格的 RunAsAny，以便准入进程会首选 hostmount-anyuid SCC 而不是它。

使用容器 CPU 资源限值的 OpenShift 沙盒容器 Operator pod 来增加 pod 可用的 CPU 数量可能比请求的 CPU 少。如果功能在容器中可用，您可以使用 oc rsh <pod> 并运行 lscpu 命令诊断 CPU 资源。

lscpu

$ lscpu

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

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

可用的离线 CPU 列表可能会更改为以无法预计的方式运行。

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

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

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

(KATA-1376)

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

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