在Kubernetes上扩容MySQL、Mongo数据库应选用StatefulSets还是Operators？

一、StatefulSets 与 Operators 的核心区别 #

• 定位不同：StatefulSets是Kubernetes原生的工作负载API对象，专门用于部署有状态应用，核心能力是保证Pod的稳定唯一网络标识、稳定持久存储、有序的部署/扩缩容/终止顺序，属于底层的基础编排资源。Operators是一种应用管理框架，基于自定义资源(CRD)+控制器模式实现，是把特定领域的运维逻辑封装成自动化代码，属于面向特定应用的上层运维编排方案。
• 能力边界不同：StatefulSets只负责基础的Pod编排规则，不感知上层应用的业务逻辑，比如用StatefulSet部署MySQL，它不会自动处理主从切换、数据备份、集群配置同步这些数据库专属的运维操作，这些都需要自行编写脚本或者人工处理。Operators是针对具体应用开发的，比如MySQL Operator、MongoDB Operator，已经内置了对应数据库的集群搭建、主从切换、备份恢复、配置更新、故障转移等全套运维逻辑，几乎不需要人工介入处理数据库专属的运维流程。
• 使用复杂度不同：StatefulSets上手门槛低，只要熟悉K8s原生资源就能配置，但是后续运维成本高，所有应用相关的运维逻辑都要自己实现。Operators初始部署需要安装对应的Operator实例和CRD，但是后续运维成本极低，大部分操作只要修改自定义资源(CR)的配置就能自动完成。

二、MySQL/MongoDB 结合 HPA 扩容的选型建议 #

二者不是互斥关系，而是搭配使用的上下层关系，绝大多数成熟的数据库Operator底层都是基于StatefulSets来编排数据库Pod的，不存在二选一的问题。

• 如果是测试环境、仅部署单实例数据库、无高可用要求，且已经自行实现了数据库扩缩容对应的运维脚本，可以直接用StatefulSets搭配HPA实现扩容。需要注意扩容前必须自行处理好数据同步、实例角色（比如MySQL的主从）调整的逻辑，HPA默认只会按照指标增减Pod数量，不会处理数据库层面的配置变更。
• 如果是生产环境，必须使用对应数据库的官方Operator，原因如下：
  • 数据库的扩缩容不止是增减Pod这么简单，新增的节点需要先同步全量+增量数据、加入集群、调整路由规则，缩容的节点需要先把数据迁移走、从集群中移除、对应存储清理，这些逻辑Operator都已经内置实现，不需要额外开发。
  • 目前主流的MySQL Operator、MongoDB Operator都已经原生支持对接HPA，或者本身就自带基于CPU/内存/连接数/磁盘使用率等指标的自动扩缩容能力，只要配置对应的阈值即可，不需要额外开发适配逻辑。
  • 生产环境数据库的高可用、故障转移、备份这些能力是必须的，StatefulSets本身不提供这些能力，Operator都已经内置，能大幅降低生产故障的概率。

三、实际配置的注意事项 #

• 不要直接对无StatefulSets封装的裸Pod或者Deployment部署的数据库做HPA扩容，数据库实例需要稳定的网络标识和持久化存储，Deployment无法满足这一点，会出现数据丢失、脑裂等问题。
• 用Operator对接HPA的时候，要先确认Operator支持的扩缩容指标，除了CPU、内存这些基础资源指标，建议优先选择数据库业务指标比如连接数、QPS、磁盘使用率作为扩容触发条件，更符合数据库的实际运行情况。
• 扩缩容之前一定要开启数据备份功能，避免异常情况导致的数据丢失。

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