什么是K8s Operators所使用的控制器模式？

控制器模式具体定义 #

K8s 本身的原生核心组件就大量使用控制器模式，核心逻辑是通过自动状态比对、偏差修复，实现资源的声明式管理。而 Operator 本质就是针对自定义资源（CRD）实现的自定义控制器：
和原生控制器（比如 Deployment 控制器、StatefulSet 控制器）负责管理 K8s 内置资源不同，Operator 面向的是用户自定义的、对应复杂业务/有状态应用的专属资源，比如 MySQL 集群、Redis 集群这类 K8s 没有内置支持的资源，都可以通过定义 CRD + 开发对应 Operator 的方式实现自动化运维。

核心运作逻辑 #

整个控制器模式的运行是一个无限循环的调和（Reconcile）过程，核心步骤如下：

• 监听资源事件：Operator 会通过 K8s API Server 持续订阅对应自定义资源（CR）的创建、更新、删除事件，第一时间获取用户在 CR 中声明的期望状态，比如期望 MySQL 集群有3个可用节点、开启数据持久化、自动备份周期为24小时这类配置。
• 比对实际状态：拿到期望状态后，Operator 会主动拉取当前集群中对应应用的实际运行状态，比如当前仅运行2个 MySQL 节点、备份策略未配置。
• 执行偏差修复：如果实际状态和期望状态存在差异，Operator 会按照预先写死在代码里的运维逻辑自动执行调整操作，比如新增一个 MySQL 实例、自动配置备份策略，直到实际状态完全匹配期望状态。
• 持续循环校验：整个流程不会只执行一次，Operator 会持续监听状态变化，只要运行过程中出现状态偏移（比如某个 MySQL 实例意外宕机、配置被人为修改），就会立刻触发新一轮的调和流程，自动修复到符合期望的状态。

这个模式最大的价值就是把复杂应用的运维经验（比如部署顺序、升级策略、故障处理流程）固化到 Operator 代码里，用户只需要声明自己想要的最终状态即可，不需要关心底层的运维操作细节，大幅降低了复杂应用在 K8s 上的运维成本。

内容的提问来源于stack exchange，提问作者Norbix