K8s中Hadoop Datanode故障排查：探针失败与磁盘满根因

周四下午，我正在盯着k8s集群的监控面板，突然收到Hadoop集群一条告警：某个datanode掉线了。这已经不是第一次处理这种问题，但每次的诱因都不完全一样。最开始我接到这类故障的第一反应是直接重启pod，但后来发现——重启往往只能解决表象，如果不找到根因，过两天同样的故障还会换个花样再来一遍。

这篇文章我准备把一次完整的k8s集群中Hadoop datanode故障排查过程整理出来，从最初的pod状态检查到最终的根因定位与修复方案，每一步怎么查、怎么看输出、怎么排除干扰因素，都会讲清楚。如果你正在维护一个运行在k8s上的Hadoop集群，或者正打算把Hadoop集群往容器化方向迁移，这篇文章里的排查思路和实操命令应该能帮你省不少时间。

1. 故障现场与第一波排查：现象往往比想象中复杂

1.1 从“一个datanode掉线”说起的实际故障现象

先说下我们当时的集群状况。一套运行了大半年的Hadoop集群，以StatefulSet方式部署在k8s里，共有5个datanode节点，每个datanode对应一个pod，底层数据目录用的是节点本地SSD。整体架构不算复杂，但足够覆盖生产使用场景。

告警触发点有两个：第一是k8s侧，datanode的某个pod状态变成了CrashLoopBackOff；第二是HDFS侧，监控脚本检测到存活datanode数量从5降到了4。两边的告警几乎同时过来，说明故障不只是容器层面的，已经影响到了数据面。

这里先说一个我从实践中得到的判断标准：如果只是pod状态异常但HDFS侧没有告警，问题往往出在容器生命周期上；如果两边同时告警，那基本可以确认是datanode进程本身真的出了问题。处理优先级上，我会先从HDFS侧切入，因为数据安全是整个集群的底线。

1.2 kubectl视角下的pod状态：先看表象，再做判断

第一波排查无非是那三板斧：看状态、看事件、看日志。我先执行了：

$ kubectl get pods -n hadoop -o wide NAME READY STATUS RESTARTS AGE datanode-0 1/1 Running 0 45d datanode-1 0/1 CrashLoopBackOff 3 45d datanode-2 1/1 Running 0 45d datanode-3 1/1 Running 0 45d datanode-4 1/1 Running 0 45d

问题pod是datanode-1，RESTARTS次数是3，状态CrashLoopBackOff。这个状态说明kubelet一直在尝试重启容器，但每次起来后不久就退出。CrashLoopBackOff本身不告诉你是进程崩溃还是探针失败，必须往下看日志和事件才能区分。

紧接着查describe：

$ kubectl describe pod datanode-1 -n hadoop ... Events: Warning Unhealthy Liveness probe failed: HTTP probe failed with statuscode: 500 Warning Unhealthy Readiness probe failed: HTTP probe failed with statuscode: 500 Warning BackOff Back-off restarting failed container

Event里出现了两个关键信息：Liveness probe failed和Readiness probe failed，状态码500。Hadoop里HTTP状态码500通常意味着datanode的web服务还活着，但健康状态检查不过——比如磁盘空间不足、线程池阻塞等情况。这里已经能初步排除“进程没起来”这种最简单的情况，问题大概率出在运行环境层面。

1.3 第一波排查中容易忽略的warning与event

很多人看到CrashLoopBackOff就直接重启pod或删掉重建，我不建议这么做。在删除或重启之前，必须先保存现场。尤其是describe里的Events记录和崩溃前的容器日志，这些是判断根因最重要的依据。

我补充了两个操作：

$ kubectl logs datanode-1 -n hadoop --tail=200 $ kubectl logs datanode-1 -n hadoop --previous --tail=200

--previous参数非常关键，它能看到上一次容器崩溃前留下的日志，而当前容器的日志往往因为进程刚启动就退出，什么都看不到。另外，我还检查了节点的状态：

$ kubectl get nodes -o wide $ kubectl describe node <node-name> | grep -A 20 "Conditions"

这一步是为了确认故障节点是否存在内存压力、磁盘压力、PID压力等问题，避免遗漏kubelet层面的诱因。排查到这一步时，我已经知道datanode-1所在的节点本身是健康的，问题大概率出在容器内部或数据目录上。

2. 从数据面到控制面的逐层复盘：这波排查链路踩过的关键点

2.1 先确认NAMENODE侧到底怎么看这个datanode

在k8s侧看到的状态是表象，接下来要做的，是从HDFS自己视角确认datanode的实际情况。Hadoop集群中，datanode是否“活着”是由namenode根据心跳来判定的，和k8s的pod状态完全是两套体系。这两套体系各自的判定结果还经常不一致——比如pod是Running，但namenode已经把datanode标记为dead。

