云原生架构 – HDUO Lab

某次处理生产环境高可用数据库集群的容灾演练故障，现象极具代表性：物理节点发生硬宕机（模拟拔电），该节点上的 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

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

Taint Controller 检测到 out-of-service 污点。
触发 Pod 的强制驱逐逻辑（无视 grace-period）。
最关键的一步：Attach/Detach Controller 捕获到该污点后，判定无需等待死亡 kubelet 的回应，直接调用 CSI 驱动的 ControllerUnpublishVolume 接口。
CSI 驱动调用云厂商 IaaS API，在云底座层面强行将云盘与死机 Node 解绑。
旧的 VolumeAttachment 被清理，新 Node 上的 Pod 顺利触发 AttachVolume，业务恢复。

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

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

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

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

查明 Pod 阻塞源头：使用 kubectl describe pod 检查 Events。如果是 Multi-Attach error，说明被旧节点锁死；如果是 volume node affinity conflict，说明 StorageClass 拓扑感知（Topology）不匹配，Pod 被调度到了 PV 所在的可用区之外。
审查 VolumeAttachment 状态：执行 kubectl get volumeattachment | grep ，查看 Attached 列的状态和绑定的 NodeName。若绑定在 NotReady 的节点上，立刻停止任何针对 Pod 的 --force 操作。
隔离与污点注入（STONITH 机制）：确认底层服务器无 IO 活动后，执行 kubectl taint nodes node.kubernetes.io/out-of-service=nodeshutdown:NoExecute 触发合法强制卸载。
校验底座 IaaS 状态（终极手段）：如果 K8S 侧显示 Attached: false 但新节点依然挂载失败，说明 CSI 控制面出现了数据不一致。需直接登录云厂商控制台（或使用 awscli/aliyun-cli），强制从 IaaS 层面 Detach 云盘，随后重建当前卡死的 VolumeAttachment 对象。

排查过程中经常能遇到一种让人血压飙升的场景：业务侧跑来报障，说 StatefulSet 扩容卡住了，Pod 一直处于 Pending 状态。为了“快速恢复”，他们熟练地加上 --force --grace-period=0 强删了 Pod 和 PVC，结果不仅新 Pod 没起来，旧的 PV 全变成了 Terminating 僵尸态，底层云盘疯狂计费，CSI Provisioner 的队列被彻底塞爆。

先抛出结论：在多可用区（Multi-AZ）集群中，StorageClass 绝对不能使用默认的 volumeBindingMode: Immediate。 必须显式声明为 WaitForFirstConsumer。否则，CSI Provisioner 会在 PVC 创建瞬间盲目在一个随机可用区创建底层存储卷，一旦 K8s 调度器受限于节点资源或 Pod 反亲和性（Anti-Affinity），将 Pod 强行调度到另一个可用区，就会触发经典的 volume node affinity conflict 死锁。而无脑的强删操作，只会引发 Finalizer 锁死，导致控制面雪崩。

案发现场：一次愚蠢的“调度冲突”与强删风暴

某次核心中间件集群扩容，运维同学反馈新加的两个 Pod 挂死在 Pending 状态。随手敲下 kubectl describe pod，看到了 K8s 存储排查中最眼熟的报错：

Warning  FailedScheduling  3m2s  default-scheduler  0/50 nodes are available: 20 node(s) didn't match pod anti-affinity rules, 30 node(s) had volume node affinity conflict.

这个报错的信息量极大。集群一共 50 个节点，其中 20 个节点因为业务配置了强反亲和性（requiredDuringSchedulingIgnoredDuringExecution）被过滤，剩下 30 个节点全部报 volume node affinity conflict。

去查一眼 PVC 和 PV 的状态，发现 PVC 已经是 Bound 状态了：

$ kubectl get pvc data-kafka-3
NAME           STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
data-kafka-3   Bound    pvc-8f9a2b3c-1234-5678-90ab-cdef12345678   500Gi      RWO            ssd-sc         15m

这就是典型的“盘建好了，但 Pod 过不去”。此时，业务研发为了自救，执行了经典的毁灭三连： kubectl delete pod kafka-3 --force kubectl delete pvc data-kafka-3 --force kubectl delete pv pvc-8f9a2b3c... --force

结果灾难发生了：PVC 和 PV 全部卡在 Terminating。CSI Controller 疯狂刷错，external-provisioner 的 Goroutine 数量飙升，API Server 持续收到无用的 Update 请求，整个存储控制面陷入瘫痪。

核心原理解析：为什么盘和计算节点会劈腿？

很多半吊子对 Kubernetes 存储生命周期的认知还停留在“建 PVC -> 绑 PV -> 挂载到 Pod”的线性思维上。在 CSI（Container Storage Interface）架构下，多可用区集群的存储拓扑感知（Topology Awareness）是一件极其严谨的事。

1. Immediate 模式的致命缺陷

查看当时的 StorageClass 配置：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ssd-sc
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
# 致命缺失：没有定义 volumeBindingMode，默认使用了 Immediate

