×

集群管理员和 Operator 目录维护者可以使用 OpenShift Container Platform 中的 Operator Lifecycle Manager (OLM) 创建和管理使用 bundle 格式打包的自定义目录。

Kubernetes 定期弃用某些 API,这些 API 会在后续版本中移除。因此,从使用移除该 API 的 Kubernetes 版本的 OpenShift Container Platform 版本开始,Operator 将无法使用已移除的 API。

如果您的集群使用自定义目录,请参阅 控制 Operator 与 OpenShift Container Platform 版本的兼容性,了解 Operator 作者如何更新其项目以避免工作负载问题并防止不兼容的升级。

先决条件

基于文件的目录

基于文件的目录是 Operator Lifecycle Manager (OLM) 中目录格式的最新迭代。它是基于纯文本(JSON 或 YAML)的声明性配置,是对早期 SQLite 数据库格式的改进,并且完全向后兼容。

从 OpenShift Container Platform 4.11 开始,默认的 Red Hat 提供的 Operator 目录以基于文件的目录格式发布。OpenShift Container Platform 4.6 到 4.10 的默认 Red Hat 提供的 Operator 目录以已弃用的 SQLite 数据库格式发布。

与 SQLite 数据库格式相关的 opm 子命令、标志和功能也已弃用,并将在未来的版本中移除。这些功能仍然受支持,必须用于使用已弃用的 SQLite 数据库格式的目录。

许多用于处理 SQLite 数据库格式的 opm 子命令和标志(例如 opm index prune)都不适用于基于文件的目录格式。有关使用基于文件的目录的更多信息,请参阅 Operator Framework 打包格式使用 oc-mirror 插件为断开连接的安装镜像镜像

创建基于文件的目录镜像

您可以使用 opm CLI 创建使用纯文本基于文件的目录格式(JSON 或 YAML)的目录镜像,该格式取代了已弃用的 SQLite 数据库格式。

先决条件
  • 您已安装 opm CLI。

  • 您的 podman 版本为 1.9.3+。

  • 已构建 bundle 镜像并将其推送到支持 Docker v2-2 的注册表。

步骤
  1. 初始化目录

    1. 通过运行以下命令创建目录的目录:

      $ mkdir <catalog_dir>
    2. 通过运行 opm generate dockerfile 命令生成可以构建目录镜像的 Dockerfile。

      $ opm generate dockerfile <catalog_dir> \
          -i registry.redhat.io/openshift4/ose-operator-registry-rhel9:v4.17 (1)
      1 使用 -i 标志指定官方 Red Hat 基础镜像,否则 Dockerfile 将使用默认的上游镜像。

      Dockerfile 必须与您在上一步中创建的目录目录位于同一父目录中。

      示例目录结构
      . (1)
      ├── <catalog_dir> (2)
      └── <catalog_dir>.Dockerfile (3)
      1 父目录
      2 目录目录
      3 opm generate dockerfile 命令生成的 Dockerfile
    3. 通过运行 opm init 命令使用 Operator 的包定义填充目录。

      $ opm init <operator_name> \ (1)
          --default-channel=preview \ (2)
          --description=./README.md \ (3)
          --icon=./operator-icon.svg \ (4)
          --output yaml \ (5)
          > <catalog_dir>/index.yaml (6)
      1 Operator 或包名称
      2 如果未指定,订阅默认使用的通道
      3 Operator 的 README.md 或其他文档的路径
      4 Operator 图标的路径
      5 输出格式:JSON 或 YAML
      6 创建目录配置文件的路径

      此命令在指定的目录配置文件中生成 olm.package 声明性配置块。

  2. 通过运行 opm render 命令将 bundle 添加到目录。

    $ opm render <registry>/<namespace>/<bundle_image_name>:<tag> \ (1)
        --output=yaml \
        >> <catalog_dir>/index.yaml (2)
    1 bundle 镜像的拉取规范
    2 目录配置文件的路径

    通道必须至少包含一个 bundle。

  3. 为 bundle 添加通道条目。例如,将以下示例修改为您的规范,并将其添加到您的 <catalog_dir>/index.yaml 文件中。

    示例通道条目
    ---
    schema: olm.channel
    package: <operator_name>
    name: preview
    entries:
      - name: <operator_name>.v0.1.0 (1)
    1 确保在 <operator_name> 后但在版本中的 v 前包含句点 (.)。否则,该条目将无法通过 opm validate 命令。
  4. 验证基于文件的目录

    1. 对目录目录运行 opm validate 命令。

      $ opm validate <catalog_dir>
    2. 检查错误代码是否为 0

      $ echo $?
      示例输出
      0
  5. 通过运行 podman build 命令构建目录镜像。

    $ podman build . \
        -f <catalog_dir>.Dockerfile \
        -t <registry>/<namespace>/<catalog_image_name>:<tag>
  6. 将目录镜像推送到注册表。

    1. 如果需要,通过运行 podman login 命令对目标注册表进行身份验证。

      $ podman login <registry>
    2. 通过运行 podman push 命令推送目录镜像。

      $ podman push <registry>/<namespace>/<catalog_image_name>:<tag>
