DolphinScheduler on k8s 云原生部署实践-编程知识

文章目录

- 前言
- 利用Kubernetes技术
- 云原生平台初始化迁移
- 基于Argo CD添加GitOps
- DolphinScheduler 在 k8s 上的服务自愈
- 可观测性
- 集成服务网格
- 云原生工作流调度
- 从HDFS升级到S3文件技术
- 总结

前言

DolphinScheduler 的高效云原生部署模式，比原始部署模式节省了95%以上的人力资源和工作时间，提升了部署效率和成本效益。
通过集成 GitOps 技术，我们提升了 DolphinScheduler 的 DevOps 管理能力，改善了软件交付效率和安全审计能力。
通过集成新的云原生技术，我们为 DolphinScheduler 增加了水平扩展、健康探测和滚动部署等功能，提升了其灵活性和适应性。
将 Prometheus 等可观测性技术整合到基础设施和服务网格中，显著提升了 DolphinScheduler 的监控功能，为其性能和健康状态提供了更深入的洞察。
与 Kubernetes 作业技术深度整合，实现了 DolphinScheduler 的混合调度器，适用于传统虚拟机和基于容器的运行环境，提升了其多样性和兼容性。

DolphinScheduler 是由 Analysys 开源的分布式、易于扩展的可视化工作流任务调度平台，解决了需要企业级问题：

多源数据连接和访问：技术领域中最常见的数据源都可以访问，添加新数据源不需要太多改动。
多样化、专业化和大规模数据任务管理：这涉及到大数据（Hadoop 系列、Flink 等）任务调度的问题，与传统调度器有着显著区别。
图形化任务编排：提供了方便的用户体验，与商业产品具有竞争力，尤其是对于大多数无法通过拖放直接生成数据任务的国外开源产品而言。
任务细节：丰富的任务、日志和运行时间轴显示，满足了开发人员对精细化数据任务管理的需求，快速定位慢 SQL 和性能瓶颈。
支持各种分布式文件系统：丰富了用户对非结构化数据的选择。
本地多租户管理：满足了大型组织对数据任务管理和隔离的需求。
完全自动化的分布式调度算法来平衡所有调度任务。
本地集群监控：可以监控 CPU、内存、连接数和 Zookeeper 状态，适用于中小企业的一站式运维。
本地任务告警功能：最大程度地减少任务操作的风险。
强大的社区运营：倾听客户的真实声音，不断添加新功能，持续优化客户体验。

基于早期的微服务技术，DolphinScheduler采用了服务注册表的概念，通过使用Zookeeper进行集群的分布式管理（许多大数据技术使用Zookeeper作为分布式集群管理）。Worker主节点可以任意添加，或者可以独立部署API管理和告警管理。作为一个企业级技术模块，它实现了微服务分离、独立部署和模块化管理的良好技术特性。然而，在容器化云原生应用迅速发展的时代，这种基本的技术模式存在一些不足之处：

需要从头开始部署，无论是安装在物理机还是虚拟机上，DolphinScheduler都需要数百个shell操作，一个节点集群可能需要数千个shell操作。
标准化的企业级DolphinScheduler涉及到管理大量基本环境，并且通常需要超过八个节点、主机和IP地址。这些基础设施信息带来了一定的管理难度。
添加节点时，还需要进行数十个操作（安装Java、配置主机、设置DS Linux用户、设置免密码登录、修改安装节点配置文件），并且整个集群需要停止和重新启动。
大型企业通常有多个集群来支持不同的业务单元，这将在工作负载中带来大量的重复。
调度器具有一些可观察性功能，但无法与主流工具集成。
整体而言，调度器仍然需要日常例行检查工作，例如调查核心Java进程异常退出。
在不同的需求和场景下，调度器的配置设置缺乏有效的管理机制或工具。

解决这些技术缺陷的核心思路包括：

如何将DolphinScheduler集成到当今主流的云原生技术中；
如何在减少人力资源的情况下部署DolphinScheduler，是否能实现完全自动化的集群安装和部署模式；
如何实现完全无服务器的DolphinScheduler，并大幅降低配置管理的管理成本；
如何标准化技术组件的实现规范；
是否可以实现无人监管运行，并且系统具备自我修复能力；
如何构建并将其集成到现有的可观测性平台中。

利用Kubernetes技术

