這篇 DolphinScheduler on k8s 雲原生部署實踐，值得所有大資料人看！

海豚调度發表於2024-04-17
K8S大資料

在當前快速發展的技術格局中，企業尋求創新解決方案來簡化運營並提高效率成為一種趨勢。

Apache DolphinScheduler作為一個強大的工具，允許跨分散式系統進行復雜的工作流任務排程。本文將深入探討如何將Apache DolphinScheduler適配並整合進現代IT環境，提升其在雲原生部署中的表現。

前言

Apache DolphinScheduler 的高效雲原生部署模式，比原始部署模式節省了95%以上的人力資源和工作時間，提升了部署效率和成本效益。

透過整合 GitOps 技術，我們提升了Apache DolphinScheduler 的 DevOps 管理能力，改善了軟體交付效率和安全審計能力。

透過整合新的雲原生技術，我們為 Apache DolphinScheduler 增加了水平擴充套件、健康探測和滾動部署等功能，提升了其靈活性和適應性。

將 Prometheus 等可觀測性技術整合到基礎設施和服務網格中，顯著提升了 DolphinScheduler 的監控功能，為其效能和健康狀態提供了更深入的洞察。

與 Kubernetes 作業技術深度整合，實現了 DolphinScheduler 的混合排程器，適用於傳統虛擬機器和基於容器的執行環境，提升了其多樣性和相容性。

專案特點

Apache DolphinScheduler 是由 Analysys 開源的分散式、易於擴充套件的視覺化工作流任務排程平臺，解決了需要企業級問題：

  • 多源資料連線和訪問：技術領域中最常見的資料來源都可以訪問，新增新資料來源不需要太多改動。

  • 多樣化、專業化和大規模資料任務管理：這涉及到大資料（Hadoop 系列、Flink 等）任務排程的問題，與傳統排程器有著顯著區別。

  • 圖形化任務編排：提供了方便的使用者體驗，與商業產品具有競爭力，尤其是對於大多數無法透過拖放直接生成資料任務的國外開源產品而言。

  • 任務細節：豐富的任務、日誌和執行時間軸顯示，滿足了開發人員對精細化資料任務管理的需求，快速定位慢 SQL 和效能瓶頸。

  • 支援各種分散式檔案系統：豐富了使用者對非結構化資料的選擇。

  • 本地多租戶管理：滿足了大型組織對資料任務管理和隔離的需求。

  • 完全自動化的分散式排程演算法來平衡所有排程任務。

  • 本地叢集監控：可以監控 CPU、記憶體、連線數和 Zookeeper 狀態，適用於中小企業的一站式運維。

  • 本地任務告警功能：最大程度地減少任務操作的風險。

  • 強大的社群運營：傾聽客戶的真實聲音，不斷新增新功能，持續最佳化客戶體驗。

分散式叢集

基於早期的微服務技術，Apache DolphinScheduler採用了服務登錄檔的概念，透過使用Zookeeper進行叢集的分散式管理（許多大資料技術使用Zookeeper作為分散式叢集管理）。

Worker主節點可以任意新增，或者可以獨立部署API管理和告警管理。作為一個企業級技術模組，它實現了微服務分離、獨立部署和模組化管理的良好技術特性。然而，在容器化雲原生應用迅速發展的時代，這種基本的技術模式存在一些不足之處：

  • 需要從頭開始部署，無論是安裝在物理機還是虛擬機器上，DolphinScheduler都需要數百個shell操作，一個節點叢集可能需要數千個shell操作。

  • 標準化的企業級DolphinScheduler涉及到管理大量基本環境，並且通常需要超過八個節點、主機和IP地址。這些基礎設施資訊帶來了一定的管理難度。

  • 新增節點時，還需要進行數十個操作（安裝Java、配置主機、設定DS Linux使用者、設定免密碼登入、修改安裝節點配置檔案），並且整個叢集需要停止和重新啟動。

  • 大型企業通常有多個叢集來支援不同的業務單元，這將在工作負載中帶來大量的重複。

  • 排程器具有一些可觀察性功能，但無法與主流工具整合。

  • 整體而言，排程器仍然需要日常例行檢查工作，例如調查核心Java程序異常退出。

  • 在不同的需求和場景下，排程器的配置設定缺乏有效的管理機制或工具。

核心技術思路

