K8s 国产数据库节点驱逐故障排查｜节点离线、Pod 漂移业务兜底方案

摘要

90% 的团队以为数据库上了 K8s、配了 StatefulSet+PVC 就高枕无忧，结果一次节点驱逐直接生产事故：Pod 卡在 Pending、数据盘挂载失败、业务断连半小时、甚至异常断电式关闭导致数据损坏。很多人归罪于「容器不适合跑数据库」，本质是没搞懂有状态服务的驱逐逻辑，也没有做分层兜底。

本文基于政务、金融生产项目实战经验，拆解三类节点驱逐的影响等级，输出五步排查法 + 三层兜底体系，覆盖主动维护、突发故障两大场景，包含 K8s 平台防护、数据库主从切换、业务熔断降级全链路方案，人大金仓 V9、达梦 DM9 双库适配。照着做，节点驱逐的业务中断时间可从小时级降到秒级。

政务选金仓，金融选达梦；MySQL 迁移选金仓，Oracle 迁移选达梦。所有方案均经过生产节点故障与演练验证，可直接落地。

一、痛点直击：节点驱逐为什么是有状态数据库的噩梦

📌 核心结论：无状态应用驱逐秒级恢复，数据库驱逐步步是坑。有状态服务天生不适合随意漂移，很多团队把数据库当无状态应用跑，节点一驱逐直接生产事故。

1.1 节点驱逐对数据库的四大致命影响

1.2 最常见的翻车现场

• 运维凌晨执行节点维护，drain 驱逐数据库节点，以为 Pod 会自动飘过去，结果业务断了 2 小时
• 节点硬件故障离线，主库 Pod 跟着挂了，等了半天没自动恢复，才想起还有备库可以切
• 驱逐后主库漂移到新节点，启动后数据不一致，只能从备份恢复，丢失故障前数据

二、先搞懂：三类节点驱逐的影响等级与差异

不是所有驱逐都一样，先分清类型，处理策略天差地别。

💡 核心差异：

• 主动驱逐：可计划、可控制，提前切主库再驱逐，业务零中断
• 故障驱逐：突发、不可控，完全依赖高可用架构和自动切换能力
• 很多团队翻车，就是用主动驱逐的思路去应对故障驱逐，傻等 Pod 漂移恢复，白白浪费时间

2.1 两种存储方案的恢复能力差异

这是最容易被忽略的底层差异，直接决定了故障后的恢复策略：

⚠️ 重点提醒：用 Local PV 追求性能的团队，必须接受节点故障时该副本数据不可用，绝对不能指望 Pod 漂移恢复，主从高可用才是唯一的兜底。

三、故障排查全流程：驱逐后数据库异常五步定位

节点驱逐后数据库异常，按这个顺序排查，5 分钟定位问题。

第一步：确认节点与驱逐状态

bash

# 1. 查看节点状态，确认是NotReady还是主动SchedulingDisabled
kubectl get nodes

# 2. 查看节点上的驱逐事件
kubectl describe node 节点名 | grep -A 20 Events

# 3. 查看是否有Pod驱逐事件
kubectl get events -n 数据库命名空间 –sort-by='.lastTimestamp' | tail -20

✅ 目标：搞清楚是主动维护还是突发故障，节点现在是离线还是正常。

第二步：查看数据库 Pod 状态

bash

# 查看Pod状态：Pending / CrashLoopBackOff / Terminating
kubectl get pods -n kingbase -o wide

# 查看Pod详情，看卡在什么地方
kubectl describe pod kingbase-0 -n kingbase

常见异常状态：

• Pending：大概率是 PVC 挂载失败、节点资源不足、调度不上去
• CrashLoopBackOff：数据库启动失败，可能数据损坏、配置错误
• Terminating：终止卡住，进程杀不掉，可能 IO hang 住

第三步：排查 PVC 与存储问题

这是最高频的卡点：

bash

# 查看PVC状态，是否还是Bound
kubectl get pvc -n kingbase

# 查看PV状态，是否绑定在故障节点
kubectl get pv -o wide | grep 对应PVC名

常见问题：

• Local PV 场景：节点故障，PV 不可用，Pod 永远 Pending
• 分布式存储：存储节点故障、挂载超时、权限问题

第四步：查看数据库启动日志

如果 Pod 已经起来但数据库没正常运行，看日志：

bash

# 查看数据库启动日志
kubectl logs kingbase-0 -n kingbase

