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

2.3. 使用命令行部署 OpenShift 沙盒容器

您可以使用命令行界面(CLI)在裸机上部署 OpenShift 沙盒容器，以执行以下任务：

  1. 安装 OpenShift 沙盒容器 Operator。

  2. 安装 Operator 后，您可以配置以下选项：

    • 配置块存储设备。

    • 安装 Node Feature Discovery (NFD) Operator 来配置节点资格检查。如需更多信息，请参阅 节点资格检查和 NFD Operator 文档。

      • 创建 NodeFeatureDiscovery 自定义资源。
  3. 创建 KataConfig 自定义资源。
  4. 可选：修改 pod 开销。
  5. 配置 OpenShift 沙盒容器工作负载对象。

2.3.1. 安装 OpenShift 沙盒容器 Operator

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

先决条件

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

流程

  1. 创建 osc-namespace.yaml 清单文件： 

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

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

    $ oc apply -f osc-namespace.yaml

  3. 创建 osc-operatorgroup.yaml 清单文件： 

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

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

    $ oc apply -f osc-operatorgroup.yaml

  5. 创建 osc-subscription.yaml 清单文件： 

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: 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.8.1

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

    $ oc apply -f osc-subscription.yaml

  7. 运行以下命令验证 Operator 是否已正确安装： 

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

    此命令可能需要几分钟来完成。

  8. 运行以下命令监控进程： 

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

    输出示例

    NAME                             DISPLAY                                  VERSION             REPLACES                   PHASE
openshift-sandboxed-containers   openshift-sandboxed-containers-operator  1.8.1    1.7.0        Succeeded

其他资源

2.3.2. 可选配置

您可在安装 OpenShift 沙盒容器 Operator 后配置以下选项。

2.3.2.1. 置备本地块卷

您可以在 OpenShift 沙盒容器中使用本地块卷。您必须首先使用 Local Storage Operator (LSO)置备本地块卷。然后，您必须使用本地块卷启用节点来运行 OpenShift 沙盒容器工作负载。

您可以使用 Local Storage Operator (LSO)为 OpenShift 沙盒容器置备本地块卷。本地卷置备程序会在定义的资源中指定的路径上查找任何块设备。

先决条件

  • 已安装 Local Storage Operator。

  • 您有一个满足以下条件的本地磁盘：

    • 它附加到一个节点。
    • 它尚未挂载。
    • 它不包含分区。

流程

  1. 创建本地卷资源。此资源必须定义本地卷的节点和路径。

    注意

    不要在同一设备中使用不同的存储类名称。这样做可创建多个持久性卷(PV)。

    例如：Block

    apiVersion: "local.storage.openshift.io/v1"
kind: "LocalVolume"
metadata:
  name: "local-disks"
  namespace: "openshift-local-storage" 1
spec:
  nodeSelector: 2
    nodeSelectorTerms:
    - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - ip-10-0-136-143
          - ip-10-0-140-255
          - ip-10-0-144-180
  storageClassDevices:
    - storageClassName: "local-sc" 3
      forceWipeDevicesAndDestroyAllData: false 4
      volumeMode: Block
      devicePaths: 5
        - /path/to/device 6

    1
    安装了 Local Storage Operator 的命名空间。
    2
    可选：包含附加了本地存储卷的节点列表的节点选择器。本例使用从 oc get node 获取的节点主机名。如果没有定义值，则 Local Storage Operator 会尝试在所有可用节点上查找匹配的磁盘。
    3
    创建持久性卷对象时使用的存储类的名称。
    4
    此设置定义是否调用 wipefs，它会删除分区表签名（魔法字符串），使磁盘准备好用于 Local Storage Operator 置备。除了签名外，没有其它数据会被清除。默认为 "false" （不调用 wipefs ）。当在需要重新使用的磁盘中，将 forceWipeDevicesAndDestroyAllData 设置为 "true" 很有用。在这些情况下，将此字段设置为 true 可消除管理员手动擦除磁盘的需要。
    5
    包含要从中选择的本地存储设备列表的路径。在启用带有本地块设备的节点来运行 OpenShift 沙盒容器工作负载时，您必须使用此路径。
    6
    使用到 LocalVolume 资源 by-id 的文件路径替换这个值，如 /dev/disk/by-id/wwn。当置备程序已被成功部署时，会为这些本地磁盘创建 PV。

  2. 在 OpenShift Container Platform 集群中创建本地卷资源。指定您刚才创建的文件： 

    $ oc apply -f <local-volume>.yaml

  3. 验证置备程序是否已创建并创建了相应的守护进程集： 

    $ oc get all -n openshift-local-storage

    输出示例

    NAME                                          READY   STATUS    RESTARTS   AGE
pod/diskmaker-manager-9wzms                   1/1     Running   0          5m43s
pod/diskmaker-manager-jgvjp                   1/1     Running   0          5m43s
pod/diskmaker-manager-tbdsj                   1/1     Running   0          5m43s
pod/local-storage-operator-7db4bd9f79-t6k87   1/1     Running   0          14m

NAME                                     TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
service/local-storage-operator-metrics   ClusterIP   172.30.135.36   <none>        8383/TCP,8686/TCP   14m

NAME                               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/diskmaker-manager   3         3         3       3            3           <none>          5m43s

NAME                                     READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/local-storage-operator   1/1     1            1           14m

NAME                                                DESIRED   CURRENT   READY   AGE
replicaset.apps/local-storage-operator-7db4bd9f79   1         1         1       14m

    请注意 所需的 和当前的 守护进程设定进程数。所需的 数量为 0 表示标签选择器无效。

  4. 验证持久性卷是否已创建： 

    $ oc get pv

    输出示例

    NAME                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
