企业官网建设流程全解析

• 云原生
• 后端
• 开发工具
• 微服务

导读

Operator 是部署在 Kubernetes 集群上的自定义控制器，其生命周期管理能力存在明显的成熟度差异。Operator Framework 社区以"Operator 能力等级模型"（Operator Capability Levels）定义了从 Level 1（Basic Install）到 Level 5（Auto Pilot）的五级能力阶梯，用于统一描述用户可以从一个 Operator 中获得的特性。本文以 Operator SDK 仓库官方文档为核心，系统讲解每一能力等级的定义、能力清单、自检引导问题，并结合仓库源码（CSV 生成、relatedImages 收集、scorecard 描述符校验等实现）说明如何在实际项目中验证和落地这些能力，帮助你在设计、实现与打包 Operator 时形成清晰的可度量目标。

核心概念与术语

在讨论能力等级之前，先明确文档使用的四组核心术语，它们贯穿全文所有等级的描述：

• Operator：安装在 Kubernetes 集群上的自定义控制器，承载领域运维知识。
• Operand：由 Operator 以服务形式提供并管理的受管工作负载。
• Custom Resource（CR）：Operator 提供的CustomResourceDefinition的一个实例，它代表 Operand 本身或对 Operand 的一次操作，也被称为主资源（primary resources）。
• Managed resources：Operator 用来构成 Operand 的 Kubernetes 对象或集群外服务，也被称为次级资源（secondary resources）。
• Custom Resource Definition（CRD）：Operator 的 API，为 CR 提供蓝图与校验规则。

能力等级从 1 到 5 依次递进，每一级代表一组独立的管理特性。不管理任何工作负载、或将工作委托给集群外编排服务的 Operator 停留在 Level 1 之下（通常认为仍属于 Level 1 范畴）。

Level 1 - Basic Install：自动化安装与配置

Level 1 是最基础的能力等级，核心要求是：Operator 能够通过 CR 完整地供给一个应用，并将所有安装配置细节收口到 CR 中。Operator 本身也应支持多种安装方式（kubectl、OLM、Catalog source）。凡是让 Operand 运行所必需的配置，都应当尽量通过 CR 表达，避免要求用户脱离 Kubernetes 去手工维护配置文件。

工作负载的安装

该等级下 Operator 应具备以下行为：

• Operator 部署 Operand 或配置集群外资源；
• Operator 等待受管资源达到健康状态；
• Operator 借助 CR 的status块向用户传达应用或受管资源的就绪状态。

示例：一个数据库 Operator 通过创建Deployment、ServiceAccount、RoleBinding、ConfigMap、PersistentVolumeClaim和Secret来部署数据库，初始化空数据库 schema，并在数据库可以接受查询时通过状态块对外发出就绪信号。

工作负载的配置

• Operator 通过 CR 的spec区段提供配置；
• Operator 对配置及其变更进行调谐（reconcile），并与受管资源的状态保持同步。

示例：管理数据库的 Operator 在用户修改数据库 CR 实例后，通过调整底层PersistentVolumeClaim的容量来实现数据库扩容。

Level 1 自检引导问题

1. 哪些安装配置可以在 CR 中设置？
2. 还有哪些安装配置可以补充加入 CR？
3. 能否在 CR 中设置 Operand 配置？如果可以，每个 Operand 支持哪些配置？
4. 能否通过 CR 或 Operator 部署的环境变量覆盖 Operand 镜像？
5. 当 CR 配置变化时，受管应用/工作负载是否以非破坏性方式更新？
6. CR 的status是否反映配置变更当前已被应用？
7. 还有哪些 Operand 配置可以补充？
8. 所有实例化的 CR 是否都包含status块？如果是，它是否给用户提供了足够的应用状态洞察？
9. 所有 CR 是否都有列出合法取值与必填字段的文档？
10. 如果 Operator 以 OLM 方式打包，其 CSV 是否在spec.relatedImages下列出了 CSV 中使用的全部镜像？

源码佐证：CSV 中的 capabilities 注解与 relatedImages

Operator SDK 在生成 ClusterServiceVersion（CSV）基础文件时，会直接写入metadata.annotations.capabilities注解。在 internal/generate/clusterserviceversion/bases/clusterserviceversion.go 中可以看到，当用户未显式指定时，默认值即为"Basic Install"（Level 1），并在 newBase 中写入注解：

