先在开头简单说清楚我的立场在 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 用了本地目录hostPathPod 一旦被调度到另一台机器旧数据就找不回来了等于让 HDFS 自己再做一次全量复制集群恢复时间会非常难看。我实际用下来比较稳的方案是两层搭配NameNode 元数据目录用 RWO 模式的块存储性能要求高延迟敏感建议用 Ceph RBD 或云厂商的高性能云盘。因为 NameNode 的 FsImage 和 EditLog 每次写操作都涉及 fsync底层存储延迟直接决定 HDFS 能扛住多高的写并发。DataNode 数据目录如果集群规模不大三到五个节点可以直接用 hostPath 配合节点亲和行为让 DataNode Pod 固定在某几台机器上数据本地化率反而更好。如果规模大、节点频繁变动就引入分布式存储或网络块存储牺牲一点数据本地化换集群弹性。这里有个容易踩的坑StorageClass 的 reclaimPolicy 别设成 Delete。我见过有人用了默认 StorageClass后来误删 PVC 导致整个 HDFS 数据全没的案例。HDFS 的数据恢复能力是把双刃剑底层存储一旦真删了什么副本策略都救不回来。建议单独为 Hadoop 建一个 StorageClassreclaimPolicy 设为 RetainPV 被释放后还能手动恢复。还有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字段关联这个 ServicePod 创建时 Kubernetes 会自动给它分配podName.serviceName格式的 DNS 记录。3.2 NameNode 的启动顺序与基于角色的就绪探针HDFS 集群有一个硬性的启动顺序先起 JournalNode再起 NameNode 完成元数据加载最后才能起 DataNode 做块汇报。如果你把三个角色拆成三个 StatefulSetKubernetes 本身不会帮你做跨 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 的持久化不只是挂个 PVCDataNode 的存储设计比 NameNode 更琐碎因为它要管理多个数据目录。Kubernetes 环境下每个 DataNode Pod 可以用多个 PVC分别挂到 Pod 的/data/dfs/dn1、/data/dfs/dn2等路径上。有个细节容易被忽视HDFS 会把一个数据块随机打散到数据目录所在的磁盘上不同磁盘的 I/O 能力和容量差异会影响集群均衡状态。所以存储规划时尽量让同一批 DataNode Pod 挂载相同规格的 PVC避免一个快盘一个慢盘混用。配置上我推荐把dfs.datanode.data.dir写成一个变量引用property namedfs.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/hostnameZooKeeper 的部署方式和 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 优雅退役。具体步骤在 ResourceManager 的 web UI 或命令行里标记该 NodeManager 为退役状态。等待它上面的 running container 全部迁移或完成。等 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 的几个关键参数几个直接影响效率的参数我都列在下面的表里带星号的是我建议你根据集群规模做二次测试的参数推荐初始值作用与理由dfs.replication2 或 3决定块副本数大集群用 2 能减少网络复制dfs.blocksize256MB大块减少 NameNode 元数据压力适合大量大文件yarn.scheduler.minimum-allocation-mb1024见下方说明yarn.scheduler.maximum-allocation-mb容器 limit 的一半防止单个 container 吃光 NodeManageryarn.nodemanager.resource.memory-mb容器限制减去预留与 Kubernetes 资源对齐io.file.buffer.size131072提高连续读写吞吐yarn.scheduler.minimum-allocation-mb的大小要重点考虑。如果设太大小任务会占不满一个容器但也浪费资源设太小调度器的心跳机制会频繁跳动负载高时的调度延迟会明显增加。我一般倾向于 1024MB 起步结合集群每天跑的作业大小做微调。5.3 监控与指标采集Prometheus 全家桶接进 HadoopKubernetes 里最顺手的监控方案自然是 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-tierhot和storage-tiercold来约束 DataNode 调度再结合 HDFS 自身的数据目录策略把低频的大表目录迁移到底层存储的冷数据 DataNode 上。这个方案的好处是存储扩容不再需要关心物理机型号你要加冷存储就新建几个挂了大容量廉价的分布式存储 PVC 的 DataNode Pod给它们打上storage-tiercold标签再把 HDFS 的目录迁移策略指过去。整个操作可以做成定时任务在集群低峰期执行。成本优化立竿见影因为廉价存储通常意味着网络盘或纠删码能省下不少块存储费用。6. 排障实录Kubernetes 上维护 Hadoop 集群的真实踩坑记录排障部分我觉得是这篇文章里头最值钱的一段。很多问题不是靠看文档能解决的写出来希望能让你少走弯路。6.1 SafeMode 卡住块汇报赶不上 NameNode 重启有次我手动重启了 NameNode之后 HDFS 一直处于 SafeModehdfs dfsadmin -safemode leave手动退出后过几分钟又卡回去。表面现象是 DataNode 注册正常但块汇报进度停在Replica不可用列表上。排查链路往下走先看 NameNode 日志发现有很多Block report from node ... is delayed by ... ms的警告。再看 DataNode 日志发现 DataNode 一直在尝试连接老 IP 的 NameNode。追到配置文件的dfs.namenode.rpc-address发现里面填的是创建 Pod 时的旧 IP而不是 headless service 的稳定 DNS 名。问题根因清楚了我在第一次部署时图省事直接在配置里写了 IP没走 hostname。之后我把配置改成 headless service 的稳定 DNS 名并重启了所有 DataNode 与 NameNodeSafeMode 在几分钟内自动解除。这个教训后来变成了我们团队所有组件配置的硬性规定所有组件间通信一律使用 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。如果你正准备做类似的迁移建议先在小集群上把状态服务和资源对齐这块验证充分再逐步放大规模。真遇到具体问题欢迎在评论区带上日志和版本信息讨论。