Debian 11上Kubernetes部署Hadoop集群实战：踩坑记录与调优

前阵子帮团队做了一次迁移，把跑在虚拟机里的一套 Hadoop 3.3.x 集群搬到了 Kubernetes 上。底层系统是 Debian 11，上面搭了一个三控三算的 K8s 集群，整套环境从规划、部署到调优，前后花了大概两周。这不是一篇纯理论分析，而是把我在实际操作中踩过的坑、验证过的配置，以及各个参数在真实负载下的表现，完整记录下来。如果你也想在 Debian 11 上用 Kubernetes 部署和管理 Hadoop 集群，或者已经在折腾但被各种问题卡住，这篇内容应该能帮你少走不少弯路。

我按整个落地链路把内容拆成七个部分：为什么用 K8s 管 Hadoop、环境准备、部署方案设计、实操部署、存储与计算效率优化、日常运维与监控、常见问题排查。其中存储和计算效率的优化是重点，因为集群部署起来只是第一步，能让它在大数据负载下稳定输出才是真正花时间的地方。

1. 为什么要用 Kubernetes 部署 Hadoop

1.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 节点规划与硬件参考

先用一张表给出最小可行环境的规划，方便你对照自己的资源做调整：

我实际用的是一台控制平面加三台计算节点的组合。控制平面只要一主，etcd 单实例，做测试和内部环境完全够用。如果将来要上生产，控制平面可以扩到三台做 HA。计算节点尽量同构，避免 YARN 资源分配时因为机器配置不均而出现某个 NodeManager 成为瓶颈。

Debian 11（Bullseye）作为宿主机系统，稳定性不错，软件包管理干净，内核版本也比较适合跑 K8s。装好基础系统后，记得先把 apt 源换成自己熟悉的高速镜像，否则后面安装依赖会很痛苦。

2.2 节点初始化实操

不管控制平面还是计算节点，下面的系统级初始化套路是通用的。首先关闭 swap，Kubernetes 从 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-cidr=10.244.0.0/16 --service-cidr=10.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 中的部署方式完全不同。我把核心组件拆成四类：

这里需要注意 NameNode 的 HA 方案。单 NameNode 架构简单，适合测试。生产环境要做 HA，要么用 Quorum Journal Manager（QJM），要么直接上 ZooKeeper + JournalNode。我在这个方案里先以单 NameNode 为主讲，后面运维章节单独说 HA 的注意事项。

3.2 网络模式：Headless Service 与稳定 DNS

Hadoop 各组件之间通过主机名或 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 namenode，DataNode 要执行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 version="1.0"?> <configuration> <property> <name>fs.defaultFS</name> <value>hdfs://hadoop-namenode:8020</value> </property> </configuration> hdfs-site.xml: | <?xml version="1.0"?> <configuration> <property> <name>dfs.replication</name> <value>2</value> </property> <property> <name>dfs.namenode.name.dir</name> <value>/data/namenode</value> </property> <property> <name>dfs.datanode.data.dir</name> <value>/data/datanode</value> </property> <property> <name>dfs.datanode.use.datanode.hostname</name> <value>true</value> </property> </configuration> yarn-site.xml: | <?xml version="1.0"?> <configuration> <property> <name>yarn.resourcemanager.hostname</name> <value>hadoop-resourcemanager</value> </property> <property> <name>yarn.nodemanager.resource.memory-mb</name> <value>8192</value> </property> </configuration>

hadoop-namenode和hadoop-resourcemanager是后面要创建的 Service 名，Hadoop 内部会通过这个 DNS 名字找到对应的进程。

4.2 部署 NameNode 并手动格式化

NameNode 是 HDFS 的大脑，Pod 创建前先准备好 PVC：

apiVersion: v1 kind: PersistentVolumeClaim metadata: name: namenode-pvc namespace: bigdata spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi storageClassName: local-storage

Deployment 挂载这个 PVC，并把 ConfigMap 里的配置挂到/etc/hadoop/conf：

apiVersion: 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 部署 DataNode：StatefulSet 和稳定身份

DataNode 用 StatefulSet 部署，并为它们创建一个 Headless Service：

apiVersion: v1 kind: Service metadata: name: hadoop-datanode-headless namespace: bigdata spec: clusterIP: None publishNotReadyAddresses: true selector: app: hadoop component: datanode ports: - port: 9864 name: data

StatefulSet 里每个 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: scheduler

NodeManager 我用 DaemonSet 部署，保证每个计算节点上都有一个执行器。不过这里要提醒一下：DaemonSet 的 Pod 名称带节点名后缀，主机名不稳定，而 YARN 的节点注册对主机名比较敏感。所以更稳妥的方式是用 StatefulSet 记账式副本，每个 NodeManager 有稳定的序号主机名。我实际环境中就是先把 NodeManager 当成 StatefulSet 部署，方便后续管理和排查。

4.5 集群功能验证

组件都起来之后，可以做一次端到端验证。先启动一个临时客户端 Pod，镜像用同一个 Hadoop 镜像，只是把 command 改成sleep infinity：

kubectl run hadoop-client --image=apache/hadoop:3.3.6 --restart=Never --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 会进入安全模式或持续做块复制，影响性能。

我还会用 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-mb=49152 yarn.nodemanager.resource.cpu-vcores=16 yarn.scheduler.maximum-allocation-mb=16384 yarn.scheduler.minimum-allocation-mb=1024

同时给 NodeManager 的 Pod 设置requests和limits：

resources: 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:MaxGCPauseMillis=200

ResourceManager 主要维护调度器状态，内存需求没有 NameNode 那么高，4G 到 8G 足够。NodeManager 的内存需求反而要注意，因为它的堆只是用来跑辅助代码，真正的内存开销在 Container 上，所以 NodeManager 自己的-Xmx维持在 1G 到 2G 就可以，别从 YARN 可用内存里抠太多。

GC 日志也要打开，方便排查：

-verbose:gc -Xloggc:/tmp/gc.log -XX:+PrintGCDetails

5.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"

监控指标里，我最关注下面几个：

配合 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 --replicas=2就完事。这样会强制杀死一个 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> --tail=50

最常见的原因有三个：

• 挂载的数据目录权限不对。HDFS 默认以hadoop用户运行，而 PVC 挂载点可能属于 root，DataNode 无法写入，启动即失败。解决方法是初始化目录属主，或在启动命令里加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.hostname=true，并让 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 上做类似的方案，我建议先从三节点的最小集群开始，把备份和恢复机制先验证好，再逐步扩大规模。别急着上自动伸缩，先把稳定跑通作为第一目标。