知识卡片
Operator用自定义资源把有状态应用的运维知识固化进控制器代码
内容
[[Helm模拟Linux包管理器思路却难以应对有状态应用]]留下的缺口，本质源于
有状态应用（依赖外部资源、实例间有拓扑顺序关系，如数据库/etcd/
Elasticsearch）和无状态应用的根本差异——无状态应用天生高可用（不用管
状态一致性，CAP里没有C的限制，A和P可以兼得），但多数关键基础服务恰恰
都是有状态的。Kubernetes从1.9版起提供StatefulSet：Pod按顺序创建/销毁
（前一个就绪才建下一个）、有稳定的编号网络名称（重启后不变）、有稳定
的持久化存储（重调度到别的节点，磁盘依然挂载）——但StatefulSet最多
只能做到创建/删除集群、扩缩容这些基础操作，备份恢复、创建删除索引、
调整平衡策略这些真正的运维动作它完全帮不上忙。用StatefulSet直接部署
Elasticsearch集群需要一份极其冗长的YAML，根本原因是Kubernetes完全不
知道Elasticsearch是什么，所有信息都要用户手把手教（这就是Red Hat所说
的”低级操作”）。Operator的解法是用自定义资源（CRD）把应用封装成更高
层次的资源，再把控制器模式从内置资源扩展到自定义资源——比如Elastic.co
官方Operator提供kind: Elasticsearch资源，用户只需十行YAML表达”部署
三个7.9.1版ES节点”这个意图（”高级指令”），Operator开发者写的专属控制器
就知道如何把它翻译成具体的底层操作。这比Helm/Kustomize更灵活的地方在于：
它们最终还是靠Kubernetes内置资源打交道，而Operator开发者可以用代码
实现内置资源做不到的操作（比如原地重启Pod而不必先删再建），代价是
开发门槛更高——etcd这个不算特别复杂的应用，官方Operator代码量也超过
一万行。
结构图：
flowchart LR
A[StatefulSet] -->|能做到| A1[创建/删除集群, 扩缩容, 稳定网络名与存储]
A -->|做不到| A2[备份恢复/索引管理/平衡策略调整]
B[用户十行YAML表达高级指令] --> C[Operator专属控制器]
C -->|把高级指令翻译为低级操作| D[创建/更新/管理底层资源]
C -.可实现StatefulSet做不到的能力.-> A2