从零到一：Kubernetes 下 HDFS 集群的硬核部署与排障实录

从零到一：Kubernetes 下 HDFS 集群的硬核部署与排障实录

在云原生时代，将传统的大数据组件部署到 Kubernetes 上，既是一次架构的升级，也是一场对排障能力的极限考验。今天下午，我们在一个全新的 K8s 环境中，从零开始部署了一套包含 HDFS、Kafka、Flink、Spark、MinIO 和 Zookeeper 的完整大数据沙箱。其中，HDFS NameNode 的部署过程堪称一波三折，经历了从满屏 CrashLoopBackOff 到最终完美 Running 的完整蜕变。本文将完整复盘这一过程，记录下那些踩过的坑与最终的解决方案。

一、 初始部署：看似顺利，暗藏杀机

下午的部署工作从基础的组件拉起开始。通过执行一系列 K8s 部署命令，Flink、Kafka、MinIO、Spark History Server 以及 Zookeeper 等组件相继启动。然而，当我们把目光转向 HDFS 的核心——NameNode 时，情况急转直下。

NameNode Pod 陷入了无尽的 CrashLoopBackOff 循环。通过 kubectl logs 查看日志，我们捕获到了第一个致命错误：Invalid URI for NameNode address (check fs.defaultFS): file:/// has no authority。这个错误直指 Hadoop 的核心配置文件 core-site.xml，说明 NameNode 启动时找不到正确的文件系统默认 URI，回退到了本地文件系统 file:///，导致 RPC 服务无法绑定。

二、 手动干预：在容器内寻找真相

面对自动化部署的失败，我们决定退一步，采用“手动挂机”的策略来排查问题。我们将 NameNode 的启动命令临时修改为 sleep infinity，让 Pod 保持 Running 状态但不执行任何服务进程。随后，通过 kubectl exec 进入容器内部，我们开始了手动修复之旅。

在容器内，我们手动修改了 core-site.xml，添加了 fs.defaultFS 指向 hdfs://hdfs-namenode:8020。然而，当我们尝试启动 NameNode 时，又遇到了第二个拦路虎：Cannot assign requested address。这是因为容器内的 DNS 无法解析 hdfs-namenode 这个主机名。我们通过手动向 /etc/hosts 文件追加 127.0.0.1 hdfs-namenode 解决了这个问题。

紧接着，第三个问题接踵而至：InconsistentFSStateException: Directory /tmp/hadoop-hadoop/dfs/name is in an inconsistent state。由于容器重启会清空 /tmp 目录，NameNode 的元数据存储目录丢失。我们果断执行了 hdfs namenode -format 重新格式化，NameNode 终于成功启动，日志中出现了令人振奋的 NameNode RPC up at: hdfs-namenode/127.0.0.1:8020。

三、 自动化固化：与 K8s 的博弈

手动验证成功后，我们面临最关键的一步：将这些手动操作“固化”到 K8s 的 Deployment 中，实现自动化启动。我们尝试将修改配置、添加 Hosts、格式化和启动命令串联成一个 Shell 脚本，写入容器的启动参数中。

然而，自动化之路远比想象中崎岖。我们先后遭遇了以下问题：

1. 权限问题：在启动脚本中直接执行 echo ... >> /etc/hosts 时，由于容器默认以普通用户运行，触发了 Permission denied。解决方案是在命令前加上 sudo sh -c 来提权执行。
2. 配置覆盖风险：最初尝试用 printf 直接覆盖 core-site.xml，结果导致 Hadoop 其他必要配置丢失，引发新的崩溃。最终我们采用了更安全的 sed 命令进行精准插入，并进一步升级为使用 K8s 原生的 ConfigMap 进行配置文件挂载，彻底解耦了配置与镜像。
3. 旧 Pod 干扰：在排查新 Pod 崩溃原因时，kubectl logs 总是默认查到旧的、已经僵死的 Pod。我们通过精准指定新 Pod 的名称，并结合 --previous 参数，成功抓取到了新 Pod 的“死亡日记”，定位到了权限问题的根源。

四、 完美收官：从 Chaos 到 Order

经过数轮的 patch、delete、logs 排查，我们终于构建出了一个完美的启动脚本。该脚本在容器启动时，会自动提权修改 Hosts，通过 ConfigMap 挂载正确的配置文件，智能检测并格式化元数据目录，最后以前台模式启动 NameNode。

当最后一个 kubectl patch 命令执行完毕，我们开启了 kubectl get pods -w 监控。看着新的 NameNode Pod 从 ContainerCreating 变为 Running，并且 READY 状态稳稳地停留在 1/1，再也没有发生任何重启，我们知道，这场战役胜利了。

随后，我们顺手清理了因镜像拉取失败而卡住的 Zookeeper Pod，整个 bigdata 命名空间终于呈现出教科书般的整洁：所有的核心组件，包括 HDFS、Kafka、Flink、Spark、MinIO 和 Zookeeper，全部处于完美的 Running 状态。

五、 复盘与思考

回顾这半个下午的排障过程，我们深刻体会到在 K8s 上部署有状态服务的复杂性。HDFS 作为一个传统的分布式文件系统，其设计初衷并非为容器化而生，因此在部署时需要额外处理主机名解析、元数据持久化和配置文件注入等问题。

这次经历也验证了 K8s 排障的核心方法论：

1. 不要畏惧手动干预：当自动化失效时，手动进入容器复现问题是定位根因的最快路径。
2. 日志是唯一的真相：所有的猜测都需要通过 kubectl logs 来验证，精准定位 Pod 名称和查看历史日志是必备技能。
3. 拥抱 K8s 原生能力：尽量使用 ConfigMap、Secret 等原生资源来管理配置，避免在启动脚本中硬编码复杂的文件修改逻辑。

至此，我们的云原生大数据沙箱环境已完全就绪。从满屏的红色报错到一片绿色的 Running，这不仅是一次成功的部署，更是一次对 K8s 和有状态服务架构的深度实践。