【硬核干货】把 DolphinScheduler 搬进 K8s:奇虎 360 商业化 900 天踩坑全记录

👋 大家好,我是远朋。过去 3 年,我们团队把部分调度任务从 Azkaban 逐步迁移到 DolphinScheduler,并开展了 K8s 容器化。今天把踩过的坑、攒下的经验一次性复盘,建议收藏!
作者介绍

王远朋上海奇虎科技有限公司 数据专家商业化 SRE & 大数据团队核心成员长期负责 DolphinScheduler 在生产环境的部署与优化,具备丰富的容器化与大数据调度经验。
在大数据任务调度的日常工作中,Apache DolphinScheduler 已经成为我们团队最核心的工具之一。过去我们一直依赖物理机进行部署,例如 3.1.9 版本仍运行在物理机环境中,但这种方式在弹性扩展、资源隔离和运维效率上逐渐暴露出问题。随着公司整体的云原生战略推进,我们最终在 2025 年将 DolphinScheduler 升级到 3.2.2,并部分迁移到 Kubernetes 平台。
迁移的动机非常明确:首先是弹性扩容,K8S 可以根据任务高峰快速扩展 Worker 节点;其次是资源隔离,避免不同任务相互影响;再者是自动化部署与回滚,大幅降低维护成本;最后,也是最重要的一点,这一切符合公司在技术层面的云原生方向。
镜像构建:从源码到模块
在迁移过程中,镜像构建是第一步。

我们先准备了一个包含 Hadoop、Hive、Spark、Flink、Python 等环境的基础镜像,然后在此基础上构建 DolphinScheduler 的基础镜像,将重新编译的各个模块和 MySQL 驱动打包其中。

这里需要注意的是,MySQL 被用作 DolphinScheduler 的元数据存储,因此驱动包必须软链到每一个模块,包括 dolphinscheduler-tools
、dolphinscheduler-master
、dolphinscheduler-worker
、dolphinscheduler-api
和 dolphinscheduler-alert-server
。

Worker 镜像
模块镜像则是在 DS 基础镜像之上进行定制,主要修改端口和配置。为了减少后续配置文件的改动,我们尽量保持模块镜像的名称与官方一致。构建时既可以单独构建某个模块,例如:

单独构建镜像
也可以批量构建所有模块:

批量构建镜像
这一步里我们遇到的典型问题包括:基础镜像过大导致构建时间过长,源码改造后的 jar 包没有覆盖旧文件,甚至不同模块的端口配置和启动脚本不一致。 这些细节如果处理不当,就会在后续部署阶段带来一系列棘手的问题。
部署方案:从自制 YAML 到官方 Helm Chart
在部署初期,我们是手写 YAML 文件来完成部署的,但这种方式在配置分散和升级维护上成本极高。后来我们改用了官方提供的 Helm Chart,这样配置集中管理,升级也更方便。
我们使用的 K8S 集群版本是 v1.25,部署时需要先创建命名空间 dolphinscheduler
,然后拉取 helm 包,例如:
在真正落地过程中,values.yaml
是最核心的文件,我们在这里踩过很多坑。下面贴出几个关键配置片段,供大家参考:
1. 镜像配置
👉 提示:一些前置的工具镜像最好提前 push 到私有仓库,避免因网络或镜像源问题导致部署失败。
2. 外置数据库配置(MySQL)
👉 内置数据库务必关闭,生产环境统一接入外部 MySQL(未来我们将切换到 PostgreSQL)。
3. LDAP 登录认证
👉 我们接入了公司 LDAP,统一用户认证,方便权限管理。
4. 共享存储配置
👉 注意:storageClassName 必须支持 ReadWriteMany
,否则多个 Worker 节点无法同时访问共享目录。

5. HDFS 配置
👉 所有大数据相关组件路径需要提前准备好,例如 /opt/soft
。
6. Zookeeper 配置
👉 使用外置 Zookeeper 时,记得关闭内置配置,同时确认 ZK 版本符合官方最低要求。
踩坑经验与维护挑战
在整个迁移过程中,我们踩过的坑不少。比如,镜像制作问题、Helm values.yaml 修改的坑,以及定制化升级和维护成本过高等。
镜像制作相关问题
镜像制作时因为基础镜像太大,导致构建过程漫长;
模块依赖差异导致重复安装;
有时候 MySQL 驱动包路径不正确,模块启动时报错;
源码改造后的 jar 包忘记覆盖旧文件,也曾造成过运行时异常,不同模块端口与启动脚本不一致,导致启动不顺利。
Helm values.yaml 注意点
sharedStoragePersistence.storageClassName 必须支持 ReadWriteMany 存储类
storage 大小
mountPath 与配置文件不一致
配置项路径缩进
关闭默认配置以及一些不需要的配置,例如 Zookeeper 外置时需关闭内置选项,同时注意 zk 需要的版本
维护升级成本
更大的挑战来自后续维护。因为我们对源码和镜像做过定制化修改,所以每当 DolphinScheduler 发布新版本,我们都需要重新对比修改点,重新构建并测试全部模块镜像。
同时,由于不同版本之间配置项差异较大,升级和回滚的过程都容易出错。这些问题导致我们的升级周期变长,维护难度加大,团队人力成本也显著上升。
未来规划与思考
为了降低长期的运维成本,我们已经在逐步推进标准化。未来计划包括:将 DolphinScheduler 的元数据库从 MySQL 切换到 PostgreSQL,全面采用社区官方镜像而非自研镜像,生产任务也会逐步迁移到 K8S 环境中。
同时,我们会引入 CI/CD 流程,并结合 Prometheus 与 Grafana 做可观测性建设,提升部署效率与监控能力。
总的来说,K8S 部署让 DolphinScheduler 在扩展性、弹性和迁移性上具备了远超物理机的优势。虽然镜像定制化和配置修改带来了不小的挑战,但随着我们逐渐回归社区版本和标准化运维,维护成本会越来越低,部署效率会越来越高。
我们的长期目标,是构建一个高可用、易扩展、统一化的调度平台,真正释放云原生的价值。如果你也在考虑把调度系统搬上 K8s,欢迎评论区交流,或加入 DolphinScheduler 社区一起搬砖!

版权声明: 本文为 InfoQ 作者【白鲸开源】的原创文章。
原文链接:【http://xie.infoq.cn/article/80b3142717df97a5ed37a2d5d】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论