数据库 Operator：把有状态中间件做成平台能力

为什么有状态中间件难#

无状态应用没有「身份」和「历史」，任何副本都能随时杀掉换台机器重来。数据库恰好相反：它有一块必须活下来的数据，还有「谁是主、谁是从」这种只存在于内存和复制关系里的状态。照搬 Deployment 的写法，几乎一定会出事。

有状态中间件比无状态应用多出六类动作，每一类都不是「重启一下」能解决的。

这些动作在传统运维里是一份人的手册：出问题按步骤敲命令。手册的问题很明显——只存在于人的脑子里，凌晨三点没人执行，执行到一半被打断也没人知道。

Operator 要做的事只有一句：把这份手册变成一段永远在运行、永远不会忘记下一步的代码。

Operator：把运维手册变成控制器#

Operator 不是新概念，它就是第 2 章里那个「控制器」模式，加上扩展 API 的能力。

• CRD（CustomResourceDefinition）：注册你自己的资源类型，比如 Cluster、FoundationDBCluster。它让「一套三副本 Redis 主从、10Gi 存储、版本 7.2.4」变成 etcd 里一条可以 kubectl get 的对象。
• 控制器：常驻进程，watch 这些对象并执行 reconcile（协调）循环：读期望 → 读现实 → 动手让两者靠近 → 再读一次。
• 状态机：控制器内部维护「现在处于哪个阶段」——创建中、运行中、切换中、升级中。它知道这一步没做完不能做下一步，这正是手册里最难自动化的部分。

一句话说清它和 Helm 的差别：

Helm 装完就走，Operator 持续纠偏。 Helm 的产物是一堆被创建出来的对象，Operator 的产物是一个一直在盯着这些对象、并会自己动手修的进程。

这张图是本章后面所有内容的空间感来源：

 用户/应用 ──▶ Service（读写端点，选主后指向主库）
                     │
 Operator ─watch──▶ Cluster CR（期望：引擎/版本/副本数/存储）
    │                │ 创建 / 提升 / 迁移
    └───────▶ 副本组：redis-0(主) redis-1(从) redis-2(从)
               或 TiKV 的一个 Raft 组（Leader + Follower × 3）
                     │ 挂载
      PVC（每副本一块独立卷）──▶ StorageClass ──▶ CSI ──▶ 真实存储

最后两层的细节在生产存储，本章只关心 Operator 那层怎么把上面几层串起来。

KubeBlocks：一个平台管多种数据库#

如果每个引擎都配一套自己的 Operator（Redis 一套、MySQL 一套、MongoDB 一套），平台团队最终要维护七八个互不相关的控制器，升级节奏、监控口径、备份方式全都不一样。KubeBlocks 的定位就是把这层统一起来：它自己是一个通用 Operator 框架，具体引擎通过「引擎定义」插进来，对上层只暴露一套 Cluster API。

早期版本（0.8/0.9 系）以 ClusterDefinition + ClusterVersion 为主，新版本逐步转向 ComponentDefinition + ComponentVersion，所以装完第一件事是确认你手里的 CRD 是哪一套：

kubectl get crd | grep kubeblocks
kubectl explain cluster.spec | head -30
# 安装用官方 Helm 仓库，命名空间固定 kb-system；下面清单按 0.9 系写，可加 --version 对齐
helm repo add kubeblocks https://apecloud.github.io/helm-charts
helm repo update
helm install kubeblocks kubeblocks/kubeblocks --namespace kb-system --create-namespace
kubectl -n kb-system get pods && kubectl get componentdefinition | grep -E 'redis|mysql'

kb-system 里的 Pod 全部 Running，并且 componentdefinition（旧版本看 clusterdefinition）里能看到 redis，就说明 Operator 与引擎定义都就绪了。缺引擎就用 kbcli addon list 检查（kbcli 从 apecloud/kbcli 的 release 页获取；新版本改用 Helm chart 安装引擎，以官方文档为准）。

动手：用 KubeBlocks 跑一套 Redis 主从#