在 Immediate 模式下，当 StatefulSet 创建出 PVC 时，CSI external-provisioner 会立刻调用云厂商 API 创建一块 EBS 盘。由于此时它不知道最终 Pod 会被调度到哪个节点，它只能随机（或根据默认规则）选择一个可用区（假设选了 Zone A）。盘建好后，生成的 PV 对象里会被硬性打上 nodeAffinity：

nodeAffinity:
  required:
    nodeSelectorTerms:
    - matchExpressions:
      - key: topology.ebs.csi.aws.com/zone
        operator: In
        values:
        - ap-southeast-1a  # 盘被锁死在了 Zone A

2. 调度器被两头堵死

接下来 kube-scheduler 开始为 Pod 寻找节点。

Pod 自身带有反亲和性，恰好 Zone A 的节点都已经部署了同一个 StatefulSet 的其他 Pod，Zone A 全部被过滤。
调度器试图把 Pod 塞进 Zone B 的节点，但在评估存储卷时，发现 PV 的 nodeAffinity 是 Zone A。
最终结果：计算资源要求去 Zone B，存储资源锁死在 Zone A。死锁形成，Pod 永久 Pending。

3. 强删引发的 Finalizer 僵尸机制

K8s 极度推崇“防御性编程”，为了防止数据丢失，设计了 Finalizer 机制。

当你删除正在被 Pod（哪怕是 Pending 但已绑定的 Pod）引用的 PVC 时，kubernetes.io/pvc-protection Finalizer 会拦截删除操作。
当你强制干掉 PV 时，kubernetes.io/pv-protection 会死死拦住。
更要命的是，底层云盘的 Delete 请求依赖 CSI 正常通信。当人为 kubectl patch 暴力清除 Finalizer 时，K8s 里的对象没了，但云厂商那边的物理云盘变成了孤儿资源（Leaked Volume），默默消耗着高昂的云预算。

破局与自救：如何体面地收拾残局？

不要一上来就改 etcd 或者无脑 patch finalizer，按顺序执行以下操作：

第一步：揪出卡死的资源并妥善释放 如果 PVC/PV 已经处于 Terminating，必须先确认底层云盘是否已经删除。如果没删，手动去云控制台删盘。确认盘没用后，再通过 Patch 清理 K8s 对象：

# 清理 PVC Finalizer
kubectl patch pvc data-kafka-3 -p '{"metadata":{"finalizers":null}}'
# 清理 PV Finalizer
kubectl patch pv pvc-8f9a2b3c-1234-5678-90ab-cdef12345678 -p '{"metadata":{"finalizers":null}}'

第二步：检查是否有残留的 VolumeAttachment 有时候 PV 删了，但 CSI 挂载记录还在，会导致同名节点后续挂载一直报错 VolumeInUse：

kubectl get volumeattachment | grep pvc-8f9a2b3c
# 如果有，同样 patch 清掉
kubectl patch volumeattachment <name> -p '{"metadata":{"finalizers":null}}'

第三步：重建 StorageClass（核心防御） StorageClass 的 volumeBindingMode 是不可变字段（Immutable），只能建新的。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ssd-sc-topology
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
volumeBindingMode: WaitForFirstConsumer # 绝对核心
allowedTopologies: # 可选：显式限制允许创建存储的可用区
- matchLabelExpressions:
  - key: topology.ebs.csi.aws.com/zone
    values:
    - ap-southeast-1a
    - ap-southeast-1b

原理揭秘：改为 WaitForFirstConsumer 后，PVC 创建时 CSI 不会立即建盘，PVC 会处于 Pending 状态。kube-scheduler 会将 Pod 调度到合适的节点（例如 Zone B），然后将选定的节点拓扑信息传递给 CSI Provisioner，CSI 再拿着 “Zone B” 的确切坐标去调用云 API 建盘。实现了“计算在哪，存储就建在哪”的精准协同。

排查清单：K8S 存储异常速查表

查调度模式冲突：检查 StorageClass 是否为 Immediate 且集群为多可用区。只要符合这两条，立刻改成 WaitForFirstConsumer。
查 PV 拓扑亲和性：kubectl get pv -o yaml，查看 nodeAffinity 中声明的 Zone，是否与 Pod 最终想要调度的 Node 所在的 Zone 完全一致。
查挂载残留对象：排查 kubectl get volumeattachments 列表中是否有长时间 Attached: true 但实际 Pod 已经销毁的僵尸记录。
查 CSI 控制平面：抓取 external-provisioner 和 external-attacher 容器的日志，搜索 Failed to attach volume 或 rate exceeded 关键字，确认是否因 API 限流导致状态不一致。

存储无小事。在基础设施即代码的今天，任何一行缺乏底层逻辑支撑的 YAML，都有可能在深夜掀起一场毁灭性的雪崩。敬畏数据，敬畏拓扑。

分类： 云原生架构

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