if b.Capabilities == "" { b.Capabilities = "Basic Install" } ... Annotations: map[string]string{ "capabilities": b.Capabilities, "alm-examples": "[]", },

也就是说，使用operator-sdk generate kustomize manifests等命令生成的 CSV 基座默认声明 Level 1 能力，开发者应根据实际实现手动提升该注解的取值。关于该注解的合法取值，可参见 website/content/en/docs/olm-integration/generation.md，其中明确metadata.annotations.capabilities表示"Operator 能力等级"，并链接到本文所依据的成熟度模型文档。

针对自检问题 10 的spec.relatedImages，SDK 提供了自动化收集实现：FindRelatedImages（见 internal/cmd/operator-sdk/generate/internal/relatedimages.go）会扫描控制器管理器的环境变量，收集 Operator 使用的全部镜像，并通过名称与镜像引用去重后生成RelatedImage列表，避免 CSV 中镜像信息遗漏或重复。

Level 2 - Seamless Upgrades：无缝升级

无缝升级意味着升级对用户尽可能无感。Operator 与 Operand 的升级通常相辅相成：Operator 升级后，应自动让每个 CR 实例化的资源进入新的期望状态，从而完成 Operand 升级。升级可以有多种定义方式，例如更新 Operand 软件、以及应用特有的内部变更（如 schema 迁移）。文档强调：升级发生时，什么会被升级、什么不会被升级，必须非常清晰。

受管工作负载的升级

• Operand 可以在升级 Operator 的过程中被升级；
• Operand 也可以作为 CR 变更的一部分被升级；
• Operator 需要理解如何升级旧版本 Operand——即先前由旧版本 Operator 管理的版本。

Operator 的升级

• Operator 可以被无缝升级，且能够继续管理旧版本 Operand 或将它们更新到新版本；
• 当 Operator 无法管理某个不受支持的 Operand 版本时，必须在 CR 的status区段中传达这一事实。

示例：管理数据库的 Operator 可以在不丢失数据的前提下，把现有数据库从旧版本更新到新版本——无论是作为配置变更的一部分，还是作为 Operator 自身升级的一部分。

Level 2 自检引导问题

1. 你的 Operator 能否升级 Operand？
2. 你的 Operator 是否在自身升级过程中同步升级 Operand？
3. 你的 Operator 能否管理旧版本的 Operand？
4. Operand 升级是否无中断？
5. 如果升级期间存在停机，Operator 是否在 CR 的status中传达这一点？

从实现角度看，Level 2 要求 Operator 把"旧版本兼容"编码进调谐逻辑：例如 Helm 类 Operator 依靠 watches.yaml 定义的版本映射与升级规则来驱动 release 升级，而 Go 类 Operator 则需要通过版本化 API（如v1alpha1、v1alpha2）与转换逻辑来管理多版本 CR。

Level 3 - Full Lifecycle：完整生命周期

Level 3 要求 Operator 自身提供备份与恢复能力，除触发这些操作外无需任何额外人工干预。需要备份的是 Operand 管理的所有有状态数据；CR 本身及 Operator 创建的 Kubernetes 资源无需备份——因为只要重新创建 CR，Operator 就应该把所有资源恢复到相同状态。此外，若 Operator 尚未为 Operand 配置 Kubernetes 韧性最佳实践，应在该等级补齐，包括：存活探针（liveness probes）、就绪探针（readiness probes）、多副本、滚动部署策略、PodDisruptionBudget、CPU 与内存的 requests/limits。

生命周期特性

• Operator 提供创建 Operand 备份的能力；
• Operator 能够从备份恢复 Operand；
• Operator 编排 Operand 上的复杂重配置流程；
• Operator 实现集群化 Operand 的故障切换（fail-over）与故障恢复（fail-back）；
• Operator 支持向集群化 Operand 添加/移除成员；
• Operator 支持应用感知的 Operand 伸缩。

示例：管理数据库的 Operator 通过刷新数据库日志并暂停对数据库文件的写活动，创建应用一致性备份。

Level 3 自检引导问题

