📚 课程目录第2章 Kubernetes Operator基础回顾

2. Kubernetes Operator 基础回顾：Operator 模式原理、CRD 与 Controller、Operator 生命周期管理

2.1 Operator 模式原理

Operator 是 Kubernetes 上打包、部署和管理复杂有状态应用的扩展机制。其核心思想是将运维专家的领域知识编码为软件，由程序自动执行原本需要人工操作的运维任务。

  核心公式： Operator = CRD（自定义资源定义）+ Controller（控制器）+ 领域知识

Operator 模式的工作原理可概括为以下闭环流程：

观察（Observe）： Controller 持续监听集群中特定 CR 实例的当前状态。
分析（Analyze）： 将当前状态与 CR 中声明的期望状态（Spec）进行对比，计算差异。
执行（Act）： 调用 Kubernetes API 或外部系统接口，执行一系列操作（如创建 Pod、配置网络、备份数据），使实际状态向期望状态收敛。

2.2 CRD 与 Controller

Operator 的两大核心组件是 CRD（Custom Resource Definition） 和 Controller。CRD 定义了新的资源类型，Controller 则负责维护该资源类型的实例状态。

2.2.1 CRD：定义你的资源

CRD 是 Kubernetes API 的扩展机制。通过声明一个 CRD 对象，你可以向集群注册一种全新的资源类型（例如 RedisCluster、Prometheus）。

以下是一个简化的 CRD 示例，定义了一个名为 RedisCluster 的自定义资源：

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: redisclusters.cache.example.com
spec:
  group: cache.example.com
  names:
    kind: RedisCluster
    plural: redisclusters
    singular: rediscluster
  scope: Namespaced
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                replicas:
                  type: integer
                  minimum: 1
                version:
                  type: string
            status:
              type: object
              properties:
                readyReplicas:
                  type: integer
                phase:
                  type: string

2.2.2 Controller：驱动状态收敛

Controller 是一个持续运行的循环（Reconciliation Loop），它通过 Informer 机制监听 CRD 实例的变化，并执行相应的业务逻辑。

关键机制： Controller 使用 Informer 监听 Kubernetes API，避免频繁轮询带来的性能开销。Informer 内部维护本地缓存，只有发生变更时才触发回调。

Controller 的核心工作流程：

步骤	动作	说明
1	注册 Informer	监听特定 CRD 的 Add/Update/Delete 事件
2	事件入队	将变更事件放入工作队列（Work Queue）
3	Worker 出队	多个 Worker 并发从队列中取出事件
4	执行调谐	调用 Reconcile 函数，对比期望状态与实际状态
5	更新状态	将调谐结果写回 CR 的 Status 字段

2.3 Operator 生命周期管理

Operator 本身也是一个运行在集群中的应用程序，其生命周期包括安装、升级、扩缩容和卸载等阶段。良好的生命周期管理是 Operator 在生产环境中稳定运行的基础。

2.3.1 安装与部署

Operator 通常通过 OLM（Operator Lifecycle Manager） 或 Helm Chart 进行部署。OLM 是 Kubernetes 社区推荐的 Operator 管理框架，提供了声明式的安装、升级和权限管理能力。

注意： 安装 Operator 时，务必关注其所需的 RBAC 权限。Operator 通常需要较高的集群权限来管理其对应的资源，权限不足会导致调谐失败。

2.3.2 升级策略

Operator 的升级需要谨慎处理，尤其是当 CRD 的 Schema 发生变化时。常见的升级策略包括：

策略	描述	适用场景
原地升级	直接更新 Operator Deployment 的镜像版本	CRD Schema 未变更，仅修复 Bug 或优化性能
滚动升级	逐步替换旧版本 Pod，保持服务不中断	Operator 为多副本部署，且无状态
蓝绿部署	同时运行新旧两套 Operator，切换流量	CRD Schema 发生重大变更，需要灰度验证

2.3.3 卸载与清理

卸载 Operator 时，需要清理其创建的所有资源，包括 CRD、CR 实例、Deployment、ServiceAccount 等。如果直接删除 CRD 而未清理 CR 实例，可能导致集群中出现孤儿资源。

最佳实践： 在卸载 Operator 前，先删除所有 CR 实例，再删除 CRD，最后删除 Operator Deployment 和相关 RBAC 资源。OLM 的 Subscription 和 ClusterServiceVersion 可以自动处理部分清理逻辑。

2.3.4 生命周期管理清单

以下清单总结了 Operator 生命周期各阶段的关键操作：

安装前： 检查集群版本兼容性、RBAC 权限、CRD 是否已存在。
安装： 使用 OLM 或 Helm 部署，确认 Operator Pod 启动成功。
运行中： 监控 Operator 日志、调谐次数、错误率；定期备份 CR 实例。
升级前： 备份 CRD 和 CR 实例；阅读升级文档，确认 Schema 兼容性。
升级： 按策略执行升级，观察调谐是否正常。
卸载： 先删除所有 CR 实例，再删除 CRD，最后删除 Operator 自身。