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

7.2. 组件和架构

7.2.1. OLM 1.0 组件概述（技术预览）

重要

OLM 1.0 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

Operator Lifecycle Manager (OLM) 1.0 包含以下组件项目：

Operator 控制器
Operator Controller 是 OLM 1.0 的核心组件，通过 API 扩展 Kubernetes，用户可以安装和管理 Operator 和扩展的生命周期。它消耗来自以下每个组件的信息。
RukPak

RukPak 是一个可插拔式解决方案，用于打包和分发云原生内容。它支持安装、更新和策略的高级策略。

RukPak 提供用于在 Kubernetes 集群上安装各种工件的内容生态系统。工件示例包括 Git 仓库、Helm chart 和 OLM 捆绑包。然后，RukPak 可以以安全的方式管理、扩展和升级这些工件，以启用强大的集群扩展。

Catalogd
Catalogd 是一个 Kubernetes 扩展，它解包基于文件的目录(FBC)内容，由容器镜像打包并提供，供集群客户端使用。作为 OLM 1.0 微服务架构的组件，用于由扩展作者打包的 Kubernetes 扩展的目录主机元数据，因此可帮助用户发现可安装的内容。

7.2.2. Operator 控制器（技术预览）

Operator Controller 是 Operator Lifecycle Manager (OLM) 1.0 的核心组件，并消耗其他 OLM 1.0 组件、RukPak 和 catalogd。它使用一个 API 扩展 Kubernetes，用户可以安装 Operator 和扩展。

重要

OLM 1.0 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

7.2.2.1. Operator API

Operator Controller 提供了一个新的 Operator API 对象，它是一个代表已安装 Operator 实例的单个资源。此 operator.operators.operatorframework.io API 通过将面向用户的 API 整合到单个对象来简化已安装的 Operator 管理。

重要

在 OLM 1.0 中，Operator 对象是集群范围的。这与早期的 OLM 版本不同，Operator 可以是命名空间范围的或集群范围的，具体取决于其相关 Subscription 和 OperatorGroup 对象的配置。

如需有关之前行为的更多信息，请参阅多租户和 Operator 共处。

Operator 对象示例

apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: <operator_name>
spec:
  packageName: <package_name>
  channel: <channel_name>
  version: <version_number>

注意

当使用 OpenShift CLI (oc) 时，由在此技术预览阶段中的 OLM 1.0 所提供的 Operator 资源需要指定完整的 <resource>.<group> 格式: operator.operators.operatorframework.io。例如： 

$ oc get operator.operators.operatorframework.io

如果您在没有 API 组的情况下只指定 Operator 资源，CLI 会为早期的 API (operator.operators.coreos.com) 返回的结果与 OLM 1.0 不相关。

其他资源

7.2.2.1.1. 指定目标版本的自定义资源(CR)示例

在 Operator Lifecycle Manager (OLM) 1.0 中，集群管理员可以在自定义资源(CR)中声明性地设置 Operator 或扩展的目标版本。

您可以通过指定以下字段来定义目标版本：

  • Channel
  • 版本号
  • 版本范围

如果您在 CR 中指定频道，OLM 1.0 会安装可在指定频道中解析的 Operator 或扩展的最新版本。当向指定的频道发布更新时，OLM 1.0 会自动更新至可以从频道解析的最新发行版本。

带有指定频道的 CR 示例

apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  channel: latest 1

1
安装可从指定频道解析的最新版本。对频道的更新会自动安装。

如果在 CR 中指定 Operator 或扩展的目标版本，OLM 1.0 将安装指定的版本。当在 CR 中指定目标版本时，OLM 1.0 在向目录发布更新时不会更改目标版本。

如果要更新集群中安装的 Operator 版本，您必须手动编辑 Operator 的 CR。指定 Operator 的目标版本将 Operator 的版本固定到指定的发行版本。

指定了目标版本的 CR 示例

apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  version: 1.11.1 1

1
指定目标版本。如果要更新安装的 Operator 或扩展版本，您必须手动将 CR 更新至所需的目标版本。

如果要为 Operator 或扩展定义可接受的版本范围，您可以使用比较字符串指定版本范围。当您指定版本范围时，OLM 1.0 会安装可由 Operator Controller 解析的 Operator 或扩展的最新版本。

指定了版本范围的 CR 示例

apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  version: >1.11.1 1

1
指定所需的版本范围大于 1.11.1 版本。如需更多信息，请参阅"支持版本范围"。

创建或更新 CR 后，运行以下命令来应用配置文件：

命令语法

$ oc apply -f <extension_name>.yaml

7.2.3. Rukpak (技术预览)

Operator Lifecycle Manager (OLM) 1.0 使用 RukPak 组件及其资源来管理云原生内容。

重要

OLM 1.0 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

7.2.3.1. 关于 RukPak

RukPak 是一个可插拔式解决方案，用于打包和分发云原生内容。它支持安装、更新和策略的高级策略。

RukPak 提供用于在 Kubernetes 集群上安装各种工件的内容生态系统。工件示例包括 Git 仓库、Helm chart 和 OLM 捆绑包。然后，RukPak 可以以安全的方式管理、扩展和升级这些工件，以启用强大的集群扩展。

在其核心上，RukPak 是一组 API 和控制器。API 打包为自定义资源定义 (CRD)，用于表达要在集群中安装的内容以及如何创建运行的内容。控制器会监视 API。

常见术语

捆绑包（Bundle）
定义要部署到集群的内容的 Kubernetes 清单集合
捆绑包镜像
在其文件系统中包含捆绑包的容器镜像
捆绑包 Git 存储库
在目录中包含捆绑包的 Git 存储库
Provisioner
在 Kubernetes 集群上安装和管理内容的控制器
捆绑包部署
生成捆绑包部署的实例

7.2.3.2. 关于置备程序

RukPak 由一系列控制器组成，称为 provisioners，后者在 Kubernetes 集群上安装和管理内容。RukPak 还提供两个主要 API：Bundle 和 BundleDeployment。这些组件协同工作，将内容整合到集群中，并安装它，并在集群中生成资源。

目前，两个置备程序被实施并捆绑到 RukPak：plain provisioner source 并解包 plain+v0 捆绑包； registry provisioner source Operator Lifecycle Manager (OLM) registry+v1 捆绑包。

每个置备程序都会被分配一个唯一 ID，它负责协调与该特定 ID匹配的 spec.provisionerClassName 字段的 Bundle 和 BundleDeployment 对象。例如，普通置备程序可以解包给定 plain+v0 捆绑包到集群中，然后实例化它，使捆绑包的内容在集群中可用。

置备程序会在 Bundle 和 BundleDeployment 资源上明确观察到引用置备程序的资源。对于给定捆绑包，置备程序会将 Bundle 资源的内容解压缩到集群中。然后，如果一个指向该捆绑包的 BundleDeployment 资源，置备程序会安装捆绑包内容，并负责管理这些资源的生命周期。

7.2.3.3. 捆绑包（Bundle）

RukPak Bundle 对象代表可供集群中的其他使用者使用的内容。就像需要拉取和解包容器镜像的内容一样，pod 才能开始使用它们，使用 Bundle 对象来引用可能需要拉取和解包的内容。因此，捆绑包是镜像概念的规范化，可用于表示任何类型的内容。

捆绑包无法自行执行；它们需要置备程序来解包并在集群中提供其内容。它们可以解包到任何任意存储介质，如挂载到 provisioner pod 目录中的 tar.gz 文件。每个 Bundle 对象都有一个关联的 spec.provisionerClassName 字段，它指示 Provisioner 对象监视和解包该特定捆绑包类型。

配置为与普通置备程序一起使用的 Bundle 对象示例

