2. Kubernetes Operator 基础回顾：Operator 模式原理、CRD 与 Controller 工作机制、Operator 生命周期管理
在深入 OPA 校验多集群 Operator 发布合规之前，必须牢固掌握 Operator 模式的核心原理。本章将系统回顾 Operator 的三大支柱：模式原理、CRD 与 Controller 工作机制、以及 Operator 生命周期管理。这些知识是后续章节中编写 OPA 策略、拦截不合规 Operator 的基础。
2.1 Operator 模式原理
Operator 是 Kubernetes 上打包、部署和管理复杂有状态应用的扩展机制。其本质是将运维人员的领域知识编码为软件，通过控制循环自动执行运维任务。
核心思想： Operator = CRD（自定义资源定义）+ Controller（控制器）。CRD 定义期望状态，Controller 持续观察当前状态并驱动其向期望状态收敛。
Operator 模式解决了传统 Helm Chart 或静态 YAML 无法处理的有状态应用生命周期管理问题，例如数据库扩缩容、备份恢复、版本升级等。
2.2 CRD 与 Controller 工作机制
2.2.1 CRD（Custom Resource Definition）
CRD 是 Kubernetes 的扩展机制，允许用户定义新的资源类型。CRD 本身是一个 API 资源，注册后即可像原生资源（如 Pod、Deployment）一样通过 kubectl 操作。
| 概念 | 说明 | 示例 |
|---|---|---|
| CRD 定义 | 声明新资源类型的 Schema（结构、验证规则） | kind: CustomResourceDefinition |
| CR 实例 | 按 CRD 定义创建的具体资源对象 | kind: MyApp |
| OpenAPI v3 Schema | CRD 中用于字段校验、默认值、子资源的规范 | spec.versions[0].schema.openAPIV3Schema |
| 版本管理 | 支持多个 API 版本共存，通过 Conversion Webhook 转换 | v1alpha1 → v1 |
最佳实践： CRD 的 Schema 应尽可能严格，包括必填字段、枚举值、最小值/最大值等。这可以在 API 入口层拦截大量错误配置，减轻 Controller 的校验负担。
2.2.2 Controller 工作机制
Controller 是 Operator 的“大脑”，其核心是一个控制循环（Reconciliation Loop）。典型的 Controller 工作流程如下：
- Watch（监听）： 通过 Informer 监听 CR 实例及关联资源的变化事件（Add/Update/Delete）。
- Reconcile（调谐）： 将事件放入工作队列，Worker 从队列取出并执行调谐逻辑。
- Compare（对比）： 读取 CR 中的期望状态，查询集群中的实际状态。
- Act（执行）： 创建、更新或删除资源，使实际状态向期望状态收敛。
- Update Status（更新状态）： 将操作结果写回 CR 的
status字段。
2.3 Operator 生命周期管理
Operator 本身也是一个需要管理的应用。其生命周期包括安装、升级、配置、监控、备份、卸载等阶段。在 OPA 合规场景中，我们尤其关注安装和升级阶段的策略校验。
2.3.1 安装方式对比
| 安装方式 | 工具/机制 | 适用场景 | OPA 校验介入点 |
|---|---|---|---|
| Helm Chart | Helm v3 | 通用 Operator 分发 | Chart 渲染后的 YAML 清单 |
| OLM (Operator Lifecycle Manager) | OperatorHub, CatalogSource | 企业级 Operator 市场 | Subscription / InstallPlan 资源 |
| 手动 YAML | kubectl apply | 开发测试环境 | Admission Webhook 拦截 |
2.3.2 升级策略
Operator 升级涉及 CRD 版本变更、Controller 镜像更新、以及存量 CR 实例的迁移。常见的升级策略包括：
- 替换升级（Recreate）： 删除旧 Pod，创建新 Pod。简单但会导致服务中断。
- 滚动升级（Rolling Update）： 逐步替换 Pod，保持服务可用。适用于无状态 Operator。
- 蓝绿部署（Blue-Green）： 同时运行新旧两套 Operator，切换流量。适用于关键业务。
合规风险提示： Operator 升级时，CRD 的 Schema 变更可能导致存量 CR 实例校验失败。OPA 策略应检查升级后的 CRD 是否向后兼容，以及是否影响现有资源。
2.3.3 生命周期状态机
一个标准的 Operator 生命周期状态机包含以下关键状态：
- Pending： Operator 资源已提交，但尚未开始安装。
- Installing： 正在创建 Deployment、ServiceAccount、RBAC 等资源。
- Succeeded： Operator 所有组件运行正常，Ready 副本数满足要求。
- Failed： 安装或运行过程中出现不可恢复的错误。
- Upgrading： 正在执行版本升级流程。
- Deleting： 正在清理 Operator 及其管理的资源。
在 OPA 策略中，我们可以针对 Installing 和 Upgrading 状态设置准入控制，确保只有通过合规校验的 Operator 才能进入运行状态。
关键总结： Operator 模式的核心是“声明式 API + 控制循环”。CRD 定义了“是什么”，Controller 实现了“怎么做”。生命周期管理则确保 Operator 自身的安全、可靠和可升级。在后续章节中，我们将利用 OPA 策略引擎，在 Operator 安装和升级的关键节点注入合规校验，实现多集群的统一治理。