1. 你的 Operator 是否支持备份 Operand？
2. 你的 Operator 是否支持从备份恢复 Operand 并重新纳入管理？
3. 你的 Operator 是否等待重配置工作按预期顺序完成？
4. 如果存在集群仲裁（cluster quorum），你的 Operator 是否将其纳入考量？
5. 你的 Operator 是否允许添加/移除 Operand 的只读从实例？
6. Operand 是否有存活探针？
7. Operand 是否有就绪探针？该探针在 Operand 任何方面未就绪时（例如数据库连接失败）是否会失败？
8. Operand 是否使用滚动部署策略？
9. 你的 Operator 是否为 Operand Pod 创建 PodDisruptionBudget 资源？
10. Operand 是否设置了 CPU requests 和 limits？

Level 4 - Deep Insights：深度洞察

Level 4 要求为 Operand 建立完整的监控与告警体系。当 Operand CR 被实例化时，Prometheus 规则（告警）和 Grafana 仪表盘等所有资源都应由 Operator 自动创建。RED 方法是决定暴露哪些指标的良好起点：

• Rate：每秒请求数；
• Errors：这些请求中失败的数量；
• Duration：这些请求所花费的时间。

告警设计上应遵循"症状优先"原则：只对与终端用户痛苦相关的症状告警，而非穷举一切可能引发痛苦的方式，告警数量越少越好；告警应链接到相关控制台，便于快速定位故障组件。原生 Kubernetes 对象会为需要提醒用户或管理员的场景发出 Events 事件对象，Operator 也应针对 Operand 相关的状态变化发出类似事件——这里的"自定义"指在部署方式本身已发出的事件之外，额外发出 Operator/Operand 特有的事件。这与 CR 条件的状态描述符（status descriptors）结合，能极大提升 Operator/Operand 行动的可见性：Operator 本质上是编码化的领域知识，最终用户不应为了看清资源现状而被迫掌握这些领域知识。事件与状态的处理应遵循 Kubernetes API 约定（Events 与 Spec/Status 相关章节）。

监控

• Operator 暴露关于自身健康状况的指标；
• Operator 暴露 Operand 的健康与性能指标。

告警与事件

• Operand 发出有用的告警；
• CR 发出自定义事件。

示例：数据库 Operator 持续解析数据库软件的日志输出，理解值得关注的日志事件（例如数据库文件磁盘空间耗尽）并产生告警；同时为数据库插桩，暴露应用级指标（例如每秒数据库查询数）。

Level 4 自检引导问题

1. 你的 Operator 是否暴露健康指标端点？
2. 你的 Operator 是否暴露 Operand 告警？
3. 每个告警是否有对应的标准操作流程（SOP）？
4. 你的 Operator 是否在服务宕机时产生严重告警，并对其他情况产生警告级告警？
5. 你的 Operator 是否监视 Operand 以创建告警？
6. 你的 Operator 是否发出自定义 Kubernetes 事件？
7. 你的 Operator 是否暴露 Operand 性能指标？

源码佐证：默认指标与描述符校验

文档特别指出：使用 Operator SDK（或 Kubebuilder）CLI 构建的项目天然基于 controller-runtime，而 controller-runtime 会默认导出一组参考指标（controller_runtime_reconcile_total、workqueue 深度、rest_client 请求速率等），可直接接入 Prometheus；关于如何启用监控与添加自定义指标，以及基于默认指标创建 Grafana 仪表盘的 JSON 清单，可参考仓库内 website/content/en/docs/best-practices/observability-best-practices.md 与 SDK 生成的监控配置（如 testdata/go/v4/monitoring/memcached-operator/config/prometheus/monitor.yaml 及其 metrics_service.yaml）。

在"状态可见性"方面，SDK 的 scorecard 提供了专门校验：SpecDescriptorsTest与StatusDescriptorsTest（见 internal/scorecard/tests/olm.go）分别验证 CSV 中所有spec字段与所有 CRD 是否都配置了对应描述符，测试名称为olm-spec-descriptors与olm-status-descriptors。这意味着 Level 4 所要求的"status 洞察 + 描述符可见性"在 SDK 工具链中是可自动验证的硬性检查项，而非仅停留在文档建议层面。

Level 5 - Auto Pilot：自动驾驶

