第 3 章 由 Operator 管理的产品
Operator 必须能够使用目标 Red Hat OpenShift 版本的 Operator Lifecycle Manager (OLM)在 Red Hat OpenShift 上部署您的软件产品。
如果任何特定的硬件要求对于运行您的认证 operator 至关重要,红帽建议通过列出产品系统要求页面中的所有要求,并将其链接到 红帽生态系统目录上的产品页面来通知 您的客户。
3.1. Operator 要求
要求 | 原因 |
---|---|
Operator 捆绑包必须成功通过 Operator SDK 捆绑包验证。 红帽建议使用 SDK 来创建 Operator,以确保格式正确。 | 确保与 Operator Lifecycle Manager (OLM)正确格式和兼容性。 |
Operator 必须更新每个自定义资源(CR)的 status 字段。 | 确保用户可以确定 CR 的运行状态并确定潜在的故障。 |
Operator 捆绑包中的集群服务版本(CSV)必须包含 Required CSV 字段中指示的所有字段,以及
也可以定义其他可选注解,如以下 Kubernetes 插件:
如需有关 CSV 中所需注解、可选注解和示例用法的更多信息,请参阅 Operator 元数据注解。 | 向用户和支持机构提供有关此 Operator 管理的产品的详细信息。 |
Operator 捆绑包必须通过设置 版本范围必须包含一个或多个主动支持的 RHOCP 版本,它们处于 完全支持阶段或维护支持阶段。 所有包含在范围中的 Red Hat OpenShift 版本,但不再被支持。对这些版本的 Operator 发布将处理在 best-effort-basis 上。 版本范围可以包括 RHOCP 的未来发行版本。在这种情况下,Operator 会在该版本正式发布后被列为已认证。 | 告知用户此 Operator 支持的 Red Hat OpenShift 版本,同时确保客户可以在红帽支持的 OpenShift 环境中进行部署。 版本详情用于决定必须更新特定于版本的 Operator 目录索引。 |
Operator 不能使用在此范围内所有 Red Hat OpenShift 版本中不存在的任何 API。 | 确保目标版本中提供了使用的任何 API。 |
Operator 捆绑包中的 CSV 必须指示 Operator 拥有的所有 CRD。 | 确保正确跟踪和管理 CRD 生命周期。 |
Operator 捆绑包中的 CSV 必须使用 | 正确识别所有依赖项。 |
Operator 名称必须与社区、认证和红帽目录中已经发布的任何其他 Operator 名称不同。 | 为避免名称冲突。 |