作为云原生系统技术的事实标准，Kubernetes已经给整个IT应用技术系统带来了革命性的变化。Kubernetes主要基于服务注册和发现、负载均衡、自动化软件发布和回滚、容器化隔离、软件自愈和分布式配置管理等核心技术特性。
不仅如此，还可以整合 Cloud Native Computing Foundation（CNCF）的许多优秀项目至 ds on k8s 部署：

DolphinScheduler的部署技术得到了改进。我们使用了Helm和Argo CD来大大简化和实现一键部署。
通过Argo CD实现了配置内容的GitOps管理机制，从而实现了现代DevOps的完整审计能力。
Kubernetes的水平Pod自动缩放技术大大简化了应用扩展的操作难度。
Kubernetes的标准化健康探针技术使得调度器的所有技术组件都具备了强大的自愈能力。
Kubernetes和Argo CD的滚动发布技术实现了DolphinScheduler工具的优雅简单升级。
使用Kube-Prometheus技术为DolphinScheduler带来了标准化的可观测性能力。
强大的UI技术简化了CMDB可视化管理、基于Kubernetes的组件配置管理、应用日志管理等。

还可以向DolphinScheduler引入了更强大的工具，以获取更丰富的云原生特性：

通过Kubernetes服务注册发现和Ingress技术实现了更轻松的服务访问；
引入了Linkerd，将服务网格的功能引入DolphinScheduler，提高了所有API的管理和监控能力；
将DolphinScheduler与Argo Workflows或标准的Kubernetes作业结合起来；
引入对象存储技术MinIO，将存储非结构化数据的技术与DolphinScheduler统一起来。

云原生平台初始化迁移

部署步骤

从 GitHub 存储库的 dolphinscheduler-1.3.9.tar.gz 文件中的 ./dolphinscheduler-1.3.9/docker/kubernetes/dolphinscheduler 文件夹中获取 Helm 包:

https://github.com/apache/dolphinscheduler/archive/refs/tags/1.3.9.tar.gz
使用以下命令来部署一个由 Kubernetes 管理的 DolphinScheduler 实例：
```
kubectl create ns ds139
helm install dolphinscheduler . -n ds139
```

有时，DolphinScheduler 用户需要集成 DataX、MySQL JDBC 驱动程序或 Oracle JDBC 驱动程序以进行 ETL 和数据库连接。我们可以下载必要的组件，构建新的 Docker 镜像，然后升级 Kubernetes 管理的 DolphinScheduler 实例：

#Download the additional components
https://repo1.maven.org/maven2/mysql/mysql-connector-java/5.1.49/mysql-connector-java-
5.1.49.jar
https://repo1.maven.org/maven2/com/oracle/database/jdbc/ojdbc8/
https://github.com/alibaba/DataX/blob/master/userGuid.md#Create a new docker image with new tag by this Dockerfile
FROM apache/dolphinscheduler:1.3.9
COPY *.jar /opt/dolphinscheduler/lib/
RUN mkdir -p /opt/soft/datax
COPY datax /opt/soft/datax#Edit image tag of helm value.yaml file, and execute helm upgrade.
helm upgrade dolphinscheduler -n ds139

一般建议在生产环境中使用独立的外部 PostgreSQL 作为 DolphinScheduler 的管理数据库。z这样，切换到外部数据库后，即使在 Kubernetes 中完全删除并重新部署 DolphinScheduler，也不需要重新创建 DolphinScheduler 的应用数据（例如用户定义的数据处理任务）。这再次证明了高可用性和数据完整性。此外，建议为 DolphinScheduler 组件配置 PersistentVolume，因为如果 pod 重新启动或升级，历史 DolphinScheduler 应用日志将会丢失。

与传统模式下执行数百个 shell 命令相比，只需修改一个配置文件，并使用单行安装命令，就可以自动安装八个 DolphinScheduler 组件，节省了大量人力成本和操作错误。对于多个 DolphinScheduler 集群，这将大大降低人力成本，业务部门的等待时间将从几天减少到不到一个小时，甚至可能十分钟内完成。

基于Argo CD添加GitOps

Argo CD 是一个基于 Kubernetes 的声明式 GitOps 持续交付工具，是 CNCF 的孵化项目，也是 GitOps 的最佳实践工具。
GitOps 对 Apache DolphinScheduler 的实现带来了以下优势：

集群软件的图形化和一键式安装
Git 记录了完整的发布过程，实现一键回滚
方便的 DolphinScheduler 工具日志查看

一旦实施完成，我们可以看到由 Argo CD 自动部署的 Pod、ConfigMap、Secret、Service、Ingress 等资源，它还显示了清单提交信息和用户名，完全记录了所有发布事件信息。同时，还可以通过一键点击回滚到历史版本。