apiVersion: apps.kubeblocks.io/v1alpha1
kind: Cluster
metadata: {name: demo, namespace: demo}
spec:
  clusterDefinitionRef: redis
  clusterVersionRef: redis-7.2.4
  terminationPolicy: Delete
  componentSpecs:
    - name: redis
      componentDefRef: redis
      replicas: 3
      resources:
        requests: {cpu: 200m, memory: 512Mi}
        limits: {memory: 1Gi}
      volumeClaimTemplates:
        - name: data
          spec: {accessModes: [ReadWriteOnce], storageClassName: local-path, resources: {requests: {storage: 10Gi}}}
    - name: redis-sentinel
      componentDefRef: redis-sentinel
      replicas: 3
      resources:
        requests: {cpu: 100m, memory: 256Mi}
        limits: {memory: 512Mi}
      volumeClaimTemplates:
        - name: data
          spec: {accessModes: [ReadWriteOnce], storageClassName: local-path, resources: {requests: {storage: 5Gi}}}

kubectl create namespace demo
kubectl apply -f redis-cluster.yaml
kubectl -n demo get cluster
kubectl -n demo get pods -l app.kubernetes.io/instance=demo -o wide
kubectl -n demo get secret | grep conn-credential
kubectl -n demo exec -it demo-redis-0 -- redis-cli ping
kubectl -n demo exec -it demo-redis-0 -- redis-cli info replication | head -5

kbcli cluster hscale demo --components redis --replicas 5 --namespace demo
kubectl -n demo edit cluster demo   # 或直接改 componentSpecs 里 redis 的 replicas
kubectl -n demo delete cluster demo

验证成功的三个特征：kubectl -n demo get cluster 的 STATUS 是 Running；demo-redis-0/1/2 与 demo-redis-sentinel-0/1/2 全部 Running；redis-cli ping 返回 PONG，info replication 里能看到一个 role:master 和两个 role:slave。日常运维动作都是这种形态，先记命令骨架，参数细节用 kbcli cluster <子命令> --help 确认（备份与恢复要单独配仓库，见下文「运维细节」）：

# 垂直扩缩容：改 CPU / 内存配额，会滚动重启组件
kbcli cluster vscale demo --components redis --cpu 1 --memory 2Gi --namespace demo
# 扩容数据盘（前提是 StorageClass 允许扩容）
kbcli cluster volume-expand demo --components redis \
  --volume-claim-templates data --storage 20Gi --namespace demo
# 升级引擎版本（版本名先 kbcli clusterversion list | grep redis 查）
kbcli cluster upgrade demo --cluster-version redis-7.2.4 --namespace demo

Redis 的两种形态：单实例与哨兵/集群#

Redis 最容易被「随手一上」，因为它看起来无状态。但它默认把数据放在内存里，Pod 重建而没挂 PVC，数据就全没了。所以先想清楚要哪种形态。

形态一：单实例 Deployment + PVC。 够用、简单、成本最低。三个关键点：数据目录必须挂 PVC、滚动策略必须是 Recreate（RWO 卷不能同时被两个节点挂载）、持久化要打开。再配一个指向 app: redis 的 Service（写法见第 7 章 Service）就能被业务访问。

apiVersion: apps/v1
kind: Deployment
metadata: {name: redis, namespace: demo}
spec:
  replicas: 1
  strategy: {type: Recreate}
  selector: {matchLabels: {app: redis}}
  template:
    metadata:
      labels: {app: redis}
    spec:
      containers:
        - name: redis
          image: redis:7.4
          args: ["redis-server", "--appendonly", "yes", "--save", "60", "1", "--maxmemory", "800mb"]
          ports: [{name: redis, containerPort: 6379}]
          resources:
            requests: {cpu: 200m, memory: 1Gi}
            limits: {memory: 1Gi}
          volumeMounts:
            - {name: data, mountPath: /data}
      volumes:
        - {name: data, persistentVolumeClaim: {claimName: redis-data}}
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata: {name: redis-data, namespace: demo}
spec:
  accessModes: [ReadWriteOnce]
  storageClassName: local-path
  resources: {requests: {storage: 10Gi}}

