前阵子帮团队做了一次迁移把跑在虚拟机里的一套 Hadoop 3.3.x 集群搬到了 Kubernetes 上。底层系统是 Debian 11上面搭了一个三控三算的 K8s 集群整套环境从规划、部署到调优前后花了大概两周。这不是一篇纯理论分析而是把我在实际操作中踩过的坑、验证过的配置以及各个参数在真实负载下的表现完整记录下来。如果你也想在 Debian 11 上用 Kubernetes 部署和管理 Hadoop 集群或者已经在折腾但被各种问题卡住这篇内容应该能帮你少走不少弯路。我按整个落地链路把内容拆成七个部分为什么用 K8s 管 Hadoop、环境准备、部署方案设计、实操部署、存储与计算效率优化、日常运维与监控、常见问题排查。其中存储和计算效率的优化是重点因为集群部署起来只是第一步能让它在大数据负载下稳定输出才是真正花时间的地方。1. 为什么要用 Kubernetes 部署 Hadoop1.1 传统 Hadoop 部署方式的痛点早些年搭 Hadoop 集群最常规的做法就是准备一堆服务器每台机器手动装 JDK、配环境变量、分发 Hadoop 安装包然后逐个修改core-site.xml、hdfs-site.xml、yarn-site.xml。这套流程有多繁琐凡是从 CDH 或者 Apache 原生部署时代过来的人都懂改一个参数要同步到全集群节点一多就极其容易漏改扩容要先准备机器、装系统、配网络一套流程走下来至少半天某个 DataNode 突然挂了NameNode 这边开始报块丢失运维就要手忙脚乱地登录机器看日志、重启进程。整个过程基本靠人工盯出了问题只能被动响应。我见过不少团队把 Hadoop 集群的部署脚本写成了几百行的 Shell里面全是 scp、ssh、sed 替换看着很唬人实际上换个网络环境就各种报错。这种方案最大的问题在于它把 Hadoop 集群当成了静态基础设施但大数据集群本身是动态的业务量涨了要加节点业务量跌了希望能缩容省资源。用传统方式做这些每次都是折腾。1.2 K8s 给 Hadoop 集群带来的实际收益Kubernetes 解决的核心问题是把手工运维变成声明式管理。你需要几台 DataNode直接改 StatefulSet 的副本数NameNode 挂了K8s 会根据健康检查自动把 Pod 重新调度要升级 Hadoop 版本改一下镜像 Tag 再滚动重启不需要逐台去 SSH 操作。这些能力对于跑在 K8s 上的大数据集群来说是实打实的收益。另一个大的好处是资源池统一。以前大数据集群和其他微服务是各自独立的资源池计算节点要么闲置要么不够用。上了 K8s 之后大家共用一套基础设施通过 Namespace、ResourceQuota 做资源隔离哪个团队需要多少资源一目了然。我们团队之前有一批 Spark 任务跑在物理机上高峰期 CPU 打满低峰期利用率不到 10%迁移到 K8s 之后这部分资源能更好地共享。还有环境一致性。镜像把 JDK、Hadoop 二进制、依赖库全部固化新节点从创建到加入集群时间从几小时缩短到几分钟而且不会再出现这台机器环境没配好导致 Hadoop 起不来的奇怪问题。1.3 但别把 Hadoop 当无状态应用盲目容器化这里必须先泼一盆冷水Hadoop 不是一个天然适合容器化的系统尤其是 HDFS 这类有状态组件直接套用无状态应用的玩法会踩出大坑。NameNode 是整个 HDFS 的元数据中枢它的目录结构、块映射关系都落在本地磁盘上一旦丢失等于整个集群数据不可用。DataNode 的身份也需要固定如果 Pod 重建后 hostname 变了NameNode 端可能会残留旧地址客户端访问就会失败。所以我在设计时坚持用了 StatefulSet 而不是 Deployment就是为了给每个 DataNode Pod 一个稳定的唯一编号和主机名。数据本地性也是一道坎。K8s 调度器默认按 CPU、内存做选择它并不清楚 YARN 上某个任务要读的 HDFS 块落在哪台机器上。如果 NodeManager 被调度到了没有对应数据副本的节点Map 任务就得远程读数据吞吐量会明显下降。这个问题到现在都是容器化大数据集群的热点话题要在调度策略和网络带宽之间做取舍。我们后面会在优化章节单独讨论。2. 环境准备Debian 11 上的 Kubernetes 集群2.1 节点规划与硬件参考先用一张表给出最小可行环境的规划方便你对照自己的资源做调整角色数量CPU内存磁盘备注控制平面1~34核8GB系统盘 100GB跑 kube-apiserver、etcd建议独立节点计算节点316核64GB系统盘 数据盘DataNode / NodeManager 都跑在这存储节点可选24核16GB大容量数据盘跑 NFS 或 Ceph看你的存储方案我实际用的是一台控制平面加三台计算节点的组合。控制平面只要一主etcd 单实例做测试和内部环境完全够用。如果将来要上生产控制平面可以扩到三台做 HA。计算节点尽量同构避免 YARN 资源分配时因为机器配置不均而出现某个 NodeManager 成为瓶颈。Debian 11Bullseye作为宿主机系统稳定性不错软件包管理干净内核版本也比较适合跑 K8s。装好基础系统后记得先把 apt 源换成自己熟悉的高速镜像否则后面安装依赖会很痛苦。2.2 节点初始化实操不管控制平面还是计算节点下面的系统级初始化套路是通用的。首先关闭 swapKubernetes 从 1.8 开始就要求节点必须关闭 swap不然 kubelet 会报错swapoff -a sed -i / swap / s/^\(.*\)$/#\1/ /etc/fstab然后加载两个关键内核模块并配置网络转发cat EOF | tee /etc/modules-load.d/k8s.conf overlay br_netfilter EOF modprobe overlay modprobe br_netfilter cat EOF | tee /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-iptables 1 net.bridge.bridge-nf-call-ip6tables 1 net.ipv4.ip_forward 1 EOF sysctl --system容器运行时我选的是 containerd。K8s 1.24 之后移除了 dockershim虽然 Docker 也能跑但 containerd 更轻量和 K8s 的集成也少一层。装 containerd 之后重点检查一下/etc/containerd/config.toml里的SystemdCgroup是否设置为true。如果这个没设对kubelet 与容器运行时的 cgroup 驱动不一致节点状态会一直 NotReady排查起来很浪费时间的。接着安装 kubeadm、kubelet、kubectl。我这次用的是 v1.26.0 版本三个组件版本要锁定避免升级不一致带来的问题apt update apt install -y apt-transport-https ca-certificates curl gpg curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.26/deb/Release.key | gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg echo deb [signed-by/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.26/deb/ / | tee /etc/apt/sources.list.d/kubernetes.list apt update apt install -y kubelet kubeadm kubectl apt-mark hold kubelet kubeadm kubectl初始化控制平面时我指定了 Pod 网段和服务网段kubeadm init --pod-network-cidr10.244.0.0/16 --service-cidr10.96.0.0/16网络插件选的 Calico性能和策略能力比 Flannel 强对 Hadoop 这种东西向流量大的集群更友好。装完 Calico 后再让计算节点通过kubeadm join加入集群。全部就绪之后kubectl get nodes应该能看到所有节点处于 Ready 状态。2.3 存储层准备这是最容易被低估的一步Hadoop 的存储分两块一块是 NameNode 的元数据必须放在可靠、可备份的存储上另一块是 DataNode 的数据块对性能要求高但对单点可靠性要求反而没那么极致因为 HDFS 本身有副本机制。我在集群里做了两种 StorageClass。NameNode 用本地 LVM 卷PV 绑定到指定节点虽然不跨节点迁移但至少保证 Pod 重建后元数据还在。DataNode 的数据盘也走的本地持久卷因为实测下来数据读写走 NFS 或网络存储写入性能衰减非常明显尤其是块上报和副本复制的时候网络存储很容易成为瓶颈。如果你的环境里没有本地裸盘退而求其次可以用 NFS CSI 驱动但一定要对 NameNode 的 fsimage 目录做独立的高性能卷别把 NameNode 和 DataNode 的存储混在一个慢速 NFS 上。我们最早踩过这个坑NameNode 的 edits 文件写盘延迟飙升直接导致整个集群卡顿。3. 部署方案设计组件拆分与配置管理3.1 组件拆分与工作负载类型Hadoop 集群里组件很多每个组件在 K8s 中的部署方式完全不同。我把核心组件拆成四类组件工作负载类型副本数存储要求说明NameNodeDeployment1HA 时可 2PVC 持久化元数据关键角色尽量保持稳定DataNodeStatefulSet按节点数Local PV 或独立数据盘使用稳定 hostname 注册ResourceManagerDeployment1HA 时可 2无状态可不用持久卷调度核心建议单独资源配额NodeManagerDaemonSet / StatefulSet按节点数本地临时目录计算执行节点可以弹性扩缩这里需要注意 NameNode 的 HA 方案。单 NameNode 架构简单适合测试。生产环境要做 HA要么用 Quorum Journal ManagerQJM要么直接上 ZooKeeper JournalNode。我在这个方案里先以单 NameNode 为主讲后面运维章节单独说 HA 的注意事项。3.2 网络模式Headless Service 与稳定 DNSHadoop 各组件之间通过主机名或 IP 通信这在 K8s 环境里是个需要仔细处理的点。DataNode 启动时会向 NameNode 汇报自己的地址NameNode 会把地址记录下来并告诉客户端。如果 DataNode 每次重建后 IP 都变NameNode 缓存里还是旧地址客户端就连不上了。我用 Headless Service 给 DataNode 这一组 Pod 提供稳定的 DNS 记录。Kubernetes 的 StatefulSet 会为每个副本生成pod-name.service-name.namespace.svc.cluster.local这样的域名Pod 重建后主机名不变只是 IP 变了NameNode 只要通过 DNS 去解析依然能找到新地址。所以我在 hdfs-site.xml 里把dfs.datanode.use.datanode.hostname设成了true让 DataNode 用主机名注册而不是 IP。另外要给 Service 设置publishNotReadyAddresses: true否则 Pod 还没 Ready 时 DNS 记录不会发布DataNode 在启动早期想解析别的 DataNode 主机名就会失败。这个参数也是我翻了很多文档才注意到的。3.3 配置管理ConfigMap 统一分发传统 Hadoop 部署最痛的是改配置要同步到每一台机器。在 K8s 里这个问题可以很优雅地解决把core-site.xml、hdfs-site.xml、yarn-site.xml、mapred-site.xml全部放进 ConfigMap挂载到所有 Hadoop 容器的/etc/hadoop/conf目录。改配置只需要更新 ConfigMap然后滚动重启相关 Pod。我用了一个小的启动脚本在容器启动时先检查配置目录是否已经挂载好再执行前台命令。Hadoop 的很多进程要求必须在前台运行否则容器会直接退出。比如 NameNode 要执行hdfs namenodeDataNode 要执行hdfs datanode这些命令本身就是阻塞式的前台进程正好符合 Docker 容器的生命周期要求。4. 实操部署从 ConfigMap 到 HDFS/YARN 全部跑起来4.1 创建命名空间和配置字典第一步自然是创建独立命名空间避免大数据组件的资源和其他业务混在一起kubectl create ns bigdata然后创建 ConfigMap。这里给出一个精简但完整的配置示例你可以直接参考apiVersion: v1 kind: ConfigMap metadata: name: hadoop-conf namespace: bigdata data: core-site.xml: | ?xml version1.0? configuration property namefs.defaultFS/name valuehdfs://hadoop-namenode:8020/value /property /configuration hdfs-site.xml: | ?xml version1.0? configuration property namedfs.replication/name value2/value /property property namedfs.namenode.name.dir/name value/data/namenode/value /property property namedfs.datanode.data.dir/name value/data/datanode/value /property property namedfs.datanode.use.datanode.hostname/name valuetrue/value /property /configuration yarn-site.xml: | ?xml version1.0? configuration property nameyarn.resourcemanager.hostname/name valuehadoop-resourcemanager/value /property property nameyarn.nodemanager.resource.memory-mb/name value8192/value /property /configurationhadoop-namenode和hadoop-resourcemanager是后面要创建的 Service 名Hadoop 内部会通过这个 DNS 名字找到对应的进程。4.2 部署 NameNode 并手动格式化NameNode 是 HDFS 的大脑Pod 创建前先准备好 PVCapiVersion: v1 kind: PersistentVolumeClaim metadata: name: namenode-pvc namespace: bigdata spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi storageClassName: local-storageDeployment 挂载这个 PVC并把 ConfigMap 里的配置挂到/etc/hadoop/confapiVersion: apps/v1 kind: Deployment metadata: name: hadoop-namenode namespace: bigdata spec: replicas: 1 selector: matchLabels: app: hadoop component: namenode template: metadata: labels: app: hadoop component: namenode spec: containers: - name: namenode image: apache/hadoop:3.3.6 command: [/bin/bash, -c] args: - hdfs namenode ports: - containerPort: 9870 name: http - containerPort: 8020 name: rpc volumeMounts: - name: hadoop-conf mountPath: /etc/hadoop/conf - name: namenode-data mountPath: /data/namenode volumes: - name: hadoop-conf configMap: name: hadoop-conf - name: namenode-data persistentVolumeClaim: claimName: namenode-pvc注意NameNode 首次启动前必须先格式化。但千万不要把这个格式化动作写进容器启动脚本否则每次重启都会清空元数据。我第一次就是图省事把hdfs namenode -format塞进了启动命令结果一次 Pod 重启整个 HDFS 的文件目录全没了那叫一个崩溃。正确做法是先用一个一次性任务执行格式化kubectl exec -it namenode-pod-name -- hdfs namenode -format -force格式化完成后再让 Deployment 里的进程正式启动。4.3 部署 DataNodeStatefulSet 和稳定身份DataNode 用 StatefulSet 部署并为它们创建一个 Headless ServiceapiVersion: v1 kind: Service metadata: name: hadoop-datanode-headless namespace: bigdata spec: clusterIP: None publishNotReadyAddresses: true selector: app: hadoop component: datanode ports: - port: 9864 name: dataStatefulSet 里每个 Pod 会根据序号生成稳定的主机名同时挂载名为datanode-data的 PVC 模板apiVersion: apps/v1 kind: StatefulSet metadata: name: hadoop-datanode namespace: bigdata spec: serviceName: hadoop-datanode-headless replicas: 3 selector: matchLabels: app: hadoop component: datanode template: metadata: labels: app: hadoop component: datanode spec: containers: - name: datanode image: apache/hadoop:3.3.6 command: [/bin/bash, -c] args: - hdfs datanode ports: - containerPort: 9864 volumeMounts: - name: hadoop-conf mountPath: /etc/hadoop/conf - name: datanode-data mountPath: /data/datanode volumes: - name: hadoop-conf configMap: name: hadoop-conf volumeClaimTemplates: - metadata: name: datanode-data spec: accessModes: - ReadWriteOnce resources: requests: storage: 50Gi storageClassName: local-storage等到 Pod 全部 Running 后进入 NameNode Pod 查看注册情况kubectl exec -it namenode-pod-name -- hdfs dfsadmin -report这里能看到每个 DataNode 的主机名、容量、剩余空间等状态。如果 DataNode 列表为空多半是配置里的fs.defaultFS或者 DNS 有问题可以从 DataNode 日志里找原因。4.4 部署 YARN 组件ResourceManager 用 Deployment 部署因为它本身没有本地状态挂掉后重新拉起即可。Service 名称要和yarn-site.xml里的yarn.resourcemanager.hostname保持一致apiVersion: v1 kind: Service metadata: name: hadoop-resourcemanager namespace: bigdata spec: selector: app: hadoop component: resourcemanager ports: - port: 8088 name: web - port: 8032 name: schedulerNodeManager 我用 DaemonSet 部署保证每个计算节点上都有一个执行器。不过这里要提醒一下DaemonSet 的 Pod 名称带节点名后缀主机名不稳定而 YARN 的节点注册对主机名比较敏感。所以更稳妥的方式是用 StatefulSet 记账式副本每个 NodeManager 有稳定的序号主机名。我实际环境中就是先把 NodeManager 当成 StatefulSet 部署方便后续管理和排查。4.5 集群功能验证组件都起来之后可以做一次端到端验证。先启动一个临时客户端 Pod镜像用同一个 Hadoop 镜像只是把 command 改成sleep infinitykubectl run hadoop-client --imageapache/hadoop:3.3.6 --restartNever --command -- sleep infinity kubectl exec -it hadoop-client -- hdfs dfs -mkdir /test kubectl exec -it hadoop-client -- hdfs dfs -put /etc/hosts /test/hosts接着跑一个 MapReduce 样例任务验证计算链路kubectl exec -it hadoop-client -- hadoop jar /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.6.jar wordcount /test/hosts /test/output如果任务能正常完成说明 HDFS 读写和 YARN 的调度都通了。我一般还会顺手看一眼 9870 和 8088 两个 Web UI确认节点状态和任务执行记录正常。5. 存储与计算效率优化让集群跑得更快更稳5.1 HDFS 数据块大小与副本策略HDFS 默认的dfs.blocksize是 128MB这对大多数大数据任务来说够用。但如果你主要跑的是大文件批处理任务建议调大到 256MB。数据块越大NameNode 维护的块元数据就越少Map 任务读取时也能减少寻道开销。反过来如果业务里很多小文件那调大块大小反而没意义因为小文件占的是命名空间不占块大小这种场景还是要从上层的文件合并说起。副本数dfs.replication在测试环境可以设成 2能省不少存储空间。生产环境建议保持 3因为 K8s 节点一旦重启如果副本数不足NameNode 会进入安全模式或持续做块复制影响性能。场景副本数建议说明单机测试1空间优先无容灾需求小规模测试集群2兼顾空间和基本容错生产集群3标准配置容忍单节点故障我还会用 HDFS 的存储策略给热数据分到 SSD 上。Hadoop 3.x 支持异构存储可以在hdfs-site.xml里配置dfs.datanode.data.dir时带上存储类型标签比如[SSD]/data/ssd、[DISK]/data/hdd然后通过hdfs storagepolicies给指定目录设置ALL_SSD或COLD策略。这个做法的收益很直观频繁访问的 Hive 表可以强制放 SSD冷数据自动落到机械盘或归档目录。5.2 YARN 资源与 K8s 调度协同这里是最容易出问题的地方。K8s 的 Pod 资源配额和 YARN 的 NodeManager 资源是两套体系如果不做对齐会出现以下几种典型情况K8s 给 NodeManager Pod 分配了 16GB limit但 YARN 认为节点有 64GB 可用于是把任务塞到内存 20GB超过容器 limit直接被 OOM Kill。反过来K8s 给 Pod 分配了 48GB但 YARN 只认为自己有 8GB大量资源被白白浪费。我在部署时把这两套体系对齐了。假设节点物理内存 64GB系统自身和 K8s 组件预留 20% 左右可以分配给 YARN 的内存大约是 48GB。我在yarn-site.xml里设置yarn.nodemanager.resource.memory-mb49152 yarn.nodemanager.resource.cpu-vcores16 yarn.scheduler.maximum-allocation-mb16384 yarn.scheduler.minimum-allocation-mb1024同时给 NodeManager 的 Pod 设置requests和limitsresources: requests: memory: 48Gi cpu: 16 limits: memory: 48Gi cpu: 16这里踩过一个很深的坑K8s 默认的驱逐机制Eviction会在节点内存不足时先杀掉一些 Pod 以释放资源而大数据任务的 Pod 往往内存占用很高恰恰是驱逐的高危对象。设置合理的 requests 后kubelet 在计算节点压力时会更谨慎地对待这些 Pod。但根本解决方式还是给大数据节点预留足够的系统余量别把整机内存分得太满。5.3 JVM 与 GC 调优Hadoop 各组件都是 Java 进程堆内存设置直接决定它能扛多大压力。NameNode 的元数据都在内存里堆设置太小文件一多就得频繁 Full GC整个集群跟着抖动。我一般给 NameNode 的HADOOP_NAMENODE_OPTS加上-Xmx8G -Xms8G -XX:UseG1GC -XX:MaxGCPauseMillis200ResourceManager 主要维护调度器状态内存需求没有 NameNode 那么高4G 到 8G 足够。NodeManager 的内存需求反而要注意因为它的堆只是用来跑辅助代码真正的内存开销在 Container 上所以 NodeManager 自己的-Xmx维持在 1G 到 2G 就可以别从 YARN 可用内存里抠太多。GC 日志也要打开方便排查-verbose:gc -Xloggc:/tmp/gc.log -XX:PrintGCDetails5.4 计算层弹性方案与数据本地性权衡K8s 一个很有吸引力的能力是自动伸缩。对于 NodeManager 来说理论上可以根据 pending 任务数做 HPA。但我在实际中并没有直接把 NodeManager 做成自动伸缩原因很简单YARN 集群的节点列表是启动时注册的如果频繁扩容缩容任务在 NodeManager 之间漂移数据本地性会进一步弱化。目前推荐的做法是保持 NodeManager 数量与 DataNode 节点尽量重合在调度 NodeManager 时通过topologySpreadConstraints尽量分散到不同节点。如果集群负载有明显的波峰波谷可以配合 K8s 的 CronJob 在业务低谷时缩容一部分 NodeManager高峰期再扩容回来。缩容前记得先通过 YARN 的yarn node -list确认节点上没有正在执行的任务或者依赖 YARN 自身的 Graceful Decommission 机制。数据本地性这块我目前的做法是给 MapReduce 和 Spark 任务设置spark.locality.wait或mapreduce.job.reduce.slowstart.completedmaps等参数允许在远端读取数据减少调度等待。毕竟在大规模 K8s 集群上强拖数据本地性调度器容易陷入死等状态反而更糟。6. 日常运维与监控长期稳定运行的关键6.1 用 Prometheus 采集 Hadoop 指标Hadoop 3.x 自带很多 JMX 指标可以通过 JMX Exporter 暴露给 Prometheus。我在每个 Hadoop 进程的启动命令里挂在了一个 JMX Exporter agent然后在 K8s Service 上加上 Prometheus 的 annotation让采集任务自动发现这些端点metadata: annotations: prometheus.io/scrape: true prometheus.io/port: 9104监控指标里我最关注下面几个指标含义告警建议HdfsNamenodeCapacityUsedNameNode 已用容量超过 80% 告警NameNodeFSStateNameNode 是否进入 SafeMode状态异常立即告警DataNode 存活数在线 DataNode 数量小于预期值告警YARN 可用内存当前空闲内存长期低于某阈值说明资源紧张YARN pending 任务数队列等待中的任务突增时调度异常配合 kube-prometheus-stack 直接部署Grafana 面板里再加几个 Hadoop 社区的 dashboard集群健康状态就能一目了然。我实际使用中Prometheus 拉取 30 秒一次就够了不需要过于频繁。6.2 日志收集Hadoop 默认会把日志写到 $HADOOP_HOME/logs 目录。在容器里我更建议把日志重定向到 stdout让 K8s 的日志系统统一收集。做法很简单在启动命令里用tail -F跟踪日志文件或者直接用hdfs namenode前台运行并让进程自己把日志打到 stdout。如果要把 Hadoop 原生日志文件保留下来可以把 logs 目录挂到一个 PVC 上否则 Pod 一删日志全没了。NameNode 的日志特别重要排查元数据问题必须依赖它。6.3 扩容与退役流程DataNode 扩容非常简单修改 StatefulSet 的副本数就行。新 Pod 启动后会自动向 NameNode 注册大概几十秒内就能看到新的节点加入。这里不用手动改任何配置文件因为 DataNode 是自动发现 NameNode 的。但缩容不能直接kubectl scale --replicas2就完事。这样会强制杀死一个 DataNode如果它上面存的副本数正好低于安全水位NameNode 会进入复制补偿状态大量数据在网络中复制迁移影响在线任务。正确流程是先在 NameNode 上把目标节点置于下线状态kubectl exec -it namenode-pod -- hdfs dfsadmin -decommission hadoop-datanode-2.hadoop-datanode-headless.bigdata.svc.cluster.local等它的状态变为Decommissioned之后再降低副本数。这个流程虽然多一步但可以保证数据块安全迁移。6.4 备份与恢复NameNode 的元数据是整个集群的命根子。我设计了两个备份维度第一NameNode 的 PVC 本身通过存储快照做定期备份。大多数存储系统都支持 PV 快照至少一天一次。第二用 K8s CronJob 定期把 NameNode 的current目录打包上传到远程存储。恢复的时候先停掉 NameNode Pod把备份的目录恢复到 PVC 里再启动 Pod。另外要定时验证备份的可恢复性别等真出故障了才发现备份是坏的。这个验证过程在测试环境做一次就行也不算太复杂。7. 常见问题与排查实录7.1 DataNode 进程反复重启现象kubectl get pods里 DataNode 的状态一直在 CrashLoopBackOff。排查思路先看日志kubectl logs datanode-pod-name --tail50最常见的原因有三个挂载的数据目录权限不对。HDFS 默认以hadoop用户运行而 PVC 挂载点可能属于 rootDataNode 无法写入启动即失败。解决方法是初始化目录属主或在启动命令里加chown。磁盘空间不足。DataNode 启动时要分配内存映射文件空间不足直接抛异常。配置里的dfs.datanode.data.dir指向了不存在的路径。检查 PV 挂载情况和 ConfigMap 里的路径是否一致。7.2 DataNode 在 NameNode 上显示 Dead现象NameNode UI 上能看到 DataNode 列表但状态是 Dead或者dfsadmin -report看不到节点。原因多半是主机名或 IP 注册问题。DataNode 注册时如果用了不稳定 IP而 NameNode 缓存了旧地址客户端就找不到了。K8s Pod 重建后 IP 变化是常态所以我在前面强调必须设置dfs.datanode.use.datanode.hostnametrue并让 Service 提供稳定的 DNS 记录。如果改了配置还是 Dead进入 DataNode Pod 里手动解析一下 NameNode 的 Service 域名nslookup hadoop-namenode.bigdata.svc.cluster.local很多时候是 CoreDNS 出问题或者 Service 的 Endpoints 为空。这个定位手段在容器化网络排查里非常实用。7.3 NameNode 一直处于 SafeMode现象HDFS 只能读不能写hdfs dfsadmin -report显示SafeMode is ON。原因NameNode 启动时要检查数据块副本情况如果副本数小于配置的dfs.replication它会一直停留在安全模式。常见场景是配置了 3 副本但集群里只有 2 个 DataNode 在线。处理方式先看dfsadmin -report里缺失块的数量。如果只是临时缺块等待一段时间后 NameNode 会自动退出 Safemode。如果缺失比例太高可以临时把dfs.replication降到 2然后手动离开安全模式kubectl exec -it namenode-pod -- hdfs dfsadmin -safemode leave但这是临时手段根本解法是恢复足够的 DataNode 或调低副本需求。7.4 Pod 被驱逐导致 YARN 节点闪断现象NodeManager 容器每隔一段时间就被杀掉YARN UI 上节点列表频繁变化。原因K8s 节点磁盘或内存压力达到驱逐阈值kubelet 会按照优先级驱逐 Pod。大数据组件属于资源大户最容易成为目标。另外一个隐藏原因是本地临时卷emptyDir被撑满。排查与解决kubectl describe node node-name看 Conditions 里是否有MemoryPressure或DiskPressure。如果是内存压力检查 NodeManager Pod 的 requests 是否真的覆盖了它的实际使用量。如果是磁盘压力检查 Docker 和 containerd 的数据目录是否放在了系统盘上建议把容器数据目录挪到大容量数据盘。7.5 配额错误导致任务提交失败现象提交 Spark 或 MapReduce 任务时报错pod failed: error: failed to create pod ... namespace bigdata ... exceeded quota原因Namespace 设置了 ResourceQuota但 Hadoop 任务的 Pod 请求的内存量超出剩余配额。处理方式查看当前配额使用情况kubectl describe resourcequota -n bigdata大数据任务的特性和普通微服务不同单个 Executor 动辄几十 GB建议给大数据组件单独建一个 Namespace并把 ResourceQuota 设得宽一些或者直接不在该 Namespace 上限制内存。7.6 Headless Service 的 DNS 解析不正常现象DataNode 间通过主机名互访失败任务报UnknownHostException。排查检查 Service 定义里是否设置了publishNotReadyAddresses: true。如果没有Pod 在未 Ready 的早期阶段不会被 DNS 记录而 Hadoop 启动序列中常存在互相依赖的解析请求。另一个坑是 selector 匹配的标签写错了导致 Service 没有 Endpoints。kubectl get endpoints -n bigdata如果 Endpoints 列表为空Service 的 selector 一定有问题修正后 DNS 自然就好了。最后再分享一个我个人的体会K8s 把 Hadoop 的部署从手工运维变成了声明式管理这是很明显的进步但 Hadoop 本身的有状态特性和数据本地性问题绕不开。如果你正准备在 Debian 11 上做类似的方案我建议先从三节点的最小集群开始把备份和恢复机制先验证好再逐步扩大规模。别急着上自动伸缩先把稳定跑通作为第一目标。