支持控制台（Console）开发人员开始试用联系人

第 2 章 在裸机上部署工作负载

您可以使用 worker 节点上安装的 Red Hat Enterprise Linux CoreOS (RHCOS)在内部裸机服务器上部署 OpenShift 沙盒容器工作负载。

注意
  • 不支持 RHEL 节点。
  • 不支持嵌套虚拟化。

您可以使用任何安装方法，包括 用户置备的、安装程序置备的 或 Assisted Installer 来部署集群。

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

部署工作流

您可以通过执行以下步骤部署 OpenShift 沙盒容器工作负载：

  1. 准备您的环境。
  2. 创建 KataConfig 自定义资源。
  3. 将您的工作负载对象配置为使用 kata 运行时类。

2.1. 准备您的环境

执行以下步骤准备您的环境：

  1. 确保集群有足够的资源。
  2. 安装 OpenShift 沙盒容器 Operator。

  3. 可选：配置节点 资格 检查以确保 worker 节点支持 OpenShift 沙盒容器：

    1. 安装 Node Feature Discovery (NFD) Operator。详情请参阅 NFD Operator 文档。
    2. 创建 NodeFeatureDiscovery 自定义资源(CR)以定义 NFD Operator 检查的节点配置参数。

2.1.1. 资源要求

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

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

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

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

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

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

默认内存大小

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

资源value

默认为虚拟机分配的内存

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 开销，如下所示。

Example

$ 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 沙盒容器 Operator

您可以使用 OpenShift Container Platform Web 控制台或命令行界面(CLI)安装 OpenShift 沙盒容器 Operator。

2.1.2.1. 使用 Web 控制台安装 Operator

您可以使用 Red Hat OpenShift Container Platform Web 控制台安装 OpenShift 沙盒容器 Operator。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 在 OpenShift Container Platform Web 控制台中导航至 Operators OperatorHub。
  2. 在 Filter by keyword 字段中，输入 OpenShift sandboxed containers。
  3. 选择 OpenShift 沙盒容器 Operator 标题并点 Install。
  4. 在 Install Operator 页面中，从可用 Update Channel 选项列表中选择 stable。

  5. 验证为 Installed Namespace 选择了 Operator recommended Namespace。这会在 openshift-sandboxed-containers-operator 命名空间中安装 Operator。如果此命名空间尚不存在，则会自动创建。

    注意

    尝试在 openshift-sandboxed-containers-operator 以外的命名空间中安装 OpenShift 沙盒容器 Operator 会导致安装失败。

  6. 验证是否为 Approval Strategy 选择了 Automatic。Automatic 是默认值，当有新的 z-stream 发行版本可用时，自动启用对 OpenShift 沙盒容器的自动更新。
  7. 点 Install。

OpenShift 沙盒容器 Operator 现已安装在集群中。

验证

  1. 导航到 Operators Installed Operators。
  2. 验证 OpenShift 沙盒容器 Operator 是否已显示。

其他资源

2.1.2.2. 使用 CLI 安装 Operator

您可以使用 CLI 安装 OpenShift 沙盒容器 Operator。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 您可以使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 创建 Namespace.yaml 清单文件： 

    apiVersion: v1
kind: Namespace
metadata:
  name: openshift-sandboxed-containers-operator

  2. 运行以下命令创建命名空间： 

    $ oc create -f Namespace.yaml

  3. 创建 OperatorGroup.yaml 清单文件： 

    apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-sandboxed-containers-operator
  namespace: openshift-sandboxed-containers-operator
spec:
  targetNamespaces:
  - openshift-sandboxed-containers-operator

  4. 运行以下命令来创建 operator 组： 

    $ oc create -f OperatorGroup.yaml

  5. 创建 Subscription.yaml 清单文件： 

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-sandboxed-containers-operator
  namespace: openshift-sandboxed-containers-operator
spec:
  channel: stable
  installPlanApproval: Automatic
  name: sandboxed-containers-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  startingCSV: sandboxed-containers-operator.v1.6.0

  6. 运行以下命令来创建订阅： 

    $ oc create -f Subscription.yaml

OpenShift 沙盒容器 Operator 现已安装在集群中。

验证

  • 运行以下命令确保 Operator 已正确安装： 

    $ oc get csv -n openshift-sandboxed-containers-operator

    输出示例

    NAME                             DISPLAY                                  VERSION             REPLACES                   PHASE
openshift-sandboxed-containers   openshift-sandboxed-containers-operator  1.6.0    1.5.3        Succeeded

2.1.2.3. 其他资源

2.1.3. 创建 NodeFeatureDiscovery CR

您可以创建一个 NodeFeatureDiscovery 自定义资源(CR)来定义 Node Feature Discovery (NFD) Operator 检查的配置参数，以确定 worker 节点可以支持 OpenShift 沙盒容器。

注意

要仅在您了解的所选 worker 节点上安装 kata 运行时，请将 feature.node.kubernetes.io/runtime.kata=true 标签应用到所选节点，并在 KataConfig CR 中设置 checkNodeEligibility: true。

要在所有 worker 节点上安装 kata 运行时，请在 KataConfig CR 中设置 checkNodeEligibility: false。

在这两种情况下，您不需要创建 NodeFeatureDiscovery CR。如果您确定节点有资格运行 OpenShift 沙盒容器，则应仅应用 feature.node.kubernetes.io/runtime.kata=true 标签。

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

先决条件

  • 已安装 NFD Operator。

流程

  1. 根据以下示例创建 nfd.yaml 清单文件： 

    apiVersion: nfd.openshift.io/v1
kind: NodeFeatureDiscovery
metadata:
  name: nfd-kata
  namespace: openshift-nfd
spec:
  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"]
# ...

  2. 创建 NodeFeatureDiscovery CR： 

    $ oc create -f nfd.yaml

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

  1. 根据以下示例创建 kata-config.yaml 清单文件： 

    apiVersion: kataconfiguration.openshift.io/v1
kind: KataConfig
metadata:
  name: example-kataconfig
spec:
  checkNodeEligibility: true

  2. 创建 KataConfig CR： 

    $ oc create -f kata-config.yaml

验证

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

    $ 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

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.