local-pv-1cec77cf   100Gi      RWO            Delete           Available           local-sc                88m
local-pv-2ef7cd2a   100Gi      RWO            Delete           Available           local-sc                82m
local-pv-3fa1c73    100Gi      RWO            Delete           Available           local-sc                48m

重要

编辑 LocalVolume 对象不会更改现有的持久性卷，因为这样做可能会导致破坏性操作。

2.3.2.2. 启用节点使用本地块设备

您可以使用本地块设备配置节点，以便在定义的卷资源中指定的路径上运行 OpenShift 沙盒容器工作负载。

先决条件

  • 已使用 Local Storage Operator (LSO)置备块设备。

流程

  • 运行以下命令，使用本地块设备启用每个节点来运行 OpenShift 沙盒容器工作负载： 

    $ oc debug node/worker-0 -- chcon -vt container_file_t /host/path/to/device

    在创建本地存储资源时，/path/to/device 必须与您定义的路径相同。

    输出示例

    system_u:object_r:container_file_t:s0 /host/path/to/device

2.3.2.3. 创建 NodeFeatureDiscovery 自定义资源

您可以创建一个 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

2.3.3. 创建 KataConfig 自定义资源

您必须创建 KataConfig 自定义资源(CR)以在 worker 节点上作为运行时类安装 kata。

创建 KataConfig CR 会触发 OpenShift 沙盒容器 Operator 来执行以下操作：

  • 在 RHCOS 节点上安装所需的 RHCOS 扩展，如 QEMU 和 kata-containers。
  • 确保 CRI-O 运行时配置了正确的运行时处理程序。
  • 使用默认配置创建一个名为 kata 的 RuntimeClass CR。这可让用户在 RuntimeClassName 字段中引用 CR 将工作负载配置为使用 kata 作为运行时。此 CR 也指定运行时的资源开销。

OpenShift 沙盒容器将 kata 作为集群中的辅助 可选运行时安装，而不是作为主要运行时。

重要

创建 KataConfig CR 会自动重启 worker 节点。重启可能需要 10 到 60 分钟。妨碍重启时间的因素如下：

  • 带有更多 worker 节点的大型 OpenShift Container Platform 部署。
  • 激活 BIOS 和 Diagnostics 实用程序。
  • 在硬盘而不是 SSD 上部署。
  • 在物理节点上部署，如裸机，而不是在虚拟节点上部署。
  • CPU 和网络较慢。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 可选：如果要启用节点资格检查，已安装了 Node Feature Discovery Operator。

流程

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

    apiVersion: kataconfiguration.openshift.io/v1
kind: KataConfig
metadata:
  name: example-kataconfig
spec:
  checkNodeEligibility: false 1
  logLevel: info
#  kataConfigPoolSelector:
#    matchLabels:
#      <label_key>: '<label_value>' 2
    1
    可选：将'checkNodeEligibility' 设置为 true 以运行节点资格检查。
    2
    可选：如果您应用了节点标签来在特定节点上安装 OpenShift 沙盒容器，请指定键和值。

  2. 运行以下命令来创建 KataConfig CR： 

    $ oc apply -f example-kataconfig.yaml

    新的 KataConfig CR 会被创建，并在 worker 节点上作为运行时类安装 kata。

    在验证安装前，等待 kata 安装完成，以及 worker 节点重新引导。

  3. 运行以下命令监控安装进度： 

    $ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"

    当安装 kataNodes 下的所有 worker 的状态并且条件 InProgress 为 False 时，如果没有指定原因，则会在集群中安装 kata。

2.3.4. 修改 pod 开销

Pod 开销描述了节点上 pod 使用的系统资源量。您可以通过更改 RuntimeClass 自定义资源的 spec.overhead 字段来修改 pod 开销。例如，如果您为容器运行的配置消耗 QEMU 进程和客户机内核数据的 350Mi 内存，您可以更改 RuntimeClass 开销来满足您的需要。

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

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

注意

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

流程

  1. 运行以下命令来获取 RuntimeClass 对象： 

    $ oc describe runtimeclass kata

  2. 更新 overhead.podFixed.memory 和 cpu 值，并将文件保存为 runtimeclass.yaml ： 

    kind: RuntimeClass
apiVersion: node.k8s.io/v1
metadata:
  name: kata
overhead:
  podFixed:
    memory: "500Mi"
    cpu: "500m"

  3. 运行以下命令来应用更改： 

    $ oc apply -f runtimeclass.yaml

2.3.5. 配置工作负载对象

您必须将 kata 设置为以下 pod 模板的对象的运行时类来配置 OpenShift 沙盒容器工作负载对象：

  • Pod 对象
  • ReplicaSet 对象
  • ReplicationController 对象
  • StatefulSet 对象
  • Deployment 对象
  • deploymentConfig 对象
重要

不要在 Operator 命名空间中部署工作负载。为这些资源创建一个专用命名空间。

先决条件

  • 您已创建了 KataConfig 自定义资源(CR)。

流程

  1. 将 spec.runtimeClassName: kata 添加到每个 pod 模板工作负载对象的清单中，如下例所示： 

    apiVersion: v1
kind: <object>
# ...
spec:
  runtimeClassName: kata
# ...

    OpenShift Container Platform 创建工作负载对象并开始调度它。

验证

  • 检查 pod 模板对象的 spec.runtimeClassName 字段。如果值为 kata，则工作负载在 OpenShift 沙盒容器中运行，使用对等 pod。
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.