# 进入容器看数据库运行日志
kubectl exec -it kingbase-0 -n kingbase — tail -50 /opt/kingbase/log/latest.log

重点看：是否在做崩溃恢复、是否有数据页错误、是否能正常接受连接。

第五步：验证业务连通性

数据库起来后，验证读写正常、主从同步正常，再放业务流量。

四、第一层：平台层防护，从 K8s 源头降低业务影响

最好的故障是不发生，先从平台层面做防护，减少驱逐的概率和影响。

4.1 配置 Pod 中断预算 PDB，主动驱逐保底

PodDisruptionBudget 保证主动驱逐时，至少保留 N 个实例，不会一次性把主备全赶走。

yaml

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: kingbase-pdb
namespace: kingbase
spec:
minAvailable: 1 # 至少保留1个实例可用
selector:
matchLabels:
app: kingbase

✅ 作用：主动维护 drain 节点时，不会把主备两个库都驱逐，至少留一个扛业务。

4.2 延长优雅终止时间，避免强制杀库

数据库关闭需要时间，尤其是有大事务的时候，终止时间设太短会被强制杀死，相当于异常断电。

yaml

spec:
terminationGracePeriodSeconds: 1800 # 最长等30分钟，给数据库足够时间优雅关闭
template:
spec:
containers:
– name: kingbase
lifecycle:
preStop:
exec:
command: ["sys_ctl", "stop", "-D", "/opt/kingbase/data", "-m", "fast"]

💡 原理：驱逐时先执行 preStop 优雅停库，等进程正常退出后再销毁 Pod，绝对不能让 kubelet 硬杀。

4.3 节点亲和 + 污点，固定数据库运行节点

不要让数据库随便飘，固定在指定的高规格节点上，减少随机调度到烂节点的概率：

yaml

spec:
template:
spec:
nodeSelector:
dedicated: database
tolerations:
– key: "dedicated"
operator: "Equal"
value: "database"
effect: "NoSchedule"
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
– labelSelector:
matchLabels:
app: kingbase
topologyKey: kubernetes.io/hostname

✅ 同时配置反亲和，主备绝对不在同一个节点，避免节点故障双挂。

4.4 优先级配置，数据库不被低优先级业务挤走

给数据库 Pod 设高优先级，节点资源不足时，先驱逐低优先级业务，保住数据库：

yaml

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: database-high
value: 1000000
globalDefault: false
description: "数据库高优先级"
—
# Pod里引用
spec:
template:
spec:
priorityClassName: database-high

4.5 存储层适配

• Local PV 场景：接受节点故障数据不可用，靠主从兜底
• 分布式存储：开启快速挂载、在线扩容，减少漂移后的恢复时间

五、第二层：数据库层高可用兜底，秒级切换不丢数据

平台防护只能降低概率，真出节点故障，最终靠数据库主从高可用兜底。

5.1 核心原则：节点故障不等漂移，直接切主库

尤其是 Local PV 场景，节点挂了数据盘就没了，等 Pod 漂移毫无意义，第一时间切备库为主库，业务秒级恢复。

5.2 标准切换流程（金仓 / 达梦通用逻辑）

人大金仓 V9 提升备库命令

bash

kubectl exec -it kingbase-1 -n kingbase — sys_ctl promote -D /opt/kingbase/data

达梦 DM9 提升备库命令

bash

kubectl exec -it dmdb-1 -n dmdb — disql SYSDBA/PASSWORD -e "ALTER DATABASE PRIMARY;"

5.3 流量自动切换：标签 + Service 机制

利用 K8s 原生 Service selector，切换角色后更新标签，流量自动漂移，不用改应用配置：

bash

# 移除旧主库master标签
kubectl label pod kingbase-0 role- -n kingbase
# 给新主库打上master标签
kubectl label pod kingbase-1 role=master -n kingbase

业务连接的是kingbase-svc，它的 selector 是role=master，标签一变流量自动切走，应用完全无感知。

5.4 数据一致性保障

• 切换前确认旧主库彻底不可写，杜绝双主脑裂
• 切换后校验核心表数据、同步位点
• 故障节点恢复后，从新主库全量重建备库，不强行回切旧主库

六、第三层：业务层兜底，断连不雪崩、重试不放大

数据库再稳，应用层没做好，也会把小故障放大成全站雪崩。

6.1 连接池适配：快速失败 + 自动重连

参考连接池优化文章的配置，核心三点：

6.2 熔断降级：数据库挂了别堆请求

