企业官网建设流程全解析

先在开头简单说清楚我的立场：在 Kubernetes 上部署 Hadoop，并不是把一个 Java 进程塞进容器就完事，真正难的是有状态服务的身份持久性、YARN 与 Kubernetes 的资源模型冲突、以及 HDFS 存储层怎么和动态调度共存。这篇文章我会以 Debian 11 为基础环境，从架构决策、环境准备、核心服务编排、资源对齐、优化与排障五个层面，把我在实际项目中走通的方案和踩过的坑完整梳理出来，适合已经能独立搭建过 Hadoop 集群、现在想把集群迁到 Kubernetes 里的运维或平台工程师参考。

1. 先想清楚架构：Kubernetes 托管 Hadoop，到底托管哪些东西

很多人一听到“Kubernetes 部署 Hadoop”，第一反应是拿 Helm Chart 一把梭，把 NameNode、DataNode、ResourceManager、NodeManager 全部定义成 Deployment，配上 Service 就完事。这个思路基本会在第一次重启 Pod 时翻车，原因是Hadoop 的心跳机制和配置体系严重依赖稳定的主机名与固定 IP，而 Kubernetes 里 Pod 的 IP 天然是漂移的，容器重建后主机名也变了。NameNode 里记录的 DataNode 地址一旦失效，整个集群的块汇报就断掉，HDFS 会进入安全模式，什么都读不了。

所以架构层面第一步不是写 YAML，而是想清楚：Kubernetes 到底该承载 Hadoop 的哪些部分。

我的做法是把集群拆成两条线：

• 有状态控制面：NameNode、JournalNode、ResourceManager、ZooKeeper，这些进程必须保持稳定的网络身份和持久化存储，启动顺序有强依赖，必须用 StatefulSet 管理。
• 无状态计算面：DataNode 和 NodeManager，这两个角色可以随时扩容、缩容、替换，Pod 挂了就重建，只要它能把数据块重新汇报上来即可。注意这里说的“无状态”仅指计算调度层面的可替换性，DataNode 的数据盘仍需要网络存储支撑，不能因为容器重建就弄丢块数据。

另外一个关键决策是：要不要在 Kubernetes 里跑 YARN，还是直接用 Kubernetes 调度 Spark？

如果你只是想让 Hadoop 承担存储和基础计算，Spark 任务可以直接用 Kubernetes 原生调度器跑，HDFS 只作为数据源，这样资源利用率和部署复杂度都会好很多。但如果业务里有大量 MapReduce 任务、依赖 YARN 的队列资源隔离、或者存量作业无法快速改造成 Kubernetes 原生调度，那 YARN 这套就必须原样保留在 Kubernetes 里。这篇文章主要针对后一种情况，也就是以 YARN 作为计算调度内核、以 Kubernetes 作为进程编排底座的混合架构。

这种混合架构的好处是可以让 YARN 的节点管理粒度更细。传统物理机部署时，NodeManager 和机器绑定，一台机器只能进一个队列；到了 Kubernetes 里，每个 NodeManager 是一个 Pod，你可以把它调度到不同机型、不同资源池，甚至让 NodeManager 的 Pod 副本数跟着集群负载走。坏处也明显：YARN 不感知 Kubernetes 的调度语义，资源申请和驱逐策略需要手工对齐，这个我放到第四节细讲。

架构决策做完了，还需要确认一件事：版本匹配度。Kubernetes 1.20 之后移除了 PodHostname 对 StatefulSet 命名的限制，但 Hadoop 2.x 和 3.x 在容器网络环境下的表现差异很大。我建议直接用 Hadoop 3.3.x，它对容器化支持比 2.x 好很多，尤其是在 DataNode 数据目录失效后的恢复逻辑上，3.x 明显更能扛。Kubernetes 版本选 1.27 或 1.28 都行，注意 kubelet 的 cgroup v2 支持和容器运行时选 containerd，别再用 docker-shim 那条老线。Debian 11 的默认内核足够跑 containerd，不需要额外折腾。

2. 环境准备与存储选型：Debian 11 的集群底面

既然标题明确要求 Debian 11，我就把系统层面的准备步骤也连带写清楚。Debian 11（代号 Bullseye）的软件仓库里，Kubernetes 相关组件基本都需要走官方 apt 源安装，系统本身不需要做太多改动，但有几个点必须提前处理。

2.1 基础系统与容器运行时