解決這些技術缺陷的核心思路包括：

  • 如何將Apache DolphinScheduler整合到當今主流的雲原生技術中；

  • 如何在減少人力資源的情況下部署DolphinScheduler，是否能實現完全自動化的叢集安裝和部署模式；

  • 如何實現完全無伺服器的DolphinScheduler，並大幅降低配置管理的管理成本；

  • 如何標準化技術元件的實現規範；

  • 是否可以實現無人監管執行，並且系統具備自我修復能力；

  • 如何構建並將其整合到現有的可觀測性平臺中。

利用Kubernetes技術

作為雲原生系統技術的事實標準，Kubernetes已經給整個IT應用技術系統帶來了革命性的變化。Kubernetes主要基於服務註冊和發現、負載均衡、自動化軟體釋出和回滾、容器化隔離、軟體自愈和分散式配置管理等核心技術特性。

不僅如此，還可以整合 Cloud Native Computing Foundation（CNCF）的許多優秀專案至 ds on k8s 部署：

  • Apache 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統一起來。

雲原生平臺初始化遷移

部署步驟

  1. 從 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

  2. 使用以下命令來部署一個由 Kubernetes 管理的 DolphinScheduler 例項：

    kubectl create ns ds139
helm install dolphinscheduler . -n ds139

  3. 有時，Apache DolphinScheduler 使用者需要整合 DataX、SeaTunnel、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 的管理資料庫。

這樣，切換到外部資料庫後，即使在 Kubernetes 中完全刪除並重新部署 DolphinScheduler，也不需要重新建立 Apache DolphinScheduler 的應用資料（例如使用者定義的資料處理任務）。

這再次證明了高可用性和資料完整性。此外，建議為Apache DolphinScheduler 元件配置 PersistentVolume，因為如果 pod 重新啟動或升級，歷史 DolphinScheduler 應用日誌將會丟失。

與傳統模式下執行數百個 shell 命令相比，只需修改一個配置檔案，並使用單行安裝命令，就可以自動安裝八個 Apache DolphinScheduler 元件，節省了大量人力成本和操作錯誤。

對於多個 DolphinScheduler 叢集，這將大大降低人力成本，業務部門的等待時間將從幾天減少到不到一個小時，甚至可能十分鐘內完成。

基於Argo CD新增GitOps

Argo CD 是一個基於 Kubernetes 的宣告式 GitOps 持續交付工具，是 CNCF 的孵化專案，也是 GitOps 的最佳實踐工具。

GitOps 對 Apache DolphinScheduler 的實現帶來了以下優勢：

  • 叢集軟體的圖形化和一鍵式安裝

  • Git 記錄了完整的釋出過程，實現一鍵回滾

  • 方便的 DolphinScheduler 工具日誌檢視

一旦實施完成，我們可以看到由 Argo CD 自動部署的 Pod、ConfigMap、Secret、Service、Ingress 等資源，它還顯示了清單提交資訊和使用者名稱，完全記錄了所有釋出事件資訊。同時，還可以透過一鍵點選回滾到歷史版本。

file

相關資源資訊可以透過kubectl命令檢視:

[root@tpk8s-master01 ~]# kubectl get po -n ds139
                           NAME                               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 ds139
              NAME                                READY              AGE
Dolphinscheduler-master		3/3		22m
Dolphinscheduler-worker		3/3		22m

[root@tpk8s-master01 ~]# kubectl get cm -n ds139
          NAME                                     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 ds139
      NAME                               CLASS                       HOSTS ADDRESS
Dolphinscheduler		<none>		ds139.abc.com

還可以看到 Kubernetes 叢集中所有 Pod 都部署在不同的主機上，例如，worker1 和 worker2 分別部署在不同的節點上。
file

一旦配置了 Ingress，我們就可以使用域名在公司的內部網路中訪問 Apache DolphinScheduler 的 Web 使用者介面，讓我們以 DNS 子域名 abc.com 為例：

http://ds139.abc.com/dolphinscheduler/ui/#/home，我們可以在Argo CD 中檢視 Apache DolphinScheduler 的每個元件的內部日誌：

file

使用 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 ds139
                   NAME                                      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 進行任何程式碼修改。

Apache DolphinScheduler 在 k8s 上的服務自愈

眾所周知，當代的IT環境總是處於不穩定狀態。換句話說，我們的技術系統將伺服器、作業系統和網路的各種故障視為叢集中的常規事件。當終端使用者無法透過瀏覽器正常訪問 Apache DolphinScheduler 的任務管理頁面，或者 DolphinScheduler 無法執行常規的大資料任務時，已經為時已晚。

技術現狀

然而，在 Apache DolphinScheduler 轉向雲原生之前，它只能依靠日常監控來檢查主節點/工作節點/API等元件是否正常執行，透過 DolphinScheduler 管理UI，或者透過 jps 檢查Java程序是否存在。

當企業擁有數百個排程環境時，這不僅會花費大量時間，而且更重要的是，系統的可用性將面臨巨大風險。

值得注意的是，Kubernetes 技術本身可以自動重啟和恢復標準化應用程式的有狀態和部署型別，甚至 CRD 本身也可以自動重啟和恢復。

當應用程式失敗時，會記錄異常事件，並重新拉取應用程式以重新啟動應用程式，Kubernetes 將記錄 pod 重新啟動的次數，以便技術人員可以快速定位故障。

除了標準化的自愈機制外，還有主動的健康監控方法。透過構建一個服務介面來主動探測正在執行 DolphinScheduler 的 pod，使用 livenessProbe 機制，當檢測次數超過失敗重試次數時，該機制可以自動重啟 pod。

此外，透過使用 readinessProbe，Kubernetes 叢集可以在探測器捕獲異常時自動切斷對異常 pod 的流量，並在異常事件消失後自動恢復對 pod 的流量請求。

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

可觀測性

我們知道，Prometheus 已經成為雲原生系統中監控工具的事實標準，將 Apache DolphinScheduler 的標準監控整合到 Prometheus 系統中對我們來說是最合理的選擇。

  • Kube-Prometheus 技術可以監控 Kubernetes 叢集中的所有資源。
  • StatefulSet、名稱空間和 Pod 是 DolphinScheduler 的三個主要資源特性。
  • 透過 Kube-Prometheus 技術，可以自動進行 CPU、記憶體、網路、IO、副本等方面的常規監控，無需額外的開發或配置。

我們在 Kubernetes 中使用 Kube-Prometheus operator 技術，在部署後自動監控 Apache DolphinScheduler 的每個元件的資源。

但請注意，Kube-Prometheus 的版本需要與 Kubernetes 的主版本對應。

整合服務網格

作為資料服務提供商，Apache DolphinScheduler 透過服務網格技術實現了服務連結的可觀察性管理，並將其納入內部服務治理系統中。
不僅需要通用資源監控，還需要服務呼叫鏈的監控技術。透過服務網格技術，可以實現 Apache DolphinScheduler 的內部服務呼叫以及 DolphinScheduler API 的外部呼叫的可觀察性分析，最佳化 DolphinScheduler 產品的服務。

此外，作為資料工具的服務元件，Apache 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

還可以觀察元件之間通訊的服務質量，包括每秒請求的數量：

file

雲原生工作流排程

要成為真正的雲原生排程工具，Apache 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是儲存大型資料檔案的事實標準，這些檔案可以很容易地訪問。

當然，Apache 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 生態系統中更多優秀的工具和功能整合，以滿足多樣化的使用者群體和場景需求。

將來的規劃路線包括下邊：

  • 使用 sidecar 定期刪除 worker 作業日誌，實現輕鬆的運維管理

  • 與 Argo Workflows 更深入地整合，使用者可以透過 API、CLI 等在 Apache DolphinScheduler 中呼叫 Argo Workflows 進行單一作業、DAG 作業和定期作業

  • 使用 HPA（Horizontal Pod Autoscaling）自動調整 DolphinScheduler 的任何元件的規模，實現更具彈性的執行環境，並處理不確定的工作負載

  • 整合 Spark 操作器和 Flink 操作器，進行全面的雲原生分散式計算

  • 實現多雲和多叢集的分散式作業排程，並加強無伺服器和 FAAS 類架構屬性。

透過引入雲原生技術和GitOps流程，Apache DolphinScheduler不僅提升了其部署和運維的效率，也增強了其在多樣化和高變性任務處理上的能力。

未來，隨著與Kubernetes生態系統中更多優秀工具和功能的整合，Apache DolphinScheduler預計將為廣泛的使用者群體和場景需求提供支援。

本文由 白鯨開源 提供釋出支援！

相關文章