apiVersion: core.rukpak.io/v1alpha1
kind: Bundle
metadata:
  name: my-bundle
spec:
  source:
    type: image
    image:
      ref: my-bundle@sha256:xyz123
  provisionerClassName: core-rukpak-io-plain

注意

捆绑包在创建后被视为不可变。

7.2.3.3.1. 捆绑包不可变

在 API 服务器接受 Bundle 对象后，捆绑包被视为 RukPak 系统的其余部分的不可变工件。这个行为强制捆绑包代表集群中要 source 的一些唯一静态内容。用户可以放心，特定捆绑包指向特定的清单集合，在没有创建新捆绑包的情况下无法更新。对于由嵌入式 BundleTemplate 对象创建的单机捆绑包和动态捆绑包，此属性为 true。

捆绑包的不可变性由核心 RukPak webhook 强制执行。此 webhook 监视 Bundle 对象事件，并对捆绑包的任何更新，检查现有捆绑包的 spec 字段是否与建议的捆绑包中的 spec 字段相同。如果它们不相等，则 Webhook 将拒绝更新。在捆绑包的生命周期中，其他 Bundle 对象字段（如 metadata 或 status）会更新，它只是被视为不可变的 spec 字段。

应用 Bundle 对象，然后尝试更新其 spec 会失败。例如，以下示例会创建一个捆绑包： 

$ oc apply -f -<<EOF
apiVersion: core.rukpak.io/v1alpha1
kind: Bundle
metadata:
  name: combo-tag-ref
spec:
  source:
    type: git
    git:
      ref:
        tag: v0.0.2
      repository: https://github.com/operator-framework/combo
  provisionerClassName: core-rukpak-io-plain
EOF

输出示例

bundle.core.rukpak.io/combo-tag-ref created

然后，修补捆绑包以指向较新的标签会返回错误： 

$ oc patch bundle combo-tag-ref --type='merge' -p '{"spec":{"source":{"git":{"ref":{"tag":"v0.0.3"}}}}}'

输出示例

Error from server (bundle.spec is immutable): admission webhook "vbundles.core.rukpak.io" denied the request: bundle.spec is immutable

核心 RukPak 准入 Webhook 会拒绝补丁，因为捆绑包的 spec 是不可变的。推荐的修改捆绑包内容的方法是通过创建一个新的 Bundle 对象而不是原位更新。

进一步的不可变注意事项

虽然 Bundle 对象的 spec 字段不可变，但 BundleDeployment 对象仍有可能变为较新的捆绑包内容版本，而无需更改底层 spec 字段。这个非预期的行为可能会在以下情况中出现：

  1. 用户在 Bundle 对象的 spec.source 字段中设置镜像标签、Git 分支或 Git 标签。
  2. 镜像标签移到新的摘要、用户将更改推送到 Git 分支，或者用户删除并在不同的提交上重新推送 Git 标签。
  3. 用户执行一些操作，以便重新创建捆绑包解包 pod，如删除解包 pod。

如果发生这种情况，步骤 2 中的新内容会因为第 3 步而解包。捆绑包部署会检测更改，并探测到新版本的内容。

这与 pod 的行为类似，其中一个 pod 的容器镜像使用标签，标签将移到不同的摘要中，然后在将来将现有 pod 重新调度到其他节点上。此时，节点会将新镜像拉取到新摘要中，并在没有用户明确要求的情况下运行不同的镜像。

为了确定底层 Bundle spec 内容没有改变，请在创建捆绑包时使用基于摘要的镜像或 Git 提交引用。

7.2.3.3.2. 普通捆绑包规格

RukPak 中的普通捆绑包是给定目录中静态、任意的 Kubernetes YAML 清单的集合。

当前实施的普通捆绑包格式是 plain+v0 格式。捆绑包格式的名称 (plain+v0) 组合了捆绑包类型 (plain) 和当前模式版本 (v0)。

注意