安装 containerd 时要注意，Debian 11 自带的 containerd 版本可能偏低，Kubernetes 1.27 以上要求 containerd 至少 1.6。建议直接从 Docker 官方 apt 源装，或者用 containerd.io 的稳定版本。装完后需要额外做一步：把SystemdCgroup配置改成 true，不然 kubelet 的 cgroup 统计会和容器运行时对不上，节点状态会一直 NotReady。

# /etc/containerd/config.toml 中的关键配置 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc] [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] SystemdCgroup = true

改完配置要重启 containerd，并且确认 kubelet 的--cgroup-driver也是 systemd，两者必须一致。

2.2 存储选型是真正决定成败的地方

HDFS 本身就是分布式存储，按理说它的数据冗余可以绕开底层存储的高可用要求，理论上一块普通磁盘就够了。但 Kubernetes 的场景不一样：StatefulSet 的 Pod 重建后，PVC 要能被重新绑定。如果你的 DataNode 用了本地目录（hostPath），Pod 一旦被调度到另一台机器，旧数据就找不回来了，等于让 HDFS 自己再做一次全量复制，集群恢复时间会非常难看。

我实际用下来比较稳的方案是两层搭配：

• NameNode 元数据目录：用 RWO 模式的块存储，性能要求高，延迟敏感，建议用 Ceph RBD 或云厂商的高性能云盘。因为 NameNode 的 FsImage 和 EditLog 每次写操作都涉及 fsync，底层存储延迟直接决定 HDFS 能扛住多高的写并发。
• DataNode 数据目录：如果集群规模不大（三到五个节点），可以直接用 hostPath 配合节点亲和行为，让 DataNode Pod 固定在某几台机器上，数据本地化率反而更好。如果规模大、节点频繁变动，就引入分布式存储或网络块存储，牺牲一点数据本地化换集群弹性。

这里有个容易踩的坑：StorageClass 的 reclaimPolicy 别设成 Delete。我见过有人用了默认 StorageClass，后来误删 PVC 导致整个 HDFS 数据全没的案例。HDFS 的数据恢复能力是把双刃剑，底层存储一旦真删了，什么副本策略都救不回来。建议单独为 Hadoop 建一个 StorageClass，reclaimPolicy 设为 Retain，PV 被释放后还能手动恢复。

还有，Kubernetes 节点上的/etc/hosts别乱改。StatefulSet 的 Pod 名是稳定的，但 IP 会变，Hadoop 配置里能用主机名的地方绝对不要填 IP。接下来第三节详细说这个。

3. 有状态服务的正确打开方式：NameNode 和 DataNode 的 StatefulSet 设计

有状态服务进 Kubernetes，核心诉求只有一个：每次重建后，它还能以同样的身份、同样的数据目录、同样的对外地址重新加入集群。这要求我们在资源定义上同时做到三件事：稳定的主机名网络标识、持久化的数据目录、可控的启动顺序。

3.1 用 Headless Service 解决主机名漂移问题

NameNode 和 DataNode 启动时需要向彼此注册地址，这些地址如果写的是 Pod IP，那 Pod 一重建就全乱套。正确做法是利用 Headless Service 给每个 Pod 一个稳定的 DNS 名字。比如我定义了一个名为hdfs-nn的 Headless Service，那么hdfs-nn-0.hdfs-nn.default.svc.cluster.local这个地址在 Pod 重建前后始终不变。也就是说，NameNode 的dfs.namenode.rpc-address和dfs.namenode.http-address都配置成这个稳定 DNS 名字，而不是某个随机 IP。

Headless Service 的 YAML 里只需要把clusterIP: None设置上，selector 指向对应的 Pod 标签即可。StatefulSet 通过serviceName字段关联这个 Service，Pod 创建时 Kubernetes 会自动给它分配podName.serviceName格式的 DNS 记录。

3.2 NameNode 的启动顺序与基于角色的就绪探针

HDFS 集群有一个硬性的启动顺序：先起 JournalNode，再起 NameNode 完成元数据加载，最后才能起 DataNode 做块汇报。如果你把三个角色拆成三个 StatefulSet，Kubernetes 本身不会帮你做跨 StatefulSet 的启动依赖，你得自己控制。