我当时执行了：

$ hdfs dfsadmin -report ... Live datanodes (4): Name: 10.244.1.17:9866 (datanode-2.hadoop-ns.hadoop.svc.cluster.local) ... Dead datanodes (1): Name: 10.244.1.12:9866 (datanode-1.hadoop-ns.hadoop.svc.cluster.local) Hostname: datanode-1.hadoop-ns.hadoop.svc.cluster.local

注意这里，datanode-1已经出现在Dead datanodes列表里。这说明至少在namenode的判定周期内，datanode-1一直没有恢复心跳，而不是临时抖一下的问题。在HDFS的设计里，datanode会定期向namenode发送心跳，心跳丢失后一段时间内（取决于心跳间隔和失效阈值配置），namenode就会把它标记为dead。

这个时间窗口很关键。如果你在事件发生后的几分钟内就介入排查，还能从namenode的日志里看到datanode最后上报心跳的时间点，精确到毫秒级。这对于判断故障发生的具体时刻很有帮助。

2.2 磁盘空间、数据目录与block report的微妙关系

Datanode这个角色本质上是管数据的，它最敏感的就是磁盘空间。一旦数据目录所在的分区满了，datanode的很多操作都会跟着出问题：没法写新block、没法上报block变动、甚至心跳都会变得不正常。

我检查了故障pod挂载的数据目录：

$ kubectl exec -it datanode-1 -n hadoop -- df -h Filesystem Size Used Avail Use% Mounted on ... /dev/nvme0n1 100G 100G 0G 100% /data/dn

果然，数据目录所在的卷使用率已经是100%。这是个非常典型的场景：datanode的数据目录满了，导致健康检查接口返回500，最终liveness探针失败、容器被kubelet杀掉。容器重启后，datanode进程尝试启动，但数据目录还是满的，启动过程中无法正常完成block上报，于是又触发探针失败，再次被杀。这个循环就表现为CrashLoopBackOff。

这里有个很多人没意识到的细节：就算datanode进程能起来，它也不会像没事一样继续服务。磁盘满的情况下，datanode对外提供的是“能用但无法写入”的降级服务，看起来活着，实际已经失去数据服务能力。所以不能只看进程状态，必须确认数据目录可用空间。

2.3 K8s的探针机制和Hadoop健康检查是怎么互相影响的

K8s的livenessProbe和readinessProbe是两套不同用途的探针：liveness决定要不要重启容器，readiness决定要不要把流量调度过去。配置在Hadoop这类Java服务上时，有它特殊的坑。

我们当时用的是HTTP探针，目标是datanode的JMX或健康检查接口。探针的执行逻辑是kubelet每隔periodSeconds执行一次HTTP请求，如果请求在timeoutSeconds内没有返回，或者返回的状态码不是预期结果，就记为一次失败；连续失败次数超过failureThreshold，就会触发杀容器或摘流量。

这里存在一个隐蔽的错位：kubelet的探针是个“外部视角”，它不管你的JVM是不是在做FullGC、磁盘是不是在刷盘。只要响应慢，它就认为你挂了。Java进程在FullGC时，整个进程会有一段很长的停顿时间，几十秒甚至几分钟都有可能。如果探针的timeoutSeconds配置得比较激进，比如2秒、3秒，而JVM刚好在做FullGC，探针就失败；如果failureThreshold设置得也很低，那一次FullGC就足以让kubelet判你死刑。

更麻烦的是，当时的情况恰好是磁盘满，磁盘IO已经非常差，JVM的GC时间被无限拉长，探针几乎每次都失败。所以表面上看是探针失败导致的CrashLoopBackOff，实际根因是磁盘空间耗尽。这才是整个链路里最容易看走眼的地方：你看到的故障点是探针，真正的引爆点是磁盘。

3. 根因锁定：健康检查误杀、资源驱逐还是存储泄压？

3.1 三个候选原因是怎么筛出来的

结合前两轮排查，我已经把候选原因缩小到三类：健康检查误杀、资源驱逐、存储泄压。接下来就是用排除法逐个确认。

先排除资源驱逐。检查节点条件和pod的存活性，节点没有MemoryPressure或DiskPressure（至少当时没有），pod也没有被驱逐过，Resources的requests和limits配置也正常。可以把这项排除。

再排除健康检查误杀本身作为根因。虽然是探针失败导致容器被杀，但探针失败是有诱因的——磁盘满。如果只调探针参数而不解决磁盘问题，下次磁盘再满，一样的循环还会出现。所以健康检查误杀是整个故障链路的“执行环节”，但不是“根因”。

