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
$ lscpu
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
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
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 离线 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"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行时安装的进度显示在
kataConfig
自定义资源 (CR) 的status
部分中。但是,如果所有以下条件都满足,则不会显示进度:-
没有定义 worker 节点。您可以运行
oc get machineconfigpool
来检查机器配置池中的 worker 节点数量。 -
没有指定
kataConfigPoolSelector
来选择要安装的节点。
在这种情况下,安装会在 control plane 节点上启动,因为 Operator 假设节点具有 control plane 和 worker 角色。
kataConfig
CR 的status
部分在安装过程中不会更新。(KATA-1017)-
没有定义 worker 节点。您可以运行
-
在 web 控制台中的 KataConfig 选项卡中,如果您在 YAML 视图中 点 Create KataConfig,则
KataConfig
YAML 缺少spec
字段。切换到 Form 视图,然后返回到 YAML 视图 来解决这个问题,并显示完整的 YAML。(KATA-1372) -
在 web 控制台的 KataConfig 选项卡中,如果一个
KataConfig
CR 已存在,会出现一个404: Not found
错误消息。要访问现有的KataConfig
CR,请转至 Home > Search。在 Resources 列表中,选择 KataConfig。(KATA-1605) -
在安装
KataConfig
CR 时,如果在第一次节点重启前启动KataConfig
CR 删除,节点状态将不正确。当发生这种情况时,Operator 会处于一个状态,Operator 会尝试同时删除并安装KataConfig
CR。预期的行为是安装停止并删除KataConfig
CR。(KATA-1851) 当您在容器的安全上下文中设置 SELinux Multi-Category Security (MCS)标签时,pod 不会启动并抛出以下错误:
Error: CreateContainer failed: EACCES: Permission denied: unknown
Error: CreateContainer failed: EACCES: Permission denied: unknown
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在创建沙盒容器时,运行时无法访问容器的安全上下文。这意味着
virtiofsd
没有使用适当的 SELinux 标签运行,且无法访问容器的主机文件。因此,您无法依赖 MCS 标签来基于每个容器隔离沙盒容器中的文件。这意味着所有容器都可以访问沙盒容器中的所有文件。目前,这个问题还没有临时解决方案。在停止沙盒容器工作负载时,以下 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
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
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 这些错误无害,可以被忽略。
有关如何访问系统日志日志的更多信息,请参阅为红帽支持收集 OpenShift 沙盒容器数据。
当使用 Web 控制台安装 OpenShift 沙盒容器 Operator 时,UI 可能会在点 Install 后显示不正确的 Operator 版本。
安装窗口中不正确的版本会出现在灰色文本中,如下所示:
由红帽提供的 <version number>。
已安装正确的 Operator。您可以进入到 Operators
Installed Operators,以查看 OpenShift 沙盒容器 Operator 下列出的正确版本。 将对等 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
不会出现。目前,这个问题还没有临时解决方案。-
OpenShift 沙盒容器的 FIPS 合规性只适用于
kata
运行时类。新的对等 pod 运行时类kata-remote-cc
尚未被完全支持,且尚未针对 FIPS 合规性进行测试。(KATA-2166)