我常用的办法是：给 DataNode 的 StatefulSet 加一个 initContainer，启动时先去探测 NameNode 的 RPC 端口是否已经真正就绪。注意不是简单的 TCP 探测，因为 NameNode 进程启动后端口就打开了，但它可能还处于 SafeMode 状态，此时 DataNode 注册会反复失败。更稳的做法是探测 NameNode 的 Web UI 接口，比如访问http://hdfs-nn-0.hdfs-nn.default.svc.cluster.local:9870/dfshealth.html#tab-overview，判断返回内容里是否已经不再显示 SafeMode 告警。这个逻辑可以写成一个小脚本放进 initContainer，滚动升级时也会因为脚本退出码非零而自动阻塞后续 Pod，效果比 readinessProbe 好。

NameNode 本身也有高可用的问题。如果业务允许短暂停机，先只部署单个 NameNode 实例也能跑。但正经生产环境建议至少开 HA：两个 NameNode 实例 + 三个 JournalNode，用 ZooKeeper 做自动故障转移。在 Kubernetes 里实现这套时，我的建议是把两个 NameNode 实例放在同一个 StatefulSet 里（即副本数设为 2），这样可以通过 headless service 的序号规则区分谁是主谁是备，再配合 ZooKeeper 的选主机制，不必额外引入 Operator。

3.3 DataNode 的持久化：不只是挂个 PVC

DataNode 的存储设计比 NameNode 更琐碎，因为它要管理多个数据目录。Kubernetes 环境下每个 DataNode Pod 可以用多个 PVC，分别挂到 Pod 的/data/dfs/dn1、/data/dfs/dn2等路径上。有个细节容易被忽视：HDFS 会把一个数据块随机打散到数据目录所在的磁盘上，不同磁盘的 I/O 能力和容量差异会影响集群均衡状态。所以存储规划时尽量让同一批 DataNode Pod 挂载相同规格的 PVC，避免一个快盘一个慢盘混用。

配置上我推荐把dfs.datanode.data.dir写成一个变量引用：

<property> <name>dfs.datanode.data.dir</name> <value>/data/dfs/dn1,/data/dfs/dn2</value> </property>

容器镜像里通过 env 把 PVC 挂载路径注入，这样 Pod 扩容时新增节点也能自动带上正确的数据目录列表。

DataNode Pod 的调度约束也要提前规划。最好的情况是给每个 DataNode Pod 加上节点亲和性，让它的 PVC 数据落在哪台机器，Pod 就尽量还调度回到那台机器。如果你的 PV 是 hostPath 类型，这一步是必须的；如果用的是分布式存储（比如 CephFS），亲和性可以放宽，但也要考虑数据本地化率对 mapreduce 作业的影响。HDFS 的块副本在 CephFS 上会经一层额外的网络转发，读性能会比 hostPath 差一截。

3.4 JournalNode 和 ZooKeeper：把“元数据三副本”也编排进来

JournalNode 承担着 HDFS 高可用时的 EditLog 同步，它本身也是强一致状态服务，同样应该用 StatefulSet 管理。部署 3 个副本时注意把它们分散到不同的 Kubernetes 节点上，避免同一个 Node 宕机带走两个 JournalNode 副本。这个用podAntiAffinity实现：

affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchLabels: app: hdfs-journalnode topologyKey: kubernetes.io/hostname

ZooKeeper 的部署方式和 JournalNode 类似，3 个副本加 peer 配置，配合 headless service 的稳定 DNS 名组成 quorum。这里不建议把所有有状态组件全部塞进一个 StatefulSet 里用 HDFS 的一键脚本处理，Kubernetes 部署方式的优势恰恰在于每个角色独立可控、独立扩容，混在一起反而失去这个优点。

4. 让 YARN 在 Kubernetes 里“听话”：ResourceManager 与 NodeManager 的资源对齐

YARN 是我个人认为整条链路里最容易被低估的一块。很多人关注的是 HDFS 那部分，以为把 NodeManager 的 Pod 定义好，集群就能统一调度了。实际上YARN 的资源模型是基于节点粒度的内存与 vCore 申报，Kubernetes 是基于 Pod 粒度的 requests 和 limits，两者天然有语义错位。最典型的情况是：NodeManager Pod 在 Kubernetes 里申请了 8GB 内存，但 YARN 并不知道这 8GB 要分给多少个 container，它只知道这个 NodeManager 可用的总内存是多少。

4.1 资源上限的显式对齐

我的经验是把三层资源口径全部显式写死：