plain+v0 捆绑包格式是 schema 版本 v0，这意味着它可能会在以后有所变化。

例如，下面显示了 plain+v0 捆绑包中的文件树。它必须具有一个 manifests/ 目录，其中包含部署应用程序所需的 Kubernetes 资源。

plain+v0 捆绑包文件树示例

$ tree manifests

manifests
├── namespace.yaml
├── service_account.yaml
├── cluster_role.yaml
├── cluster_role_binding.yaml
└── deployment.yaml

静态清单必须位于 manifests/ 目录中，其中至少包含一个资源，以便捆绑包是置备程序可以解包的有效 plain+v0 捆绑包。manifests/ 目录还必须是扁平的；所有清单都必须位于顶层，且无子目录。

重要

不要在不是静态清单的普通捆绑包的 manifests/ 目录中包含任何内容。否则，从该捆绑包创建内容时会出现错误。任何不能使用 oc apply 命令应用的文件将导致错误。多对象 YAML 或 JSON 文件也有效。

7.2.3.3.3. registry 捆绑包规格

registry 捆绑包或 registry+v1 捆绑包包含一组以旧 Operator Lifecycle Manager (OLM) 捆绑包格式组织的静态 Kubernetes YAML 清单。

其他资源

7.2.3.4. BundleDeployment

警告

BundleDeployment 对象通过安装和删除对象来更改 Kubernetes 集群的状态。务必要验证并信任正在安装和限制访问权限的内容，方法是使用 RBAC 到 BundleDeployment API 到需要这些权限的用户。

RukPak BundleDeployment API 指向 Bundle 对象，并表明它应当处于活动状态。这包括从活跃捆绑包的旧版本获取。BundleDeployment 对象可能还包括所需捆绑包的嵌入式 spec。

与 pod 生成容器镜像实例一样，捆绑包部署会生成捆绑包部署的版本。捆绑包部署可被视为 pod 概念的一般化。

捆绑包部署如何根据引用的捆绑包对集群进行更改，具体由配置为监视该捆绑包部署的置备程序定义。

配置为与普通置备程序一起工作的 BundleDeployment 对象示例

apiVersion: core.rukpak.io/v1alpha1
kind: BundleDeployment
metadata:
  name: my-bundle-deployment
spec:
  provisionerClassName: core-rukpak-io-plain
  template:
    metadata:
      labels:
        app: my-bundle
    spec:
      source:
        type: image
        image:
          ref: my-bundle@sha256:xyz123
      provisionerClassName: core-rukpak-io-plain

7.2.4. OLM 1.0 中的依赖项解析（技术预览）

Operator Lifecycle Manager (OLM) 1.0 使用依赖项管理器来解析 RukPak 捆绑包目录的限制。

重要

OLM 1.0 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

7.2.4.1. 概念

用户有一组预期，软件包管理器不应执行以下操作：

  • 安装无法实现依赖关系或与另一个软件包依赖项冲突的软件包
  • 安装其约束无法被当前可安装软件包满足的软件包
  • 更新软件包会导致破坏依赖它的另一个软件包
7.2.4.1.1. 示例：成功解析

用户想要安装具有以下依赖关系的软件包 A 和 B：

软件包 A v0.1.0

软件包 B latest

↓ (依赖于)

↓ (依赖于)

软件包 C v0.1.0

软件包 D latest

此外，用户希望将 A 的版本固定到 v0.1.0。

传递给 OLM 1.0 的软件包和限制

软件包

  • A
  • B

约束（constraint）

  • v0.1.0 依赖于 C v0.1.0
  • A 固定到 v0.1.0
  • B 依赖于 D

输出

  • 解决方案集：

    • A v0.1.0
    • B latest
    • C v0.1.0
    • D latest
7.2.4.1.2. 示例：不成功的解析

用户想要安装具有以下依赖关系的软件包 A 和 B：

软件包 A v0.1.0

