5.6.3. 手动定义的 CSV 字段

很多 CSV 字段无法使用生成的、不属于 Operator SDK 的特殊通用清单进行填充。这些字段大多由人工编写，是一些有关 Operator 和各种自定义资源定义 (CRD) 的元数据。

Operator 作者必须直接修改其集群服务版本(CSV)YAML 文件，将个性化数据添加到以下必填字段。当检测到任何必填字段中缺少数据时，Operator SDK 在生成 CSV 时发出警告。

下表详细介绍了需要手动定义的 CSV 字段，哪些是可选的。

表 5.5. 必填

字段描述

metadata.name

该 CSV 的唯一名称。Operator 版本应包含在名称中，以保证唯一性，如 app-operator.v0.1.1。

metadata.capabilities

根据 Operator 成熟度模型划分的能力等级。选项包括 Basic Install、Seamless Upgrades、Full Lifecycle、Deep Insights 和 Auto Pilot。

spec.displayName

用于标识 Operator 的公共名称。

spec.description

有关 Operator 功能的简短描述。

spec.keywords

描述 Operator 的关键词。

spec.maintainers

维护 Operator 的个人或组织实体，含名称和电子邮件地址。

spec.provider

Operator 的供应商（通常是机构）,含 名称。

spec.labels

供 Operator 内部使用的键值对。

spec.version

Operator 的语义版本，如 0.1.1。

spec.customresourcedefinitions

Operator 使用的任何 CRD。如果 deploy/ 中存在任何 CRD YAML 文件，Operator SDK 将自动填充该字段。但 CRD 清单 spec 中没有的几个字段需要用户输入：

  • description：CRD 描述。
  • resources：CRD 利用的任何 Kubernetes 资源，如 Pod 和 StatefulSet 对象。
  • specDescriptors：用于 Operator 输入和输出的 UI 提示。

表 5.6. 选填

字段描述

spec.replaces

被该 CSV 替换的 CSV 名称。

spec.links

与被管理的 Operator 或应用程序相关的 URL（如网站和文档），各自含名称和 url。

spec.selector

Operator 可用于配对群集中资源的选择器。

spec.icon

Operator 独有的 base64 编码图标，通过 mediatype 在 base64data 字段中设置。

spec.maturity

软件在这个版本中达到的成熟度。选项包括 planning、pre-alpha、alpha、beta、stable、mature、inactive 和 deprecated。

有关以上每个字段应包含哪些数据的更多详情，请参见 CSV spec。

注意

目前需要用户干预的几个 YAML 字段可能会从 Operator 代码中解析。

其他资源

5.6.3.1. Operator 元数据注解

operator 开发人员可以在集群服务版本（CSV）的元数据中手动定义某些注解，以启用功能或在用户界面（UI）中突出功能，如 OperatorHub。

下表列出了可使用 metadata.annotations 字段手动定义的 Operator 元数据注解。

表 5.7. 注解

字段描述

alm-examples

提供自定义资源定义（CRD）模板最小配置集。兼容的 UI 会预先填充此模板，供用户进一步自定义。

operatorframework.io/initialization-resource

指定安装 Operator 时必须创建的一个所需的自定义资源。必须包含带有完整 YAML 定义的模板。

operatorframework.io/suggested-namespace

设置部署 Operator 的建议命名空间。

operators.openshift.io/infrastructure-features

Operator 支持的基础架构功能。在 web 控制台中通过 OperatorHub 发现 Operator 时，用户可以查看和过滤这些功能。有效的、区分大小写的值：

  • disconnected：Operator 支持被镜像到断开连接的目录中，包括所有依赖项，且不需要访问互联网。Operator 列出了镜像所需的所有相关镜像。
  • cnf：Operator 提供了一个 Cloud-native Network Function（CNF）Kubernetes 插件。
  • CNI：Operator 提供了一个 Container Network Interface（CNI）Kubernetes 插件。
  • CSI：Operator 提供了一个 Container Storage Interface（CSI）Kubernetes 插件。
  • FIPS：Operator 接受底层平台的 FIPS 模式，并可用于引导到 FIPS 模式的节点。
重要

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

  • proxy-aware：Operator 支持在代理后面的集群上运行。Operator 接受标准代理环境变量 HTTP_PROXY 和 HTTPS_PROXY，Operator Lifecycle Manager（OLM）在集群配置为使用代理时自动为 Operator 提供这些环境变量。传递给受管工作负载的 Operands 所需的环境变量。

operators.openshift.io/valid-subscription

用于列出使用 Operator 所需的任何特定订阅的空闲数组。例如，'["3Scale Commercial License", "Red Hat Managed Integration"]'。

operators.operatorframework.io/internal-objects

在 UI 中隐藏不用于用户操作的 CRD。

使用案例示例

Operator 支持断开连接和代理

operators.openshift.io/infrastructure-features: '["disconnected", "proxy-aware"]'

Operator 需要 OpenShift Container Platform 许可证

operators.openshift.io/valid-subscription: '["OpenShift Container Platform"]'

Operator 需要 3scale 许可证

operators.openshift.io/valid-subscription: '["3Scale Commercial License", "Red Hat Managed Integration"]'

Operator 支持断开连接和代理，且需要一个 OpenShift Container Platform 许可证

operators.openshift.io/infrastructure-features: '["disconnected", "proxy-aware"]'
operators.openshift.io/valid-subscription: '["OpenShift Container Platform"]'

其它资源