2.2. Operator Framework 打包格式


本指南概述了 OpenShift Container Platform 中 Operator Lifecycle Manager (OLM) 所支持的 Operator 打包格式。

注意

OpenShift Container Platform 4.8 及更高版本中删除了对 Operator 的传统软件包清单格式的支持。软件包清单格式中的现有 Operator 项目可使用 Operator SDK pkgman-to-bundle 命令迁移到捆绑包格式。如需了解更多详细信息,请参阅迁移软件包清单项目以使用捆绑格式

2.2.1. 捆绑包格式

Operator 的 Bundle Format 是 Operator Framework 引入的新打包格式。为提高可伸缩性并为自行托管目录的上游用户提供更好地支持,Bundle Format 规格简化了 Operator 元数据的发布。

Operator 捆绑包代表 Operator 的单一版本。磁盘上的捆绑包清单是容器化的,并作为捆绑包镜像提供,该镜像是一个不可运行的容器镜像,其中存储了 Kubernetes 清单和 Operator 元数据。然后,使用现有容器工具(如 podmandocker)和容器 registry(如 Quay)来管理捆绑包镜像的存储和发布。

Operator 元数据可以包括:

  • 标识 Operator 的信息,如名称和版本。
  • 驱动 UI 的额外信息,例如其图标和一些示例自定义资源 (CR)。
  • 所需的和所提供的 API。
  • 相关镜像。

将清单加载到 Operator Registry 数据库中时,会验证以下要求:

  • 该捆绑包必须在注解中至少定义一个频道。
  • 每个捆绑包都只有一个集群服务版本(CSV)。
  • 如果 CSV 拥有自定义资源定义(CRD),则该 CRD 必须存在于捆绑包中。

2.2.1.1. 清单

捆绑包清单指的是一组 Kubernetes 清单,用于定义 Operator 的部署和 RBAC 模型。

捆绑包包括每个目录的一个 CSV,一般情况下,用来定义 CRD 所拥有的 API 的 CRD 位于 /manifest 目录中。

捆绑包格式布局示例

etcd
├── manifests
│   ├── etcdcluster.crd.yaml
│   └── etcdoperator.clusterserviceversion.yaml
│   └── secret.yaml
│   └── configmap.yaml
└── metadata
    └── annotations.yaml
    └── dependencies.yaml

额外支持的对象

以下对象类型也可以包括在捆绑包的 /manifests 目录中:

支持的可选对象类型

  • ClusterRole
  • ClusterRoleBinding
  • ConfigMap
  • ConsoleYamlSample
  • PodDisruptionBudget
  • PriorityClass
  • PrometheusRule
  • 角色
  • RoleBinding
  • Secret
  • 服务
  • ServiceAccount
  • ServiceMonitor
  • VerticalPodAutoscaler

当捆绑包中包含这些可选对象时,Operator Lifecycle Manager(OLM)可以从捆绑包创建对象,并随 CSV 一起管理其生命周期:

可选对象的生命周期

  • 删除 CSV 后,OLM 会删除可选对象。
  • 当 CSV 被升级时:

    • 如果可选对象的名称相同,OLM 会更新它。
    • 如果可选对象的名称在版本间有所变化,OLM 会删除并重新创建它。

2.2.1.2. 注解

捆绑包还在其 /metadata 文件夹中包含 annotations.yaml 文件。此文件定义了更高级别的聚合数据,以帮助描述有关如何将捆绑包添加到捆绑包索引中的格式和软件包信息:

annotations.yaml 示例

annotations:
  operators.operatorframework.io.bundle.mediatype.v1: "registry+v1" 1
  operators.operatorframework.io.bundle.manifests.v1: "manifests/" 2
  operators.operatorframework.io.bundle.metadata.v1: "metadata/" 3
  operators.operatorframework.io.bundle.package.v1: "test-operator" 4
  operators.operatorframework.io.bundle.channels.v1: "beta,stable" 5
  operators.operatorframework.io.bundle.channel.default.v1: "stable" 6

1
Operator 捆绑包的介质类型或格式。registry+v1 格式表示它包含 CSV 及其关联的 Kubernetes 对象。
2
镜像中的该路径指向含有 Operator 清单的目录。该标签保留给以后使用,当前默认为 manifests/manifests.v1 值表示捆绑包包含 Operator 清单。
3
镜像中的该路径指向包含捆绑包元数据文件的目录。该标签保留给以后使用,当前默认为 metadata/metadata.v1 值表示这个捆绑包包含 Operator 元数据。
4
捆绑包的软件包名称。
5
捆绑包添加到 Operator Registry 时订阅的频道列表。
6
从 registry 安装时,Operator 应该订阅到的默认频道。
注意

如果出现不匹配的情况,则以 annotations.yaml 文件为准,因为依赖这些注解的集群 Operator Registry 只能访问此文件。

2.2.1.3. 依赖项文件

Operator 的依赖项列在捆绑包的 metadata/ 目录中的 dependencies.yaml 文件中。此文件是可选的,目前仅用于指明 Operator-version 依赖项。

依赖项列表中,每个项目包含一个 type 字段,用于指定这一依赖项的类型。受支持的 Operator 依赖项有两种:

  • olm.package:此类型表示特定 Operator 版本的依赖项。依赖项信息必须包含软件包名称以及软件包的版本,格式为 semver。例如,您可以指定具体版本,如 0.5.2,也可指定一系列版本,如 >0.5.1
  • olm.gvk:使用 gvk 类型,作者可以使用 group/version/kind(GVK)信息指定依赖项,类似于 CSV 中现有 CRD 和基于 API 的使用。该路径使 Operator 作者可以合并所有依赖项、API 或显式版本,使它们处于同一位置。

在以下示例中,为 Prometheus Operator 和 etcd CRD 指定依赖项:

dependencies.yaml 文件示例

dependencies:
  - type: olm.package
    value:
      packageName: prometheus
      version: ">0.27.0"
  - type: olm.gvk
    value:
      group: etcd.database.coreos.com
      kind: EtcdCluster
      version: v1beta2

2.2.1.4. 关于 opm

opm CLI 工具由 Operator Framework 提供,用于 Operator 捆绑格式。您可以通过一个名为 index 的捆绑包列表创建和维护 Operator 目录,类似于软件存储库。其结果是一个名为 index image(索引镜像) 的容器镜像,它可以存储在容器的 registry 中,然后安装到集群中。

索引包含一个指向 Operator 清单内容的指针数据库,可通过在运行容器镜像时提供的已包含 API 进行查询。在 OpenShift Container Platform 中,Operator Lifecycle Manager(OLM)可通过在 CatalogSource 中引用索引镜像来使它作为目录一个(catalog),它会定期轮询镜像,以对集群上安装的 Operator 进行更新。

  • 有关安装 opm CLI 的步骤,请参阅 CLI 工具
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.