• Kubernetes 层：NodeManager Pod 的资源 requests = limits，防止容器被驱逐后出现抖动的二次分配。
• YARN 层：yarn.nodemanager.resource.memory-mb必须等于容器内存 limit 减去系统预留；yarn.nodemanager.resource.cpu-vcores也要对应到容器 CPU limit 换算后的核数。
• NodeManager 的 JVM 堆：YARN_NODEMANAGER_HEAPSIZE不要超过容器内存 limit 的 40% 到 50%，否则堆外内存和 OOM 问题会频繁出现。

三层不齐会怎样？我给你讲个真实现象：Kubernetes 把 NodeManager Pod 的 limits 设成 16GB，但 YARN 配置里写的是 20GB，结果当 NodeManager 负载上来、YARN 调度出去的 container 数量一多，Pod 的内存用量超过 Kubernetes 的 limit，直接触发 Container OOMKilled。Pod 重启后 NodeManager 向 ResourceManager 重新注册，但之前所有运行中的任务全部失败。这个故障在日志上表现为一个反常的 Killed 事件，排查起来会绕很久。

4.2 YARN 调度与 Kubernetes 调度之间的关系

另一个需要想清楚的问题是：YARN 的队列调度器和 Kubernetes 的调度器各自在管什么？如果 NodeManager 以静态 Pod 的方式长期驻留，那么 Kubernetes 只在 NodeManager 创建和销毁时介入，任务调度完全由 YARN 内部完成。如果 NodeManager 副本数会动态伸缩，那 Kubernetes 的调度器负责决定 NodeManager 放哪台机器，YARN 的调度器负责在 NodeManager 内部给任务分配资源。两层调度叠加后，必须保证底层节点的资源余量不会同时被两层的容量规划占满。我的建议是：Kubernetes 层给 NodeManager 的 CPU 预留 10% 的余量，YARN 层不要在 nodemanager 配置里把资源打满，留出操作系统和 kubelet 本身需要的开销。

在实际配置中，YARN 还支持yarn.resourcemanager.placement-constraints.handler这类高级参数，可以配合集群联邦调度。但这个特性在 Hadoop 3.3.x 里还不够成熟，我测试中发现故障转移时约束恢复有 bug，所以生产环境不建议开。

4.3 NodeManager 的滚动更新与优雅退役

当你需要升级 Hadoop 版本或者调整 NodeManager 配置时，如果直接对 StatefulSet 做滚动更新，Kubernetes 会逐 Pod 重建。普通服务这样没问题，但 YARN 的场景特别敏感——NodeManager 如果突然消失，它身上已经运行的 container 会全部被杀掉，任务重新调度，严重的情况下所有队列都会陷入 pending 等待。

正确做法是在滚动更新前先让 NodeManager 优雅退役。具体步骤：

1. 在 ResourceManager 的 web UI 或命令行里标记该 NodeManager 为退役状态。
2. 等待它上面的 running container 全部迁移或完成。
3. 等 NodeManager 状态变为DECOMMISSIONED之后，再触发 Kubernetes 层面的 Pod 重建。

Hadoop 3.3.x 提供了更方便的/scheduler接口，可以通过 REST API 直接操作节点退役。我搭过一个最小自动化脚本，用 curl 轮询节点状态，等退役完成后才执行kubectl rollout restart。这个流程看起来繁琐，但它在生产升级时的作用非常大，能避免大量不必要的任务失败。

5. 从“能跑”到“跑得快”：效率优化与监控实践

集群能跑通只是第一步，真正的价值在于让大数据计算和存储的效率达到可用水平。这一节主要讲我在三个方向上做的优化：数据本地化、HDFS 参数调优、可观测性建设。

5.1 数据本地化率：Kubernetes 环境下更需要主动干预

传统 Hadoop 部署在物理机上时，HDFS 数据本地化率天然很高，因为 DataNode 和 NodeManager 往往在同一台机器。到了 Kubernetes 里，如果 DataNode Pod 和 NodeManager Pod 是独立调度的，很容易出现数据在一台机器、计算在另一台机器的局面，MapReduce 会退化成 Remote Read，网络流量大幅上升，作业耗时成倍增长。

要干预数据本地化率，最简单的方式是把 DataNode 和 NodeManager 放进同一个 StatefulSet 副本里，或者至少强亲和到同一节点。按 Pod 序号一一对应的话，可以直接用podAffinity把 NodeManager 调度到与同序号 DataNode Pod 相同的节点上。Kubernetes 的调度器不会自动帮你做这种名字到名字的对应，需要靠labelSelector配合topologyKey写出来。我在实际项目里的做法是给 DataNode Pod 加一个hdfs-nodename标签，NodeManager 调用podAffinity去匹配这个标签，拓扑域限制在 hostname，这样调度成功率很高。

