Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

第 3 章 部署 OpenShift 沙盒容器工作负载

您可以使用 Web 控制台或 OpenShift CLI（oc）安装 OpenShift 沙盒容器 Operator。安装 OpenShift 沙盒容器 Operator 之前，您必须准备 OpenShift Container Platform 集群。

3.1. 先决条件
复制链接

在安装 OpenShift 沙盒容器前，请确保 OpenShift Container Platform 集群满足以下要求：

  • 集群必须使用 Red Hat Enterprise Linux CoreOS (RHCOS) worker 在内部裸机基础架构上安装。您可以使用任何安装方法，包括用户置备、安装程序置备或协助的安装程序来部署集群。

    注意
    • OpenShift 沙盒容器仅支持 RHCOS worker 节点。不支持 RHEL 节点。
    • 不支持嵌套虚拟化。

  • 您可以在 Amazon Web Services (AWS) 裸机实例上安装 OpenShift 沙盒容器。不支持由其他云提供商提供的裸机实例。

    重要

    在 AWS 裸机实例上安装 OpenShift 沙盒容器只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

    有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

3.1.1. OpenShift 沙盒容器的资源要求
复制链接

OpenShift 沙盒容器允许用户在沙盒运行时 (Kata) 中的 OpenShift Container Platform 集群中运行工作负载。每个 pod 由一个虚拟机（VM）表示。每个虚拟机都在 QEMU 进程中运行，并托管一个 kata-agent 进程，它充当管理容器工作负载的监管程序，以及这些容器中运行的进程。两个额外的进程会增加开销：

  • containerd-shim-kata-v2 用于与 pod 通信。
  • virtiofsd 代表客户机处理主机文件系统访问。

每个虚拟机都配置有默认内存量。对于明确请求内存的容器，额外的内存会被热插到虚拟机中。

在没有内存资源的情况下运行的容器会消耗可用内存，直到虚拟机使用的总内存达到默认分配。客户机及其 I/O 缓冲区也消耗内存。

如果容器被授予特定数量的内存，那么该内存会在容器启动前热插到虚拟机中。

当指定内存限制时，如果消耗的内存超过限制，工作负载将被终止。如果没有指定内存限制，则虚拟机中运行的内核可能会耗尽内存。如果内核内存不足，它可能会终止虚拟机上的其他进程。

默认内存大小

下表列出了资源分配的一些默认值。

Expand
资源值

默认为虚拟机分配的内存

2Gi

启动时客户机 Linux 内核内存使用

~110Mi

QEMU 进程使用的内存（虚拟机内存除外）

~30Mi

virtiofsd 进程使用的内存（虚拟机 I/O 缓冲区除外）

~10Mi

containerd-shim-kata-v2 进程使用的内存

~20Mi

在 Fedora 上运行 dnf install 后的文件缓冲区缓存数据

~300Mi* [1]

文件缓冲区会出现并在多个位置考虑：

  • 在客户机中它被显示为文件缓冲缓存。
  • 在映射允许的用户空间文件 I/O 操作的 virtiofsd 守护进程中。
  • 在 QEMU 进程中作为客户机内存。
注意

内存使用率指标正确考虑内存用量总量，该指标仅计算该内存一次。

Pod 开销描述了节点上 pod 使用的系统资源量。您可以使用 oc describe runtimeclass kata 获取 Kata 运行时的当前 pod 开销，如下所示。

示例

$ oc describe runtimeclass kata
Copy to Clipboard Toggle word wrap

输出示例

kind: RuntimeClass
apiVersion: node.k8s.io/v1
metadata:
  name: kata
overhead:
  podFixed:
    memory: "500Mi"
    cpu: "500m"
Copy to Clipboard Toggle word wrap

您可以通过更改 RuntimeClass 的 spec.overhead 字段来更改 pod 开销。例如，如果您为容器运行的配置消耗 QEMU 进程和客户机内核数据的 350Mi 内存，您可以更改 RuntimeClass 开销来满足您的需要。

注意

红帽支持指定的默认开销值。不支持更改默认开销值，这可能会导致技术问题。

在客户机中执行任何类型的文件系统 I/O 时，将在客户机内核中分配文件缓冲区。文件缓冲区也在主机上的 QEMU 进程以及 virtiofsd 进程中映射。

