1. 故障现象与第一反应1.1 凌晨那一串报警datanode容器反复重启先说结论这不是一个罕见的边缘问题。把Hadoop跑在Kubernetes上以后datanode故障会以一种特别拧巴的方式呈现出来跟裸机部署时代完全不一样。裸机上datanode挂了顶多进程没了你跑去看stdout就行在K8s里挂了你看到的是Pod反复重启、Pending、CrashLoopBackOff甚至看起来“活着”但实际已经被Namenode标记为dead排查路径绕了一大圈。我这次碰到的场景是这样的K8s集群里部署了一个Hadoop 3.3.xdatanode用的是StatefulSet方式每个副本对应一个有状态数据节点数据目录挂的是块存储PVC。某一晚大概22点Prometheus告警开始响——datanode的HDFS容量指标消失紧接着k8s的事件流里出现BackOffdatanode-0这个Pod进入了CrashLoopBackOff状态重启计数器一路往上跳。当时第一反应不是去重启Pod而是先把故障面圈出来。因为CrashLoopBackOff只是个表象真正的问题可能在磁盘、在JVM参数、在资源限额甚至在PVC的底层存储。盲目重启解决不了任何问题而且会掩盖日志里的关键线索。所以我先看了三样东西Pod状态、Events、退出码。退出码是第一个关键信号。如果你用kubectl get pod看到容器一直在重启一定要加-o wide或者describe查退出码。137是SIGKILL表示超出了资源配额被系统杀掉143是SIGTERM通常是优雅关闭超时后强杀1或2一般是JVM自己退出。这三个退出码对应的排查方向完全不一样后面我会细说。1.2 先给场景定性这不是Hadoop单机问题而是容器化Hadoop的共性问题很多人在K8s上跑Hadoop是把它当成一个“可以自动重启的分布式数据库”来用的。但实际上Hadoop的datanode是个有状态服务它对“进程存活”和“数据可用”的看法跟Kubernetes的探针直觉完全不同。Kubernetes默认认为“容器还在跑”就是健康所以readinessProbe如果配得不得当datanode卡在半死不活的状态时K8s不会干预。Hadoop的NameNode那边则认为datanode只要超过heartbeat超时默认3秒一次心跳超时10分钟考虑为dead就把这个节点标记为离线。两边判定机制不同这就导致一个很麻烦的现象你从K8s那边看Pod是Running的但从HDFS看这个节点已经没了。所以这篇文章里我会围绕一个核心思路展开排查datanode故障必须同时看K8s给的信号和Hadoop给的信号两边对照才能定位到根因。文章后面给的排查步骤、命令、参数、坑点都是我从实际运维中整理出来的适合在K8s上跑Hadoop的团队参考。2. 排查思路从现象到根因不要一上来就瞎重启2.1 先看Kubernetes资源状态再看Hadoop进程本身我习惯的排查顺序是先K8s后Hadoop倒不是K8s优先级更高而是K8s能最快告诉我“系统层面发生了什么”。具体来说分四步走第一步看Pod状态和分布情况。命令是kubectl get pod -n hadoop -o wide注意看Pod落在哪个节点因为datanode如果因为磁盘、PvcAttach之类的问题调度失败会卡在Pending。如果多个datanode同时挂还要看是不是同一个Node都挂了——那问题可能出在宿主机层面比如IO饿死、磁盘故障、网络分区。第二步看Events。kubectl describe pod datanode-0 -n hadoop这是最直观的事件流。你能看到FailedMount、Unhealthy、OOMKilled、BackOff这些关键词。这些关键词基本已经把问题分类好了后面处理会快很多。第三步看日志。这里有一个很多人踩过的坑kubectl logs datanode-0默认拿的是当前这个容器的输出但容器都CrashLoop了拿到的往往是最近一次启动的日志不是崩溃前的。正确操作是kubectl logs datanode-0 --previous这样才能读到上一次退出前的JVM日志。如果你连previous都没看到东西说明日志打到stdout之外的路径了得进容器翻logs目录。第四步回到Hadoop本身。进入NameNode容器跑hdfs dfsadmin -report。看输出里的Live datanodes和Dead datanodes列表。这个命令是判断“Hadoop实际受影响范围”的最终依据。这套顺序的核心逻辑是先把故障外沿摸清再往下钻。就像修房子漏水先看哪面墙湿了再拆墙别一上来就对着水管凿。2.2 三类高频故障根因磁盘、内存、网络在我的经验里容器化datanode出问题80%能归到下面三类。磁盘相关。K8s里datanode的数据目录往往是PVC。如果块存储容量打满datanode进程写block文件时直接抛No space left on device异常。诡异的是这个异常不一定会立刻导致进程崩溃很多时候是持续打日志、写不进去、NameNode那边心跳还在但块汇报全部失败最终被Namenode判定dead。这类问题在Prometheus里看HDFS容量和使用率最明显。内存相关。datanode的JVM堆设置如果跟Pod的limits不一致就会出问题。比如你在hadoop-env.sh里写export HADOOP_DATANODE_OPTS-Xmx4g但Pod的memory limit只有2Gi那么JVM运行一段时间堆用完以后操作系统开始给容器施压最终触发K8s的OOMKilled退出码137。还有一种情况是JVM设置正常但宿主机内存紧张Pod被驱逐状态变成Evicted。网络相关。这个比较隐蔽。K8s集群里如果用了NetworkPolicy或者节点间安全组规则有问题datanode可以与NameNode建立连接但心跳包会丢弃或延迟。Hadoop的心跳超时是10分钟一旦超过NameNode直接把这个datanode标记为Dead。你去看Pod可能是Running进程也在但就是干不了活。三类问题里磁盘最常见网络最隐蔽内存最容易配错。我建议排查时先磁盘、再内存、最后网络。2.3 一个容易忽略的检查项Pod的调度约束与漂移还有一类问题在排查时很容易被忽略Pod调度本身。datanode绑定的是PVC如果你用的是regional块存储比如某些云平台的云盘它是有拓扑约束的——只能在特定的可用区或节点上挂载。K8s调度器在调度Pod时如果节点选择器、容忍度、存储拓扑之间的关系没处理好就会导致Pod错误调度到另一个节点PVC挂不上去一直Pending。这种问题在全新的K8sHadoop环境里很常见。你按照裸机思维把datanode当成无状态服务随便调度结果状态起不来。所以我强烈建议datanode用StatefulSet加稳定的PVC配好nodeSelector别让它漂移。还有一种更隐蔽的Kubernetes节点维护场景。比如节点要升级内核你cordon了节点drain了Pod。datanode被驱逐后因为PVC跨节点不可挂载新Pod起不来。在HDFS层面这个datanode会一直Dead直到你手动干预。这类问题虽然没有“CrashLoop”那么吓人但对HDFS的副本健康影响很大。3. 实操过程一步步处理数据节点故障3.1 确认故障面Pod状态、退出码、事件不绕弯子先给出一套可以直接抄的命令序列。# 查Pod整体状态注意退出次数和AGE kubectl get pod -n hadoop -o wide | grep datanode # 查具体Pod的事件和退出码 kubectl describe pod datanode-0 -n hadoop # 查看最近的日志如果是CrashLoop务必加--previous kubectl logs datanode-0 -n hadoop --previous --tail200我那次故障里kubectl get pod输出显示datanode-0处于CrashLoopBackOffRESTARTS显示23次这就是一个典型的反复退出场景。describe里的Events出现了一条Last State: TerminatedExit Code: 137。看到137第一反应就是内存超限被杀。但先别急着调内存。我用kubectl logs --previous看了一下崩溃前的日志结果发现日志末尾有大量Exceptionjava.io.IOException: No space left on device。这一下子就奇怪了——退出码是137日志却是磁盘写满仔细再往下看才发现datanode的data目录写满后JVM在做block report时频繁触发GCGC线程在写GC日志时把磁盘彻底打爆随后容器因为内存不足被K8s杀掉。如果没有--previous参数我只会看到“OOMKilled”这一个表象根本不会想到磁盘才是真凶。所以这个参数真的值得养成习惯。拿到这个信息后我马上又开始查PVC的使用率。命令也很简单kubectl get pvc -n hadoop kubectl describe pvc>kubectl exec -it datanode-0 -n hadoop -- bash ls -lrt $HADOOP_HOME/logs/ tail -n 100 hadoop-hadoop-datanode-*.log其次崩溃类型的判断日志关键字会对上退出码。Exit Code 1通常是datanode自己初始化失败比如core-site.xml里fs.defaultFS配置成localhost之类或者本机ID不匹配Exit Code 137通常是容器被杀原因可能是memory limit超了也可能是磁盘IO卡死导致K8s判定无响应Exit Code 143通常是优雅关闭超时被kill常见于StatefulSet滚动更新或节点驱逐场景严格来说不是进程本身出错。还有一类很典型日志里看到的是java.net.ConnectException: Connection refused指向NameNode的9000端口。这种问题在K8s里特别容易混淆——从datanode容器里看NameNode Service是否存在、DNS解析是否正确、NetworkPolicy是否放行。你单纯的telnet测试也不一定对因为容器网络跟宿主机网络不一样。我建议这样检查# 进入datanode容器测试NameNode服务连通性 kubectl exec -it datanode-0 -n hadoop -- sh -c nc -vz namenode 9000 # 用nslookup查DNS解析 kubectl exec -it datanode-0 -n hadoop -- nslookup namenode日志读到这一步基本能把故障分类定了磁盘满、OOM、网络不通、配置错误。接下来的修复动作才有针对性。3.3 磁盘故障的完整恢复流程案例一回到我那次故障。确认是磁盘使用率98%以后我先是分析了一下数据盘里到底什么东西占满了。用du命令扫一遍发现除了HDFS的block数据外还有一堆日志文件占了几十GB甚至还有hadoop的tmp目录里残留的大文件。这里先说一个经验不要直接盲目扩容PVC。如果底层是块存储扩容可能不支持热扩容需要重建Pod而且你的K8s版本、StorageClass配置也要支持AllowVolumeExpansion。在扩容之前更应该先检查数据是不是真的已经没用。我的处理步骤是这样# 第一步找到大目录 du -sh $HADOOP_HOME/logs/* | sort -h du -sh /data/dfs/dn/* | sort -h # 第二步清理掉可回收的日志和大文件 # 比如保留最近7天日志其余压缩或删除 find $HADOOP_HOME/logs -mtime 7 -name *.log* -exec rm -f {} \; # 第三步如果HDFS容量本身也快满要结合hdfs的均衡策略清理完日志后用df -h重新确认使用率降到了80%以下。这时候我没有急着去让Pod自动重启。因为HDFS的datanode在异常退出后它的内存状态里还有一部分block信息没有汇报给NameNode直接重启虽然也能重新注册但如果数据目录里还有一些未完成的tmp文件可能导致部分block校验失败。所以我做了一件关键动作进入容器手动清理每个写了一半的临时文件。HDFS的block写入期间会生成带.tmp后缀的文件如果进程被杀这些文件会残留在数据目录里重启后会占用空间也影响启动时的fsck检查。# 确认tmp文件 find /data/dfs/dn -name *.tmp -type f | head -50 # 确认这些文件确实不再被引用后删除等我确认数据目录干净了才修改了StatefulSet里的重启策略把Pod标记删除一下让它重新调度。这里要注意StatefulSet的Pod删除后由于PVC保留数据不会丢Pod会重新创建并挂载同一块PVC。算是容器化Hadoop相对裸机的一个好处——节点宕机数据盘跟着Pod走前提是存储系统支持跨节点挂载。重启后datanode先进入Registration状态然后开始BlockReport。几分钟后在NameNode里执行hdfs dfsadmin -reportLive datanode的数量恢复故障就算初步解决了。3.4 内存限制导致的OOM恢复流程案例二第二个案例是datanode没有磁盘问题日志也干净但Pod频繁被OOMKilled退出码137Events里写着: Memory cgroup out of memory: Kill process。这是K8s与JVM搭配时最经典的一个矛盾。为什么说矛盾因为JVM默认的堆配置和容器cgroup的内存感知是不一致的。如果你的镜像里是OpenJDK 8它默认从宿主机读取/proc/meminfo取值默认最大堆可能是宿主机的1/4或1/2。如果宿主机内存很大JVM认为自己可以用很大内存但实际上容器cgroup限制了1GiJVM很快就把进程内存推到limit上限K8s直接杀。我的修复方法分为两步。第一步是显式设置JVM堆参数让堆大小适配Pod限额# 在hadoop-env.sh里修改或新增 export HADOOP_DATANODE_OPTS-Xms512m -Xmx1024m -XX:UseContainerSupport -XX:MaxRAMPercentage50.0注意UseContainerSupport这个参数在JDK 8u191和JDK 9才支持。如果你的Hadoop镜像用的JDK版本太老最好直接显式指定-Xmx不要只靠MaxRAMPercentage。这里我踩过坑镜像里是OpenJDK 8u172当时不支持UseContainerSupport于是堆内存直接又爆了。第二步是检查K8s层面的resources配置。datanode的StatefulSet里requests和limits不能写得太离谱。我的建议是limits.memory 2Gi那JVM的-Xmx就写1.5Gi留出至少几百MB给非堆内存、线程栈、元空间和GC的额外开销。如果只有1Gi的limitXmx给768m左右比较稳。修复之后用kubectl rollout restart statefulset/datanode -n hadoop滚动重启。滚动过程中注意观察因为datanode是有状态服务滚动重启会触发HDFS的replicationNameNode会感知到节点下线、上线。如果你的副本数很少比如只有1个副本滚动重启期间宁可手动逐个删Pod也不要一次性滚完避免HDFS短时间内丢失过多副本。4. 影响范围与深层原理为什么必须把故障节点从HDFS集群中摘掉4.1 HDFS副本机制三副本不是绝对保险很多人在K8s上跑Hadoop都会说“三副本很安全”但这句话的前提是副本分散在不同的故障域里。K8s集群里如果你有3个datanode副本策略是3那么数据块会被复制到3个datanode上。但这3个datanode如果因为某种原因同时挂掉HDFS里就真的一块冗余都没有了。更常见的风险是你以为自己有3个副本但因为之前发生过故障某些数据块实际副本数只有2甚至1这时候再挂一个节点就有数据丢失的风险。所以在处理datanode故障时一定要先看hdfs fsck报告确认故障节点的副本负载。命令hdfs fsck / -files -blocks -locations | tail -50输出里能看到Under-replicated Block的数量。如果故障节点上的块副本数低于2且你要做的操作是彻底替换节点那就必须先把数据补完再下线不能急。4.2 离线节点不处理会有什么后果datanode故障如果长时间不处理影响是逐步放大的。第一阶段HDFS容量减少集群可用存储下降。第二阶段由于副本数下降NameNode会持续调度块复制后台复制任务占用带宽和CPU业务读写性能开始波动。第三阶段如果故障节点上的块副本数降到2以下甚至1NameNode会把相关文件标记为缺失数据可用性直接受影响。等到真的要读取这些文件时客户端会抛IOException。还有一个很多人忽略的点离线节点上的BlockReport如果持续失败NameNode的内存里会保留这些块的位置信息造成元数据膨胀。虽然NameNode会对超时节点标记为Dead并清掉它的块位置但如果你的datanode只是被K8s驱逐、PV还挂着NameNode可能认为它只是暂时失联块的位置不会立刻清除期间的元数据状态会比较混乱。所以我处理这类故障的原则是能恢复就尽快恢复恢复不了就主动退役。不要让它一直处于Dead和Alive之间反复横跳这种状态对HDFS最伤。4.3 节点退役与重启的时机选择节点什么时候可以重启什么时候必须退役我的判断标准是看“故障类型 副本安全”。如果只是内存参数写错、配置错误这一类非数据损坏问题重启是安全的。如果是磁盘损坏、文件系统异常、PV数据不完整建议走退役流程。退役操作并不复杂。先把datanode加进excludes文件然后执行hdfs dfsadmin -refreshNodes。NameNode会把这个节点标记为Decommission In Progress后台把它的block逐步复制到其他节点。这个过程会持续一段时间时间长短取决于数据量。等状态变成Decommissioned再把节点彻底移除。但这里也有一个K8s场景的特殊坑StatefulSet的Pod被重新调度后hostname会保持相同如果你只是删Pod不删PVCdatanode重新启动后会重新向NameNode注册。如果之前没有执行过退役注册后它会重新加入集群这没问题。但如果之前执行过退役NameNode的excludes列表里还有它重新启动后它会被再次排斥。所以在做退役时要同步更新ConfigMap里的excludes文件否则会出现“节点已退役但重启后又想加入”的奇怪状态。5. 常见问题与避坑技巧实录5.1 重启策略的坑datanode的容器重启策略设置成Always是常规选择但我不建议在StatefulSet里用默认的Always就撒手不管。有一种场景容器每次启动后都能运行一小段时间然后因为内存增长被OOMKilledK8s会按BackOff周期反复重启这个周期从10s、20s一直翻倍到300s。这期间NameNode那边会看到datanode不停地上线、下线、再次注册导致大量的block报告积压集群整体性能下降。我的做法是遇到这种“反复注册”的情况先把副本数scale到0确认数据安全后再恢复kubectl scale statefulset datanode --replicas0 -n hadoop # 处理好配置问题后 kubectl scale statefulset datanode --replicas3 -n hadoop这个操作看起来激进但实际很安全。因为datanode下线后NameNode会启动replication去补足副本只要你的集群还有足够多的存活节点这个过程会自动完成。比让故障节点反复横跳要稳得多。5.2 容器镜像里JVM堆参数的坑Hadoop的官方镜像和你自己在Dockerfile里构建的镜像JVM参数配置差别很大。官方镜像一般已经把HADOOP_DATANODE_OPTS定义好你在K8s里可以通过env覆盖自己构建的镜像一定要在hadoop-env.sh里把堆参数写清楚否则默认值很可能不合适。我建议给datanode统一加上这些参数export HADOOP_DATANODE_OPTS-Xms1g -Xmx2g -XX:UseG1GC -XX:MaxDirectMemorySize512m $HADOOP_DATANODE_OPTS堆不要超过Pod limit的70%。直接内存Direct Memory要给够datanode在传输block时大量使用堆外内存默认值有时不够。我踩过一次MaxDirectMemorySize不足导致dfs数据写入失败的问题日志里报Direct buffer memory。如果你用了Hadoop 3.x还可以考虑把netty的direct memory配置也检查一遍。5.3 数据目录挂载的坑K8s里datanode的数据目录挂载方式直接决定了故障恢复的难度。我在生产环境里的标准做法是这样每个datanode的dfs.datanode.data.dir指向一个独立PVC不要多个目录共用一个PVC。原因很简单如果PV损坏影响范围能控制在一个datanode内而不是多个datanode同时挂。还有一点PVC的回收策略Reclaim Policy要设置成Retain千万别是Delete。一旦你误删PVC底层存储直接清了HDFS上的数据再也找不回来。这个属于惨痛教训很多人把statefulset删掉后才发现PVC没了数据没了欲哭无泪。另外PV的访问模式必须是ReadWriteOnce因为datanode的数据目录同一时间只能被一个Pod挂载。如果你不小心把多个datanode指向同一个ReadWriteMany的PVHDFS会直接因为“数据目录冲突”启动失败。5.4 排障命令速查表我把常用操作整理成了一张表方便大家查目的命令查看datanode Pod状态kubectl get pod -n hadoop -o wide | grep datanode查看Pod事件和退出码kubectl describe pod datanode-0 -n hadoop查看崩溃前日志kubectl logs datanode-0 -n hadoop --previous进入容器查看文件日志kubectl exec -it datanode-0 -n hadoop -- bash查看HDFS节点状态hdfs dfsadmin -report查看数据块副本健康hdfs fsck / -files -blocks -locations检查节点退役状态hdfs dfsadmin -getDecommissioningStatus刷新节点排除名单hdfs dfsadmin -refreshNodes查看PVC使用率kubectl describe pvc>