服务器K8s集群Hadoop排错：从Pod异常到任务失败的排查思路

在Kubernetes集群里运行Hadoop时，报错通常不会直接告诉你是哪一层出了问题。
它可能来自Pod调度、容器启动、网络解析，也可能只是YARN任务本身配置不对。
排错的第一步不是急着改配置，而是先确认故障发生在哪一层。

本文按Pod状态检查、容器日志定位、网络与资源验证、任务层复查的顺序展开，每一步都给出可执行的命令和预期结果。
适用前提是你已经有一套可用的K8s集群，并且用Pod或Operator方式部署了Hadoop组件。

先看Pod状态，判断问题层级

Hadoop在K8s上通常以多个Pod形式运行，比如NameNode、DataNode、ResourceManager、NodeManager。
任何组件异常，先执行：

kubectl get pods -n  -o wide

重点关注三列：STATUS、RESTARTS、NODE。

• Pending：调度失败，常见原因是节点资源不足、污点未容忍、PVC未绑定。
• CrashLoopBackOff：容器反复退出，需要看容器日志和退出码。
• Running但READY为0/1：容器进程在，但探针未通过，Hadoop服务可能没真正就绪。
• Error或Completed：一次性任务结束或异常退出，需要确认是否符合预期。

如果Pod处于Pending，继续查事件：

kubectl describe pod  -n 

看Events部分。
出现Insufficient memory说明节点资源不够；
出现node(s) had taint说明需要加toleration；
出现waiting for pod to be scheduled且PVC是Pending，则要检查StorageClass和PVC绑定状态。

容器日志里找Hadoop自己的报错

Pod状态正常不代表Hadoop服务正常。
进入日志排查：

kubectl logs  -n  --tail=200

如果Pod重启过，加--previous看上一次退出前的日志：

kubectl logs  -n  --previous

Hadoop组件常见日志位置在容器内/opt/hadoop/logs/或/usr/local/hadoop/logs/，具体取决于镜像构建方式。
可以先进入容器确认：

kubectl exec -it  -n  -- bash
ls /opt/hadoop/logs/

NameNode启动失败常见原因包括：dfs.namenode.name.dir指向的目录不可写、集群ID不一致、格式化残留。
DataNode反复掉线则优先看它能否连上NameNode的RPC端口，默认是8020或9000，以你的core-site.xml为准。

ResourceManager日志里如果出现Connection refused到NodeManager，
说明NodeManager没注册上，
需要回到NodeManager Pod检查它是否正常监听。

网络与资源：两个最容易忽略的检查点

Hadoop组件之间依赖主机名和端口通信。
K8s里Pod IP会变，所以通常用Headless Service或StatefulSet的稳定DNS名。

先确认Service和Endpoints：

kubectl get svc -n 
kubectl get endpoints -n 

如果Endpoints为空，说明Pod的label和Service的selector不匹配，或者Pod没Ready。

在Pod里测试连通性：

kubectl exec -it  -n  -- bash
ping 
telnet  8020

telnet不通时，先检查core-site.xml里fs.defaultFS写的是不是Service名和正确端口。
如果写的是Pod IP，Pod重建后必然失效。

资源方面，Hadoop对内存敏感。
容器内存限制过低时，JVM可能被OOM Kill，Pod显示OOMKilled。
查看退出原因：

kubectl describe pod  -n  | grep -A2 "Last State"

如果确认是OOM，需要调大resources.limits.memory，同时确认Hadoop的mapred-site.xml、yarn-site.xml里JVM堆参数没有超过容器限制。
堆内存加堆外内存超过limit，同样会被杀。

任务层排错：YARN任务卡住或失败

Pod和网络都正常，但提交到YARN的任务失败，问题就在任务配置和资源队列。

先看ResourceManager Web UI或命令行：

yarn application -list
yarn application -status 

状态长期停在ACCEPTED，通常是队列资源不足或调度器配置限制。
检查yarn-site.xml里的yarn.resourcemanager.scheduler.address和队列容量。

如果任务报Container killed by YARN for exceeding memory limits，说明Container内存超限。
需要调整yarn.nodemanager.resource.memory-mb和单个Container的mapreduce.map.memory.mb、mapreduce.reduce.memory.mb。

任务日志可以通过：

yarn logs -applicationId 

查看具体是哪个Container失败，再回到对应NodeManager Pod日志里找堆栈。

避坑清单

• 不要用Pod IP做Hadoop配置，Pod重建后IP变化会导致通信中断，应使用Service DNS名。
• 格式化NameNode前先确认数据目录，误格式化会清空元数据，生产环境务必先备份。
• JVM堆参数要和容器limit匹配，堆内存加直接内存超过limit会被OOM Kill。
• 修改ConfigMap后要重启对应Pod，Hadoop不会自动热加载core-site.xml等配置。
• 时区不一致可能导致任务时间异常，容器内建议统一设置TZ环境变量。

验证修复效果

改完配置后，按这个顺序验证：

1. kubectl get pods -n 确认所有Hadoop组件Running且READY。
2. kubectl logs确认启动日志没有ERROR或Exception。
3. 在NameNode Pod里执行hdfs dfsadmin -report，确认DataNode数量正常。
4. 提交一个简单WordCount或hdfs dfs -ls /测试读写。
5. yarn application -list确认任务能正常完成。

如果某一步不通过，回到对应层级继续排查，不要同时改多个配置，否则很难判断是哪一处生效。

常见疑问

Pod一直Pending，但节点资源看起来够，怎么办？

检查节点是否有污点、PVC是否绑定、Pod是否指定了不存在的nodeSelector。
用kubectl describe pod看Events最直接。

Hadoop Pod能启动，但DataNode一直不注册到NameNode，怎么查？

在DataNode Pod里telnet 8020，不通就是网络或配置问题；
通了但不注册，看DataNode日志里的clusterID是否和NameNode一致。

改了ConfigMap，Pod重启后配置没生效？

确认Pod确实挂载了该ConfigMap，并且重启的是使用该ConfigMap的Pod，不是其他组件。
可以用kubectl exec进入容器cat对应配置文件确认内容。

服务器K8s集群Hadoop排错的核心思路是分层定位：先看Pod状态，再看日志，然后查网络和资源，最后回到YARN任务本身。
每一步都有对应的命令和验证点，按顺序排查比盲目改配置更有效。