软件包 B latest

↓ (依赖于)

↓ (依赖于)

软件包 C v0.1.0

软件包 C v0.1.0

此外，用户希望将 A 的版本固定到 v0.1.0。

传递给 OLM 1.0 的软件包和限制

软件包

  • A
  • B

约束（constraint）

  • v0.1.0 依赖于 C v0.1.0
  • A 固定到 v0.1.0
  • v0.1.0 依赖于 C v0.1.0

输出

  • 解决方案集：

    • 无法解决，因为 A v0.1.0 需要 C v0.1.0，这与 B latest 需要 C v0.2.0 相冲突

7.2.5. Catalogd （技术预览）

Operator Lifecycle Manager (OLM) 1.0 使用 catalogd 组件及其资源来管理 Operator 和扩展目录。

重要

OLM 1.0 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

7.2.5.1. 关于 OLM 1.0 中的目录

您可以使用 catalogd 组件查询 Kubernetes 扩展的目录，如 Operator 和控制器，从而发现可安装的内容。Catalogd 是一个 Kubernetes 扩展，为集群客户端解包目录内容，并是微服务的 Operator Lifecycle Manager (OLM) 1.0 套件的一部分。目前，catalogd 解包要打包并分发为容器镜像的目录内容。

重要

如果您尝试安装没有唯一名称的 Operator 或扩展，则安装可能会失败，或者导致无法预计的结果。这是因为以下原因：

  • 如果在集群中安装了 mulitple 目录，OLM 1.0 不包括在安装 Operator 或扩展时指定目录的机制。
  • Operator Lifecycle Manager (OLM) 1.0 中的依赖项解析需要集群中用于安装的所有 Operator 和扩展都使用其捆绑包和软件包的唯一名称。

其他资源

7.2.5.1.1. OLM 1.0 中红帽提供的 Operator 目录

Operator Lifecycle Manager (OLM) 1.0 默认不包括红帽提供的 Operator 目录。如果要在集群中添加红帽提供的目录，请为目录创建一个自定义资源 (CR)，并将其应用到集群。以下自定义资源 (CR) 示例演示了如何为 OLM 1.0 创建目录资源。

重要

如果要使用托管在安全 registry 上的目录，如来自 registry.redhat.io 的红帽提供的 Operator 目录，则必须有一个范围到 openshift-catalogd 命名空间的 pull secret。如需更多信息，请参阅"为在安全 registry 上托管的目录创建 pull secret"。

Red Hat Operator 目录示例

apiVersion: catalogd.operatorframework.io/v1alpha1
kind: Catalog
metadata:
  name: redhat-operators
spec:
  source:
    type: image
    image:
      ref: registry.redhat.io/redhat/redhat-operator-index:v4.15
      pullSecret: <pull_secret_name>
      pollInterval: <poll_interval_duration> 1

1
指定轮询远程 registry 以获取较新的镜像摘要的时间间隔。默认值为 24h。有效单位包括秒 (s)、分钟 (m) 和小时 (h)。要禁用轮询，请设置零值，如 0s。

认证的 Operator 目录示例

apiVersion: catalogd.operatorframework.io/v1alpha1
kind: Catalog
metadata:
  name: certified-operators
spec:
  source:
    type: image
    image:
      ref: registry.redhat.io/redhat/certified-operator-index:v4.15
      pullSecret: <pull_secret_name>
      pollInterval: 24h

Community Operators 目录示例

apiVersion: catalogd.operatorframework.io/v1alpha1
kind: Catalog
metadata:
  name: community-operators
spec:
  source:
    type: image
    image:
      ref: registry.redhat.io/redhat/community-operator-index:v4.15
      pullSecret: <pull_secret_name>
      pollInterval: 24h

以下命令在集群中添加目录：

命令语法

$ oc apply -f <catalog_name>.yaml 1

1
指定目录 CR，如 redhat-operators.yaml。

其他资源

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.