第 27 章：Operator

这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 Operator 用自定义资源和控制器把领域专家的运维知识自动化，例如部署、扩容、备份、故障切换和升级。

27.1 核心组成

Custom Resource Definition
  -> Custom Resource
  -> Controller / Operator
  -> Reconcile desired state

例如数据库 Operator 可以管理：

1. 集群拓扑；
2. 主从复制；
3. 备份；
4. 故障切换；
5. 版本升级；
6. 监控规则。

27.2 CRD 示例

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: postgresclusters.example.com
spec:
  group: example.com
  names:
    kind: PostgresCluster
    plural: postgresclusters
    singular: postgrescluster
  scope: Namespaced
  versions:
    - name: v1
      served: true
      storage: true

自定义资源：

apiVersion: example.com/v1
kind: PostgresCluster
metadata:
  name: shop-db
spec:
  replicas: 3
  version: "16"
  storage: 200Gi
  backup:
    schedule: "0 1 * * *"

27.3 Reconcile 原则

控制器会被反复调用，必须：

1. 幂等；
2. 不假设每次都成功；
3. 处理最终一致；
4. 依赖 status 而不是内存状态；
5. 避免长时间阻塞；
6. 正确处理删除和 finalizer。

27.4 开发方式

常用框架：

27.5 使用 Operator 的风险

1. 复杂度转移而非消失；
2. Operator 自身故障影响业务；
3. CRD 版本演进复杂；
4. 备份和升级路径要验证；
5. 权限往往较大；
6. 社区项目维护性不确定。

本章小结

Operator 把运维流程编码为控制循环，适合复杂有状态系统。使用前要评估成熟度、备份、升级、权限和故障场景。

思考题

1. CRD 和 CR 的关系是什么？
2. Reconcile 为什么必须幂等？
3. Operator 适合哪些工作负载？
4. Operator 权限为什么要最小化？
5. 如何验证 Operator 升级方案？