例如，如果您在客户机中使用 300Mi 文件缓冲区缓存，QEMU 和 virtiofsd 都显示使用 300Mi 额外内存。但是，所有三种情况下都使用相同的内存。换句话说，内存使用的总量仅为 300Mi，这个值被映射在三个不同的位置。报告内存使用率指标时，会正确计算。

在运行 OpenShift 沙盒容器前，您可以检查集群中的节点是否有资格运行 Kata 容器。有些集群节点可能不符合沙盒容器的最低要求。节点不合格的最常见原因是节点上缺少虚拟化支持。如果您试图在不符合节点上运行沙盒工作负载，则会出现错误。您可以使用 Node Feature Discovery (NFD) Operator 和 NodeFeatureDiscovery 资源自动检查节点资格。

注意

如果您只想在符合条件的所选 worker 节点上安装 Kata 运行时，请将 feature.node.kubernetes.io/runtime.kata=true 标签应用到所选节点，并在 KataConfig 资源中设置 checkNodeEligibility: true。

另外，要在所有 worker 节点上安装 Kata 运行时，在 KataConfig 资源中设置 checkNodeEligibility: false。

在这两种场景中，您不需要创建 NodeFeatureDiscovery 资源。如果您确定节点有资格运行 Kata 容器，则应该只应用 feature.node.kubernetes.io/runtime.kata=true 标签。

以下流程将 feature.node.kubernetes.io/runtime.kata=true 标签应用到所有有资格的节点，并将 KataConfig 资源配置为检查节点资格。

先决条件

  • 安装 OpenShift CLI（oc）。
  • 以具有 cluster-admin 特权的用户身份登录。
  • 安装 Node Feature Discovery (NFD) Operator。

流程

  1. 创建 NodeFeatureDiscovery 资源来检测适合运行 Kata 容器的节点功能：

    1. 将以下 YAML 保存到 nfd.yaml 文件中： 

      apiVersion: nfd.openshift.io/v1
kind: NodeFeatureDiscovery
metadata:
  name: nfd-kata
  namespace: openshift-nfd
spec:
  operand:
    image: quay.io/openshift/origin-node-feature-discovery:4.10
    imagePullPolicy: Always
    servicePort: 12000
  workerConfig:
    configData: |
      sources:
         custom:
           - name: "feature.node.kubernetes.io/runtime.kata"
             matchOn:
               - cpuId: ["SSE4", "VMX"]
                 loadedKMod: ["kvm", "kvm_intel"]
               - cpuId: ["SSE4", "SVM"]
                 loadedKMod: ["kvm", "kvm_amd"]
      Copy to Clipboard Toggle word wrap

    2. 创建 NodeFeatureDiscovery 自定义资源(CR)： 

      $ oc create -f nfd.yaml
      Copy to Clipboard Toggle word wrap

      输出示例

      nodefeaturediscovery.nfd.openshift.io/nfd-kata created
      Copy to Clipboard Toggle word wrap

      feature.node.kubernetes.io/runtime.kata=true 标签应用到所有合格的 worker 节点。

  2. 在 KataConfig 资源中将 checkNodeEligibility 字段设置为 true 来启用这个功能，例如：

    1. 将以下 YAML 保存到 kata-config.yaml 文件中： 

      apiVersion: kataconfiguration.openshift.io/v1
kind: KataConfig
metadata:
  name: example-kataconfig
spec:
  checkNodeEligibility: true
      Copy to Clipboard Toggle word wrap

    2. 创建 KataConfig CR： 

      $ oc create -f kata-config.yaml
      Copy to Clipboard Toggle word wrap

      输出示例

      kataconfig.kataconfiguration.openshift.io/example-kataconfig created
      Copy to Clipboard Toggle word wrap

验证

  • 验证集群中是否应用了正确的标签： 

    $ oc get nodes --selector='feature.node.kubernetes.io/runtime.kata=true'
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                           STATUS                     ROLES    AGE     VERSION
compute-3.example.com          Ready                      worker   4h38m   v1.23.3+e419edf
compute-2.example.com          Ready                      worker   4h35m   v1.23.3+e419edf
    Copy to Clipboard Toggle word wrap

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat