HDUO Lab

标签： StatefulSet

  • 深入 K8S VolumeAttachment 死锁排查：Node 宕机引发的 Multi-Attach 挂载冲突与 Non-Graceful 驱逐实战

    某次处理生产环境高可用数据库集群的容灾演练故障，现象极具代表性：物理节点发生硬宕机（模拟拔电），该节点上的 StatefulSet Pod 被重新调度到新节点后，长时间卡在 ContainerCreating 状态。最终结论：在未进行 STONITH（Shoot The Other Node In The Head）确认前，直接对挂载了块存储的 Pod 执行 --force 删除是极度危险的低级操作。这会彻底打乱 K8S AD 控制器（Attach/Detach Controller）与 CSI 驱动的协同状态。正确的解法是利用 K8S 的 Non-Graceful Node Shutdown（NGNS）特性，通过 out-of-service 污点触发底层合法的 Volume 卸载。

    遇到 Pod 驱逐卡住，第一反应就是敲 kubectl delete pod xxx --force --grace-period=0，这种肌肉记忆在跑 Web 服务的无状态场景下无所谓，但在 StatefulSet + RWO（ReadWriteOnce）块存储场景下，就是在人为制造存储脑裂。

    案发现场与暴力操作的代价

    监控大盘显示某核心服务的 P99 延迟突增至超时阈值，对应的底层 Node 因为内核 Panic 处于 NotReady 状态。 排查新调度的 Pod 状态，发现报出经典的 CSI 挂载冲突错误：

    Warning  FailedAttachVolume  3m2s (x12 over 15m)  attachdetach-controller
Multi-Attach error for volume "pvc-8f9a3b2c" Volume is already exclusively attached to one node and can't be attached to another

    排查过程中发现，之前的处理人员看 Pod 一直处于 Terminating，反手就是一个 --force 强删。 表面上看，Pod 从 APIServer 的 etcd 记录里消失了，并且顺利在另一台 Node 上生成了处于 Pending/ContainerCreating 的新 Pod，看似调度成功。但实际上，底层存储的控制面完全是乱套的。

    通过查看当前的 VolumeAttachment 对象，真相一目了然：

    # kubectl get volumeattachment -l "kubernetes.io/pv-name=pvc-8f9a3b2c" -o yaml
...
spec:
  attacher: ebs.csi.aws.com
  nodeName: dead-node-01   <-- 依然绑定在旧的死亡节点上
  source:
    persistentVolumeName: pvc-8f9a3b2c
status:
  attached: true           <-- CSI 认为还没有卸载

    为什么 K8S 会死锁？谈谈防御性编程的底线

    这个“死锁”不是 Bug，而是 K8S 存储架构在设计上的底线防御机制（Fencing）。

    在 CSI（Container Storage Interface）的生命周期语义中，一个 RWO 的云盘（如 AWS EBS、阿里云 ESSD）要挂载到新节点，必须确保在旧节点上已经完全脱离。 当 Node 宕机处于 NotReady 时，K8S 的 kube-controller-manager 无法和该节点上的 kubelet 通信。AD 控制器为了防止数据损坏，会一直等待 kubelet 汇报 UnpublishVolume（卸载文件系统）完成。

    如果不强制等待会怎样？ 假设 Node 并没有死，只是网络发生脑裂（Split-Brain），Node 上的业务进程仍在疯狂将 Page Cache 刷入磁盘（ext4/xfs）。如果此时 AD 控制器直接调用云厂商 API 将云盘强行卸载并挂载到新 Node 上，新旧两个 Kernel 同时对同一个 Block Device 的 Superblock 和 Journal 区域进行写操作，文件系统会在几秒钟内被彻底击穿，导致不可逆的数据损坏。

    强删 Pod (--force) 仅仅是删除了逻辑对象，并没有改变 VolumeAttachment 的物理挂载状态。CSI external-attacher 看到旧的挂载关系未解除，自然拒绝向底层 IaaS 发起新的 AttachVolume API 请求。

    破局之道：Non-Graceful Node Shutdown

    在 K8S 1.26+ 时代（或开启了相关 Feature Gate 的早期版本），处理这种硬宕机有了标准的官方姿势。

    不要去动 Pod，也不要试图手动去 kubectl edit volumeattachment 删 finalizers（这会导致 APIServer 状态与云厂商 IaaS 状态彻底脱节，后续挂载永久失败）。

    第一步：确认物理节点死亡。 通过云控制台、IPMI 或底层带外管理，确保该 Node 已经处于 Power Off 状态，或者至少其网络和存储 HBA 卡已被彻底隔离。这是所有操作的前提。

    第二步：打上 out-of-service 污点。 向 K8S 宣告该节点已物理死亡，允许绕过 kubelet 的优雅等待：

    kubectl taint nodes dead-node-01 node.kubernetes.io/out-of-service=nodeshutdown:NoExecute

    这个操作会触发连锁反应：

    1. Taint Controller 检测到 out-of-service 污点。

    2. 触发 Pod 的强制驱逐逻辑（无视 grace-period）。

    3. 最关键的一步：Attach/Detach Controller 捕获到该污点后，判定无需等待死亡 kubelet 的回应，直接调用 CSI 驱动的 ControllerUnpublishVolume 接口。

    4. CSI 驱动调用云厂商 IaaS API，在云底座层面强行将云盘与死机 Node 解绑。

    5. 旧的 VolumeAttachment 被清理，新 Node 上的 Pod 顺利触发 AttachVolume，业务恢复。

    待故障节点修好重新加回集群前，记得移除污点：

    kubectl taint nodes dead-node-01 node.kubernetes.io/out-of-service-

    排查清单：同类 Volume 挂载异常速查

    针对 StatefulSet + CSI 存储卡 ContainerCreating 的场景，请严格按照以下顺序排查：

    1. 查明 Pod 阻塞源头： 使用 kubectl describe pod 检查 Events。如果是 Multi-Attach error，说明被旧节点锁死；如果是 volume node affinity conflict，说明 StorageClass 拓扑感知（Topology）不匹配，Pod 被调度到了 PV 所在的可用区之外。

    2. 审查 VolumeAttachment 状态： 执行 kubectl get volumeattachment | grep ，查看 Attached 列的状态和绑定的 NodeName。若绑定在 NotReady 的节点上，立刻停止任何针对 Pod 的 --force 操作。

    3. 隔离与污点注入（STONITH 机制）： 确认底层服务器无 IO 活动后，执行 kubectl taint nodes node.kubernetes.io/out-of-service=nodeshutdown:NoExecute 触发合法强制卸载。

    4. 校验底座 IaaS 状态（终极手段）： 如果 K8S 侧显示 Attached: false 但新节点依然挂载失败，说明 CSI 控制面出现了数据不一致。需直接登录云厂商控制台（或使用 awscli/aliyun-cli），强制从 IaaS 层面 Detach 云盘，随后重建当前卡死的 VolumeAttachment 对象。