Kubernetes中运行关系型数据库的StatefulSet能否实现水平扩缩容？

• 冗余：应用代码部署多个副本的原因是，当某个节点故障时，负载均衡器后的其他节点可以承接流量，保障服务可用。
• 负载分流：负载均衡器可以将流量分发到多个应用实例上，降低单实例压力。
• A/B测试：可以让不同节点运行不同版本的应用，对外提供服务以完成测试。
• 无中断运维：可以下线单个实例进行运维操作，其余实例保持运行，实现服务零停机。

所以我认为如果条件允许，底层支撑的数据库也应该做同样的配置。我知道很多NoSQL数据库原生更适配多实例部署，但我当前关注的是关系型数据库的相关方案。

我尝试过使用CrunchyData postgres-operator、MySQL官方Operator这类组件，但它们的文档存在问题，我没能成功搭建运行，且相关社区活跃度较低，在生产环境依赖这类组件让我十分担忧，甚至MySQL Operator的文档还明确标注了不适用于生产环境。

我看到Kubernetes原生的StatefulSet支持扩缩容，但这些文档完全没有针对数据库场景做说明。我理解多实例部署的难点在于数据库需要通过卷持久化写入磁盘，多实例场景下需要解决数据同步、流量路由的问题。

请问自行实现关系型数据库的StatefulSet水平扩缩容是否难度很高？我是否应该采用如下方案更合适：开发环境在集群中运行单副本数据库镜像以降低成本，生产环境使用云厂商托管的数据库服务比如Cloud SQL for PostgreSQL来托管扩缩容、高可用相关能力，再通过Kustomize管理不同环境的YAML配置差异？

补充：我后续找到了一款体验很好的Postgres Operator，按照官方文档操作一次就部署成功了，它是由Postgres官方维护的。

回答 #

自行实现关系型数据库基于StatefulSet的水平扩缩容难度非常高，非必要不建议中小团队自研实现。
StatefulSet本身仅提供了稳定的实例命名、持久化卷绑定、有序部署/销毁这几个基础能力，完全不涉及关系型数据库多副本运行的核心逻辑：包括主从自动选主切换、主从数据一致性校验、读写请求自动路由、扩缩容时的存量数据同步/冗余副本数据清理、故障自愈机制等，这些逻辑都需要你自行开发定制控制器、配套运维脚本实现，过程中还要踩脑裂、数据同步异常、丢数等大量生产级的坑，对团队的数据库底层能力、Kubernetes二次开发能力要求极高，投入产出比极低。

你提到的「开发环境单副本数据库+生产环境云托管数据库+Kustomize管理多环境配置」的方案是目前绝大多数业务场景下的最优选择：

• 开发环境用单副本数据库完全满足功能测试需求，不需要额外投入高可用能力的运维成本，性价比极高
• 生产环境用云厂商托管的数据库，直接复用云厂商的高可用、备份恢复、弹性扩缩容、安全运维等成熟能力，不需要自己维护数据库运维体系，出问题也有厂商技术支持兜底，稳定性远高于自行运维的数据库
• 用Kustomize管理不同环境的配置差异也非常合理，你只需要把数据库连接地址、权限凭证等字段做差异化配置，不同环境加载对应配置即可，维护成本极低

你后续找到的PostgreSQL官方维护的Operator可以作为备选方案，如果你的业务有必须在Kubernetes集群内部署数据库的强需求（比如合规要求数据不能流出集群、云托管数据库成本过高），可以在充分测试后使用，上线前一定要做足混沌测试，验证主从切换、扩缩容、故障恢复等场景下的数据一致性和服务可用性，确认符合预期后再推生产。

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