最后锁定存储泄压。数据目录100%满，datanode无法正常写入和上报block，这是整个链路的起点。磁盘满这件事不是一蹴而就的，它通常经历了一个缓慢的累积过程。我在复盘时去查了监控，确认了数据目录的用量在过去三周里从60%缓慢爬升到满，但我们的磁盘告警阈值设置为90%，按常理应该在90%时就已经收到告警——但实际上告警确实触发了，只是被当成了一般性通知，没有引起足够重视。这个点后面在预防措施里我也做了调整。

3.2 livenessProbe参数与JVM停顿时间的关系

确定根因后，再回头看探针参数就很清楚了。当时我们的配置大致如下：

参数	当时配置	建议参考配置
initialDelaySeconds	30	60
periodSeconds	10	30
timeoutSeconds	2	10
failureThreshold	3	3

问题就出在timeoutSeconds=2这个配置上。Java进程在任何一次FullGC超过2秒，探针就会失败；连续3次失败，容器被重启。在正常情况下这偶发的概率不高，但一旦磁盘IO恶化，GC时间急剧上升，这个配置就成了一颗定时炸弹。

这里我要强调一句：探针参数不是越小越“灵敏”，而是要匹配Java进程的实际响应特性。Java服务因为GC的存在，天然就有几百毫秒到几秒的响应波动区间，探针超时时间至少要留足10秒以上才算稳健。同时，如果你发现探针频繁失败，不要急着改参数——先搞清楚为什么失败，探针只是信号，不是问题本身。

3.3 K8s的驱逐机制和HDFS冗余策略叠加后的连锁反应

另外一个需要警惕的点是：当一个datanode故障时，HDFS不会坐视不管，它会自动把缺失的副本补回来。但副本恢复是有代价的。Namenode会把缺失的block任务分发给其他健康的datanode，这些datanode会复制数据块并上报。整个过程中集群的磁盘IO和网络IO都会明显上升。

如果在短时间内有多个datanode一起出问题，副本数会急剧下降，恢复时引发的额外负载可能拖垮剩余的datanode——这就是故障“雪崩”的典型路径。虽然这次我们只有datanode-1一个节点出问题，但我在排查时也特意检查了其他datanode的负载情况，确认它们的IO和CPU没有异常高企，才放心进行修复操作。

建议固定一个意识：任何单个datanode故障，都要检查集群整体负载。尤其是HDFS副本恢复期间，其他节点如果本来就处在很高负载下，很容易被“压垮”，变成连锁故障。

4. 修复落地与数据安全的双重验证

4.1 恢复datanode的完整操作序列

修复的第一步不是重启pod，而是先给数据目录腾出空间。当时临时清理了一批日志文件和一个长期未删除的临时目录，空间从100%降到了85%左右。然后才开始恢复datanode。

我给出的操作序列是这样的：

1. 确认磁盘空间已释放 2. 删除异常pod让StatefulSet重新调度 kubectl delete pod datanode-1 -n hadoop 3. 确认pod重新创建并变为Running kubectl get pods -n hadoop -w 4. 观察日志，确认datanode启动和注册过程 kubectl logs datanode-1 -n hadoop -f

这里有个细节：StatefulSet的pod删除后，会自动按名字重建，而且因为StatefulSet管理的pod名字是固定的，新pod会沿用原有的存储卷——前提是你使用的是RWO类型的PVC且卷能够重新挂载到新pod。如果你的datanode使用的是local PV，删除pod后，新pod会被调度到同一节点（因为volumeAffinity的限制），这一步通常没问题，但如果有节点亲和、调度约束等配置，需要提前验证。

4.2 如何确认HDFS侧真的完成了数据再平衡

Pod恢复Running只是第一步，真正要确认的是HDFS侧恢复了数据服务能力。我先看datanode是否重新注册成功：

$ hdfs dfsadmin -report Live datanodes (5): ... Name: 10.244.1.12:9866 (datanode-1.hadoop-ns.hadoop.svc.cluster.local) Hostname: datanode-1.hadoop-ns.hadoop.svc.cluster.local

Live datanodes数量和恢复前一致了。但这还不够，还需要检查数据块的副本状态是否恢复到了正常水平：

$ hdfs fsck / -files -blocks -locations ... Status: HEALTHY

fsck输出里的Status如果显示HEALTHY，说明没有缺失块；如果还有under-replicated的块，会显示具体数量。正常情况下，datanode恢复注册后，namenode会把该datanode上缺失的block信息重新注册回来，然后经过一段时间的block report，集群会自行完成副本恢复。全程一般需要几分钟到几十分钟不等，取决于数据量。

4.3 容器重启之后，block report恢复顺序的核对

最后一步我要做的是核对block report是否正常完成。这个环节容易被忽略，但它直接影响数据完整性。

Datanode启动时，会先扫描本地数据目录，在内存中建立block列表，然后向namenode发起一个最初的block report。之后是周期性的增量报告。如果block report一直没有成功上报，namenode会认为这个datanode上的数据块全部不可用，可能触发不必要的副本复制，白白消耗集群资源。

