🚨 赛博排障实录:CNPG 密码“脑裂”与内核级破门指南
⚠️ 事故现场:完美的图纸,打不开的大门
Section titled “⚠️ 事故现场:完美的图纸,打不开的大门”在部署 pgAdmin 接入 CloudNativePG (CNPG) 时,即便你严格遵守了 GitOps 的每一行配置,提取了最新的 K8s Secret 密码,依然可能遇到那个令人抓狂的报错:
FATAL: password authentication failed for user "postgres"这种“钥匙(Secret)打不开自家大门(Database)”的现象,在 Operator 模式下被称为 “状态撕裂” (State Desync),俗称 “脑裂”。
🧠 深度复盘:为什么会被“天坑”算计?
Section titled “🧠 深度复盘:为什么会被“天坑”算计?”这本质上是 Kubernetes 的声明式状态 与 数据库的物理持久化状态 发生了脱节。
1. CNPG 的“一次性”发卡机制
Section titled “1. CNPG 的“一次性”发卡机制”CNPG 管家只在集群 第一次初始化 (Bootstrap) 的那一瞬间,会生成随机密码并同时写入 K8s Secret 和数据库底层引擎。
2. K8s 与物理存储 (Longhorn) 的脱节
Section titled “2. K8s 与物理存储 (Longhorn) 的脱节”如果你曾删除过 CNPG 实例但保留了 Longhorn 数据卷,当你再次拉起集群时:
- K8s 视角:这是一个新任务,它会生成一个全新的 Secret(新钥匙)。
- Postgres 视角:挂载旧硬盘后,它依然守着第一次建库时的旧密码(老锁芯)。
- 结果:外面显示的密码是 A,但门里认的密码是 B。
🔨 赛博暴力破门方案:潜入内核强行修正
Section titled “🔨 赛博暴力破门方案:潜入内核强行修正”既然外面的钥匙失效了,作为赛博堡垒的造物主,我们不再纠结于 Secret,直接利用 Socket 直连 潜入数据库心脏,从内部强制重置密码。
步骤 1:直捣黄龙,潜入主节点
Section titled “步骤 1:直捣黄龙,潜入主节点”利用 kubectl exec 绕过网络认证,以本地超级用户身份进入数据库 Pod:
# 进入主节点终端并直连 psqlkubectl exec -it -n database homelab-db-cluster-1 -- psql步骤 2:内核级重置密码
Section titled “步骤 2:内核级重置密码”进入 postgres=# 提示符后,执行 SQL 语句进行“物理修正”:
-- 强行将 postgres 用户的锁芯更换为你预设的密码ALTER USER postgres WITH PASSWORD '你的新密码';
-- 退出内核\q👑 总结:首席承包商的终极底牌
Section titled “👑 总结:首席承包商的终极底牌”这次排障告诉我们一个真理:在云原生时代,GitOps 是流程,但 kubectl 是真理。
不管外面的声明式配置如何演变,只要你能以系统造物主的身份进行“内核级干预”,你就永远拥有整座赛博堡垒的最终解释权。
💡 避坑准则
Section titled “💡 避坑准则”- 重建集群时:若要彻底重置密码,必须连同 Longhorn 的 PVC 一起清理。
- 排障优先级:当应用层认证失败时,优先检查物理存储是否包含陈旧状态。