2、Operator模式基础：Operator概念、CRD与Controller原理、Operator SDK简介、Operator生命周期管理
2.1 Operator 核心概念
Operator 是 Kubernetes 生态中用于封装运维知识、自动化管理复杂有状态应用的一种软件扩展模式。其本质是将人类运维人员对特定应用的领域知识（部署、扩缩容、备份、恢复、升级）编码为可重复执行的程序逻辑，通过 Kubernetes 原生 API 与集群交互。
核心思想：Operator = CRD（自定义资源定义）+ Controller（控制器）。CRD 定义应用期望状态的数据模型，Controller 通过调谐循环（Reconciliation Loop）持续将实际状态驱向期望状态。
| 概念 | 类比 | 说明 |
|---|---|---|
| CRD | 数据库表结构 | 定义新的资源类型（如 EtcdCluster、RedisSentinel） |
| CR 实例 | 表中的一行记录 | 用户提交的具体声明（如 3 节点 Etcd 集群） |
| Controller | 后台守护进程 | 监听 CR 变化，执行调谐逻辑 |
| 调谐循环 | 无限 for 循环 | 对比期望状态与当前状态，执行差异操作 |
2.2 CRD 与 Controller 原理
2.2.1 CRD（Custom Resource Definition）
CRD 是 Kubernetes 扩展 API 的核心机制。通过定义 CRD，用户可以创建新的资源类型，Kubernetes 会像处理原生资源（Pod、Service）一样处理这些自定义资源。
# 一个简单的 EtcdCluster CRD 示例
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: etcdclusters.operator.example.com
spec:
group: operator.example.com
names:
kind: EtcdCluster
plural: etcdclusters
singular: etcdcluster
scope: Namespaced
versions:
- name: v1
served: true
storage: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
size:
type: integer
minimum: 1
maximum: 7
version:
type: string
status:
type: object
properties:
readyReplicas:
type: integer
phase:
type: string2.2.2 Controller 调谐循环
Controller 的核心逻辑是一个无限循环，称为调谐循环（Reconciliation Loop）。每次循环执行以下步骤：
- 监听事件：通过 Informer 机制监听 CR 的创建、更新、删除事件。
- 获取期望状态：从 CR 实例的
spec字段读取用户期望的状态。 - 获取当前状态：查询集群中实际运行的资源（Pod、Service、PVC 等）。
- 对比差异：比较期望状态与当前状态，生成差异操作列表。
- 执行操作：调用 Kubernetes API 创建、更新或删除资源。
- 更新状态：将执行结果写回 CR 的
status字段。
调谐循环设计原则：Controller 必须具有幂等性，即多次执行相同输入应产生相同结果。即使调谐过程中断，重启后也能从当前状态继续，不会导致资源状态不一致。
2.3 Operator SDK 简介
Operator SDK 是 Red Hat 主导的开源框架，用于简化 Operator 的开发、测试和部署。它提供了脚手架工具、高级 API 和测试框架，让开发者专注于业务逻辑而非基础设施。
| 功能模块 | 说明 | 常用命令/组件 |
|---|---|---|
| 脚手架生成 | 自动生成项目骨架、API 类型、控制器模板 | operator-sdk init、operator-sdk create api |
| 控制器开发 | 提供 Reconciler 接口，开发者只需实现调谐逻辑 | Reconcile(ctx, req) (Result, error) |
| Webhook 支持 | 内置 Mutating 和 Validating Webhook 生成 | operator-sdk create webhook |
| 测试框架 | 提供 envtest 本地测试环境，支持集成测试 | envtest、ginkgo |
| 部署编排 | 生成 OLM（Operator Lifecycle Manager）兼容的部署包 | make bundle、operator-sdk run bundle |
SDK 版本选择：目前主流使用 Operator SDK v1.x（基于 Kubebuilder v3），支持 Go、Ansible、Helm 三种语言。Go 语言 Operator 性能最优、灵活性最高，是生产环境的首选。
# 使用 Operator SDK 创建 Go 语言 Operator 项目
# 1. 初始化项目
operator-sdk init --domain=example.com --repo=github.com/example/etcd-operator
# 2. 创建 API（CRD + Controller）
operator-sdk create api --group=operator --version=v1 --kind=EtcdCluster --resource=true --controller=true
# 3. 生成 CRD 清单
make generate
make manifests
# 4. 构建并推送镜像
make docker-build docker-push IMG=registry.example.com/etcd-operator:v1.0.0
# 5. 部署到集群
make deploy IMG=registry.example.com/etcd-operator:v1.0.02.4 Operator 生命周期管理
Operator 的生命周期管理涉及从开发、测试、部署到升级、退役的全过程。OLM（Operator Lifecycle Manager）是 Kubernetes 社区标准的管理框架。
2.4.1 生命周期阶段
- 开发阶段：使用 Operator SDK 创建项目，编写 CRD 定义和 Controller 逻辑，本地测试。
- 打包阶段：生成 OLM 兼容的 Bundle（包含 CRD、RBAC、Deployment、CSV）。
- 发布阶段：将 Bundle 推送到 OperatorHub 或私有 Catalog。
- 安装阶段：用户通过 OLM 安装 Operator，OLM 自动处理依赖和权限。
- 运行阶段：Operator 持续运行，管理 CR 实例，执行调谐循环。
- 升级阶段：通过更新 Subscription 的 channel 或 source 实现平滑升级。
- 退役阶段：删除 Subscription 和 ClusterServiceVersion，清理资源。
2.4.2 OLM 核心组件
| 组件 | 类型 | 职责 |
|---|---|---|
| CatalogSource | CR | 定义 Operator 包的来源（如 OperatorHub 索引） |
| Subscription | CR | 用户订阅某个 Operator 的某个 channel |
| ClusterServiceVersion (CSV) | CR | 描述 Operator 的元数据、部署方式、依赖关系 |
| OperatorGroup | CR | 定义 Operator 的目标命名空间范围 |
| InstallPlan | CR | 自动生成的安装计划，包含需要创建的资源列表 |
生命周期管理注意事项：
- Operator 升级时需确保 CRD 版本兼容，避免数据丢失。
- 退役 Operator 前应先删除所有 CR 实例，否则资源可能变成孤儿。
- 生产环境建议使用 OLM 管理 Operator，避免手动部署导致的版本混乱。
2.5 本章小结
- Operator 本质：CRD + Controller 的组合，将运维知识编码为可重复执行的程序。
- CRD 定义资源模型：通过 OpenAPI Schema 约束用户输入，确保数据合法性。
- Controller 执行调谐：监听 CR 变化，对比期望与当前状态，执行差异操作。
- Operator SDK 加速开发：提供脚手架、Reconciler 接口、测试框架和 OLM 集成。
- OLM 管理全生命周期：从开发、打包、发布到安装、升级、退役，标准化管理流程。