OpenShift 的沙盒容器的支持

OpenShift Container Platform 4.9

OpenShift 沙盒容器指南

Red Hat OpenShift Documentation Team

摘要

OpenShift 沙盒容器支持 OpenShift Container Platform 为用户提供对将 Kata Containers 作为额外可选运行时运行的内置支持。

第 1 章 {sandboxed-containers-first} 1.1 发行注记

1.1. 关于此版本

本发行注记介绍了 OpenShift 沙盒容器 1.1 和 Red Hat OpenShift Container Platform 4.9 的开发。

这个产品目前还只是一个技术预览。OpenShift 沙盒容器并不适用于生产环境。如需更多信息,请参阅红帽客户门户网站中的支持功能的范围

1.2. 新功能及功能增强

1.2.1. FIPS 兼容性

现在,OpenShift 沙盒容器会自动启用 FIPS 模式。在以 FIPS 模式安装的 OpenShift Container Platform 集群上部署的 OpenShift 沙盒容器不会污点集群的 FIPS 支持。如需更多信息,请参阅了解合规性和风险管理

1.2.2. 使用 must-gather 来收集资源

OpenShift 沙盒容器 Operator 现在包含一个 must-gather 镜像,允许您收集特定于此 Operator 的自定义资源和日志文件,以及用于诊断目的的底层运行时组件。如需更多信息,请参阅为红帽支持收集 OpenShift 沙盒容器数据

1.2.3. 断开连接的环境

现在,您可以在断开连接的环境中安装 OpenShift 沙盒容器 Operator。如需更多信息,请参阅部署 OpenShift 沙盒容器工作负载的额外资源