其他资源

更新或筛选基于文件的目录镜像

您可以使用 opm CLI 更新或筛选使用基于文件的目录格式的目录镜像。通过提取现有目录镜像的内容,您可以根据需要修改目录,例如:

  • 添加包

  • 移除包

  • 更新现有包条目

  • 详细说明每个包、通道和 bundle 的弃用消息

然后,您可以将镜像重建为目录的更新版本。

或者,如果您已经在镜像注册表上拥有目录镜像,则可以使用 oc-mirror CLI 插件在将目录镜像镜像到目标注册表时自动从该目录镜像的更新源版本中修剪任何已移除的镜像。

有关 oc-mirror 插件和此用例的更多信息,请参阅“使用 oc-mirror 插件为断开连接的安装镜像镜像”中的“保持镜像注册表内容更新”部分,特别是“修剪镜像”小节。

先决条件
  • 您的工作站上有以下内容:

    • opm CLI。

    • podman 版本 1.9.3+。

    • 基于文件的目录镜像。

    • 最近在您的工作站上初始化的与该目录相关的目录目录结构。

      如果您没有初始化的目录目录,请创建目录并生成 Dockerfile。有关更多信息,请参阅“创建基于文件的目录镜像”步骤中的“初始化目录”步骤。

步骤
  1. 将目录镜像的内容以 YAML 格式提取到目录目录中的 index.yaml 文件中。

    $ opm render <registry>/<namespace>/<catalog_image_name>:<tag> \
        -o yaml > <catalog_dir>/index.yaml

    或者,您可以使用 -o json 标志以 JSON 格式输出。

  2. 根据您的规范修改生成的 index.yaml 文件的内容。

    在将软件包发布到目录后,假设您的某个用户已安装它。请确保目录中先前发布的所有软件包都具有到当前或更新的通道头的更新路径,以避免使安装了该版本的用户的软件包无法使用。

    • 要添加运营商,请按照“创建基于文件的目录映像”过程中的创建软件包、捆绑包和通道条目的步骤进行操作。

    • 要删除运营商,请删除与软件包相关的olm.packageolm.channelolm.bundle Blob 集。以下示例显示了必须删除以从目录中删除example-operator软件包的一组 Blob。

      已删除条目的示例
      ---
      defaultChannel: release-2.7
      icon:
        base64data: <base64_string>
        mediatype: image/svg+xml
      name: example-operator
      schema: olm.package
      ---
      entries:
      - name: example-operator.v2.7.0
        skipRange: '>=2.6.0 <2.7.0'
      - name: example-operator.v2.7.1
        replaces: example-operator.v2.7.0
        skipRange: '>=2.6.0 <2.7.1'
      - name: example-operator.v2.7.2
        replaces: example-operator.v2.7.1
        skipRange: '>=2.6.0 <2.7.2'
      - name: example-operator.v2.7.3
        replaces: example-operator.v2.7.2
        skipRange: '>=2.6.0 <2.7.3'
      - name: example-operator.v2.7.4
        replaces: example-operator.v2.7.3
        skipRange: '>=2.6.0 <2.7.4'
      name: release-2.7
      package: example-operator
      schema: olm.channel
      ---
      image: example.com/example-inc/example-operator-bundle@sha256:<digest>
      name: example-operator.v2.7.0
      package: example-operator
      properties:
      - type: olm.gvk
        value:
          group: example-group.example.io
          kind: MyObject
          version: v1alpha1
      - type: olm.gvk
        value:
          group: example-group.example.io
          kind: MyOtherObject
          version: v1beta1
      - type: olm.package
        value:
          packageName: example-operator
          version: 2.7.0
      - type: olm.bundle.object
        value:
          data: <base64_string>
      - type: olm.bundle.object
        value:
          data: <base64_string>
      relatedImages:
      - image: example.com/example-inc/example-related-image@sha256:<digest>
        name: example-related-image
      schema: olm.bundle
      ---
    • 要添加或更新运营商的弃用消息,请确保在与软件包的index.yaml文件相同的目录中存在deprecations.yaml文件。有关deprecations.yaml文件格式的信息,请参阅“olm.deprecations 模式”。

  3. 保存更改。

  4. 验证目录

    $ opm validate <catalog_dir>
  5. 重建目录

    $ podman build . \
        -f <catalog_dir>.Dockerfile \
        -t <registry>/<namespace>/<catalog_image_name>:<tag>
  6. 将更新的目录映像推送到注册表

    $ podman push <registry>/<namespace>/<catalog_image_name>:<tag>
