1. Operator 发布包概述

Operator 发布包是将 Operator 的代码、配置、CRD（Custom Resource Definition）、RBAC 规则、部署清单等所有运行时所需资源打包而成的可分发制品。它是 Operator 从开发环境走向生产集群的“交付载体”，也是 Operator Lifecycle Manager（OLM）等管理框架进行安装、升级、依赖解析和健康检查的基本单元。

1.1 发布包的定义与核心组成

一个标准的 Operator 发布包至少包含以下四类资源：

1.2 常见发布包格式

目前社区和生态中主流的 Operator 发布包格式有两种：Bundle 格式和 Helm Chart 格式。两者在结构、管理方式和适用场景上存在显著差异。

1.2.1 Bundle 格式（Operator 生态标准）

Bundle 是 Operator Framework 官方定义的标准化打包格式，也是 OLM 原生支持的格式。其目录结构如下：

example-operator/
├── manifests/
│   ├── example.io_examples.yaml          # CRD
│   ├── operator_rbac_role.yaml
│   ├── operator_rbac_rolebinding.yaml
│   ├── operator_deployment.yaml
│   └── operator_serviceaccount.yaml
├── metadata/
│   ├── annotations.yaml                  # 包名、版本、依赖、OCP 兼容性
│   └── dependencies.yaml                 # 依赖的 Operator 列表
├── bundle.Dockerfile                     # 构建 OLM 索引镜像的入口
└── tests/
    └── scorecard/
        └── config.yaml                   # 验证测试配置

1.2.2 Helm Chart 格式（传统 Kubernetes 应用打包）

Helm Chart 是 Kubernetes 生态中最成熟的打包格式。当 Operator 本身通过 Helm 方式实现（即 helm-operator 类型）时，发布包直接采用 Chart 结构：

example-helm-operator/
├── Chart.yaml                    # 名称、版本、依赖
├── values.yaml                   # 默认配置值
├── templates/
│   ├── crds/                     # CRD 存放目录
│   │   └── example-crd.yaml
│   ├── deployment.yaml
│   ├── rbac.yaml
│   └── _helpers.tpl
├── charts/                       # 子 Chart 依赖
└── README.md

1.3 发布包在 Operator 生命周期中的作用

发布包贯穿 Operator 从开发到退役的完整生命周期，其核心作用体现在以下四个阶段：

1. 构建与验证阶段 —— 发布包是 CI/CD 管线的输出产物，通过 operator-sdk bundle validate 或 helm lint 进行静态校验，确保结构完整、CRD 合法、RBAC 最小权限。
2. 分发与索引阶段 —— 发布包被构建为 OLM 索引镜像（Index Image）或 Helm 仓库索引，供集群内的 OLM 或 Helm 客户端发现和拉取。
3. 安装与升级阶段 —— OLM 根据发布包中的依赖声明和替换策略，自动解析依赖链、执行安装或滚动升级，避免资源冲突。
4. 运维与审计阶段 —— 发布包作为“部署快照”被归档，用于回滚、故障排查和合规审计。每次 Operator 版本变更都对应一个不可变的发布包。

1.4 发布包校验的必要性

发布包一旦进入生产环境，其质量问题将直接影响集群稳定性。常见的发布包缺陷包括：

• CRD 版本冲突 —— 新版本 CRD 删除了旧版本中仍在使用的字段，导致存量资源无法解析。
• RBAC 权限不足 —— Operator 运行时因缺少对特定资源的访问权限而崩溃。
• 依赖缺失 —— 发布包声明依赖某个 Operator，但索引中未包含该依赖。
• 镜像地址错误 —— 部署清单中的容器镜像 tag 不存在或与架构不匹配。