数据本地化还和 HDFS 的块副本数量有关。Kubernetes 集群如果节点多而每台机器的存储只是网络盘，副本数建议保持默认 3。但如果你用的是节点本地的裸盘或 hostPath，副本数可以降到 2，因为节点故障后块丢失风险已经通过存储副本兜底了，没必要在 HDFS 层再叠第三副本，减少大量复制流量。

5.2 HDFS 与 YARN 的几个关键参数

几个直接影响效率的参数我都列在下面的表里，带星号的是我建议你根据集群规模做二次测试的：

yarn.scheduler.minimum-allocation-mb的大小要重点考虑。如果设太大，小任务会占不满一个容器但也浪费资源；设太小，调度器的心跳机制会频繁跳动，负载高时的调度延迟会明显增加。我一般倾向于 1024MB 起步，结合集群每天跑的作业大小做微调。

5.3 监控与指标采集：Prometheus 全家桶接进 Hadoop

Kubernetes 里最顺手的监控方案自然是 Prometheus。Hadoop 3.3.x 的 HDFS 和 YARN 都自带基于 JMX 的 Metric 接口，可以不用额外代理直接抓取。需要做的配套工作有三件：

• 给每个 Hadoop 服务开启 JMX 端口暴露，并在 Kubernetes Service 里定义对应的监控端口。
• 用 Prometheus 的jmx_exporter或prometheus_jmx插件把 JMX 指标转换成 Prometheus 格式。
• 在 Grafana 里设置 NameNode 的 FsImage 大小、DataNode 的块总数、ResourceManager 的队列 pending 数量等核心面板。

我这里要特意提一个坑：Hadoop 的 JMX 接口在容器环境下可能因为 RMI 动态端口的问题抓不到数据。解决办法是把 JMX 的com.sun.management.jmxremote.rmi.port和com.sun.management.jmxremote.port都显式设置为同一个固定端口，并且让该端口和 Prometheus 抓取端口保持一致。如果不固定这个端口，JVM 会随机挑一个大端口，而 Kubernetes 容器内的防火墙策略通常不会放行这个大端口，抓取就会失败。这个坑我排了很久才定位到，希望你能绕过去。

5.4 冷数据与热数据：利用 Kubernetes 的拓扑标签做存储分层

大数据集群里不全是热数据，很多历史数据访问频次很低。物理机时代，分层存储要靠管理员手动搬数据，费时费力。到了 Kubernetes 中，你可以通过给不同节点打标签（比如storage-tier=hot和storage-tier=cold）来约束 DataNode 调度，再结合 HDFS 自身的数据目录策略，把低频的大表目录迁移到底层存储的冷数据 DataNode 上。

这个方案的好处是，存储扩容不再需要关心物理机型号：你要加冷存储，就新建几个挂了大容量廉价的分布式存储 PVC 的 DataNode Pod，给它们打上storage-tier=cold标签，再把 HDFS 的目录迁移策略指过去。整个操作可以做成定时任务，在集群低峰期执行。成本优化立竿见影，因为廉价存储通常意味着网络盘或纠删码，能省下不少块存储费用。

6. 排障实录：Kubernetes 上维护 Hadoop 集群的真实踩坑记录

排障部分我觉得是这篇文章里头最值钱的一段。很多问题不是靠看文档能解决的，写出来希望能让你少走弯路。

6.1 SafeMode 卡住：块汇报赶不上 NameNode 重启

有次我手动重启了 NameNode，之后 HDFS 一直处于 SafeMode，hdfs dfsadmin -safemode leave手动退出后过几分钟又卡回去。表面现象是 DataNode 注册正常，但块汇报进度停在Replica不可用列表上。排查链路往下走：

1. 先看 NameNode 日志，发现有很多Block report from node ... is delayed by ... ms的警告。
2. 再看 DataNode 日志，发现 DataNode 一直在尝试连接老 IP 的 NameNode。
3. 追到配置文件的dfs.namenode.rpc-address，发现里面填的是创建 Pod 时的旧 IP，而不是 headless service 的稳定 DNS 名。