• 数据库不可用时，接口快速熔断降级，返回友好提示
• 禁止前端无限重试，重试次数最多 2-3 次，避免放大故障
• 非核心业务直接降级，保住核心申报、查询等主流程

6.3 读写分离兜底：主库挂了读业务还能跑

• 主库故障时，读请求自动切到备库执行
• 非实时场景可以接受轻微延迟，先保证业务可用，再恢复主库

七、分场景 SOP：主动维护 vs 故障驱逐标准处理流程

7.1 场景一：主动维护节点（计划内）

目标：业务零中断

7.2 场景二：节点突发故障离线

目标：最快恢复业务，数据零丢失

八、生产避坑：10 个节点驱逐最容易踩的致命错误

⚠️ 坑 1：以为有 StatefulSet 就高可用，不做主从

• 后果：节点一挂，数据库直接凉，数据都拿不出来
• 正解：容器化数据库必须配主从高可用，单实例永远有单点风险

⚠️ 坑 2：Local PV 节点坏了，傻等 Pod 漂移恢复

• 后果：Pod 一直 Pending，业务断几十分钟，还找不到原因
• 正解：Local PV 场景节点故障直接切备库，别等漂移

⚠️ 坑 3：优雅终止时间设太短，强制杀数据库

• 后果：数据库异常关闭，启动要做长时间恢复，甚至数据损坏
• 正解：terminationGracePeriodSeconds 设 1800 秒，配 preStop 优雅停库

⚠️ 坑 4：不配置 PDB，主动驱逐把主备一起赶走

• 后果：drain 节点时两个库都被驱逐，业务完全中断
• 正解：配置 PDB，至少保留 1 个实例

⚠️ 坑 5：故障后强行回切旧主库，导致脑裂

• 后果：双主都写，数据分裂，集群彻底报废
• 正解：旧主库恢复后作为新备库加入，不要回切

⚠️ 坑 6：没有标签切换机制，切主了流量还打旧主库

• 后果：数据库切完了，业务还连旧地址，全超时
• 正解：Service 绑定 role 标签，切主同步更标签，流量自动切

⚠️ 坑 7：应用没有重试和熔断，断连直接雪崩

• 后果：数据库一断，请求堆成山，恢复后直接被打挂
• 正解：连接池配超时，接口配熔断重试

⚠️ 坑 8：驱逐前不切主，硬赶主库 Pod

• 后果：主动维护也搞出业务中断，完全没必要
• 正解：主动驱逐先切主，再赶备库，零中断

⚠️ 坑 9：不做演练，真故障了手忙脚乱

• 后果：流程不熟，操作失误，故障时间翻倍
• 正解：每季度做一次节点驱逐演练，练熟切换流程

⚠️ 坑 10：只关注主库，备库状态从来不看

• 后果：真要切备库的时候，发现备库早就同步断了，切不了
• 正解：每日巡检主从同步状态，备库健康才能兜底

九、监控预警：提前发现节点风险，别等驱逐了才救火

最好的故障处理，是提前发现、提前干预。

9.1 必加监控告警

9.2 节点巡检每日必查

十、应急演练：定期验证兜底能力，别真故障了手忙脚乱

方案写得再好，不练都是纸上谈兵。

10.1 季度演练标准动作

10.2 演练验收标准

• 业务中断时间 < 3 分钟
• 切换过程无数据丢失、无数据不一致
• 团队操作熟练，无失误步骤
• 演练后输出复盘报告，优化流程和方案

总结

K8s 节点驱逐对数据库来说从来不是小事，不能拿无状态应用的经验套有状态服务。三层兜底体系做好：平台层做防护减少驱逐影响、数据库层做主从切换秒级恢复、业务层做熔断避免雪崩，再加上定期演练，不管是主动维护还是突发故障，都能稳得住。

容器化数据库的高可用，从来不是靠 K8s 自动漂移，而是靠架构设计和流程规范。把每一层的兜底做扎实，节点故障就只是一次普通运维操作，而不是生产事故。

政务选金仓，金融选达梦；MySQL 迁移选金仓，Oracle 迁移选达梦。

📚 专栏推荐：专注 SpringBoot3 + 人大金仓 + 达梦信创实战，持续输出生产级部署、性能调优、故障排查、高可用架构干货，关注不迷路。

觉得文章有用的话，欢迎点赞、收藏、关注三连，后续更新更多信创数据库云原生落地的硬核内容。