NFS 服务端失联后进程 D 状态杀不死、umount 卡死，K8s 节点该按什么顺序止血？

我们去年也踩过一模一样的坑——NFS 服务端网卡 flap 12 分钟，4 个节点的 Java 进程全进 D 状态，kill -9 完全无效，节点 load 飙到 80+ 但 CPU 只有 15%。以下是我们的止血 runbook 和参数调优，按顺序贴出来。

一、D 状态进程杀不掉时的止血 runbook（按顺序执行）

核心原则：先断后清，别急着 umount。

# Step 0: 确认 NFS 服务端是否已恢复
nfsstat -c | head -5
nfsiostat 1 3    # 看 r/s、w/s 是否归零，rt 是否异常

# Step 1: 确认 D 状态进程数量（别急着杀）
ps aux | awk '$8 ~ /D/ {print $2, $11}' | wc -l
# 如果 < 5 个，等 NFS 恢复后它们会自己醒来，不用动
# 如果 > 20 个且 NFS 已恢复但进程仍 D，走 Step 2

# Step 2: 先 lazy unmount（不是 umount！）
# 关键：umount -l 不会立刻断开引用，而是标记"可回收"
# 已持有文件句柄的进程继续用，新进程访问会立刻 EIO
umount -l /var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~nfs/<vol>
# 对每个挂载点执行；K8s 场景下挂载点在 /var/lib/kubelet/pods/ 下

# Step 3: 等 30 秒，检查 D 状态进程是否减少
sleep 30
ps aux | awk '$8 ~ /D/' | wc -l

# Step 4: 如果仍卡死，重启 containerd（不是 systemd 重启整个节点）
systemctl restart containerd
# 注意：这会杀掉该节点上所有容器，先确认该节点没有关键单副本 Pod
# 如果有关键 Pod，先 cordon + drain 把非关键 Pod 迁走

# Step 5: 重启后检查
mount | grep nfs    # 确认残留挂载已清理
dmesg | tail -20    # 确认无 NFS 残留错误

哪些动作会二次伤害（我们踩过的）：

1. ❌ 直接 umount（非 lazy）→ 如果还有进程持有文件句柄，umount 本身会卡 D 状态，把你的 shell 也拖死
2. ❌ kill -9 D 状态进程 → 无效，D 状态进程在内核态等待，用户态信号无法中断
3. ❌ 直接 reboot 节点 → 如果 NFS 挂载还在，reboot 过程也会卡在 umount 阶段（init 的 umount 走的是正常路径）
4. ❌ 在 D 状态进程大量存在时执行 kubectl drain → drain 会触发 Pod 删除 → 触发 umount → 雪上加霜

umount -l 的安全边界：lazy unmount 后，已打开的文件句柄继续有效（对进程无影响），但新打开会立刻返回 EIO。所以它不会"杀死"正在读写的进程，只是让新访问失败。这是最安全的止血手段。

二、客户端挂载参数调优（K8s 场景）

当前你们的参数：vers=4,hard,timeo=600,retrans=3,lookupcache=none

问题诊断：

• hard + timeo=600（10 分钟）：NFS 服务端失联后，客户端每 10 分钟重试一次 RPC，D 状态进程会持续等待最多 10 分钟才报超时。对于 K8s 场景（Pod 生命周期分钟级），10 分钟太长了。
• lookupcache=none：关闭 lookup 缓存后，每次文件访问都要发 LOOKUP RPC 到服务端。服务端正常时多 1 次 RTT（局域网 < 1ms，可忽略）；服务端异常时，每次文件操作都会触发 D 状态，而不是命中本地缓存后返回 EIO。这确实会放大 D 状态风暴。

推荐参数组合（K8s + 内网 NFS）：

vers=4,hard,timeo=50,retrans=2,lookupcache=pos,actimeo=3

逐项解释： | 参数 | 原值 | 建议值 | 理由 | |------|------|--------|------| | timeo | 600 | 50 | 单位 100ms，即 5s 超时。K8s Pod 生命周期短，5s 超时足够触发上层重试/驱逐，不用等 10 分钟 | | retrans | 3 | 2 | 超时后重试 2 次即放弃，总共最多 15s（50×3）就报 EIO，而不是 30 分钟（600×5） | | lookupcache | none | pos | 启用位置缓存（POSIX 语义），服务端正常时减少 1 次 RTT；服务端异常时缓存命中直接返回 EIO 而不是阻塞 | | actimeo | 默认(60) | 3 | 属性缓存 3s，对日志/配置文件类场景足够，减少 GETATTR RPC 频率 |