相关资源信息可以通过kubectl命令查看:

[root@tpk8s-master01 ~]# kubectl get po -n ds139NAME                               READY   STATUS  RESTARTS           AGE
Dolphinscheduler-alert-96c74dc84-72cc9	1/1	Running	0		22m
Dolphinscheduler-api-78db664b7b-gsltq	1/1	Running	0		22m
Dolphinscheduler-master-0			1/1	Running	0		22m
Dolphinscheduler-master-1			1/1	Running	0		22m
Dolphinscheduler-master-2			1/1	Running	0		22m
Dolphinscheduler-worker-0			1/1	Running	0		22m
Dolphinscheduler-worker-1			1/1	Running	0		22m
Dolphinscheduler-worker-2			1/1	Running	0		22m[root@tpk8s-master01 ~]# kubectl get statefulset -n ds139NAME                                READY              AGE
Dolphinscheduler-master		3/3		22m
Dolphinscheduler-worker		3/3		22m[root@tpk8s-master01 ~]# kubectl get cm -n ds139NAME                                     DATA                AGE
Dolphinscheduler-alert		15		23m
Dolphinscheduler-api			1		23m
Dolphinscheduler-common		29		23m
Dolphinscheduler-master		10		23m
Dolphinscheduler-worker		7		23m[root@tpk8s-master01 ~]# kubectl get service -n ds139
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
Dolphinscheduler-api	ClusterIP	10.43.238.5	<none> 12345/TCP 23m
Dolphinscheduler-master-headless ClusterIP None	<none> 5678/TCP 23m
Dolphinscheduler-worker-headless ClusterIP None 	<none> 1234/TCP,50051/TCP 23m[root@tpk8s-master01 ~]# kubectl get ingress -n ds139NAME                               CLASS                       HOSTS ADDRESS
Dolphinscheduler		<none>		ds139.abc.com

还可以看到 Kubernetes 集群中所有 Pod 都部署在不同的主机上，例如，worker1 和 worker2 分别部署在不同的节点上。

一旦我们配置了 Ingress，我们就可以使用域名在公司的内部网络中访问 DolphinScheduler 的 Web 用户界面，让我们以 DNS 子域名 abc.com 为例：http://ds139.abc.com/dolphinscheduler/ui/#/home。我们可以在 Argo CD 中查看 Apache DolphinScheduler 的每个组件的内部日志：

使用 Argo CD，修改主节点、工作节点、API 或警报等组件的副本数量非常方便。Apache DolphinScheduler 的 Helm 配置还保留了 CPU 和内存的设置信息。在 value.yaml 文件中修改副本的设置。修改后，我们可以将其推送到公司的内部源代码系统：

master:podManagementPolicy: "Parallel"replicas: "5"
worker:podManagementPolicy: "Parallel"replicas: "5"
alert:replicas: "3"
api:replicas: "3"

只需在 Argo CD 上点击同步即可进行同步，所需的相应 pod 将被添加。

[root@tpk8s-master01 ~]# kubectl get po -n ds139NAME                                      READY   STATUS              RESTARTS            AGE
Dolphinscheduler-alert-96c74dc84-72cc9	1/1	Running		0		43m
Dolphinscheduler-alert-96c74dc84-j6zdh	1/1	Running		0		2m27s
Dolphinscheduler-alert-96c74dc84-rn9wb	1/1	Running		0		2m27s
Dolphinscheduler-api-78db664b7b-6j8rj	1/1	Running		0		2m27s
Dolphinscheduler-api-78db664b7b-bsdgv	1/1	Running		0		2m27s
Dolphinscheduler-api-78db664b7b-gsltq	1/1	Running		0		43m
Dolphinscheduler-master-0			1/1	Running		0		43m
Dolphinscheduler-master-1			1/1	Running		0		43m
Dolphinscheduler-master-2			1/1	Running		0		43m
Dolphinscheduler-master-3			1/1	Running		0		2m27s
Dolphinscheduler-master-4			1/1	Running		0		2m27s
Dolphinscheduler-worker-0			1/1	Running		0		43m
Dolphinscheduler-worker-1			1/1	Running		0		43m
Dolphinscheduler-worker-2			1/1	Running		0		43m
Dolphinscheduler-worker-3			1/1	Running		0		2m27s
Dolphinscheduler-worker-4			1/1	Running		0		2m27s

