跳转至

认证异常故障报告（F3：munge 密钥不一致）

故障时间

2026-09-10 20:46:04 注入（k8s-node-03 覆盖随机密钥）→ 20:48:01 完成恢复，闭环验证通过。

现象

  1. 注入后 munge、slurmd 服务均 active，本地 munge -n | unmunge 自检 Success——单机视角一切正常（故障隐蔽性极强）。
  2. master → node-03 跨节点验证：unmunge: Error: Invalid credential。
  3. srun -w k8s-node-03 报：Required node not available (down, drained or reserved)；作业 380 排队后分配被撤销。
  4. sinfo 显示节点 idle*（IDLE+NOT_RESPONDING）——控制器侧症状是"节点失联"，slurmctld 日志中无任何认证/credential 字样。

影响范围

  • 单节点（node-03）无法接收作业与响应心跳，在该节点排队/指定的作业全部无法运行；
  • 若主控密钥被改则为全集群瘫（本例仅注入计算节点）；
  • 不影响其他节点作业运行。

根因原理

  • munge 为全集群对称密钥认证：slurmctld↔slurmd 每条 RPC 都以 munge 凭证签名+验证。密钥逐字节不一致 = 对端永远验签失败。
  • 症状分离机理：node-03 slurmd 收到 master 的 REQUEST_PING，解码 master 签名凭证失败 → 无法回有效响应；对 slurmctld 而言等同于"无响应"→ 走 1.1 节失联路径（NOT_RESPONDING→DOWN），因此控制器日志干净，认证报错只出现在计算节点 slurmd 日志。
  • 单机自检必然通过：munge -n | unmunge 是同钥自签自验，与集群密钥无关——这就是"服务全绿但集群不通"的根源。

证据摘要

[node-03] 新 key md5 = 4a91bb9e1d67837d7e3e9eed442e42d2（基线 318fd0afb38e9279a68523a455d964b5）
[node-03] munge -n | unmunge → STATUS: Success (0)        ← 隐蔽性证据
[master]  munge -n | ssh k8s-node-03 unmunge → unmunge: Error: Invalid credential
[master]  srun: Required node not available (down, drained or reserved)
[master]  sinfo -n k8s-node-03 → idle*（NOT_RESPONDING）；slurmctld 日志 grep munge/credential → 空
[node-03] journalctl -u slurmd：
  20:46:15 error: Munge decode failed: Invalid credential
  20:46:15 auth/munge: _print_cred: ENCODED/DECODED: Thu Jan 01 08:00:00 1970  ← 解码失败时间戳无效
  20:46:15 error: [K8S-master-01:63296] auth_g_verify: REQUEST_PING has authentication error:
          Invalid authentication credential
  20:46:15 error: [K8S-master-01:63296] failed: Protocol authentication error

解决方案

原子化修复步骤（高危操作，全程持备份）：

# 0) 前置：注入前已备份 cp -a /etc/munge/munge.key /etc/munge/munge.key.bak.20260910
# 1) 还原密钥
cp -a /etc/munge/munge.key.bak.20260910 /etc/munge/munge.key
chown munge:munge /etc/munge/munge.key && chmod 600 /etc/munge/munge.key
# 2) 重启认证与守护进程（munge 必须重启才重读 key；restart slurmd 立即触发重注册）
systemctl restart munge && systemctl restart slurmd
# 3) 回滚路径：若还原后仍异常，从主控重新分发主控侧备份 key 再执行同上两步

验证结果

  • node-03 key md5 还原为 318fd0afb38e9279a68523a455d964b5，munge/slurmd active，本地自检 Success。
  • master→node-03 跨节点 munge -n | unmunge → STATUS: Success (0)。
  • srun -w k8s-node-03 hostname：job 381 has been allocated resources → 正确输出 k8s-node-03。
  • sinfo 节点经 completing 短暂过渡回 idle；三节点 md5 终检一致。

预防建议

  1. 密钥分发进验收清单：新节点上架/重装后必做跨节点 munge 测试（munge -n | ssh <node> unmunge），并把三节点 md5 基线（318fd0afb38e9279a68523a455d964b5）写入 CMDB。
  2. 监控对 idle*/down* 且 slurmd active 的组合告警，提示优先查认证而非重启服务。
  3. 禁止在计算节点用"本地自检"判定 munge 健康，巡检脚本一律用跨节点链路测试。
  4. 变更 munge key 的正规路径：先在主控生成 → 集中分发（Ansible 等幂等推送）→ 全集群滚动 restart munge → 跨节点验证，避免逐台手工改导致不一致。

来源：/home/rain/Documents/slurm/slurm_study/slurm_study_plan/阶段5_故障排查/认证异常故障报告.md ｜ 最后更新：2026-09-10 20:54（由 build/sync.py 同步，请勿在站点侧修改）