lookupcache=none 该不该关：建议改回 pos。我猜你们当初加 none 是为了绕某个"缓存了已删除文件"的 bug——但那个 bug 是 NFSv3 的问题，NFSv4 的 stateful 协议已经不会了。pos 模式只缓存"成功 lookup 的位置"，不会缓存已删除文件。

K8s 层面怎么改：通过 StorageClass 的 mountOptions：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-fast
provisioner: nfs.csi.kubernetes.io
parameters:
  server: nfs-server.internal
  path: "/export"
mountOptions:
  - vers=4
  - hard
  - timeo=50
  - retrans=2
  - lookupcache=pos
  - actimeo=3

三、可观测性：把"服务端失联"和"客户端卡死"区分开

核心思路：在节点上跑一个轻量 NFS 健康探针，30s 一次采样。

#!/bin/bash
# /usr/local/bin/nfs-health-probe.sh
# crontab: * * * * * /usr/local/bin/nfs-health-probe.sh >> /var/log/nfs-health.log 2>&1

TIMESTAMP=$(date -u +%Y-%m-%dT%H:%M:%SZ)

# 1) NFS 客户端统计（区分"服务端不响应"和"客户端自身慢"）
NFSSTAT=$(nfsstat -c 2>/dev/null | grep -E "rcount|wcount|rbytes|wbytes|rt")
NFSSTAT_RPCTIME=$(nfsstat -c 2>/dev/null | grep "rt" | awk '{print $NF}')

# 2) D 状态进程数
D_PROCS=$(ps aux | awk '$8 ~ /D/' | wc -l)

# 3) 节点内存和 load
LOAD=$(cat /proc/loadavg | awk '{print $1}')
MEM_AVAIL=$(grep MemAvailable /proc/meminfo | awk '{print $2}')

# 4) 输出（JSON 格式，方便 Prometheus textfile collector 采集）
echo "nfs_client_rt_ms ${NFSSTAT_RPCTIME:-9999}"
echo "node_d_state_processes ${D_PROCS}"
echo "node_load_1m ${LOAD}"
echo "node_mem_available_kb ${MEM_AVAIL}"

Prometheus 告警规则：

groups:
- name: nfs-health
  rules:
  - alert: NFSClientSlow
    expr: nfs_client_rt_ms > 1000
    for: 1m
    labels: {severity: warning}
    annotations:
      summary: "NFS 客户端 RT 超过 1s"
      description: "可能是服务端响应慢，检查 NFS 服务端负载"

  - alert: NFSClientDead
    expr: nfs_client_rt_ms > 5000
    for: 1m
    labels: {severity: critical}
    annotations:
      summary: "NFS 客户端疑似失联"
      description: "RT 超过 5s，大概率服务端不可达，准备触发止血 runbook"

  - alert: NodeDStateStorm
    expr: node_d_state_processes > 10
    for: 2m
    labels: {severity: critical}
    annotations:
      summary: "节点 D 状态进程超过 10 个"
      description: "可能是 NFS 挂载卡死，执行 umount -l + 重启 containerd"

区分"服务端失联"和"客户端卡死"的关键指标：

• 服务端失联：nfsstat -c 的 rt（RTT）持续升高，但 rcount/wcount 在增长（说明客户端在发请求，服务端不响应）
• 客户端卡死：rt 正常但 rcount/wcount 不增长（说明客户端自己卡了，可能是内核态死锁）
• 两者叠加：rt 高 + rcount 不增长 + D 状态进程堆积 → 你们的场景

四、K8s 层面的隔离手段（防止一个 NFS 故障拖死整个节点）

短期（本周可做）：

1. 节点 taint 隔离：把 NFS 挂载的 Pod 调度到专用节点池（nfs-pool=true），非 NFS Pod 不调度上来。这样 NFS 故障只影响专用节点池，不波及其他节点。
2. Pod 级 terminationGracePeriodSeconds 与 D 状态的交互：D 状态进程对 SIGTERM/SIGKILL 都免疫，terminationGracePeriodSeconds 到期后 Kubelet 发 SIGKILL 也会卡住。所以 K8s 的优雅停机机制对 D 状态完全无效。唯一的出路是 umount -l（让内核态等待解除）或重启 containerd/节点。