不仅如此，基于 Argo CD 的 GitOps 技术为整个 DolphinScheduler 工具提供了图形化、自动化、可追溯、可审计和强大的 DevOps、回滚和监控功能，而无需对 DolphinScheduler 进行任何代码修改。

DolphinScheduler 在 k8s 上的服务自愈

众所周知，当代的IT环境总是处于不稳定状态。换句话说，我们的技术系统将服务器、操作系统和网络的各种故障视为集群中的常规事件。当最终用户无法通过浏览器正常访问 DolphinScheduler 的任务管理页面，或者 DolphinScheduler 无法运行常规的大数据任务时，已经为时已晚。

然而，在 DolphinScheduler 转向云原生之前，它只能依靠日常监控来检查主节点/工作节点/API等组件是否正常运行，通过 DolphinScheduler 管理UI，或者通过 jps 检查Java进程是否存在。当企业拥有数百个调度环境时，这不仅会花费大量时间，而且更重要的是，系统的可用性将面临巨大风险。

值得注意的是，Kubernetes 技术本身可以自动重启和恢复标准化应用程序的有状态和部署类型，甚至 CRD 本身也可以自动重启和恢复。当应用程序失败时，会记录异常事件，并重新拉取应用程序以重新启动应用程序，Kubernetes 将记录 pod 重新启动的次数，以便技术人员可以快速定位故障。

除了标准化的自愈机制外，还有主动的健康监控方法。通过构建一个服务接口来主动探测正在运行 DolphinScheduler 的 pod，使用 livenessProbe 机制，当检测次数超过失败重试次数时，该机制可以自动重启 pod。此外，通过使用 readinessProbe，Kubernetes 集群可以在探测器捕获异常时自动切断对异常 pod 的流量，并在异常事件消失后自动恢复对 pod 的流量请求。

livenessProbe:enabled: trueinitialDelaySeconds: "30"periodSeconds: "30"timeoutSeconds: "5"failureThreshold: "3"successThreshold: "1"
readinessProbe:enabled: trueinitialDelaySeconds: "30"periodSeconds: "30"timeoutSeconds: "5"failureThreshold: "3"successThreshold: "1"

可观测性

我们知道，Prometheus 已经成为云原生系统中监控工具的事实标准，将 DolphinScheduler 的标准监控整合到 Prometheus 系统中对我们来说是最合理的选择。Kube-Prometheus 技术可以监控 Kubernetes 集群中的所有资源。StatefulSet、命名空间和 Pod 是 DolphinScheduler 的三个主要资源特性。通过 Kube-Prometheus 技术，可以自动进行 CPU、内存、网络、IO、副本等方面的常规监控，无需额外的开发或配置。

我们在 Kubernetes 中使用 Kube-Prometheus operator 技术，在部署后自动监控 Apache DolphinScheduler 的每个组件的资源。但请注意，Kube-Prometheus 的版本需要与 Kubernetes 的主版本对应。

集成服务网格

作为数据服务提供商，DolphinScheduler 通过服务网格技术实现了服务链接的可观察性管理，并将其纳入内部服务治理系统中。

DolphinScheduler 不仅需要通用资源监控，还需要服务调用链的监控技术。通过服务网格技术，可以实现 DolphinScheduler 的内部服务调用以及 DolphinScheduler API 的外部调用的可观察性分析，优化 DolphinScheduler 产品的服务。

此外，作为数据工具的服务组件，DolphinScheduler 可以通过服务网格工具无缝集成到企业的内部服务模式中。它使得具有 TLS 服务通信能力、客户端服务通信重试机制和跨集群服务注册发现等功能成为可能，而无需修改 DolphinScheduler 的代码。通过服务网格技术，可以实现对 Apache DolphinScheduler 的 API 外部服务调用和内部调用的可观察性分析，从而优化 Apache DolphinScheduler 产品服务。

我们使用了 Linkerd 作为服务网格产品进行集成，这也是 CNCF 出色的毕业项目之一。通过修改 Apache DolphinScheduler Helm 中 value.yaml 文件中的注释，并重新部署，可以快速将网格代理 sidecar 注入到 DolphinScheduler 的 master、worker、API、alert 等组件中。

annotations:linkerd.io/inject: enabled

还可以观察组件之间通信的服务质量，包括每秒请求的数量：

云原生工作流调度

要成为真正的云原生调度工具，DolphinScheduler需要能够调度云原生作业流程。

DolphinScheduler调度的任务都是在固定的Pod中执行。在这种模式下，任务开发技术的隔离要求相对较高。

