Operator 模式

有些应用特别难伺候，比如数据库、消息队列。它们不只是”起个进程”，还要管备份、恢复、版本升级、故障切换。这些活儿过去靠运维手册，靠人盯着。Operator 模式就是把这套经验写进代码。

56-1 Operator 是什么

Operator 是 Kubernetes 的扩展软件，它利用定制资源（CR）来管理应用及其组件。它遵循 Kubernetes 的核心理念——控制器循环。

你可以把它理解成一个”懂业务的机器人运维”。它盯着集群里你声明的资源，不断比对”现在是什么样”和”应该是什么样”，然后动手把差距补上。

它的雏形来自 CoreOS 公司。社区里有很多现成范例，可以在 OperatorHub.io 上找到。

56-2 一个具体例子

以 etcd Operator 为例，它怎么管理 etcd 集群？核心就是三步循环：

1. 通过 Kubernetes API 观察集群当前状态。
2. 分析当前状态和期望状态的差别。
3. 调用 etcd 的管理 API 或 Kubernetes API，消除这些差别。

再比如一个”SampleDB”Operator，它的工作流是这样：

• 你提交了 SampleDB 类型的资源，声明要一个数据库。
• 控制器发现有新资源，于是创建 PVC 提供持久存储，创建 StatefulSet 跑数据库，再创建 Job 做初始化。
• 你删掉这个资源，控制器先打快照，再清理 StatefulSet 和存储卷。
• 它还会定期备份，发现版本过旧就自动升级。

56-3 用 CRD 承载领域知识

Operator = 定制资源 + 定制控制器。CRD 定义”数据库长什么样”，控制器负责”怎么把数据库跑起来并保持健康”。

部署一个 Operator，最常见的做法是把 CRD 和它的控制器一起装进集群。控制器本身通常以 Deployment 形式运行，处于控制平面之外，就像普通应用一样。

装好之后，你操作这个 Operator 的方式非常 Kubernetes 化：

kubectl get SampleDB
kubectl edit SampleDB/example-database

改完配置，Operator 会自动应用变更，并维持服务良好。你几乎不用关心背后发生了什么。

56-4 它能自动化什么

Operator 能接管的事很多：

• 按需部署应用。
• 备份和恢复应用状态。
• 处理应用代码升级，连带改数据库 schema 等配置。
• 把不支持 Kubernetes API 的服务，通过 Service 暴露出去让它被发现。
• 模拟故障测试集群韧性。
• 在分布式应用里选主，而不依赖应用内部的选举逻辑。

56-5 自己写一个 Operator

如果社区里没有你想要的 Operator，可以自己写。任何能当 Kubernetes API 客户端的语言都行，Go、Python、Rust、Java、.NET 都有对应 SDK。

最主流的两个脚手架工具：

• kubebuilder：官方风格，Go 语言，生成项目骨架、CRD、控制器代码。
• Operator Framework / operator-sdk：封装更厚，集成测试、打包、分发。

一个典型流程是：用工具初始化项目，用一条命令创建 API（同时生成 CRD 和控制器骨架），然后在 Reconciler 里写”如何把现实对齐到期望”的逻辑，最后把 Operator 部署到集群。

56-6 Operator 与周边工具

它和几个概念容易混淆，厘清一下：

• 和 StatefulSet：StatefulSet 提供稳定的网络标识、持久存储。Operator 在此基础上，还能处理备份、故障切换、版本升级等更复杂的场景。
• 和 Helm：Helm 负责”把应用装进去”，Operator 负责”让应用持续健康运行”。两者互补，Helm 装，Operator 守。
• 和 Puppet 这类静态配置工具：Puppet 配一次就完了，Operator 是实时动态维持状态。

56-7 实战建议

不要为了用 Operator 而用 Operator。一个无状态 Web 服务，Deployment 就够了，没必要上 Operator。

只有当应用有”持续运维逻辑”——数据库、缓存、消息队列、监控系统这类——Operator 的价值才凸显出来。判断标准很简单：如果应用的”正确运行”需要人来不断干预，那就值得考虑 Operator。

一句话：Operator 把运维老手的脑子，装进了控制器的循环里。