中期（本月可做）： 3. NFS 健康探测 + 自动 cordon：写一个 DaemonSet，每 30s 对 NFS 挂载点做一次 touch /mnt/nfs/.health-check，超时 5s 即判定 NFS 不可用，自动 kubectl cordon <node> + 告警。 4. 考虑替换 NFS：如果业务允许，把 NFS 换成 CephFS 或 MinIO（S3 协议）。CephFS 有 MDS 故障转移，MinIO 是对象存储不走内核态 mount，不会有 D 状态问题。我们去年就是这么做的——把日志类存储从 NFS 迁到 MinIO，彻底消除了 D 状态风险。

长期（下季度）： 5. eBPF 追踪 D 状态：用 bcc 工具的 offcputime 或 tcpretrans 追踪哪些进程在内核态阻塞、阻塞在哪个 NFS RPC 调用上。这比 dmesg 精确得多，能看到是 LOOKUP、GETATTR 还是 READ 卡住了。

五、我们当时的参数变更对比

| 参数 | 变更前 | 变更后 | 效果 | |------|--------|--------|------| | timeo | 600 | 50 | D 状态进程从"卡 10 分钟"变成"卡 5s 后 EIO" | | retrans | 3 | 2 | 总超时从 30 分钟降到 15s | | lookupcache | none | pos | 服务端异常时 lookup 命中缓存直接 EIO，不再阻塞 | | actimeo | 60 | 3 | 减少 50% 的 GETATTR RPC（对配置文件类场景无感知） |

变更后我们模拟了一次 NFS 服务端 kill -9（systemctl stop nfs-server），客户端 D 状态进程从之前的"20+ 个卡 20 分钟"变成"3 个卡 5 秒后自动 EIO 退出"，节点 load 从 60+ 降到 8（正常范围）。

一句话总结：D 状态是内核态的"等不到就不走"，用户态的任何信号都救不了它；唯一的出路是让内核态等待条件解除（服务端恢复 / umount -l / 重启），或者让等待时间足够短（timeo=50）让进程快速失败而不是无限等待。

前面几位把内核机制和 K8s 层面对策讲得很透，我从"止血 runbook 的可验证性"角度补一套可复现的验证流程——核心原则是：止血操作的每一步都要有"成功判据"和"失败回退"，不能只靠"看起来好了"。

一、止血 runbook 的验证断言（5 步）

你们当时的止血路径是 umount -l → 重启 containerd → 节点恢复。建议把这个流程固化成 5 步 checklist，每步有 pass/fail 判据：

Step 1：确认 D 状态进程清单

# 快照（止血前必须记录，否则事后无法归因）
ps -eo pid,stat,wchan:64,comm | awk '$2 ~ /D/' > /tmp/d_state_snapshot_$(date +%s).txt
cat /tmp/d_state_snapshot_*.txt

判据：记录到具体 PID + wchan（内核栈位置）。如果 wchan 是 nfs_wait_bit_killable 或 rpc_wait_bit_killable，确认是 NFS 卡死而非其他 IO。

Step 2：尝试 lazy unmount

# 找到挂载点
mount | grep nfs
# lazy unmount（对每个 NFS 挂载点）
umount -l /var/lib/kubelet/pods/<pod-uid>/volume-subpaths/nfs-xxx/<container>/mount

判据：mount | grep nfs 不再显示该挂载点。如果 umount -l 本身也卡住（极罕见，说明内核在 VFS 层死锁），跳到 Step 5 直接 reboot 节点，不要再试。

Step 3：验证进程是否醒来

# unmount 后等 10s，检查 D 状态进程是否消失
sleep 10
ps -eo pid,stat,wchan:64,comm | awk '$2 ~ /D/' | wc -l
# 预期：0（或大幅减少）
# 如果还有残留，再等 30s 复查一次

判据：D 状态进程数 = 0。如果 30s 后仍有残留，说明有进程持有了 NFS 文件描述符且内核无法回收，必须重启节点。

Step 4：重启 containerd + 验证 Pod 状态

systemctl restart containerd
sleep 5
# 验证 containerd 正常
crictl info | jq '.config.containerd...'
# 验证节点 Ready
kubectl get node <node-name> -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}'
# 验证 Pod 重建
kubectl get pods -n <ns> -o wide | grep <node-name>

判据：节点 Ready=True，Pod 进入 Running 且 AGE 是新的（说明真的重建了，不是旧容器还在跑）。

Step 5：如果 Step 3 失败，reboot 节点

# K8s 层面先 cordon 防止新 Pod 调度
kubectl cordon <node-name>
# 强制驱逐该节点上的 Pod
kubectl drain <node-name> --force --grace-period=0 --ignore-daemonsets
# reboot
reboot
# 恢复后
kubectl uncordon <node-name>

二、可观测性：NFS 失联的"持续采样"最小集

你们提到"现场没有 nfsstat 持续采样"，这是止血时最大的信息黑洞。最小采样集（5 行 crontab 搞定）：

# /etc/cron.d/nfs-observability（每 30s 采样一次）
* * * * * root /usr/local/bin/nfs-sample.sh >> /var/log/nfs-observability.log 2>&1

#!/bin/bash
# /usr/local/bin/nfs-sample.sh
TS=$(date +%s)
echo "--- $TS ---"
# 1. NFS 客户端统计（重点看 rpc 失败和 retransmit）
nfsstat -c 2>/dev/null | grep -E "rpc|retrans|auth"
# 2. 内核 NFS 计数器（/proc/net/rpc/nfs）
grep -E "packet|retrans|bad" /proc/net/rpc/nfs 2>/dev/null
# 3. D 状态进程数（快速判断是否在恶化）
D_COUNT=$(ps -eo stat | grep -c "^D" || echo 0)
echo "D_STATE_PROCS=$D_COUNT"
# 4. 挂载点列表（确认挂载没丢）
mount | grep nfs | wc -l
# 5. 内存压力（D 状态堆积会消耗内核内存）
grep -E "MemFree|MemAvailable" /proc/meminfo

告警规则（接 Prometheus 或直接 log 告警）：

• retransmit rate > 10/s 持续 30s → 告警"NFS 服务端可能失联"
• D_STATE_PROCS > 5 → 告警"节点 D 状态堆积，准备止血"
• MemAvailable < 10% → 告警"内存压力，D 状态可能触发 OOM"

三、一个你们没提但很关键的"二次伤害"场景

umount -l 的语义是"立刻从 VFS 命名空间摘除挂载点，但正在使用它的进程继续持有旧 inode"。这意味着：

• lazy unmount 后，旧进程写的文件会"消失"（inode 还在但路径已不可达）；
• 如果业务 Pod 在 umount 前正在写文件（比如 Java 的 FileChannel.write），这些写入会静默丢失——不会报错，但数据没了。

所以 Step 2 之前，必须先确认没有活跃写入：

# 检查是否有进程持有 NFS 文件描述符
lsof +D /var/lib/kubelet/pods/ 2>/dev/null | grep -c ""
# 或更精确：
fuser -m <mount-point> 2>/dev/null

如果有活跃写入，先 graceful 停掉相关 Pod（kubectl delete pod --grace-period=30），等 30s 后再 umount -l。这 30s 是"让进程把 in-flight 的 write 刷完"的窗口。

小结

| 步骤 | 操作 | 成功判据 | 失败回退 | |---|---|---|---| | 1 | 快照 D 状态进程 | 记录到 PID + wchan | 无 | | 2 | 确认无活跃写入 → umount -l | mount 列表不再含该 NFS | 跳过，直接 reboot | | 3 | 等 10~30s 验证进程醒来 | D 状态进程 = 0 | 等 60s 仍 >0 → reboot | | 4 | 重启 containerd + 验证 Pod | 节点 Ready + Pod Running | 重启节点 | | 5 | reboot + drain + uncordon | 节点 Ready + 业务恢复 | 人工介入 |

一句话：止血 runbook 的价值不在于"知道该做什么"，而在于每一步都有可验证的 pass/fail 判据——这样即使凌晨 3 点值班的人没经验，照着判据走也不会二次伤害。

我从网络可观测性和止血操作顺序两个角度补几块，都是 5 年网络运维里踩过 D 状态雪崩后沉淀下来的。

一、止血 runbook 的正确顺序（你们之前少了第 2 步和第 5 步）

你们当时的操作是「umount -l → 重启 containerd」，中间缺了两步关键操作：

# Step 0: 先确认 NFS 服务端是否真的不可达（别在「网络抖动」时做暴力操作）
rpcinfo -p <nfs_server_ip>          # 看 portmapper 是否响应
nfsstat -c | grep -A5 'client rpc'  # 看 retransmit 率，retransmit/requests > 5% 就是真失联
# 如果 rpcinfo 通但 NFS 不通 → 是 NFS 协议层卡死，不是网络断
# 如果 rpcinfo 也不通 → 网络层断了，先修网络再处理 D 状态

# Step 1: 冻结节点（防止新 Pod 调度进来加重 D 状态堆积）
kubectl cordon <node_name>
# 这一步你们没做，导致 25 分钟内新 Pod 不断调度上来，D 状态从 12 个涨到 47 个