持久化参数决定「重启后还剩多少数据」：--save 60 1 是 RDB 快照（文件小、恢复快，但两次快照之间宕机会丢数据），--appendonly yes 是 AOF 日志（丢数据窗口小，代价是磁盘 IO 与体积），--appendfsync everysec 是 AOF 的刷盘频率（默认每秒，最多丢 1 秒）。`--maxmemory` 必须明显小于容器 memory limit，否则会被 OOMKilled。RDB 和 AOF 文件都写在 /data 下，所以它们和 PVC 是一件事的两面：/data 不落 PVC，持久化配置再全也没意义。用 kubectl -n demo exec redis -- ls /data 应该能看到 appendonly.aof 或 dump.rdb。

形态二：主从 + 哨兵，或 Redis Cluster。 什么时候才需要多副本？三个信号：数据不能丢且要求自动故障切换、单机内存或 QPS 到顶、要按容量横向扩展。反过来，如果只是页面缓存、丢了能重建，单实例加备份就是正确选择——多一套哨兵只是多一份排障成本。主从加哨兵能自动选主，但容量不扩展、写入仍只能打主库；Redis Cluster 用分片解决容量与写入扩展，代价是多 key 操作跨 slot 受限、客户端必须支持，最少 3 主 3 从。

在 Kubernetes 上落地，要么用专用 Redis Operator（如 spotahome/redis-operator 的 RedisFailover，或 OT-CONTAINER-KIT/redis-operator），要么直接用 KubeBlocks 的 redis 加 redis-sentinel 组件。判据是：已经用 KubeBlocks 管其它数据库，就不要再为 Redis 单独引入一套 Operator。

故障切换演练：别等真出事才第一次切#

主从加哨兵的方案，没演练过就等于没有高可用。KubeBlocks 部署的集群里哨兵名与集群名一致，可以手动触发一次切换：先确认当前拓扑，把目标从库的优先级调高（数值越小越优先，默认 100），再让哨兵发起故障转移。

# 让 demo-redis-1 更可能被选为新主（replica-priority 越小越优先，默认 100）
kubectl -n demo exec -it demo-redis-1 -- redis-cli -a "$REDIS_DEFAULT_PASSWORD" config set replica-priority 10
# 主动触发一次故障转移，观察业务是否无感
kubectl -n demo exec -it demo-redis-sentinel-0 -- redis-cli -a "$SENTINEL_PASSWORD" -p 26379 SENTINEL FAILOVER demo
# 验证角色真的换了
kubectl -n demo exec -it demo-redis-0 -- redis-cli -a "$REDIS_DEFAULT_PASSWORD" info replication | head -3

info replication 里 role:master 从 demo-redis-0 挪到 demo-redis-1 就说明切换成功。生产上必须演练的理由有两条：Redis 主从是异步复制，切换瞬间最后一次未同步的写会丢，这个窗口只能在演练里量出来并告知业务；应用必须连读写 Service 而不是具体 Pod 名或 Pod IP，否则切完请求还打在旧主上。备份侧用 redis-cli BGSAVE 生成 RDB，再把 /data 下的 dump.rdb 与 appendonly.aof 转存到对象存储——卷快照只能整体回滚，逻辑备份才能跨版本、跨云恢复。

参考：reference/k8s-in-action/db/kubeblocks/kbcli-0.9.3/day-3-redis.md

TiKV 与 FoundationDB：分布式 KV 什么时候值得#

当单机内存装不下、又需要强一致时，才轮到分布式 KV。这类系统比单机 Redis 复杂一个量级，因为「数据」和「谁是主」都不再是单个节点的事。

TiKV：Raft + PD 调度。 TiKV 的定位是分布式事务 KV 存储，典型形态是 PD + TiKV（再加 TiDB 就是 HTAP 数据库，也可以只当 KV 用）。PD（Placement Driver）是集群的大脑，存元数据、做调度与负载均衡，自身用 Raft 仲裁，3 节点起步；TiKV 是真正存数据的节点，数据切成若干 Region，每个 Region 用 Raft 复制到多个 TiKV 节点，副本数 3 起步；TiDB 是可选的 SQL 层。