1.3. 程序错误修复

  • 在以前的版本中,当在 OpenShift 沙盒容器中运行 Fedora 时,一些软件包需要的文件访问权限更改,OpenShift Container Platform 默认不授予容器。在这个版本中,这些权限默认被授予。(BZ#1915377)
  • 在以前的版本中,在 OpenShift Container Platform Web 控制台中的 kataConfgPoolSelector 中添加值会使用空值填充 scheduling.nodeSelector。因此,使用具有 kata 值的 RuntimeClass 对象的 pod 可以调度到没有安装 Kata Containers 运行时的节点。在这个版本中,只有带有与 kataConfgPoolSelector 中定义的标签标记的节点才会安装 Kata Containers 运行时。(BZ#2019384)
  • 在以前的版本中,Operator Hub 上的 OpenShift 沙盒容器 Operator 详情页面缺少字段。在这个发行版本中,这些字段不再缺失。(BZ#2019383)
  • 在以前的版本中,创建多个 KataConfig 自定义资源会导致静默失败,OpenShift Container Platform Web 控制台没有错误来通知用户创建多个自定义资源失败。在这个版本中,用户在尝试创建多个自定义资源时收到错误。(BZ#2019381)
  • 在以前的版本中,有些实例,OpenShift Container Platform Web 控制台中的 Operator Hub 没有显示 Operator 的图标。在这个版本中,图标总是被显示。(BZ#9019380)

1.4. 已知问题

  • 如果使用 OpenShift 沙盒容器,您可能会在访问 OpenShift Container Platform 集群中从 hostPath 卷挂载的文件或目录时收到 SELinux 拒绝。即使运行特权沙盒容器,这些拒绝也会发生,因为特权沙盒容器不会禁用 SELinux 检查。

    在默认情况下,主机上的 SELinux 策略会保证主机文件系统完全与沙盒工作负载隔离,并提供对 virtiofsd 或 QEMU 中潜在的安全漏洞的更强的保护。

    如果挂载的文件或目录在主机上没有特定的 SELinux 要求,您可以使用本地持久性卷作为替代方案。文件会自动重新标记为 container_file_t,遵循 SELinux 容器运行时。如需更多信息,请参阅使用本地卷的持久性存储

    挂载文件或目录时,自动重新标记不是选项,则主机上应该具有特定的 SELinux 标签。相反,您可以在主机上设置自定义 SELinux 规则,以允许 virtiofsd 访问这些特定标签。(BZ#1904609

1.5. 异步勘误更新

OpenShift 沙盒容器 4.9 的安全更新、程序错误修正、功能增强更新将会通过红帽网络以异步勘误的形式发布。所有的 OpenShift Container Platform 4.9 勘误都可以通过红帽客户门户网站获得OpenShift Container Platform 生命周期包括了详细的与异步勘误相关的内容。

红帽客户门户网站的用户可以在红帽订阅管理(RHSM)帐户设置中启用勘误通知功能。当勘误通知被启用后,用户会在有与其注册的系统相关的勘误发行时接收到电子邮件通知。

注意

用户的红帽客户门户网站账户需要有注册的系统,以及使用 OpenShift Container Platform 的权限才可以接收到 OpenShift Container Platform 的勘误通知。

本节的内容将会持续更新,以提供以后发行的与 OpenShift 沙盒容器 1.1.0 相关的异步勘误信息。

1.5.1. RHEA-2021:3941 - OpenShift 沙盒容器 1.1.0 镜像发行版本、程序错误修正和增强公告

发布日期:2021 年 10 月 21 日

OpenShift 沙盒容器版本 1.1.0 现已正式发布。此公告包含带有改进和程序错误修复的 OpenShift 沙盒容器的更新。

其程序错误修正列表包括在 RHEA-2021:3941 公告中。

第 2 章 了解 OpenShift 沙盒容器

OpenShift 沙盒容器支持 OpenShift Container Platform 为用户提供对将 Kata Containers 作为额外可选运行时运行的内置支持。这对希望执行以下任务的用户特别有用:

  • 运行特权或不受信任的工作负载。
  • 确保每个工作负载的内核隔离。
  • 在租户之间共享相同的工作负载。
  • 确保正确隔离和沙盒测试软件。
  • 确保跨越 VM 边界的默认资源控制。

OpenShift 沙盒容器还让用户能够从希望运行的工作负载类型中进行选择,以满足不同的用例。

您可以使用 OpenShift 沙盒容器 Operator 来执行诸如安装和删除、更新和状态监控等任务。

沙盒容器仅在裸机上受支持。

Red Hat Enterprise Linux CoreOS(RHCOS)是 OpenShift 沙盒容器 1.0.0 唯一支持的操作系统。

2.1. OpenShift 沙盒容器常用术语

以下是整个文档中所使用的术语:

Sandbox

沙盒(sandbox)是一种隔离的环境,程序可以在其中运行。在沙盒中,您可以运行未经测试或不受信任的程序,而不影响到主机机器或操作系统。

在 OpenShift 沙盒容器环境中,沙盒通过使用虚拟化在不同的内核中运行工作负载来实现,从而增强了对在同一主机上运行的多个工作负载之间的交互的控制。

Pod

pod 是继承自 Kubernetes 和 OpenShift Container Platform 的构造。它代表了可以部署容器的资源。容器在 pod 内运行,pod 用于指定可以在多个容器之间共享的资源。

在 OpenShift 沙盒容器上下文中,pod 被实施为一个虚拟机。多个容器可以在同一虚拟机上在同一 pod 中运行。

OpenShift 沙盒容器 Operator

Operator 是一个软件组件,可自动执行一般需要人工在系统上执行的操作。

OpenShift 沙盒容器 Operator 的任务是管理集群上沙盒容器的生命周期。它涉及如安装和删除沙盒容器软件以及状态监控等操作。

Kata 容器
Kata 容器是一个上游核心项目,用于构建 OpenShift 沙盒容器。OpenShift 沙盒容器将 Kata 容器与 OpenShift Container Platform 集成。
KataConfig
KataConfig 对象代表沙盒容器的配置。它们存储有关集群状态的信息,如部署软件的节点。
RHCOS 扩展
Red Hat Enterprise Linux CoreOS(RHCOS)扩展是安装可选 OpenShift Container Platform 软件的一种机制。OpenShift 沙盒容器 Operator 使用此机制在集群中部署沙盒容器。
运行时类
RuntimeClass 对象用于描述可以使用哪个运行时来运行给定工作负载。OpenShift 沙盒容器 Operator 安装和部署了名为 kata 的运行时类。运行时类包含有关运行时的信息,用于描述运行时需要运行的资源,如 pod 开销

2.2. OpenShift 沙盒容器构建块

OpenShift 沙盒容器 Operator 封装了来自 Kata 容器的所有组件。它管理安装、生命周期和配置任务。

OpenShift 沙盒容器 Operator 以 Operator 捆绑包格式打包为两个容器镜像。捆绑包镜像包含元数据,这是使 operator OLM 就绪所必需的。第二个容器镜像包含监控和管理 KataConfig 资源的实际控制器。

2.3. RHCOS 扩展

OpenShift 沙盒容器 Operator 基于 Red Hat Enterprise Linux CoreOS(RHCOS)扩展概念。沙盒容器 RHCOS 扩展包含用于 Kata、QEMU 及其依赖项的 RPM。您可以使用 Machine Config Operator 提供的 MachineConfig 资源启用它们。

2.4. 了解合规性及风险管理

OpenShift 沙盒容器可以在启用了 FIPS 的集群中使用。

在 FIPS 模式下运行时,OpenShift 沙盒容器组件、虚拟机和虚拟机镜像会根据 FIPS 进行调整。

FIPS 合规性是高安全性环境中所需的最重要的组件之一,可确保节点上只允许使用支持的加密技术。

重要

只有在 x86_64 架构中的 OpenShift Container Platform 部署支持 FIPS 验证的/Modules in Process 加密库。

要了解红帽对 OpenShift Container Platform 合规框架的观点,请参阅 OpenShift 安全性指南手册中的“风险管理和法规就绪状态”一章。

第 3 章 部署 OpenShift 沙盒容器工作负载

您可以使用 Web 控制台或 OpenShift CLI(oc)安装 OpenShift 沙盒容器 Operator。安装 OpenShift 沙盒容器 Operator 之前,您必须准备 OpenShift Container Platform 集群。

3.1. 先决条件

在安装 OpenShift 沙盒容器前,请确保 OpenShift Container Platform 集群满足以下要求:

  • 集群必须使用 Red Hat Enterprise Linux CoreOS (RHCOS) worker 在内部裸机基础架构上安装。

    重要
    • OpenShift 沙盒容器仅支持 RHCOS worker 节点。不支持 RHEL 节点。
    • 不支持嵌套虚拟化。

3.1.1. OpenShift 沙盒容器的资源要求

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

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

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

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

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

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

默认内存大小

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

资源

默认为虚拟机分配的内存

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

示例

$ oc describe runtimeclass kata

输出示例

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

您可以通过更改 RuntimeClassspec.overhead 字段来更改 pod 开销。例如,如果您为容器运行的配置消耗 QEMU 进程和客户机内核数据的 350Mi 内存,您可以更改 RuntimeClass 开销来满足您的需要。

注意

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

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

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

3.2. 使用 Web 控制台部署 OpenShift 沙盒容器工作负载

您可从 web 控制台部署 OpenShift 沙盒容器工作负载。首先,您必须安装 OpenShift 沙盒容器 Operator,然后创建 KataConfig 自定义资源 (CR)。在沙盒容器中部署工作负载后,您必须手动将 kata 作为 runtimeClassName 添加到工作负载 YAML 文件中。

3.2.1. 使用 Web 控制台安装 OpenShift 沙盒容器 Operator

您可从 OpenShift Container Platform Web 控制台安装 OpenShift 沙盒容器 Operator。

先决条件

  • 已安装 OpenShift Container Platform 4.9。
  • 您可以使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 从 Web 控制台中的 Administrator 视角,进入到 OperatorsOperatorHub
  2. Filter by keyword 字段中,输入 OpenShift sandboxed containers
  3. 选择 OpenShift sandboxed containers 标题。
  4. 阅读 Operator 信息并单击 Install
  5. Install Operator 页面中:

    1. 从可用 Update Channel 选项列表中选择 preview-1.1
    2. 验证为 Installed Namespace 选择了 Operator recommended Namespace。这会在 openshift-sandboxed-containers-operator 命名空间中安装 Operator。如果此命名空间尚不存在,则会自动创建。

      注意

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

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

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

验证

  1. 从 Web 控制台中的 Administrator 视角,导航到 OperatorsInstalled Operators
  2. 验证 OpenShift 沙盒容器 Operator 是否在 operator 列表中列出。

3.2.2. 在 web 控制台中创建 KataConfig 自定义资源

您必须创建一个 KataConfig 自定义资源(CR),以便在集群节点上启用将 kata 作为 RuntimeClass

先决条件

  • 在集群中安装了 OpenShift Container Platform 4.9。
  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 已安装 OpenShift 沙盒容器 Operator。
注意

Kata 默认安装在所有 worker 节点上。如果要在特定节点上安装 kata 作为 RuntimeClass,您可以向这些节点添加标签,然后在创建时定义 KataConfig CR 中的标签。

流程

  1. 从 Web 控制台中的 Administrator 视角,导航到 OperatorsInstalled Operators
  2. 从 Operator 列表中选择 OpenShift 沙盒容器 Operator。
  3. KataConfig 选项卡中,点 Create KataConfig
  4. Create KataConfig 页面中,选择通过 YAML 视图 配置 KataConfig CR。
  5. 将以下清单复制并粘贴到 YAML 视图中

    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: cluster-kataconfig

    如果要在所选节点上安装 kata 作为 RuntimeClass,请在清单中包括该标签:

     apiVersion: kataconfiguration.openshift.io/v1
     kind: KataConfig
     metadata:
       name: cluster-kataconfig
     spec:
       kataConfigPoolSelector:
         matchLabels:
          <label_key>: '<label_value>' 1
    1
    kataConfigPoolSelector 中的标签只支持单个值;不支持 nodeSelector 语法。
  6. Create

新的 KataConfig CR 会被创建,并开始在 worker 节点上作为 RuntimeClass 安装 kata

重要

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

验证

  1. KataConfig 选项卡中,选择新的 KataConfig CR。
  2. KataConfig 页面中,选择 YAML 选项卡。
  3. 监控状态中的 installationStatus 字段。

    每次有更新时都会出现一条消息。点 Reload 查看更新的 KataConfig CR。

    Completed nodes 的值等于 worker 或已标记的节点的数量,则代表安装已完成。该状态还包含安装完成的节点的列表。

3.2.3. 使用 Web 控制台在沙盒容器中部署工作负载

OpenShift 沙盒容器将 Kata 安装为集群上的辅助、可选运行时,而不是主运行时。

要在沙盒容器中部署 pod 模板工作负载,您必须手动将 kata 作为 runtimeClassName 添加到工作负载 YAML 文件中。

先决条件

  • 在集群中安装了 OpenShift Container Platform 4.9。
  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 已安装 OpenShift 沙盒容器 Operator。
  • 您已创建了 KataConfig 自定义资源 (CR)。

流程

  1. 从 web 控制台中的 Administrator 视角,展开 Workloads 并选择您要创建的工作负载类型。
  2. 在工作负载页面中,点击以创建工作负载。
  3. 在工作负载的 YAML 文件中,在列出容器的 spec 字段中,添加 runtimeClassName: kata

    Pod 示例

        apiVersion: v1
        kind: Pod
        metadata:
          name: example
          labels:
            app: httpd
          namespace: openshift-sandboxed-containers-operator
        spec:
          runtimeClassName: kata
          containers:
            - name: httpd
              image: 'image-registry.openshift-image-registry.svc:5000/openshift/httpd:latest'
              ports:
                - containerPort: 8080

    部署示例

        apiVersion: apps/v1
        kind: Deployment
        metadata:
          name: example
          namespace: openshift-sandboxed-containers-operator
        spec:
          selector:
            matchLabels:
              app: httpd
          replicas: 3
          template:
            metadata:
              labels:
                app: httpd
            spec:
              runtimeClassName: kata
              containers:
                - name: httpd
                  image: >-
                    image-registry.openshift-image-registry.svc:5000/openshift/httpd:latest
                  ports:
                    - containerPort: 8080

  4. Save

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

3.3. 使用 CLI 部署 OpenShift 沙盒容器工作负载

您可以使用 CLI 部署 OpenShift 沙盒容器工作负载。首先,您必须安装 OpenShift 沙盒容器 Operator,然后创建 KataConfig 自定义资源。在沙盒容器中部署工作负载后,您必须将 kata 作为 runtimeClassName 添加到工作负载 YAML 文件中。

3.3.1. 使用 CLI 安装 OpenShift 沙盒容器 Operator

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

先决条件

  • 已在集群中安装了 OpenShift Container Platform 4.9。
  • 已安装 OpenShift CLI(oc)。
  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 您已订阅了 OpenShift 沙盒容器目录。

    注意

    订阅 OpenShift 沙盒容器目录为 openshift-sandboxed-containers-operator 命名空间提供了对 OpenShift 沙盒容器 Operator 的访问权限。

流程

  1. 为 OpenShift 沙盒容器 Operator 创建 Namespace 对象。

    1. 创建一个包含以下清单的 Namespace 对象 YAML 文件:

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-sandboxed-containers-operator
    2. 创建 Namespace 对象:

      $ oc create -f Namespace.yaml
  2. 为 OpenShift 沙盒容器 Operator 创建 OperatorGroup 对象。

    1. 创建一个包含以下清单的 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
    2. 创建 OperatorGroup 对象:

      $ oc create -f OperatorGroup.yaml
  3. 创建 Subscription 对象,以便为 OpenShift 沙盒容器 Operator 订阅命名空间

    1. 创建一个包含以下内容的 Subscription 对象 YAML 文件:

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: openshift-sandboxed-containers-operator
        namespace: openshift-sandboxed-containers-operator
      spec:
        channel: "preview-1.1"
        installPlanApproval: Automatic
        name: sandboxed-containers-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
        startingCSV: sandboxed-containers-operator.v1.1.0
    2. 创建 Subscription 对象:

      $ oc create -f Subscription.yaml

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

注意

以上列出的所有对象文件名都是建议。您可以使用其他名称创建对象 YAML 文件。

验证

  • 确保正确安装 Operator:

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

    输出示例

    NAME                             DISPLAY                                  VERSION  REPLACES     PHASE
    openshift-sandboxed-containers   openshift-sandboxed-containers-operator  1.1.0    1.0.2        Succeeded

3.3.2. 使用 CLI 创建 KataConfig 自定义资源

您必须创建一个 KataConfig 自定义资源 (CR)来作为 RuntimeClass 在节点上安装 kata。创建 KataConfig CR 会触发 OpenShift 沙盒容器 Operator 来执行以下操作:

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

Kata 默认安装在所有 worker 节点上。如果要在特定节点上安装 kata 作为 RuntimeClass,您可以向这些节点添加标签,然后在创建时定义 KataConfig CR 中的标签。

先决条件

  • 在集群中安装了 OpenShift Container Platform 4.9。
  • 已安装 OpenShift CLI(oc)。
  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 已安装 OpenShift 沙盒容器 Operator。

流程

  1. 使用以下清单创建 YAML 文件:

    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: cluster-kataconfig
  2. (可选)如果只在所选节点上安装 kata 作为 RuntimeClass,请创建一个包含清单中的标签的 YAML 文件:

    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: cluster-kataconfig
    spec:
      kataConfigPoolSelector:
        matchLabels:
          <label_key>: '<label_value>' 1
    1
    kataConfigPoolSelector 中的标签只支持单个值;不支持 nodeSelector 语法。
  3. 创建 KataConfig 资源:

    $ oc create -f <file name>.yaml

新的 KataConfig CR 会被创建,并开始在 worker 节点上作为 RuntimeClass 安装 kata

重要

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

验证

  • 监控安装进度:

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

    Is In Progress 的值显示为 false 后,安装就已完成。

3.3.3. 使用 CLI 在沙盒容器中部署工作负载

OpenShift 沙盒容器将 Kata 安装为集群上的辅助、可选运行时,而不是主运行时。

要在沙盒容器中部署 pod 模板工作负载,您必须将 kata 作为 runtimeClassName 添加到工作负载 YAML 文件中。

先决条件

  • 在集群中安装了 OpenShift Container Platform 4.9。
  • 已安装 OpenShift CLI(oc)。
  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 已安装 OpenShift 沙盒容器 Operator。
  • 您已创建了 KataConfig 自定义资源 (CR)。

流程

  • runtimeClassName: kata 添加到任何 pod 模板对象中:

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

Pod 对象示例

  apiVersion: v1
  kind: Pod
  metadata:
   name: mypod
  spec:
    runtimeClassName: kata

Deployment 对象示例

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: mypod
    labels:
      app: mypod
  spec:
    replicas: 3
    selector:
      matchLabels:
        app: mypod
    template:
      metadata:
        labels:
          app: mypod
      spec:
        runtimeClassName: kata
        containers:
        - name: mypod
          image: myImage

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

验证

  • 检查 pod 模板对象上的 runtimeClassName 字段。如果 runtimeClassNamekata,则工作负载在 OpenShift 沙盒容器中运行。

3.4. 其他资源

第 4 章 卸载 OpenShift 沙盒容器

4.1. 使用 Web 控制台卸载 OpenShift 沙盒容器

您可以使用 OpenShift Container Platform Web 控制台卸载 OpenShift 沙盒容器。

4.1.1. 删除 OpenShift 沙盒容器资源

要卸载 OpenShift 沙盒容器,必须首先删除 OpenShift 沙盒容器自定义资源 KataConfig。这会从集群中移除并卸载 kata 运行时及其相关资源。

先决条件

  • 已在集群中安装了 OpenShift Container Platform 4.9。
  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 您没有正在运行的、使用 kata 作为 runtimeClassName 的 pod。

    • 已安装 OpenShift CLI(oc)。
    • 已安装命令行 JSON 处理器(jq)。
    • 运行以下命令,验证您没有运行使用 kata 作为 runtimeClassName 的 pod:

      $ oc get pods -A -o json | jq -r '.items[] | select(.spec.runtimeClassName | test("kata")).metadata.name'

流程

  1. 删除所有使用 runtimeClassName 的 pod,其值为 kata
  2. 在 OpenShift Container Platform web 控制台中,从 Projects 列表中选择 openshift-sandboxed-containers
  3. 进入到 OperatorsInstalled Operators 页面。
  4. OpenShift 沙盒容器
  5. OpenShift 沙盒 containers Operator 选项卡。
  6. Operator Details 中的滚动列表,然后单击 Delete KataConfig
  7. 在确认窗口中点击 Delete

4.1.1.1. 使用 web 控制台删除命令空间

您可以使用 OpenShift Container Platform web 控制台删除一个命名空间。

先决条件

  • 已在集群中安装了 OpenShift Container Platform 4.9。
  • 您可以使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 导航至 AdministrationNamespaces
  2. 在命名空间列表中找到要删除的 openshift-sandboxed-containers-operator 命名空间。
  3. 在命名空间列表的最右侧,从 Options 菜单中选择 Delete Namespace
  4. Delete Namespace 窗格打开时,在字段中输入 openshift-sandboxed-containers-operator

    注意

    如果 Delete Namespace 选项不可用,代表您没有删除命名空间的权限。

  5. Delete

4.1.2. 删除 OpenShift 沙盒容器 Operator

您可以通过删除目录订阅并撤销对 Operator 的命名空间访问权限来删除 OpenShift 沙盒容器 Operator。

先决条件

  • 已在集群中安装了 OpenShift Container Platform 4.9。
  • 您可以使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 导航到 OperatorsOperatorHub 页面。
  2. 搜索 OpenShift sandboxed containers,然后选择 Operator。
  3. Uninstall
  4. 删除 openshift-sandboxed-containers-operator 命名空间。

4.2. 通过 CLI 卸载 Kata 运行时

您可以使用 OpenShift Container Platform 命令行界面(CLI) 卸载 OpenShift 沙盒容器。

4.2.1. 删除 OpenShift 沙盒容器资源

您可以从集群中移除和卸载 kata 运行时及其所有相关资源,如 CRI-O 配置和 RuntimeClass

先决条件

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

流程

  1. 运行以下命令来删除 KataConfig 自定义资源:

    $ oc delete kataconfig <KataConfig_CR_Name>
  2. 运行以下命令来删除 KataConfig 自定义资源定义:

    $ oc delete crd kataconfigs.kataconfiguration.openshift.io

OpenShift 沙盒容器 Operator 会删除最初为在集群中启用运行时创建的所有资源。运行上述命令后,集群将恢复到安装过程之前的状态。现在,您可以删除 openshift-sandboxed-containers-operator 命名空间。

验证

  • 要验证 KataConfig 自定义资源是否已删除,请运行以下命令:

    $ oc get kataconfig <KataConfig_CR_Name>

    输出示例

    No KataConfig instances exist

  • 要验证 KataConfig 自定义资源的定义已被删除,请运行以下命令:

    $ oc get crd kataconfigs.kataconfiguration.openshift.io

    输出示例

    Unknown CR KataConfig

4.2.2. 删除 OpenShift 沙盒容器 Operator

您可以从集群中删除 OpenShift 沙盒容器 Operator。

先决条件

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

流程

  1. 运行以下命令,从 Operator Lifecyle Manager(OLM)中删除 OpenShift 沙盒容器 Operator 订阅:

    $ oc delete subscription openshift-sandboxed-containers-subscription -n openshift-sandboxed-containers-operator
  2. 运行以下命令,将 OpenShift 沙盒容器的集群服务版本(CSV)名称设置为环境变量:

    CSV_NAME=$(oc get csv -n openshift-sandboxed-containers-operator -o=custom-columns=:metadata.name)
  3. 运行以下命令,删除 OpenShift 沙盒容器的 CSV 名称:

    $ oc delete csv ${CSV_NAME} -n openshift-sandboxed-containers-operator

第 5 章 升级 OpenShift 沙盒容器

您可以通过升级 OpenShift 沙盒容器 Operator 和 OpenShift 沙盒容器工件来升级 OpenShift 沙盒容器的组件。

5.1. 升级 OpenShift 沙盒容器 Operator

您可以使用 Operator Lifecycle Manager(OLM)手动或自动升级 OpenShift 沙盒容器 Operator。您可以在初始部署过程中选择手动或自动升级。在手动升级的情况下,Web 控制台会显示集群管理员可以安装的可用更新。

5.2. 升级 OpenShift 沙盒容器工件

OpenShift 沙盒容器工件使用 Red Hat Enterprise Linux CoreOS(RHCOS)扩展部署到集群中。

RHCOS 扩展沙盒容器包含运行 Kata 容器所需的组件,如 Kata 容器运行时、虚拟机监控程序 QEMU 和其他依赖项。当将集群升级到新版 OpenShift Container Platform 时,扩展会被升级。

第 6 章 为红帽支持收集 OpenShift 沙盒容器数据

在提交问题单时同时提供您的集群信息,可以帮助红帽支持为您进行排除故障。

您可使用 must-gather 工具来收集有关 OpenShift Container Platform 集群的诊断信息,包括虚拟机和有关 OpenShift 沙盒容器的其他数据。

为了获得快速支持,请提供 OpenShift Container Platform 和 OpenShift 沙盒容器的诊断信息。

6.1. 关于 must-gather 工具

oc adm must-gather CLI 命令可收集最有助于解决问题的集群信息,包括:

  • 资源定义
  • 服务日志

默认情况下,oc adm must-gather 命令使用默认的插件镜像,并写入 ./must-gather.local

另外,您可以使用适当的参数运行命令来收集具体信息,如以下部分所述:

  • 要收集与一个或多个特定功能相关的数据,请使用 --image 参数和镜像,如以下部分所述。

    例如:

    $ oc adm must-gather  --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v4.9.0
  • 要收集审计日志,请使用 -- /usr/bin/gather_audit_logs 参数,如以下部分所述。

    例如:

    $ oc adm must-gather -- /usr/bin/gather_audit_logs
    注意

    作为默认信息集合的一部分,不会收集审计日志来减小文件的大小。

当您运行 oc adm must-gather 时,集群的新项目中会创建一个带有随机名称的新 pod。在该 pod 上收集数据,并保存至以 must-gather.local 开头的一个新目录中。此目录在当前工作目录中创建。

例如:

NAMESPACE                      NAME                 READY   STATUS      RESTARTS      AGE
...
openshift-must-gather-5drcj    must-gather-bklx4    2/2     Running     0             72s
openshift-must-gather-5drcj    must-gather-s8sdh    2/2     Running     0             72s
...

6.2. 关于收集 OpenShift 沙盒容器数据

您可以使用 oc adm must-gather CLI 命令来收集有关集群的信息。以下功能和对象与 OpenShift 沙盒容器关联:

  • 所有属于任何 OpenShift 沙盒容器资源的命名空间及其子对象
  • 所有 OpenShift 沙盒容器自定义资源定义 (CRD)

oc adm must-gather CLI 命令收集以下组件日志:

  • QEMU 日志
  • 审计日志
  • OpenShift 沙盒容器日志
  • CRI-O 日志

只要至少有一个 pod 使用 kata 运行时运行,则这些组件日志就会被收集。

要使用 must-gather 来收集 OpenShift 沙盒容器数据,您必须指定 OpenShift 沙盒容器镜像:

--image=registry.redhat.io/openshift-sandboxed-containers-tech-preview/osc-must-gather-rhel8:1.1.0

6.3. 其他资源

法律通告

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.