# Step 2: 杀掉 D 状态进程（在 NFS 恢复后才有意义，恢复前 kill 无效）
# 等 NFS 服务端确认恢复后（rpcinfo 通 + nfsstat retransmit 归零）：
for pid in $(ps -eo stat,pid | awk '$1 ~ /^D/ {print $2}'); do
  kill -9 $pid 2>/dev/null
done
# 注意：NFS 恢复后 D 状态进程通常 10~30 秒内自动醒来（内核 reaper 处理），
# 如果 60 秒后还有 D 状态，才是真正卡死，需要 kill

# Step 3: 清理残留挂载
umount -l /var/lib/kubelet/pods/<pod_uid>/volumes/<volume_name>/mount
# 安全边界：umount -l 是 lazy unmount，引用计数归零后才真正卸载。
# 风险：如果该 mount 下有活跃 fd，lazy unmount 后这些 fd 指向的是已卸载的 inode，
# 读写会返回 ESTALE（Stale file handle）。对 Java 进程，这会变成 UncheckedIOException。
# 所以：先 kill 持有 fd 的进程，再 umount -l，顺序不能反。

# Step 4: 重启 containerd（如果 umount -l 后仍有残留）
systemctl restart containerd
# 这一步会杀掉该节点上所有容器（包括健康的），是最后手段

# Step 5: 恢复调度 + 验证
kubectl uncordon <node_name>
# 验证：ps -eo stat,pid | awk '$1 ~ /^D/' 输出为空
# 验证：dmesg | tail -20 没有新的 nfs: server not responding

二、客户端挂载参数建议（K8s NFS 场景）

你们当前的 vers=4,hard,timeo=600,retrans=3,lookupcache=none 有三个问题：

1. timeo=600（6 秒）对 K8s 场景太短。timeo 是 NFS RPC 超时（单位 1/10 秒），600=6 秒。但 K8s Pod 的 liveness probe 默认 timeout 是 1 秒、period 是 10 秒——如果 NFS 抖动 3 秒，你的 liveness 就失败了，K8s 会重启 Pod，但 D 状态进程杀不掉，Pod 卡在 terminating。建议 timeo=1000（10 秒），给内核 retransmit 留够窗口。

2. retrans=3 在 timeo=600 下意味着 18 秒就放弃。如果服务端只是 GC 停顿 20 秒，你的客户端已经放弃 3 次了。建议 retrans=5 或 retrans=8，配合 timeo=1000，总容忍窗口 50~80 秒。

3. lookupcache=none 是最大问题。这个参数关闭了 NFS 客户端的 dentry/inode 缓存，每次文件访问都要向服务端发 LOOKUP RPC。正常场景下，一个 Java 应用启动时加载 200 个 class 文件 = 200 次 LOOKUP RPC，如果 NFS 服务端稍有延迟（>10ms），启动时间从 2 秒涨到 5 秒。更危险的是：NFS 服务端故障时，lookupcache=none 意味着每次文件访问都会触发 RPC 超时，D 状态进程堆积速度是正常场景的 3~5 倍。我们集群之前也是这个参数，改成 lookupcache=pos（positive cache）后，同样的服务端故障，D 状态进程从 47 个降到 11 个——因为大部分文件访问命中了本地缓存，不触发 RPC。

推荐参数：

# /etc/fstab 或 K8s StorageClass 的 mountOptions
vers=4,hard,timeo=1000,retrans=5,lookupcache=pos,rsize=1048576,wsize=1048576
# hard：不放弃（配合合理的 timeo/retrans）
# lookupcache=pos：缓存成功的 lookup，失败的每次都重新查（安全）
# rsize/wsize=1MB：减少 RPC 次数，降低服务端压力

三、可观测性：持续采样 NFS 健康

你们当时最大的问题是「现场没有持续采样」，事后只能翻内核日志。建议在每个 NFS 客户端节点跑一个 cron（每 10 秒）：

#!/bin/bash
# /opt/monitor/nfs-health.sh
LOG=/var/log/nfs-health.log
TS=$(date '+%Y-%m-%dT%H:%M:%S.%3N')

# 1) NFS 客户端统计
nfsstat -c 2>/dev/null | awk '/^client rpc/{flag=1;next} /^client nfs/{exit} flag' >> /tmp/nfs-sample
# 2) 网络层：到 NFS 服务端的 RTT 和丢包
RTT=$(ping -c 1 -W 1 <nfs_server_ip> 2>/dev/null | awk -F'/' '/rtt/{print $5}')
# 3) D 状态进程数
D_COUNT=$(ps -eo stat | grep -c '^D' || echo 0)
# 4) 记录
echo "$TS rtt_ms=${RTT:-timeout} d_state_count=$D_COUNT" >> $LOG

关键告警规则：

• rtt_ms > 50 持续 30 秒 → P2 告警（NFS 网络开始劣化）
• d_state_count > 5 → P1 告警（D 状态堆积，准备止血）
• d_state_count > 20 → P0 告警（节点即将不可用，立即 cordon）

四、K8s 层面的隔离手段

K8s 1.28 目前没有 storage class 级别的「挂载超时」，但可以通过以下组合实现近似效果：

1. Pod 级：terminationGracePeriodSeconds: 60（给 NFS RPC 超时留够时间），配合 preStop hook 里 sync（把脏页刷到 NFS）+ sleep 5（等 sync 完成）。

2. 节点级：用 nodeSelector 或 taint 把 NFS 依赖的 Pod 限制在 2~3 个专用节点上。这样 NFS 故障只影响这 2~3 个节点，而不是 12 个节点全挂。你们当前 12 个节点都挂 NFS，等于「一个 NFS 服务端故障 = 全集群文件 I/O 不可用」，这个爆炸半径太大了。

3. 更优雅的方案：对无状态服务，把 NFS 换成 EFS/CephFS（带客户端超时和自动重连），或者把配置类数据（不需要文件 I/O 的）从 NFS 迁到 ConfigMap/etcd。NFS 只留给你真正需要 POSIX 文件语义的场景（比如日志共享、模型文件加载）。

五、一句话总结

你们这次 25 分钟故障的根因不是「NFS 参数没调对」，而是「12 个节点共享 NFS + 没有 cordon 机制 + lookupcache=none 放大了 RPC 风暴」三者叠加。止血时最该做的一步是第一时间 cordon，这一步 5 秒钟就能做，但能阻止 D 状态从 12 个涨到 47 个。

结论先行：NFS hard mount 下 D 状态进程无法被用户态信号杀死，这不是 bug 而是内核设计（TASK_UNINTERRUPTIBLE 不可被 kill -9 中断）。止血的核心不是"杀进程"，而是让内核 NFS 客户端放弃等待——即 umount -l（lazy unmount）把 mount 点从 VFS 命名空间摘掉，让后续 I/O 立即返回 -EIO 而非无限重试。下面按你问的 5 个点逐一展开。

1. 可复制的止血 Runbook（按顺序执行）

前提：确认服务端是否已恢复（ping <nfs-server> + rpcinfo -p <nfs-server>），分两种情况。

情况 A：服务端已恢复，但客户端进程仍 D

# Step 1: 定位 D 状态进程及其挂载点
ps -eo pid,stat,wchan:32,comm | awk '$2 ~ /^D/'
# 输出示例: 12345 D nfs4_wait_reclaimcomplete java

# Step 2: 找到对应的 mount 点
cat /proc/mounts | grep nfs4
# 输出: 10.0.1.5:/export/data /var/lib/kubelet/pods/xxx/volumes/kubernetes.io~nfs/data nfs4 ...

# Step 3: lazy unmount（关键操作）
umount -l /var/lib/kubelet/pods/xxx/volumes/kubernetes.io~nfs/data
# 效果: VFS 立刻将该 mount 从命名空间摘除，仍在该路径 I/O 的进程
#       下一次 syscall 返回 -EIO，D 状态解除

# Step 4: 如果 containerd 的 rm 仍卡（因为它持有旧 fd）
systemctl restart containerd
# 重启后 containerd 重新扫描，已 lazy umount 的挂载不再阻塞

# Step 5: K8s 侧清理残留 Pod
kubectl delete pod <pod> --force --grace-period=0 -n <ns>

安全边界：umount -l 后，仍持有该 mount 的进程后续 I/O 得到的是 -EIO（不是 EAGAIN/EINTR），所以：

• 业务代码必须有 I/O 重试逻辑（Java 的 NFS client 默认重试 3 次后抛异常）；
• 如果业务是"写日志到 NFS"且没有 catch，进程会 crash，但不会数据损坏（NFSv4 有 session 保护）。

情况 B：服务端未恢复（网卡 flap 未修好）

此时 umount -l 也救不了（因为 kernel 还在等 RPC 响应），顺序变成：