它比单机 Redis 复杂在「副本数」有两个不同含义：PD 的 3 是控制面高可用（保证大脑不脑裂），TiKV 的 3 是数据副本数（保证机器挂了数据不丢）。一句话记住扩容逻辑：水平扩展靠加 TiKV 节点，然后由 PD 把 Region 重新分片搬过去。 所以扩容不是「改个数字就完事」，要等数据搬迁完成；缩容更谨慎——必须先把 store 标记为待下线，等 Region 全部迁走再移除节点（TiUP 的 store delete 加 prune 就是这两步）。

在 Kubernetes 上通常由 TiDB Operator 或 KubeBlocks 管理。TiDB Operator 用 Helm 安装，再用 TidbCluster 声明集群（版本号按最新 release 替换）：

helm repo add pingcap https://charts.pingcap.org/
helm repo update
helm install tidb-operator pingcap/tidb-operator --namespace tidb-admin --create-namespace
kubectl -n tidb-admin get pods

TidbCluster 的关键结构是三个组件各自的 replicas 与存储——spec.pd（replicas: 3、storageClassName、requests.storage）、spec.tikv（同样三项，存储要给足）、spec.tidb（无状态 SQL 层，2 副本起）。字段名随 TiDB Operator 版本变化，写之前用 kubectl explain tidbcluster.spec.tikv 确认；验证看 kubectl -n demo get pods 里 tikv-demo-tikv-0/1/2 与 tikv-demo-pd-0/1/2 全部 Running。

FoundationDB：分布式事务 KV。 它更偏「给别人当元数据底座」——JuiceFS、3FS 这类分布式文件系统常拿它存元数据。它同样由 Operator 管理，安装走 kustomize（版本号按最新 release 替换）：

kubectl apply -k "https://github.com/FoundationDB/fdb-kubernetes-operator/config/default?ref=v2.10.0"
kubectl -n fdb-system get pods

FoundationDBCluster（apps.foundationdb.org/v1beta2）有四个必须想清楚的注意点：集群文件（cluster file） 是客户端找到集群坐标的依据，它不是「连接串」而是集群的身份，Operator 会写进 Secret / ConfigMap，业务挂载时必须用集群里那一份；存储引擎（如 ssd-2）在数据库配置里指定，选错会影响性能与升级路径；副本数 / 冗余模式用冗余模式表达，double 大致对应三副本，要与节点数和故障域匹配；故障域默认按 kubernetes.io/hostname 分散进程，节点数少于副本数时无法真正分散，等于白配。关键字段是 spec.version、spec.faultDomain.key、spec.processCounts（如 storage: 3、stateless: -1）与 spec.processes.general.volumeClaimTemplate；冗余模式与存储引擎在 databaseConfiguration 里，字段名随版本变化，用 kubectl explain foundationdbcluster.spec 核对。验证时找一个名字带 log 或 storage 的 Pod 执行 kubectl -n fdb-system exec -it fdb-demo-log-1 -- fdbcli --exec "status minimal"，看到 The database is available 才算真的起来了。

选型决策表：不是所有数据库都值得搬进 Kubernetes#

前面讲的都是「能这么做」，但更重要的一句是：不是所有数据库都值得搬进 Kubernetes。搬进来的收益是标准化、自助化、可复现；代价是你得自己承担存储性能、备份恢复、版本升级与故障演练。团队里没有能兜住这些事的人，自建就只是把风险从「云厂商的 SLO」搬到了「你的值班表」。

运维细节：下线节点、备份恢复与集群文件#

TiKV：下线一个节点比加一个节点危险#

