红帽全球峰会第 2 章 部署 OpenShift 沙盒容器工作负载
您可以使用 Web 控制台或 OpenShift CLI（oc）安装 OpenShift 沙盒容器 Operator。在安装 OpenShift 沙盒容器 Operator 之前，您必须准备 Red Hat OpenShift 集群。
2.1. 先决条件
在安装 OpenShift 沙盒容器前，请确保 Red Hat OpenShift 集群满足以下要求：
集群必须使用 Red Hat Enterprise Linux CoreOS (RHCOS) worker 在内部裸机基础架构上安装。您可以使用任何安装方法，包括用户置备、安装程序置备或协助的安装程序来部署集群。
注意- OpenShift 沙盒容器仅支持 RHCOS worker 节点。不支持 RHEL 节点。
- 不支持嵌套虚拟化。
- 您可以在 Amazon Web Services (AWS) 裸机实例上安装 OpenShift 沙盒容器。不支持由其他云提供商提供的裸机实例。
2.1.1. OpenShift 沙盒容器的资源要求
OpenShift 沙盒容器允许用户在沙盒运行时 (Kata) 的 Red Hat OpenShift 集群上运行工作负载。每个 pod 由一个虚拟机（VM）表示。每个虚拟机都在 QEMU 进程中运行，并托管一个 kata-agent 进程，它充当管理容器工作负载的监管程序，以及这些容器中运行的进程。两个额外的进程会增加开销：
-
containerd-shim-kata-v2用于与 pod 通信。 -
virtiofsd代表客户机处理主机文件系统访问。
每个虚拟机都配置有默认内存量。对于明确请求内存的容器，额外的内存会被热插到虚拟机中。
在没有内存资源的情况下运行的容器会消耗可用内存，直到虚拟机使用的总内存达到默认分配。客户机及其 I/O 缓冲区也消耗内存。
如果容器被授予特定数量的内存，那么该内存会在容器启动前热插到虚拟机中。
当指定内存限制时，如果消耗的内存超过限制，工作负载将被终止。如果没有指定内存限制，则虚拟机中运行的内核可能会耗尽内存。如果内核内存不足，它可能会终止虚拟机上的其他进程。
默认内存大小
下表列出了资源分配的一些默认值。
| 资源 | 值 |
|---|---|
| 默认为虚拟机分配的内存 | 2Gi |
| 启动时客户机 Linux 内核内存使用 | ~110Mi |
| QEMU 进程使用的内存（虚拟机内存除外） | ~30Mi |
|
| ~10Mi |
|
| ~20Mi |
|
在 Fedora 上运行 | ~300Mi* [1] |
文件缓冲区会出现并在多个位置考虑：
- 在客户机中它被显示为文件缓冲缓存。
-
在映射允许的用户空间文件 I/O 操作的
virtiofsd守护进程中。 - 在 QEMU 进程中作为客户机内存。
内存使用率指标正确考虑内存用量总量，该指标仅计算该内存一次。
Pod 开销描述了节点上 pod 使用的系统资源量。您可以使用 oc describe runtimeclass kata 获取 Kata 运行时的当前 pod 开销，如下所示。
示例
$ oc describe runtimeclass kata
输出示例
kind: RuntimeClass
apiVersion: node.k8s.io/v1
metadata:
name: kata
overhead:
podFixed:
memory: "500Mi"
cpu: "500m"
您可以通过更改 RuntimeClass 的 spec.overhead 字段来更改 pod 开销。例如，如果您为容器运行的配置消耗 QEMU 进程和客户机内核数据的 350Mi 内存，您可以更改 RuntimeClass 开销来满足您的需要。
红帽支持指定的默认开销值。不支持更改默认开销值，这可能会导致技术问题。
在客户机中执行任何类型的文件系统 I/O 时，将在客户机内核中分配文件缓冲区。文件缓冲区也在主机上的 QEMU 进程以及 virtiofsd 进程中映射。
例如，如果您在客户机中使用 300Mi 文件缓冲区缓存，QEMU 和 virtiofsd 都显示使用 300Mi 额外内存。但是，所有三种情况下都使用相同的内存。换句话说，内存使用的总量仅为 300Mi，这个值被映射在三个不同的位置。报告内存使用率指标时，会正确计算。
其他资源
2.1.2. 检查集群节点是否有资格运行 OpenShift 沙盒容器
在运行 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。
流程
创建
NodeFeatureDiscovery资源来检测适合运行 Kata 容器的节点功能：将以下 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"]创建
NodeFeatureDiscovery自定义资源(CR)：$ oc create -f nfd.yaml
输出示例
nodefeaturediscovery.nfd.openshift.io/nfd-kata created
feature.node.kubernetes.io/runtime.kata=true标签应用到所有合格的 worker 节点。
在
KataConfig资源中将checkNodeEligibility字段设置为true来启用这个功能，例如：将以下 YAML 保存到
kata-config.yaml文件中：apiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: example-kataconfig spec: checkNodeEligibility: true
创建
KataConfigCR：$ oc create -f kata-config.yaml
输出示例
kataconfig.kataconfiguration.openshift.io/example-kataconfig created
验证
验证集群中是否应用了正确的标签：
$ oc get nodes --selector='feature.node.kubernetes.io/runtime.kata=true'
输出示例
NAME STATUS ROLES AGE VERSION compute-3.example.com Ready worker 4h38m v1.25.0 compute-2.example.com Ready worker 4h35m v1.25.0
其他资源
- 有关安装 Node Feature Discovery (NFD) Operator 的更多信息，请参阅安装 NFD。
