别再拿 Kubernetes 硬怼数据库了：聊聊 Stateful Workloads 的正确打开方式

大家好，我是 Echo_Wish。
一个在运维坑里反复横跳、被数据库 Pod 教做人无数次的人。

今天这个话题，其实挺“危险”的：

在 Kubernetes 上跑有状态服务（数据库、队列）到底靠不靠谱？

你要是在群里问一句，答案一定是两派极端：

• A 派：

  “不行！数据库就不该上 K8s！”

• B 派：

  “我们全上了，挺稳的。”

谁对？
说句不好听的：
👉 “都对，也都不对。”

问题从来不是 能不能跑，而是：

你是不是用对了姿势。

一、先泼盆冷水：Kubernetes 天生“讨厌状态”

咱先把话说透。

Kubernetes 的设计哲学是：

• Pod 随时可能死
• 节点随时可能没
• 调度是随机的
• 自愈靠重建

而数据库、队列是什么性格？

• 数据不能丢
• 身份不能乱
• 顺序不能错
• 恢复要可控

你发现没有？

👉 这俩在性格上是天然冲突的。

所以，硬把 VM 那套思维搬进 K8s，100% 出事故。

二、StatefulSet：不是“Deployment + PVC”这么简单

很多人第一次跑数据库，流程是这样的：

1. 写个 Deployment
2. 挂个 PVC
3. 启动成功
4. 心想：稳了

然后某天，节点挂了。

数据库 Pod 被调度到另一台机器，
你突然发现：

• 启动慢得要死
• IP 变了
• 主从炸了
• 客户端连不上

于是你开始骂：

“Kubernetes 不适合数据库！”

但其实，是你没用 StatefulSet。

1️⃣ StatefulSet 解决的不是“存储”，而是“身份”

StatefulSet 给你三样非常关键的东西：

• 稳定的 Pod 名字
• 固定的启动顺序
• 一一绑定的 PVC

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: mysql
  replicas: 3
  selector:
    matchLabels:
      app: mysql

Pod 会长这样：

mysql-0
mysql-1
mysql-2

👉 这不是好看，这是“数据库的命”。

2️⃣ 我的血泪经验

当年有个 MySQL 主从集群：

• Deployment 跑的
• Pod 名字随机
• 主节点靠环境变量指定

只要滚动升级一次，
整个集群就跟抽盲盒一样。

换成 StatefulSet 后，
世界一下就安静了。

三、存储选型：别再迷信“云厂商默认盘”

Stateful Workloads，80% 的坑都在存储上。

1️⃣ 三个现实结论

我先直接给结论：

1. 网络盘 != 万能
2. 性能瓶颈一定会出现
3. 你迟早会遇到 IO 抖动

2️⃣ 正确姿势：StorageClass 是第一等公民

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/csi
parameters:
  type: ssd
reclaimPolicy: Retain

注意这个 Retain。

👉 数据库 PVC，千万别用 Delete。

你不想哪天误删 StatefulSet，
发现数据也跟着“自愈”了。

3️⃣ 关于本地盘（Local PV）

如果你跑的是：

• Elasticsearch
• ClickHouse
• Kafka（是的，真有人这么干）

那我会认真建议你：

考虑 Local PV + Pod 反亲和。

代价是调度复杂，
好处是：性能稳定，延迟可控。

四、数据库 ≠ 数据库：别一刀切

说点很多文章不敢说的。

1️⃣ 哪些适合上 K8s？

✅ 原生支持分布式的

• Cassandra
• Elasticsearch
• ClickHouse
• TiDB
• Pulsar BookKeeper

这些系统，本身就假设：

节点会挂
网络会抖
成员会变

和 K8s 的哲学，是对齐的。

2️⃣ 哪些要慎重？

⚠️ 强主从、强一致、单写入口

• MySQL
• PostgreSQL
• Redis（非 Cluster）

不是不能跑，而是你得：

• 上 Operator
• 上成熟方案
• 接受复杂度

五、Operator：这是“成年人的玩法”

如果你还在手写脚本搞：

• 主从切换
• 扩缩容
• 备份恢复

那我真心劝你一句：

别再折磨自己了。

1️⃣ Operator 的本质

Operator =
把数据库运维经验写进控制器

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: my-cluster
spec:
  instances: 3

背后帮你做的事情包括：

• 初始化
• 健康检查
• Failover
• Rolling Upgrade

2️⃣ 我的真实感受

第一次把 MySQL 交给 Operator 后，我最大的感受是：

我终于不用 3 点起床切主了。

六、队列系统：比数据库更适合 K8s，但也别作死

Kafka、RabbitMQ、Pulsar
这些看起来很适合 K8s。

但坑也不少。

1️⃣ Kafka 的三个关键点

• StatefulSet
• 固定 Broker ID
• 外部访问别乱搞

broker.id=$(echo ${HOSTNAME##*-})

Broker ID 必须和 Pod 绑定。

2️⃣ Pulsar / RabbitMQ 的建议

• 用官方 Operator
• 别自己写启动脚本
• 集群状态交给系统管

七、我最想强调的一句话

在 Kubernetes 上跑有状态服务，本质不是“部署问题”，而是“运维模式的升级”。

如果你：

• 还想 SSH
• 还想手工修
• 还想靠经验拍脑袋

那你一定会骂 K8s。

但如果你愿意：

• 把规则写进 YAML
• 把经验交给 Operator
• 把故障当成常态

你会发现：

👉 Kubernetes 并没有你想象中那么不适合状态。

八、最后总结（很现实）

• 小规模、简单系统
  👉 不上 K8s，也完全没问题
• 多环境、多集群、标准化要求高
  👉 Stateful Workloads + K8s，是迟早的事

别迷信，也别恐惧。

技术不是信仰，是权衡。