TiKV 扩容只是加节点等 PD 搬数据，缩容则必须先让 Region 迁走再移除节点，否则副本数掉到 2 以下就有丢数据风险。这一步在 TiUP 上的顺序是 scale-in → 等状态变 Tombstone → prune；在 Kubernetes 里等价动作是把 spec.tikv.replicas 调小，由 TiDB Operator 或 KubeBlocks 调 PD 的接口完成。手工核对进度的命令是：

# 在 PD Pod 里看 store 状态：Up → Offline → Tombstone，region_count 归零才算迁完
kubectl -n demo exec -it tikv-demo-pd-0 -- pd-ctl store
# 把某个 store 标记为下线（Operator 缩容时替你做的事）
kubectl -n demo exec -it tikv-demo-pd-0 -- pd-ctl store delete <store-id>

三条生产约束：下线前确认剩余节点装得下这些 Region，容量不够会一直卡在 Offline；挑业务低峰做，迁移会打满磁盘与网络；耗时从几分钟到几小时不等，迁移没完别去重启其它节点。临时维护和永久下线是两回事：前者只停进程，PD 发现 Disconnect 后自动补齐副本，节点回来再重平衡，不需要 prune。

备份也要分两件事：PD 元数据备份（tiup cluster meta backup）保住的是集群拓扑与调度元数据；业务数据备份要导出到对象存储（TiDB 生态用 BR，K8s 里是 Backup 对象），才是能恢复数据的那一份。只备元数据不备数据，恢复出来是一个空集群。

参考：reference/k8s-in-action/db/tikv/permanently-take-a-node-offline.md、reference/k8s-in-action/db/tikv/backup-restore.md

FoundationDB：集群文件与冗余模式#

FDB 有两个别的数据库没有的概念，配错了业务直接连不上、或者冗余白配：集群文件（cluster file）是客户端发现集群的入口（内含协调器地址与集群 ID），Operator 会把它写进 Secret / ConfigMap，业务必须挂载集群里那一份，不要自己拼地址——扩缩容或换协调器时只有集群文件会更新。冗余模式决定数据放几份，double 大致对应三副本、triple 对应五副本，且必须与故障域（默认 kubernetes.io/hostname）匹配：只有 3 个节点却配 triple，等于把多份数据放在同一台机器上。

kubectl -n fdb-system exec -it fdb-demo-log-1 -- fdbcli --exec "status details"

status minimal 打出 The database is available 才算可用；status details 里的 Redundancy mode 与 Datacenter/Machine 容错行，是判断「冗余有没有真的生效」的唯一依据。改冗余模式不是改个字段就完事：从 double 升到 triple 需要额外节点容量并触发数据重分布，先在测试集群量出容量与耗时。

参考：reference/k8s-in-action/db/fdb/README.md

KubeBlocks：备份与恢复的固定动作#

KubeBlocks 的备份是「先配仓库、再建备份、最后演练恢复」三步，缺任何一步备份都只会停在 Pending。

# 1. 备份仓库：S3 或一块共享 PVC，必须先存在且 STATUS 为 Ready
kubectl get backuprepo
# 2. 按需备份，并确认真的完成（STATUS 期望 Completed）
kbcli cluster backup demo --namespace demo
# 3. 恢复到新集群，而不是原地覆盖
kbcli cluster restore demo-restore --backup demo-backup --namespace demo

定时备份要在 Cluster 的 spec.backup 里写 schedule（cron 表达式）与保留策略，比人手敲 kbcli 可靠。备份方法由引擎的 BackupPolicy 决定（PostgreSQL 的 pg-basebackup、Redis 的 RDB），用 kubectl get backuppolicy 查实际可用值——不同引擎支持的备份方式不同，`backupMethod` 选错会一直失败。

参考：reference/k8s-in-action/db/kubeblocks/kubeblocks-0.9.3/README.md、reference/k8s-in-action/db/kubeblocks/kubeblocks-0.8.4/README.md

生产要点与常见坑#