# 1. 先确认网络层
tcpdump -i eth0 -nn host <nfs-server> -c 5   # 看是否有 retransmit
# 2. 如果网络完全断，umount -l 仍然有效（让内核放弃等待）
umount -l <mountpoint>
# 3. 但注意：lazy umount 后如果网络恢复，该挂载点不会自动重新挂上
#    K8s 场景下 kubelet 的 volume manager 会重新 attach

二次伤害警告：

• ❌ 不要对 D 状态进程反复 kill -9——无效且浪费 CPU 在信号处理路径上；
• ❌ 不要在 umount -l 之前 fuser -km <mountpoint>——fuser 本身会阻塞在 I/O 上；
• ❌ 不要 echo 3 > /proc/sys/vm/drop_caches——对 NFS 无效（NFS 数据不在 page cache 的常规路径）。

2. 客户端挂载参数建议（K8s 场景）

你当前的参数：vers=4,hard,timeo=600,retrans=3,lookupcache=none

| 参数 | 当前值 | 建议值 | 理由 | |------|--------|--------|------| | hard | hard | hard（保留） | soft 会在超时后静默返回 EIO，导致数据不一致；K8s 场景必须 hard | | timeo | 600（=60s） | 100（=10s） | 单位是 1/10 秒；60s 意味着单个 RPC 要等 60s 才超时，D 状态堆积窗口太长。10s 足够覆盖正常 NFS 延迟（P99 通常 < 100ms），且让故障暴露更快 | | retrans | 3 | 5 | 配合 timeo=100，总等待 = 5×10s = 50s 后返回 EIO，比原来的 3×60s=180s 快很多 | | lookupcache | none | pos（默认） | none 关闭了 lookup 缓存，每次 open() 都要发 LOOKUP RPC 到服务端。在 12 节点 × 多 Pod 场景下，lookup 风暴会打满服务端 fd。改回 pos 后，同一路径的 lookup 在 actimeo 窗口内走本地缓存 | | actimeo | 未设 | 30 | NFSv4 下此参数被服务端 nfsd 的 acdirmin/acdirmax 控制，但客户端建议显式设 30s，平衡一致性与性能 |

修改方式（K8s NFS Provisioner）：

# 如果是用 nfs-subdir-external-provisioner
apiVersion: v1
kind: ConfigMap
metadata:
  name: nfs-provisioner-config
  namespace: kube-system
data:
  nfsMountOptions: "vers=4,hard,timeo=100,retrans=5,lookupcache=pos,actimeo=30"

或者在 StorageClass 的 mountOptions 里改：

kind: StorageClass
metadata:
  name: nfs-fast
provisioner: example.com/nfs
mountOptions:
  - vers=4
  - hard
  - timeo=100
  - retrans=5
  - lookupcache=pos
  - actimeo=30

改完后需要重建 PVC/Pod 才能生效（已挂载的不会热更新）。

为什么 lookupcache=none 会放大 lookup 风暴：Java 应用每次 new File("/data/xxx").exists() 或 new FileInputStream(...) 都会触发 VFS → NFS LOOKUP。假设 10 个 Pod × 每秒 200 次文件操作 = 2000 LOOKUP/s 打到 NFS 服务端。lookupcache=pos + actimeo=30 下，30 秒内同路径的 lookup 走本地缓存，实际 RPC 量降 99%+。

3. 可观测性：区分「服务端失联」和「客户端卡死」

部署一个节点级 DaemonSet 采样：

#!/bin/bash
# /opt/nfs-monitor.sh —— 每 5 秒采样一次，输出到 local 日志
LOG=/var/log/nfs-monitor.log
while true; do
  ts=$(date '+%Y-%m-%d %H:%M:%S')
  # 1. NFS 客户端 RPC 统计（关键指标）
  rpc_stats=$(cat /proc/net/rpc/nfs 2>/dev/null | head -5)
  # 2. NFS 客户端详细（retrans = 关键！）
  client_stats=$(nfsstat -c 2>/dev/null | grep -A2 "client rpcs")
  # 3. 挂载点 I/O
  mount_io=$(iostat -x 1 1 2>/dev/null | grep nfs)
  # 4. D 状态进程数
  d_count=$(ps -eo stat | awk '$1 ~ /^D/' | wc -l)
  
  echo "[$ts] D=$d_count" >> $LOG
  echo "  $client_stats" >> $LOG
  echo "  $mount_io" >> $LOG
  sleep 5
done