问题根因清楚了：我在第一次部署时图省事，直接在配置里写了 IP，没走 hostname。之后我把配置改成 headless service 的稳定 DNS 名并重启了所有 DataNode 与 NameNode，SafeMode 在几分钟内自动解除。这个教训后来变成了我们团队所有组件配置的硬性规定：所有组件间通信一律使用 Kubernetes 内部的 DNS 名，禁止直接使用 Pod IP。

6.2 YARN 的容器 OOM 和 Kubernetes 的 OOMKilled 混在一起

另一个坑来自内存的超卖。现象是集群运行一段时间后，NodeManager 的 Pod 被 KubernetesOOMKilled，但是 YARN 日志里作业却没有报任何 Java 内存溢出。这就让人迷惑了——到底是谁内存不够？

排查下来发现是 NodeManager 进程除了 YARN 分配出去的容器内存，还要承担自身 JVM 堆、DirectMemory、网络缓冲、元数据缓存等开销。我当时把YARN_NODEMANAGER_HEAPSIZE设成了容器限制的 60%，结果这部分 JVM 堆外还有大量页缓存和网络 I/O 缓冲，总量超过了 Kubernetes 的 limit。解决办法很简单：把 NodeManager 的 JVM 堆降低到容器限制的 40% 以内，同时把容器 limit 调大 3-4GB 作为系统开销预留。再配合container_memory_working_set_bytes和container_memory_usage_bytes两条 Prometheus 指标持续观察，确认内存曲线处于稳定区间。

6.3 Kubernetes 网络策略端口封锁导致的跨节点通信失败

Kubernetes 集群开启了 NetworkPolicy 的网络隔离时，Hadoop 的端口矩阵会让新手非常难受。RPC、Web UI、DataNode 数据传输、YARN 的 shuffle、ZooKeeper 的 quorum 端口加起来能凑出一大张表。我见过一个故障：作业能提交，但 Map 任务总是拉取不到 shuffle 数据，反复重试，失败率 99%。日志里只有connection refused，但节点之间ping是通的。

最后逐端口测，发现是 NodeManager 和 ResourceManager 之间有一个端口被 NetworkPolicy 拦了。YARN shuffle 的端口不是固定的，它会取一个区间，而我们的 NetworkPolicy 只放行了常见的 8088、8030、8031、8032 这些固定端口，shuffle 随机端口段被挡掉。解决办法是在 NetworkPolicy 里放开yarn.nodemanager.aux-service对应的端口段，或者干脆把 shuffle 端口范围显式配置成一个固定值，减少安全策略的盲区。

这里也要顺带提醒：开启 NetworkPolicy 时建议把 Hadoop 服务的端口矩阵整理成一张表，放进我们前面的部署文档里，方便后续运维核对，别等故障出现了再来一个个试端口。

收尾：几个关于生产落地的个人体会

写到这里，核心方案和关键避难点都覆盖得差不多了。最后说几个我自己的体会。

Kubernetes 里跑 Hadoop，最大的收益不是“自动扩缩容”，而是“交付能力”。以前交付一套 Hadoop 集群，物理机巡检、网络调试、版本对齐，没个一天下不来。现在我把所有 YAML 和镜像都版本化管理，一条命令就能在全新的 Debian 11 Kubernetes 集群里拉起整套环境。团队里新同学照着文档也能快速复现，排障效率明显上来了。

第二，不要追求“完美混合调度”。Kubernetes 和 YARN 是两个架构理念完全不同的调度器，强行整合所有能力，得到的往往不是优雅，而是复杂度。现阶段把 HDFS 和 YARN 作为有状态的支撑服务稳定跑在 Kubernetes 上，计算任务该走 YARN 走 YARN，该走 Kubernetes 原生调度走 Kubernetes 原生调度，各留一部分空间给后续演进，这是更实际的生产策略。

第三，数据安全永远是底线的底线。Hadoop 的副本策略不能替代 Kubernetes 存储的备份。我后来给 NameNode 元数据目录额外加了一份定时快照任务，每隔几小时把 FsImage 和 EditLog 打包传到独立存储。这个动作看起来小，但在一次机房级故障中帮我省下了整整一周从零恢复元数据的功夫。

这套方案我和团队在多个项目里迭代过，版本组合是 Debian 11 + Kubernetes 1.27 + containerd 1.6 + Hadoop 3.3.6。如果你正准备做类似的迁移，建议先在小集群上把状态服务和资源对齐这块验证充分，再逐步放大规模。真遇到具体问题，欢迎在评论区带上日志和版本信息讨论。