StatefulSet 与 Operator 的边界。 StatefulSet 给的是稳定身份：稳定的 Pod 名字与网络标识、每副本独立 PVC、按序启停。它不给的是业务语义：不知道谁是主、不知道数据有没有追平、不会选主、不会备份、不会编排版本升级。所以边界很清楚：能靠 StatefulSet 解决的别上 Operator；需要理解主从、自动切换、备份恢复的就必须是 Operator——Operator 内部通常也用 StatefulSet 承载 Pod，只是在上面加了一层「懂数据库」的控制器。

PDB 与滚动升级。 节点维护时 kubelet 会驱逐 Pod，三个副本同时被驱逐数据库就不可用了。给数据库 Pod 配 PodDisruptionBudget 能限制自愿驱逐的数量：

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata: {name: redis-pdb, namespace: demo}
spec:
  minAvailable: 2
  selector: {matchLabels: {app.kubernetes.io/instance: demo}}

PDB 只约束自愿驱逐（kubectl drain、节点维护），不阻止节点宕机，也未必阻止 Operator 自己发起的升级滚动。同时必须保证副本分散在不同节点（反亲和或拓扑约束），否则三个副本落在一台机器上，PDB 也救不了。

存储、备份、观测与 OOM。 三条经验：

• 存储性能直接决定数据库性能：优先本地 NVMe 或网络块存储（三副本），不要用 NFS 跑数据库，量法见生产存储。
• 备份不是快照，监控也不是可选项：快照与源卷往往在同一套存储里，集群整体故障时一起没，真正的备份要落到另一套介质并定期演练恢复（见备份与恢复）；连接数、复制延迟、慢查询、磁盘水位、OOM 次数都要有指标与告警（见可观测性）。
• 内存型数据库最容易 OOM：requests 要接近真实工作集；引擎自己的内存上限必须小于容器 limits（经验取 70%~80%），剩下的留给复制缓冲与 fork 的写时复制，否则一次全量同步就可能被 OOMKill。

常见错误速查表。 数据库类故障的排查顺序和普通应用不同：先看 Operator 说的状态，再看 Pod，最后看引擎自己的日志。

自测题#

小结#

• 有状态中间件比无状态应用多出数据持久性、主从选主、数据迁移、备份恢复、版本升级、脑裂六类运维动作，这些动作原本写在人的手册里。
• Operator = CRD（描述期望）+ 控制器（reconcile 纠偏）+ 状态机（知道下一步该做什么）；与 Helm 的差别是一句话：Helm 装完就走，Operator 持续纠偏。
• KubeBlocks 用一套 Cluster API 统一多种引擎，核心对象是 Cluster / Component / ComponentDefinition / ClusterVersion / OpsRequest，扩缩容、升级、备份都有对应的 kbcli cluster 子命令。
• Redis 单实例（Deployment + PVC + Recreate 策略）适合可重建的缓存；要自动故障切换就上主从加哨兵，要扩容量才需要 Redis Cluster。
• TiKV 用 PD 管调度、TiKV 存数据，Raft 三副本起步，水平扩展靠加 TiKV 节点加 PD 重新分片；FoundationDB 适合做事务型 KV 底座，注意集群文件、存储引擎、冗余模式与故障域。
• 不是所有数据库都值得搬进 Kubernetes：运维能力不足时，托管数据库是更专业的选择。

练习#

1. 用本章的选型表，给你手头最熟悉的一个有状态服务写出结论：单实例、主从加哨兵、分布式 KV，还是干脆托管？写出三条理由，并指出最大的风险点在哪。
2. 把练习里的 Cluster 清单改成「两副本」版本，然后想清楚：如果这一套用 Raft 协议，两副本在故障时会变成什么状态？为什么？对照第二道自测题验证你的推理。
3. 假设平台要给 10 个业务团队提供「自助申请一套 Redis」的能力，列出你需要的三样东西：命名空间配额方案、备份与恢复演练流程、必须监控的指标。配额可参考命名空间与 RBAC，指标口径参考可观测性。

数据库与中间件做成平台能力之后，平台本身也要被守住：交付流程回到 GitOps 持续交付，恢复能力回到备份与恢复，集群侧的资源规划回到生产集群部署。