写点什么

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

作者:白鲸开源
  • 2025-09-02
    天津
  • 本文字数:2576 字

    阅读完需:约 8 分钟

【硬核干货】把 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-toolsdolphinscheduler-masterdolphinscheduler-workerdolphinscheduler-apidolphinscheduler-alert-server



Worker 镜像


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


./build.sh worker-server
复制代码



单独构建镜像


也可以批量构建所有模块:


./build-all.sh
复制代码



批量构建镜像


这一步里我们遇到的典型问题包括:基础镜像过大导致构建时间过长,源码改造后的 jar 包没有覆盖旧文件,甚至不同模块的端口配置和启动脚本不一致。 这些细节如果处理不当,就会在后续部署阶段带来一系列棘手的问题。


部署方案:从自制 YAML 到官方 Helm Chart

在部署初期,我们是手写 YAML 文件来完成部署的,但这种方式在配置分散和升级维护上成本极高。后来我们改用了官方提供的 Helm Chart,这样配置集中管理,升级也更方便。


我们使用的 K8S 集群版本是 v1.25,部署时需要先创建命名空间 dolphinscheduler,然后拉取 helm 包,例如:


helm pull oci://registry-1.docker.io/apache/dolphinscheduler-helm --version 3.2.2
复制代码


在真正落地过程中,values.yaml 是最核心的文件,我们在这里踩过很多坑。下面贴出几个关键配置片段,供大家参考:

1. 镜像配置

image:  registry: my.private.repo  repository: dolphinscheduler  tag: 3.2.2  pullPolicy: IfNotPresent
复制代码


👉 提示:一些前置的工具镜像最好提前 push 到私有仓库,避免因网络或镜像源问题导致部署失败。

2. 外置数据库配置(MySQL)

mysql:  enabled: false   # 关闭内置 MySQLexternalMysql:  host: mysql.prod.local  port: 3306  username: ds_user  password: ds_password  database: dolphinscheduler
复制代码


👉 内置数据库务必关闭,生产环境统一接入外部 MySQL(未来我们将切换到 PostgreSQL)。

3. LDAP 登录认证

ldap:  enabled: true  url: ldap://ldap.prod.local:389  userDn: cn=admin,dc=company,dc=com  password: ldap_password  baseDn: dc=company,dc=com
复制代码


👉 我们接入了公司 LDAP,统一用户认证,方便权限管理。

4. 共享存储配置

sharedStoragePersistence:  enabled: true  storageClassName: nfs-rwx  size: 100Gi  mountPath: /dolphinscheduler/shared
复制代码


👉 注意:storageClassName 必须支持 ReadWriteMany,否则多个 Worker 节点无法同时访问共享目录。


5. HDFS 配置

hdfs:  defaultFS: hdfs://hdfs-nn:8020  path: /dolphinscheduler  rootUser: hdfs
复制代码


👉 所有大数据相关组件路径需要提前准备好,例如 /opt/soft

6. Zookeeper 配置

zookeeper:  enabled: false   # 关闭内置 ZKexternalZookeeper:  quorum: zk1.prod.local:2181,zk2.prod.local:2181,zk3.prod.local:2181
复制代码


👉 使用外置 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 社区一起搬砖!



发布于: 刚刚阅读数: 3
用户头像

白鲸开源

关注

一家开源原生的DataOps商业公司。 2022-03-18 加入

致力于打造下一代开源原生的DataOps 平台,助力企业在大数据和云时代,智能化地完成多数据源、多云及信创环境的数据集成、调度开发和治理,以提高企业解决数据问题的效率,提升企业分析洞察能力和决策能力。

评论

发布
暂无评论
【硬核干货】把 DolphinScheduler 搬进 K8s:奇虎 360 商业化 900 天踩坑全记录_开源_白鲸开源_InfoQ写作社区