验证
  1. 在 Web 控制台中,导航到管理集群设置配置页面中的 OperatorHub 配置资源。

  2. 添加目录源或更新现有目录源以使用更新的目录映像的拉取规范。

    有关更多信息,请参阅本节“其他资源”中的“将目录源添加到集群”。

  3. 目录源处于就绪状态后,导航到运营商OperatorHub页面,并检查所做的更改是否反映在运营商列表中。

基于 SQLite 的目录

运营商目录的 SQLite 数据库格式是一个已弃用的功能。OpenShift Container Platform 中仍然包含已弃用的功能,并且继续受支持;但是,它将在该产品的未来版本中删除,并且不推荐用于新部署。

有关 OpenShift Container Platform 中已弃用或删除的主要功能的最新列表,请参阅 OpenShift Container Platform 发行说明的已弃用和已删除的功能部分。

创建基于 SQLite 的索引映像

您可以使用opm CLI 创建基于 SQLite 数据库格式的索引映像。

先决条件
  • 您已安装 opm CLI。

  • 您的 podman 版本为 1.9.3+。

  • 已构建 bundle 镜像并将其推送到支持 Docker v2-2 的注册表。

步骤
  1. 启动新索引

    $ opm index add \
        --bundles <registry>/<namespace>/<bundle_image_name>:<tag> \(1)
        --tag <registry>/<namespace>/<index_image_name>:<tag> \(2)
        [--binary-image <registry_base_image>] (3)
    1 要添加到索引的捆绑包映像的逗号分隔列表。
    2 您希望索引映像具有的映像标签。
    3 可选:用于提供目录的替代注册表基本映像。
  2. 将索引映像推送到注册表。

    1. 如果需要,请使用目标注册表进行身份验证

      $ podman login <registry>
    2. 推送索引映像

      $ podman push <registry>/<namespace>/<index_image_name>:<tag>

更新基于 SQLite 的索引映像

在将 OperatorHub 配置为使用引用自定义索引映像的目录源后,集群管理员可以通过向索引映像添加捆绑包映像来保持集群上可用的运营商最新。

您可以使用opm index add命令更新现有的索引映像。

先决条件
  • 您已安装 opm CLI。

  • 您的 podman 版本为 1.9.3+。

  • 构建索引映像并将其推送到注册表。

  • 您有一个引用索引映像的现有目录源。

步骤
  1. 通过添加捆绑包映像来更新现有索引

    $ opm index add \
        --bundles <registry>/<namespace>/<new_bundle_image>@sha256:<digest> \(1)
        --from-index <registry>/<namespace>/<existing_index_image>:<existing_tag> \(2)
        --tag <registry>/<namespace>/<existing_index_image>:<updated_tag> \(3)
        --pull-tool podman (4)
    1 --bundles标志指定要添加到索引的其他捆绑包映像的逗号分隔列表。
    2 --from-index标志指定先前推送的索引。
    3 --tag标志指定要应用于更新的索引映像的映像标签。
    4 --pull-tool标志指定用于拉取容器映像的工具。

    其中

    <registry>

    指定注册表的 hostname,例如quay.iomirror.example.com

    <namespace>

    指定注册表的命名空间,例如ocs-devabc

    <new_bundle_image>

    指定要添加到注册表的新捆绑包映像,例如ocs-operator

    <digest>

    指定捆绑包映像的 SHA 映像 ID 或摘要,例如c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41

    <existing_index_image>

    指定先前推送的映像,例如abc-redhat-operator-index

    <existing_tag>

    指定先前推送的映像标签,例如4.17

    <updated_tag>

    指定要应用于更新的索引映像的映像标签,例如4.17.1

    示例命令
    $ opm index add \
        --bundles quay.io/ocs-dev/ocs-operator@sha256:c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41 \
        --from-index mirror.example.com/abc/abc-redhat-operator-index:4.17 \
        --tag mirror.example.com/abc/abc-redhat-operator-index:4.17.1 \
        --pull-tool podman
  2. 推送更新的索引映像

    $ podman push <registry>/<namespace>/<existing_index_image>:<updated_tag>
  3. 在运营商生命周期管理器 (OLM) 自动轮询目录源中引用的索引映像时,请验证是否已成功添加新软件包。

    $ oc get packagemanifests -n openshift-marketplace