特别是在Python语言环境下，团队中会存在不同版本的Python基础和依赖包，甚至版本之间的差异可能会出现数百种组合。依赖包的轻微差异就会导致Python程序运行错误。这也是阻止DolphinScheduler运行大量Python应用程序的障碍。建议采取以下方法，以便DolphinScheduler能够快速与Kubernetes作业系统集成，并具有强大的任务隔离和并发能力：

使用标准的Kubernetes API系统进行作业提交。可以通过kubectl命令行或REST API直接提交任务。
将kubectl命令文件上传到DolphinScheduler，并通过DolphinScheduler的shell任务提交。
使用Argo Workflows项目的Argo CLI命令或REST API命令进行提交。

无论是Kubernetes还是Argo Workflows，都需要添加watch功能，因为Kubernetes是一种异步技术，需要等待任务完成。

在这里，我们以Argo Workflows为例，我们可以在DolphinScheduler中创建一个新的shell任务或步骤，并将以下命令粘贴到其中。结果，我们可以将常规的数据作业（例如数据库SQL作业、Spark作业或Flink作业）和云原生作业结合起来，执行更全面的作业流程。例如，这个作业是一个Hive SQL任务，用于导出Web应用的用户点击数据：

beeline -u "jdbc:hive2://192.168.1.1:10006" --outputformat=csv2 -e "select * from database.user-click" > user-click.csv

这个示例作业是一个Python Tensorflow任务，用于通过训练数据构建机器学习模型。该作业通过HTTP方式运行。首先，我们运行该作业：
通过HTTP方式运行Python Tensorflow作业

curl --request POST -H "Authorization: ${ARGO_TOKEN}" -k \--url https://argo.abc.com/api/v1/workflows/argo \--header 'content-type: application/json' \--data '{"namespace": "argo","serverDryRun": false,"workflow": {"metadata": {"name": "python-tensorflow-job","namespace": "argo"},"spec": {"templates": [{"name": "python-tensorflow","container": {"image": "tensorflow/tensorflow:2.9.1","command": ["python"],"args": ["training.py"],"resources": {}}}],"entrypoint": "python-tensorflow","serviceAccountName": "argo","arguments": {}}}}'

然后我们可以检查工作信息和状态:

#Http way to check the Python Tensorflow job information and status
curl --request GET -H "Authorization: ${ARGO_TOKEN}" -k \--url https:/argo.abc.com/api/v1/workflows/argo/python-tensorflow-job

从HDFS升级到S3文件技术

分布式算法是云原生技术领域之一，比如谷歌的Kubeflow技术，它完美地结合了TensorFlow和Kubernetes。分布式算法通常使用文件，而S3是存储大型数据文件的事实标准，这些文件可以很容易地访问。当然，DolphinScheduler还集成了MinIO技术，通过简单的配置可以实现S3文件管理。

首先，通过修改Helm value.yaml文件中的configmap部分，将其指向一个MinIO服务器。

configmap:DOLPHINSCHEDULER_OPTS: ""DATA_BASEDIR_PATH: "/tmp/dolphinscheduler"RESOURCE_STORAGE_TYPE: "S3"RESOURCE_UPLOAD_PATH: "/dolphinscheduler"FS_DEFAULT_FS: "s3a://dfs"FS_S3A_ENDPOINT: "http://192.168.1.100:9000"FS_S3A_ACCESS_KEY: "admin"FS_S3A_SECRET_KEY: "password"

在MinIO中存储文件的桶的名称称为“dolphinscheduler”。用户通过DolphinScheduler UI上传的共享文件存储在这个文件夹中。

总结

作为一款新一代的云原生大数据工具，Apache DolphinScheduler 有望在将来与 Kubernetes 生态系统中更多优秀的工具和功能集成，以满足多样化的用户群体和场景需求。ds 将来的规划路线包括下边：

使用 sidecar 定期删除 worker 作业日志，实现轻松的运维管理
与 Argo Workflows 更深入地集成，用户可以通过 API、CLI 等在 Apache DolphinScheduler 中调用 Argo Workflows 进行单一作业、DAG 作业和定期作业
使用 HPA（Horizontal Pod Autoscaling）自动调整 DolphinScheduler 的任何组件的规模，实现更具弹性的运行环境，并处理不确定的工作负载
集成 Spark 操作器和 Flink 操作器，进行全面的云原生分布式计算
实现多云和多集群的分布式作业调度，并加强无服务器和 FAAS 类架构属性。