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


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

  1. 安装 OpenShift 沙盒容器 Operator。
  2. 安装 Operator 后,您可以配置以下选项:

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

      • 创建 NodeFeatureDiscovery 自定义资源。
  3. 可选:自定义 Kata 代理策略。
  4. 创建 KataConfig 自定义资源。
  5. 可选:修改 pod 开销。
  6. 配置 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.9.0
  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.9.0    1.8.1        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. 自定义 Kata 代理策略

Kata 代理策略是一种安全机制,用于控制使用 Kata 运行时运行的 pod 的代理 API 请求。使用 Rego 编写并由 Pod 虚拟机(VM)中的 Kata 代理强制,此策略决定哪些操作被允许或拒绝。

您可以针对特定用例使用自定义策略来覆盖默认策略,如在安全不是关注的地方进行开发和测试。例如,您可以在 control plane 可以被信任的环境中运行。您可以通过几种方法应用自定义策略:

  • 将其嵌入到 pod 虚拟机镜像中。
  • 修补对等 pod 配置映射。
  • 为工作负载 pod YAML 添加注解。

对于生产环境系统,首选的方法是使用 initdata 覆盖 Kata 代理策略。以下流程使用 io.katacontainers.config.agent.policy 注解将自定义策略应用到单独的 pod。该策略以 Base64 编码的 Rego 格式提供。此方法会在创建 Pod 时覆盖默认策略,而不修改 pod 虚拟机镜像。

注意

自定义策略完全替换了默认策略。要只修改特定的 API,请包含完整的策略并调整相关规则。

流程

  1. 使用自定义策略创建 policy.rego 文件。以下示例显示了所有可配置的 API,并且为演示启用了 execlog

    package agent_policy
    
    import future.keywords.in
    import input
    
    default CopyFileRequest := false
    default CreateContainerRequest := false
    default CreateSandboxRequest := true
    default DestroySandboxRequest := true
    default ExecProcessRequest := true  # Enabled to allow exec API
    default GetOOMEventRequest := true
    default GuestDetailsRequest := true
    default OnlineCPUMemRequest := true
    default PullImageRequest := true
    default ReadStreamRequest := true   # Enabled to allow log API
    default RemoveContainerRequest := true
    default RemoveStaleVirtiofsShareMountsRequest := true
    default SignalProcessRequest := true
    default StartContainerRequest := true
    default StatsContainerRequest := true
    default TtyWinResizeRequest := true
    default UpdateEphemeralMountsRequest := true
    default UpdateInterfaceRequest := true
    default UpdateRoutesRequest := true
    default WaitProcessRequest := true
    default WriteStreamRequest := false

    此策略启用 exec (ExecProcessRequest)和 log (ReadStreamRequest) API。根据您的需要,调整 truefalse 值以进一步自定义策略。

  2. 运行以下命令,将 policy.rego 文件转换为 Base64 编码的字符串:

    $ base64 -w0 policy.rego

    复制下一步骤中要使用的输出。

  3. 将 Base64 编码的策略添加到 my-pod.yaml pod 规格文件中:

    apiVersion: v1
    kind: Pod
    metadata:
      name: <pod_name>
      annotations:
        io.katacontainers.config.agent.policy: <base64_encoded_policy>
    spec:
      runtimeClassName: kata-remote
      containers:
      - name: <container_name>
        image: registry.access.redhat.com/ubi9/ubi:latest
        command:
        - sleep
        - "36000"
        securityContext:
          privileged: false
          seccompProfile:
            type: RuntimeDefault
  4. 运行以下命令来应用 pod 清单:

    $ oc apply -f my-pod.yaml

2.3.4. 创建 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. 根据以下示例创建 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 的状态并且条件 InProgressFalse 时,如果没有指定原因,则会在集群中安装 kata

2.3.5. 修改 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"
  3. 运行以下命令来应用更改:

    $ oc apply -f runtimeclass.yaml

2.3.6. 配置工作负载对象

您必须将 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.