过滤基于 SQLite 的索引映像

基于运营商捆绑包格式的索引映像是运营商目录的容器化快照。您可以过滤或 *修剪* 除指定软件包列表之外的所有索引,这将创建仅包含所需运营商的源索引副本。

先决条件
  • 您的 podman 版本为 1.9.3+。

  • 您拥有 grpcurl(第三方命令行工具)。

  • 您已安装 opm CLI。

  • 您可以访问支持 Docker v2-2 的注册表。

步骤
  1. 使用目标注册表进行身份验证。

    $ podman login <target_registry>
  2. 确定要包含在修剪的索引中的软件包列表。

    1. 在容器中运行要修剪的源索引映像。例如

      $ podman run -p50051:50051 \
          -it registry.redhat.io/redhat/redhat-operator-index:v4.17
      示例输出
      Trying to pull registry.redhat.io/redhat/redhat-operator-index:v4.17...
      Getting image source signatures
      Copying blob ae8a0c23f5b1 done
      ...
      INFO[0000] serving registry                              database=/database/index.db port=50051
    2. 在单独的终端会话中,使用grpcurl命令获取索引提供的软件包列表

      $ grpcurl -plaintext localhost:50051 api.Registry/ListPackages > packages.out
    3. 检查packages.out文件并确定要保留在修剪的索引中的此列表中的哪些软件包名称。例如

      软件包列表的示例片段
      ...
      {
        "name": "advanced-cluster-management"
      }
      ...
      {
        "name": "jaeger-product"
      }
      ...
      {
      {
        "name": "quay-operator"
      }
      ...
    4. 在执行podman run命令的终端会话中,按CtrlC停止容器进程。

  3. 运行以下命令以修剪除指定软件包之外的所有源索引

    $ opm index prune \
        -f registry.redhat.io/redhat/redhat-operator-index:v4.17 \(1)
        -p advanced-cluster-management,jaeger-product,quay-operator \(2)
        [-i registry.redhat.io/openshift4/ose-operator-registry:v4.9] \(3)
        -t <target_registry>:<port>/<namespace>/redhat-operator-index:v4.17 (4)
    1 要修剪的索引。
    2 要保留的软件包的逗号分隔列表。
    3 仅对于 IBM Power® 和 IBM Z® 映像:与目标 OpenShift Container Platform 集群主版本和次版本匹配的标签的 Operator Registry 基本映像。
    4 正在构建的新索引映像的自定义标签。
  4. 运行以下命令将新的索引映像推送到目标注册表

    $ podman push <target_registry>:<port>/<namespace>/redhat-operator-index:v4.17

    其中<namespace>是注册表上的任何现有命名空间。

目录源和 Pod 安全准入

Pod 安全准入在 OpenShift Container Platform 4.11 中引入,以确保 Pod 安全标准。使用基于 SQLite 的目录格式和在 OpenShift Container Platform 4.11 之前发布的opm CLI 工具版本构建的目录源无法在受限的 Pod 安全强制执行下运行。

在 OpenShift Container Platform 4.17 中,命名空间默认情况下不具有受限的 Pod 安全强制执行,并且默认目录源安全模式设置为legacy

计划在未来的 OpenShift Container Platform 版本中包含所有命名空间的默认受限强制执行。当发生受限强制执行时,目录源 Pod 规范的 Pod 安全上下文必须与受限 Pod 安全标准匹配。如果您的目录源映像需要不同的 Pod 安全标准,则必须显式设置命名空间的 Pod 安全准入标签。

如果您不想将基于 SQLite 的目录源 Pod 作为受限运行,则无需在 OpenShift Container Platform 4.17 中更新目录源。

但是,建议您立即采取措施以确保您的目录源在受限的 Pod 安全强制执行下运行。如果您不采取措施以确保您的目录源在受限的 Pod 安全强制执行下运行,则您的目录源可能无法在未来的 OpenShift Container Platform 版本中运行。

作为目录作者,您可以通过完成以下任一操作来启用与受限 Pod 安全强制执行的兼容性

  • 将您的目录迁移到基于文件的目录格式。

  • 使用 OpenShift Container Platform 4.11 或更高版本中发布的 opm CLI 工具版本更新您的目录镜像。

SQLite 数据库目录格式已弃用,但 Red Hat 仍支持。在未来的版本中,将不支持 SQLite 数据库格式,目录需要迁移到基于文件的目录格式。从 OpenShift Container Platform 4.11 开始,默认的 Red Hat 提供的 Operator 目录以基于文件的目录格式发布。基于文件的目录与受限 Pod 安全强制执行兼容。

如果您不想更新您的 SQLite 数据库目录镜像或将您的目录迁移到基于文件的目录格式,您可以配置您的目录以提升权限运行。

将 SQLite 数据库目录迁移到基于文件的目录格式

您可以将已弃用的 SQLite 数据库格式目录更新到基于文件的目录格式。

先决条件
  • 您拥有一个 SQLite 数据库目录源。

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

  • 您的工作站上安装了 OpenShift Container Platform 4.17 中发布的最新版本 opm CLI 工具。

步骤
  1. 通过运行以下命令将您的 SQLite 数据库目录迁移到基于文件的目录:

    $ opm migrate <registry_image> <fbc_directory>
  2. 通过运行以下命令为您的基于文件的目录生成 Dockerfile:

    $ opm generate dockerfile <fbc_directory> \
      --binary-image \
      registry.redhat.io/openshift4/ose-operator-registry:v4.17
后续步骤
  • 生成的 Dockerfile 可以构建、标记并推送到您的注册表。

重建 SQLite 数据库目录镜像

您可以使用 OpenShift Container Platform 版本中发布的最新版本 opm CLI 工具重建您的 SQLite 数据库目录镜像。

先决条件
  • 您拥有一个 SQLite 数据库目录源。

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

  • 您的工作站上安装了 OpenShift Container Platform 4.17 中发布的最新版本 opm CLI 工具。

步骤
  • 运行以下命令使用更新版本的 opm CLI 工具重建您的目录:

    $ opm index add --binary-image \
      registry.redhat.io/openshift4/ose-operator-registry:v4.17 \
      --from-index <your_registry_image> \
      --bundles "" -t \<your_registry_image>

配置目录以提升权限运行

如果您不想更新您的 SQLite 数据库目录镜像或将您的目录迁移到基于文件的目录格式,您可以执行以下操作以确保您的目录源在默认 Pod 安全强制执行更改为受限时运行:

  • 在您的目录源定义中手动将目录安全模式设置为 legacy。此操作可确保您的目录即使在默认目录安全模式更改为受限时也能使用旧版权限运行。

  • 为目录源命名空间标记基线或特权 Pod 安全强制执行。

SQLite 数据库目录格式已弃用,但 Red Hat 仍支持。在未来的版本中,将不支持 SQLite 数据库格式,目录需要迁移到基于文件的目录格式。基于文件的目录与受限 Pod 安全强制执行兼容。

先决条件
  • 您拥有一个 SQLite 数据库目录源。

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

  • 您有一个目标命名空间,该命名空间支持运行具有 baselineprivileged 提升的 Pod 安全准入标准的 Pod。

步骤
  1. 通过将 spec.grpcPodConfig.securityContextConfig 标签设置为 legacy 来编辑 CatalogSource 定义,如下例所示:

    CatalogSource 定义示例
    apiVersion: operators.coreos.com/v1alpha1
    kind: CatalogSource
    metadata:
      name: my-catsrc
      namespace: my-ns
    spec:
      sourceType: grpc
      grpcPodConfig:
        securityContextConfig: legacy
      image: my-image:latest

    在 OpenShift Container Platform 4.17 中,spec.grpcPodConfig.securityContextConfig 字段默认设置为 legacy。在未来的 OpenShift Container Platform 版本中,计划将默认设置更改为 restricted。如果您的目录无法在受限强制执行下运行,建议您手动将此字段设置为 legacy

  2. 编辑您的 <namespace>.yaml 文件,以向您的目录源命名空间添加提升的 Pod 安全准入标准,如下例所示:

    <namespace>.yaml 文件示例
    apiVersion: v1
    kind: Namespace
    metadata:
    ...
      labels:
        security.openshift.io/scc.podSecurityLabelSync: "false" (1)
        openshift.io/cluster-monitoring: "true"
        pod-security.kubernetes.io/enforce: baseline (2)
      name: "<namespace_name>"
    1 通过向命名空间添加 security.openshift.io/scc.podSecurityLabelSync=false 标签来关闭 Pod 安全标签同步。
    2 应用 Pod 安全准入 pod-security.kubernetes.io/enforce 标签。将标签设置为 baselineprivileged。除非命名空间中的其他工作负载需要 privileged 配置文件,否则请使用 baseline Pod 安全配置文件。

向集群添加目录源

向 OpenShift Container Platform 集群添加目录源可使用户发现和安装 Operator。集群管理员可以创建引用索引镜像的 CatalogSource 对象。OperatorHub 使用目录源来填充用户界面。

或者,您可以使用 Web 控制台来管理目录源。在**管理** → **集群设置** → **配置** → **OperatorHub** 页面中,单击**源**选项卡,您可以在其中创建、更新、删除、禁用和启用各个源。

先决条件
  • 您已构建并将索引镜像推送到注册表。

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

步骤
  1. 创建一个引用您的索引镜像的 CatalogSource 对象。

    1. 修改以下内容以符合您的规格,并将其保存为 catalogSource.yaml 文件:

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: my-operator-catalog
        namespace: openshift-marketplace (1)
        annotations:
          olm.catalogImageTemplate: (2)
            "<registry>/<namespace>/<index_image_name>:v{kube_major_version}.{kube_minor_version}.{kube_patch_version}"
      spec:
        sourceType: grpc
        grpcPodConfig:
          securityContextConfig: <security_mode> (3)
        image: <registry>/<namespace>/<index_image_name>:<tag> (4)
        displayName: My Operator Catalog
        publisher: <publisher_name> (5)
        updateStrategy:
          registryPoll: (6)
            interval: 30m
      1 如果您希望目录源对所有命名空间中的用户全局可用,请指定 openshift-marketplace 命名空间。否则,您可以为目录指定不同的命名空间,以便该目录仅对该命名空间可用。
      2 可选:将 olm.catalogImageTemplate 注解设置为您的索引镜像名称,并在构建镜像标签的模板时使用一个或多个 Kubernetes 集群版本变量。
      3 指定 legacyrestricted 的值。如果未设置该字段,则默认值为 legacy。在未来的 OpenShift Container Platform 版本中,计划将默认值更改为 restricted。如果您的目录无法使用 restricted 权限运行,建议您手动将此字段设置为 legacy
      4 指定您的索引镜像。如果您在镜像名称后指定标签,例如 :v4.17,则目录源 Pod 使用 Always 的镜像拉取策略,这意味着 Pod 始终在启动容器之前拉取镜像。如果您指定摘要,例如 @sha256:<id>,则镜像拉取策略为 IfNotPresent,这意味着 Pod 仅在节点上不存在镜像时才拉取镜像。
      5 指定发布目录的名称或组织名称。
      6 目录源可以自动检查新版本以保持最新。
    2. 使用该文件创建 CatalogSource 对象。

      $ oc apply -f catalogSource.yaml
  2. 验证以下资源是否已成功创建。

    1. 检查 Pod

      $ oc get pods -n openshift-marketplace
      示例输出
      NAME                                    READY   STATUS    RESTARTS  AGE
      my-operator-catalog-6njx6               1/1     Running   0         28s
      marketplace-operator-d9f549946-96sgr    1/1     Running   0         26h
    2. 检查目录源

      $ oc get catalogsource -n openshift-marketplace
      示例输出
      NAME                  DISPLAY               TYPE PUBLISHER  AGE
      my-operator-catalog   My Operator Catalog   grpc            5s
    3. 检查包清单

      $ oc get packagemanifest -n openshift-marketplace
      示例输出
      NAME                          CATALOG               AGE
      jaeger-product                My Operator Catalog   93s

您现在可以从 OpenShift Container Platform Web 控制台上的**OperatorHub** 页面安装 Operator。

从私有注册表访问 Operator 的镜像

如果由 Operator Lifecycle Manager (OLM) 管理的某些与 Operator 相关的镜像托管在经过身份验证的容器镜像注册表(也称为私有注册表)中,则 OLM 和 OperatorHub 默认情况下无法拉取这些镜像。要启用访问权限,您可以创建一个包含注册表身份验证凭据的拉取密钥。通过在目录源中引用一个或多个拉取密钥,OLM 可以处理将密钥放置在 Operator 和目录命名空间中以允许安装。

Operator 或其操作数所需的其它镜像也可能需要访问私有注册表。OLM 不会在此场景中处理将密钥放置在目标租户命名空间中,但是可以将身份验证凭据添加到全局集群拉取密钥或单个命名空间服务帐户以启用所需的访问权限。

在确定由 OLM 管理的 Operator 是否具有适当的拉取访问权限时,应考虑以下类型的镜像:

索引镜像

CatalogSource 对象可以引用索引镜像,这些镜像使用 Operator 包格式,并且是作为托管在镜像注册表中的容器镜像打包的目录源。如果索引镜像托管在私有注册表中,则可以使用密钥来启用拉取访问权限。

Bundle 镜像

Operator bundle 镜像是作为容器镜像打包的元数据和清单,代表 Operator 的唯一版本。如果目录源中引用的任何 bundle 镜像托管在一个或多个私有注册表中,则可以使用密钥来启用拉取访问权限。

Operator 和操作数镜像

如果从目录源安装的 Operator 使用私有镜像(无论是 Operator 镜像本身还是其监视的操作数镜像之一),则 Operator 将无法安装,因为部署将无法访问所需的注册表身份验证。在目录源中引用密钥并不会使 OLM 能够将密钥放置在安装操作数的目标租户命名空间中。

相反,可以将身份验证详细信息添加到openshift-config命名空间中的全局集群拉取密钥,这为集群上的所有命名空间提供访问权限。或者,如果不允许访问整个集群,则可以将拉取密钥添加到目标租户命名空间的default服务帐户。

您可以通过为注册表凭据创建密钥并将密钥与相关目录一起使用来访问私有注册表中的 Operator 镜像。

先决条件
  • 您至少有一个以下内容托管在私有注册表中:

    • 索引镜像或目录镜像。

    • Operator bundle 镜像。

    • Operator 或操作数镜像。

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

步骤
  1. 为每个所需的私有注册表创建一个密钥。

    1. 登录私有注册表以创建或更新您的注册表凭据文件。

      $ podman login <registry>:<port>

      注册表凭据文件的路径可能因用于登录注册表的容器工具而异。对于podman CLI,默认位置是${XDG_RUNTIME_DIR}/containers/auth.json。对于docker CLI,默认位置是/root/.docker/config.json

    2. 建议每个密钥只包含一个注册表的凭据,并在单独的密钥中管理多个注册表的凭据。多个密钥可以在后面的步骤中包含在CatalogSource对象中,OpenShift Container Platform 将把这些密钥合并到一个虚拟凭据文件中,以便在拉取镜像时使用。

      注册表凭据文件默认情况下可以存储多个注册表的详细信息,或者存储一个注册表中的多个存储库的详细信息。验证文件的当前内容。例如:

      存储多个注册表凭据的文件
      {
          "auths": {
              "registry.redhat.io": {
                  "auth": "FrNHNydQXdzclNqdg=="
              },
              "quay.io": {
                  "auth": "fegdsRib21iMQ=="
              },
              "https://quay.io/my-namespace/my-user/my-image": {
                  "auth": "eWfjwsDdfsa221=="
              },
              "https://quay.io/my-namespace/my-user": {
                  "auth": "feFweDdscw34rR=="
              },
              "https://quay.io/my-namespace": {
                  "auth": "frwEews4fescyq=="
              }
          }
      }

      由于此文件用于在后续步骤中创建密钥,因此请确保每个文件只存储一个注册表的详细信息。这可以通过以下两种方法之一完成:

      • 使用podman logout <registry>命令删除其他注册表的凭据,直到只剩下您想要的那个注册表。

      • 编辑您的注册表凭据文件,并将注册表详细信息分离到多个文件中。例如:

        存储一个注册表凭据的文件
        {
                "auths": {
                        "registry.redhat.io": {
                                "auth": "FrNHNydQXdzclNqdg=="
                        }
                }
        }
        存储另一个注册表凭据的文件
        {
                "auths": {
                        "quay.io": {
                                "auth": "Xd2lhdsbnRib21iMQ=="
                        }
                }
        }
    3. openshift-marketplace命名空间中创建一个包含私有注册表身份验证凭据的密钥。

      $ oc create secret generic <secret_name> \
          -n openshift-marketplace \
          --from-file=.dockerconfigjson=<path/to/registry/credentials> \
          --type=kubernetes.io/dockerconfigjson

      重复此步骤为任何其他所需的私有注册表创建附加密钥,更新--from-file标志以指定另一个注册表凭据文件路径。

  2. 创建或更新现有的CatalogSource对象以引用一个或多个密钥。

    apiVersion: operators.coreos.com/v1alpha1
    kind: CatalogSource
    metadata:
      name: my-operator-catalog
      namespace: openshift-marketplace
    spec:
      sourceType: grpc
      secrets: (1)
      - "<secret_name_1>"
      - "<secret_name_2>"
      grpcPodConfig:
        securityContextConfig: <security_mode> (2)
      image: <registry>:<port>/<namespace>/<image>:<tag>
      displayName: My Operator Catalog
      publisher: <publisher_name>
      updateStrategy:
        registryPoll:
          interval: 30m
    1 添加spec.secrets部分并指定任何所需的密钥。
    2 指定 legacyrestricted 的值。如果未设置该字段,则默认值为 legacy。在未来的 OpenShift Container Platform 版本中,计划将默认值更改为 restricted。如果您的目录无法使用 restricted 权限运行,建议您手动将此字段设置为 legacy
  3. 如果已订阅的 Operator 引用的任何 Operator 或操作数镜像需要访问私有注册表,您可以为集群中的所有命名空间或单个目标租户命名空间提供访问权限。

    • 要为集群中的所有命名空间提供访问权限,请将身份验证详细信息添加到openshift-config命名空间中的全局集群拉取密钥。

      集群资源必须适应新的全局拉取密钥,这可能会暂时限制集群的可用性。

      1. 从全局拉取密钥中提取.dockerconfigjson文件。

        $ oc extract secret/pull-secret -n openshift-config --confirm
      2. 使用您所需的私有注册表或注册表的身份验证凭据更新.dockerconfigjson文件,并将其保存为新文件。

        $ cat .dockerconfigjson | \
            jq --compact-output '.auths["<registry>:<port>/<namespace>/"] |= . + {"auth":"<token>"}' \(1)
            > new_dockerconfigjson
        1 <registry>:<port>/<namespace>替换为私有注册表详细信息,将<token>替换为您的身份验证凭据。
      3. 使用新文件更新全局拉取密钥。

        $ oc set data secret/pull-secret -n openshift-config \
            --from-file=.dockerconfigjson=new_dockerconfigjson
    • 要更新单个命名空间,请将拉取密钥添加到目标租户命名空间中需要访问权限的 Operator 的服务帐户。

      1. 重新创建您为openshift-marketplace在租户命名空间中创建的密钥。

        $ oc create secret generic <secret_name> \
            -n <tenant_namespace> \
            --from-file=.dockerconfigjson=<path/to/registry/credentials> \
            --type=kubernetes.io/dockerconfigjson
      2. 通过搜索租户命名空间来验证 Operator 的服务帐户的名称。

        $ oc get sa -n <tenant_namespace> (1)
        1 如果 Operator 安装在单个命名空间中,请搜索该命名空间。如果 Operator 为所有命名空间安装,请搜索openshift-operators命名空间。
        示例输出
        NAME            SECRETS   AGE
        builder         2         6m1s
        default         2         6m1s
        deployer        2         6m1s
        etcd-operator   2         5m18s (1)
        
        1 已安装的 etcd Operator 的服务帐户。
      3. 将密钥链接到 Operator 的服务帐户。

        $ oc secrets link <operator_sa> \
            -n <tenant_namespace> \
             <secret_name> \
            --for=pull
其他资源

禁用默认 OperatorHub 目录源

在 OpenShift Container Platform 安装期间,默认情况下会为 OperatorHub 配置从 Red Hat 和社区项目提供的 Operator 目录。作为集群管理员,您可以禁用默认目录集。

步骤
  • 通过将disableAllDefaultSources: true添加到OperatorHub对象来禁用默认目录的源。

    $ oc patch OperatorHub cluster --type json \
        -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'

或者,您可以使用 Web 控制台来管理目录源。在**管理** → **集群设置** → **配置** → **OperatorHub** 页面中,单击**源**选项卡,您可以在其中创建、更新、删除、禁用和启用各个源。

删除自定义目录

作为集群管理员,您可以通过删除相关的目录源来移除之前添加到集群的自定义 Operator 目录。

先决条件
  • 您可以作为具有 cluster-admin 角色的用户访问集群。

步骤
  1. 在 Web 控制台的**管理员**视角中,导航到**管理** → **集群设置**。

  2. 点击**配置**选项卡,然后点击**OperatorHub**。

  3. 点击**源**选项卡。

  4. 选择您要移除的目录的选项菜单 kebab,然后点击**删除 CatalogSource**。