数据库上 K8s 架构选型

数据库上不上 K8s 没有通用标准答案，只有场景适配。 本质是一场「架构收益 vs 运维复杂度」的取舍博弈。 Kubernetes 擅长解决调度问题，不是数据问题。

快速决策矩阵

三大约束条件

约束一：团队能力

中小团队 / 无专职DBA → 不上
    有运维但缺K8s经验 → 不上
    有平台团队 + DB运维能力 → 可评估

K8s + 数据库 = 双重复杂度叠加，出问题没人排查、没人兜底，生产事故风险极高。

约束二：现有基础设施

约束三：业务需求

• 对弹性有强诉求（流量波动大、需快速扩缩容）→ 可上
• 对 IO 延迟敏感（高并发 OLTP）→ 谨慎评估
• 纯为"架构好看"统一而统一 → 不上，脱离业务需求的架构选型是过度设计

核心矛盾

存储层风险最大： 数据库依赖低延迟稳定 IO 和顺序读写。PVC + CSI + 网络存储的多层转发会直接导致 IO 抖动、读写延迟不可控、排查难度翻倍。

调度层风险最隐蔽： K8s 自动调度、Pod 驱逐对无状态应用友好，但数据库的主从复制、集群分片依赖固定节点，频繁漂移摧毁高可用。

最佳实践方案

方案一：稳定为王（80% 企业首选）

业务应用 → 全量 K8s
核心数据库 → 云 RDS / 物理机

数据面与控制面彻底分离，简单、稳定、好维护。

方案二：进阶云原生（中大型平台团队）

基于 Operator 托管数据库集群
  → 绑定本地 SSD / 高性能本地存储
  → 舍弃低效网络盘
  → 单独制定 DB SLO、监控告警、备份容灾体系

推荐 Operator：MySQL Operator、PostgreSQL Operator、Vitess（大规模）、TiDB（原生分布式）。

Operator 能封装：自动故障转移、集群拓扑管理、备份策略、生命周期管控。 只靠 StatefulSet 部署，只是把数据库"装进了容器"，没有解决任何有状态难题。

方案三：大厂极致

自研数据库平台化管控，K8s 只作为底层调度底座，不直接暴露复杂能力给业务。

关联页面