判据： | 指标 | 服务端失联 | 客户端卡死（参数问题） | |------|-----------|---------------------| | retrans 增长率 | 持续 > 0 且 sends 停滞 | retrans 高但 sends 仍有增长（说明网络通但响应慢） | | dmesg | nfs: server not responding, still trying | 无此日志，只有 nfs: server <ip> not responding, timed out | | tcpdump | 无任何包到达 | 有请求发出、有 ACK 回但无数据（服务端处理慢） | | D 状态进程 wchan | nfs4_wait_clnt_confirm / rpc_wait_bit_killable | nfs4_atomic_open / nfs4_do_setattr |

Prometheus 暴露（如果已有 node_exporter）：

# D 状态进程数
node_processes_state{state="sleeping_uninterruptible"}
# NFS retrans 速率
rate(nfs_client_retrans_total[5m])
# NFS 服务端超时次数
rate(nfs_client_timeouts_total[5m])

告警规则：rate(nfs_client_retrans_total[5m]) > 10 持续 2 分钟 → P2 告警。

4. K8s 层面的隔离手段

坦率说，K8s 1.28 对 NFS 的"优雅隔离"能力有限，但有几个可以做的事：

a) 用 CSI 替代 in-tree NFS Provisioner nfs-subdir-external-provisioner 是 in-tree 风格，没有 NodePublishVolume 超时。换成社区 csi-driver-nfs 后，CSI spec 里有 timeout 字段（默认 10s），超时后 kubelet 直接标记 Volume 为 FailedAttach，Pod 进入 ContainerCreating 而非卡 D 状态。

b) 节点级 systemd 超时 如果你用 systemd 管理 NFS 挂载（而非 kubelet 直接 mount）：

# /etc/systemd/system/mnt-data-nfs.mount
[Mount]
What=10.0.1.5:/export/data
Where=/data/nfs
Options=vers=4,hard,timeo=100,retrans=5
[Service]
TimeoutStartSec=30

TimeoutStartSec=30 意味着 systemd 在 30s 后放弃等待，标记挂载失败，后续 I/O 立即 EIO。

c) Pod 级隔离（有限）

• terminationGracePeriodSeconds 对 D 状态进程无效（kill 信号无法送达 TASK_UNINTERRUPTIBLE）；
• 唯一有效的 Pod 级手段是 preStop hook 里做 umount -l（但 K8s 不直接支持）；
• 实际做法：在业务容器里加一个 sidecar，监听 /healthz 失败后执行 umount -l：

containers:
- name: nfs-guard
  image: alpine:3.19
  command: ["/bin/sh", "-c"]
  args:
  - |
    while true; do
      if ! timeout 5 ls /data/nfs/ 2>/dev/null; then
        echo "NFS unresponsive, lazy unmount"
        umount -l /data/nfs 2>/dev/null
        exit 1
      fi
      sleep 10
    done
  volumeMounts:
  - name: nfs-data
    mountPath: /data/nfs

（这个方案有局限：sidecar 本身也可能 D 状态，但至少给了一个"看门狗"机会。）

d) 终极方案：别用 NFS 跑有状态业务 12 节点共享 4 台 NFS，单点故障半径 = 整个集群的 NFS 挂载。如果业务允许，换成：

• 对象存储（MinIO/Ceph RGW）+ FUSE（io_uring 路径短，D 状态概率低）；
• 或者 CephFS（MDS 有 active/standby，故障切换 < 5s）；
• 或者干脆把"文件"拆成"数据库记录 + 对象存储 blob"。

5. 我踩过的坑（对比参考）

去年我们一个 8 节点集群（K8s 1.26，NFS 同构）遇到完全一样的场景。区别是：

• 我们当时 timeo=1200（120s！），D 状态堆积了 40 分钟才手动处理；
• umount -l 后 containerd 没重启，结果 3 个 Pod 的 rm 仍然卡着（containerd 持有旧 fd）；
• 最终恢复路径：umount -l → systemctl restart containerd → kubectl delete --force → 节点恢复正常，总耗时 18 分钟（含排查）。

改完参数（timeo=100,retrans=5,lookupcache=pos）后，上个月又出了一次 NFS 故障（服务端磁盘 IO hang），这次 D 状态在 12s 内自动解除（5×10s=50s 超时 + 少量 buffer），umount -l 都没来得及执行，kubelet 自动重新 attach 了。

总结优先级：

1. 立刻改 timeo=100,retrans=5,lookupcache=pos（影响最大，改完重建 Pod）；
2. 本周加 nfs-monitor DaemonSet + Prometheus 告警；
3. 本季度 评估 CSI 替换 + 业务侧 I/O 重试加固；
4. 长期 如果 NFS 故障频率 > 1 次/季度，启动存储层迁移。