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
    Copy to Clipboard Toggle word wrap

    输出示例

    CPU(s):                          16
    On-line CPU(s) list:             0-12,14,15
    Off-line CPU(s) list:            13
    Copy to Clipboard Toggle word wrap

    离线 CPU 列表可能会不可预测地从 run 改为 run。

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

    metadata:
      annotations:
        io.katacontainers.config.hypervisor.default_vcpus: "16"
    Copy to Clipboard Toggle word wrap

    (KATA-1376)

  • 运行时安装的进度显示在 kataConfig 自定义资源 (CR) 的 status 部分中。但是,如果所有以下条件都满足,则不会显示进度:

    • 没有定义 worker 节点。您可以运行 oc get machineconfigpool 来检查机器配置池中的 worker 节点数量。
    • 没有指定 kataConfigPoolSelector 来选择要安装的节点。

    在这种情况下,安装会在 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
    Copy to Clipboard Toggle word wrap

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

    (KATA-1278)

  • 在 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)
  • 升级 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"}}'
    Copy to Clipboard Toggle word wrap

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

    (KATA-1650)

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat