【硬核干货】把 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 基础镜像之上进行定制，主要修改端口和配置。为了减少后续配置文件的改动，我们尽量保持模块镜像的名称与官方一致。构建时既可以单独构建某个模块，例如：

./build.sh worker-server