2.4. 已知问题

在访问 OpenShift Container Platform 集群中从 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

$ 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 列表可能会不可预测地从 run 改为 run。

作为临时解决方案，您可以使用 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)

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

Error: CreateContainer failed: EACCES: Permission denied: unknown

Error: CreateContainer failed: EACCES: Permission denied: unknown

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

(KATA-1875)

临时内存卷的 sizeLimit 选项不适用于 OpenShift 沙盒容器。临时卷大小默认为分配给沙盒容器的内存的 50%。可以通过重新挂载卷来手动更改此卷的大小。例如，如果分配给沙盒容器的内存为 6 GB，并且临时卷挂载到 /var/lib/containers，您可以使用以下命令将这个卷的大小增加到默认 50%：

mount -o remount,size=4G /var/lib/containers

$ mount -o remount,size=4G /var/lib/containers

(KATA-2579)

io.katacontainers.config.hypervisor.default_vcpus 和 io.katacontainers.config.hypervisor.default_memory 注解遵循 QEMU 的语义，对对等 pod 有以下限制：

相反，建议您将 io.katacontainers.config.hypervisor.machine_type: <instance type/instance size> 注解用于灵活的 pod 虚拟机大小。(KATA-2575, KATA-2577, KATA-2578)

在从 OpenShift 沙盒容器 Operator 1.4.1 自动升级到 1.5 的过程中，升级会 处于待处理状态。

如果您的订阅被设置为自动更新，则安装 OpenShift 沙盒容器的升级。但是，如果安装了 KataConfig CR （自定义资源），则 CSV 会处于 pending 状态。

您可以运行以下命令来检查 Subscription 对象的状态：

oc get sub osc-operator -n openshift-osc-operator -o yaml

$ oc get sub osc-operator -n openshift-osc-operator -o yaml

以下错误会出现在 Subscription 对象的 status 部分，以及 upgrade InstallPlan 对象的 status 部分：

message: 'error validating existing CRs against new CRD''s schema for "kataconfigs.kataconfiguration.openshift.io":
      error validating custom resource against new schema for KataConfig /example-kataconfig:
      [].status.runtimeClass: Invalid value: "string": status.runtimeClass in body
      must be of type array: "string"'

message: 'error validating existing CRs against new CRD''s schema for "kataconfigs.kataconfiguration.openshift.io":
      error validating custom resource against new schema for KataConfig /example-kataconfig:
      [].status.runtimeClass: Invalid value: "string": status.runtimeClass in body
      must be of type array: "string"'

如果收到这个错误，则必须卸载，然后重新安装 OpenShift 沙盒容器 Operator：

(KATA-2593)