我在日志里确认了这段内容：

$ kubectl logs datanode-1 -n hadoop | grep "block report" 2025-05-20 14:32:18 INFO dfs.datanode.DataNode: DatanodeCommand: block report received 2025-05-20 14:32:18 INFO dfs.datanode.DataNode: Successfully sent block report to namenode

看到这条日志，基本可以确认datanode已经成功向namenode上报了本地block列表。到这里，这次故障的完整修复流程算是走完了，从发现到恢复大约40分钟。

5. 这类故障的预防措施：把排错经验变成运维防线

5.1 给K8s里的Hadoop调优时的几个必查参数

基于这次踩坑的经验，我在后续维护中形成了一份datanode部署时的参数检查表，在这里分享给你。

检查项	建议值/策略	说明
livenessProbe.timeoutSeconds	10	给JVM GC留出余地
livenessProbe.periodSeconds	30	降低探针频率，减少误判
resources.requests.memory	堆内存的1.5倍	留有堆外内存余量
resources.limits.memory	略大于requests	避免节点内存超卖导致OOM
terminationGracePeriodSeconds	60以上	确保datanode能优雅停机、完成safe mode相关操作

还有几个JVM层面的参数也值得注意：-XX:+UseG1GC、-XX:MaxGCPauseMillis=200可以在一定程度上缓解GC长停顿的问题；-Xmx和-Xms建议设置成相同的值，避免运行时堆扩容引发额外停顿。

5.2 监控与告警配置的参考指标

这次故障暴露出来的最大监控盲区，是我们没有对磁盘使用率设置分级的告警阈值。只是设置了90%的告警，结果真等到90%时，距离实际挂掉已经没有多少缓冲时间了。我后来把磁盘监控改成了多级告警：

• 数据目录70%时警告，属于提醒级别
• 数据目录85%时严重告警，需要立即处理
• 数据目录95%时紧急告警，需要马上停止写入并排查

除此之外，还有几个持续在盯的指标：

• LiveNodes数量变化
• UnderReplicatedBlocks数量
• DataNode的JMX指标，比如DfsDatanodeBlockCount、DfsDatanodeReadWriteStatus
• Pod重启次数和探针失败次数

UnderReplicatedBlocks这个指标特别重要，但它的波动具有一定的滞后性。从datanode失联到namenode判定dead，再到安排副本复制，中间有数分钟的延迟。所以这个指标更适合在故障恢复后持续观察，而不是当作实时告警。

5.3 常规演练：故障注入与恢复时间目标验证

纸上谈兵没有意义，我们后来把故障处理做成了定期的演练科目。方法是主动制造故障，验证监控、告警、排查链路和恢复时间是否都符合预期。

具体做法是：每个月挑一个低峰时段，在测试环境里手动执行kubectl delete pod datanode-xxx -n hadoop，甚至模拟磁盘满的场景。然后记录从pod删除到HDFS侧完全恢复用了多长时间，和预期的恢复时间目标（RTO）对比。如果发现恢复时间超过预期，就回头检查是副本恢复太慢，还是监控告警链路有延迟。

这个演练帮我发现过一个问题：当datanode被删除后，因为StatefulSet自动重建，pod短时间内就能起来，但HDFS侧的副本恢复花了将近一个小时才完成。后来排查发现是dfs.namenode.replication.max的默认并发限制，数量设小的时候对大批block的恢复速度影响很大。调大后，恢复速度明显加快。

最后再分享一点个人的实操体会

踩过这次坑之后，我对k8s集群里跑Hadoop组件有了一个比较深的感受——k8s的探针和HDFS的心跳是两套完全独立但又互相影响的机制，排查任何datanode故障时，必须同时从两个体系去看，不能只信一边。你看，pod状态正常但HDFS侧已经标记dead的情况可能发生，相反，pod处于CrashLoopBackOff但HDFS还没来得及判dead的情况也可能发生。

更重要的一个体会是，排错时优先找“源头”，不要被表面现象牵着走。这次故障的第一现场是探针失败，但如果我当时只盯着探针参数去调整，磁盘满的问题就会继续潜伏，迟早还会用另一种方式爆出来。探针失败、容器重启这些都是结果，不是原因。先找到那个触发这一切的底层变化——无论是磁盘、内存、网络还是配置，才能让集群真正稳定下来。

下次如果你也遇到类似的datanode故障，建议按照这个顺序排查：先看pod和事件，再看HDFS侧的心跳状态，然后确认磁盘空间和系统负载，最后再决定是调整探针参数、释放磁盘空间还是需要重新调度pod。这套思路放在大多数容器化的大数据组件，比如hbase的RegionServer、kafka的broker上，也都是通用的。