最高能力等级的目标是显著减少乃至消除 Operand 管理中剩余的人工干预：Operator 应随负载上升自动伸缩 Operand，理解应用级性能指标并判断其健康与运行状态，主动修复不健康的 Operand，并调优 Operand 性能（例如把 Pod 调度到其他节点，或修改 Operand 配置）。

自动伸缩（Auto-scaling）

• Operator 基于 Operand 指标在负载上升时向上扩容；
• Operator 基于 Operand 指标在负载低于阈值时向下缩容。

自动修复（Auto-Healing）

• Operator 能基于 Operand 指标/告警/日志自动修复不健康的 Operand；
• Operator 能基于 Operand 指标阻止 Operand 进入不健康状态。

自动调优（Auto-tuning）

• Operator 能针对特定工作负载模式自动调优 Operand；
• Operator 能把工作负载动态迁移到最合适的节点。

异常检测（Abnormality detection）

• Operator 能判断偏离标准性能画像的情况。

示例：数据库 Operator 监控数据库查询负载，自动伸缩额外的只读从副本；检测到索引性能欠佳时，在低负载时段自动重建索引；理解数据库的正常性能画像，对大量慢查询产生告警；当慢查询与高磁盘延迟同时出现时，自动把数据库文件迁移到更高性能等级的另一个PersistentVolume上。

Level 5 自检引导问题

1. 你的 Operator 能否读取每秒请求数等相关指标，并水平或垂直自动伸缩（即增加 Pod 数量或 Pod 资源用量）？
2. 基于问题 1，它能否缩减 Pod 数量或 Pod 占用的资源总量？
3. 基于 Level 4 建立的深度洞察，你的 Operator 能否判断 Operand 何时变得不健康，并采取行动（重新部署、修改配置、恢复备份等）？
4. 同样借助 Level 4 的深度洞察，你的 Operator 能否动态学习性能基线并找到最佳配置，从而调整配置以达到该状态？
5. 它能否把工作负载迁移到更优的节点、存储或网络？
6. 当任何东西低于已学习的性能基线且无法自动纠正时，它能否检测并告警？

能力等级在 Operator SDK 工具链中的落地实践

综合前文，能力等级模型不仅是设计理念，也已经渗透到 SDK 的代码生成与校验流程中，建议按以下路径在项目里逐项落实：

1. 声明能力等级：在 CSV 基座的metadata.annotations.capabilities注解中按实际实现填写（默认生成值为Basic Install，见 internal/generate/clusterserviceversion/bases/clusterserviceversion.go）；CSV 其他字段的填写规范可参考 website/content/en/docs/olm-integration/generation.md。
2. 补齐镜像清单：使用generate bundle/generate packagemanifests时，SDK 通过 relatedimages.go 自动从控制器环境变量收集镜像，确保 CSV 的spec.relatedImages完整（对应 Level 1 自检问题 10）。
3. 用 scorecard 自动校验：运行operator-sdk scorecard时，olm-spec-descriptors、olm-status-descriptors（internal/scorecard/tests/olm.go）等测试会检查 CSV/CRD 描述符完整性，这正是 Level 4 可见性要求的自动化体现；相关测试断言可参见 internal/scorecard/tests/bundle_test.go。
4. 以引导问题为验收清单：将五个等级共 38 道引导问题转化为迭代验收项，配合 testdata/go/v4/memcached-operator 这类示例项目（其中 memcached-operator.clusterserviceversion.yaml 展示了包含capabilities注解与relatedImages的真实 CSV）逐级提升。

结语

Operator 能力等级模型为"我的 Operator 做到了什么程度"提供了可沟通、可度量、可验收的统一语言：Level 1 解决"能不能自动装好"，Level 2 解决"能不能平滑升级"，Level 3 解决"数据与生命周期是否完整"，Level 4 解决"状态是否可见可告警"，Level 5 则追求"全自动的自我管理与自我优化"。结合 Operator SDK 的 CSV 生成默认值、relatedImages 自动收集与 scorecard 描述符校验等源码级能力，你可以把每一级的要求转化为具体的实现与验证动作，稳步把一个基础安装型 Operator 打磨成具备完整生命周期与深度洞察的高能力 Operator。

• 云原生
• 后端
• 开发工具
• 微服务