2.3. 使用命令行部署工作负载


您可以使用命令行部署 OpenShift 沙盒容器工作负载。

2.3.1. 可选:使用 Local Storage Operator 置备本地块卷

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

先决条件

  • 安装了 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
    包含要从中选择的本地存储设备列表的路径。在块设备上部署沙盒容器节点时,您必须使用此路径。
    6
    使用到 LocalVolume 资源 by-id 的实际本地磁盘文件路径(如 /dev/disk/by-id/wwn)替换这个值。当置备程序已被成功部署时,会为这些本地磁盘创建 PV。
  2. 在 OpenShift Container Platform 集群中创建本地卷资源。指定您刚才创建的文件:

    $ oc create -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. 可选:在块设备上部署节点

如果为 OpenShift 沙盒容器置备本地块卷,您可以选择在定义的卷资源中指定的路径上部署节点。

先决条件

  • 已使用 Local Storage Operator 置备块设备

流程

  • 对您要使用块设备部署的每个节点运行以下命令:
$ 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.3. 创建 KataConfig 自定义资源

您必须创建一个 KataConfig 自定义资源(CR)来作为 worker 节点上的运行时类安装 kata

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

  • 在 RHCOS 节点上安装所需的 RHCOS 扩展,如 QEMU 和 kata-containers
  • 确保 CRI-O 运行时配置了正确的运行时处理程序。
  • 使用默认配置创建一个名为 kataRuntimeClass 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. 根据以下示例创建 cluster-kataconfig.yaml 清单文件:

    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: cluster-kataconfig
    spec:
      checkNodeEligibility: false 1
      logLevel: info
    1
    可选:将'checkNodeEligibility' 设置为 true 以运行节点资格检查。
  2. 可选: 要在所选节点上安装 kata,请按照以下示例指定节点标签:

    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: cluster-kataconfig
    spec:
      kataConfigPoolSelector:
        matchLabels:
          <label_key>: '<label_value>' 1
    # ...
    1
    指定所选节点的标签。
  3. 创建 KataConfig CR:

    $ oc create -f cluster-kataconfig.yaml

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

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

验证

  • 运行以下命令监控安装进度:

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

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

详情请参阅 KataConfig 状态信息

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.memorycpu 值,保存为 RuntimeClass.yaml

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

2.3.5. 配置工作负载对象

您可以通过将 kata 配置为以下 pod 模板对象的运行时类来部署 OpenShift 沙盒容器工作负载:

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

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

先决条件

  • 您已为供应商创建了 secret 对象。
  • 您已为供应商创建了配置映射。
  • 您已创建了 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.