KubeFlow-Pipeline及Argo實現(xiàn)原理速析

Argo Workflow流程引擎，可以編排容器流程來執(zhí)行業(yè)務邏輯，在20年4月8日進入CNCF孵化器組。

而KubeFlow的Pipeline子項目，由Google開源，其全面依賴Argo作為底層實現(xiàn)，并增強持久層來補充流程管理能力，同時通過Python-SDK來簡化流程的編寫。

1????? Argo流程引擎

Argo的步驟間可以傳遞信息，即下一步（容器）可以獲取上一步（容器）的結(jié)果。結(jié)果傳遞有2種：

1.???? 文件：上一步容器新生成的文件，會直接出現(xiàn)在下一步容器里面。

2.???? 信息：上一步的執(zhí)行結(jié)果信息（如某文件內(nèi)容），下一步也可以拿到。

下面我們就來解讀一下，Argo怎么實現(xiàn)“信息”在容器間的傳遞的，以及它和其他的流程引擎實現(xiàn)傳遞的區(qū)別。

1.2????? 文件怎么從上一個容器跑到下一個容器里的？

Argo流程，可以指定2個步驟之間，傳遞結(jié)果文件（Artifact）。即假設(shè)流程為：A->B，那么A容器跑完，B容器可以取得上一個容器的輸出文件。

如下：A容器生成一個 /tmp/hello_world.txt 文件，Argo將這個文件，放到了B容器里面，并重命名為 /tmp/message文件。

注意：流程上的每個步驟，都對應執(zhí)行一個容器。 在A跑完后容器就退出了，然后才跑的B（這時候已經(jīng)沒有A容器在運行了）。

所以Argo怎么把一個文件從A容器“拷貝”到B容器里面的？

1.2.1??????? 容器間通過共享存儲？（NO）

一般容器間共享文件，首先想到的都是：咱使用共享存儲呀，大家都掛載同一個PVC不就行了。

確實共享存儲可以實現(xiàn)容器共享文件，但是這里Argo可以：

（1）任意指定文件傳遞。（2）傳遞后文件可以改名字。

這2個是共享Volume做不到的，畢竟容器掛載目錄得提前設(shè)定好，然后文件名大家看到的也是一樣的。所以顯然文件傳遞，不是通過共享PVC掛載實現(xiàn)的。

（Ps：不過Argo也在考慮這種實現(xiàn)方式，畢竟共享目錄不需要任何額外IO，透傳效率更高。見：https://github.com/argoproj/argo/issues/1349）

1.2.2??????? 通過管理面中轉(zhuǎn)？（YES）

沒有共享目錄，那中轉(zhuǎn)文件，只能是通過先取出來，再塞回去的方式嘍。實際上Argo也確實這么做的，只是實現(xiàn)上還有些約束。

（1）?????? “臨時中轉(zhuǎn)倉庫”需要引入第三方軟件（Minio）

（2）?????? 文件不能太大

（3）?????? 需要在用戶容器側(cè)，增加“代理”幫忙上傳&下載文件。

1.2.3??????? 中轉(zhuǎn)文件具體實現(xiàn)（docker cp）

現(xiàn)在我們打開Argo看看具體怎么實現(xiàn)的。因為你要取一個容器里面的文件，或者把一個文件放入一個容器，也不容易實現(xiàn)呢。

（1）?????? 小滑頭Argo居給用戶容器設(shè)置了一個SideCar容器，通過這個SideCar去讀取用戶的文件，然后上傳到臨時倉庫。

（2）?????? 一個Pod里面的兩個Container，文件系統(tǒng)也是獨立的，并不能直接取到另一個Container的文件。所以Sidecar容器為了取另一個容器里的文件，又把主機上面的docker.sock掛載進來了。這樣就相當于拿到了主機Root權(quán)限，可以任意cp主機上任意容器里面的文件。

事實上，Sidecar里面取文件的實現(xiàn)是：

docker cp -a 023ce:/tmp/hello_world.txt - | gzip > /argo/outputs/artifacts/hello-art.tgz

感覺稍微有點暴力。

1.2.4??????? 中轉(zhuǎn)實現(xiàn)的其他方式

實際上，通過sidecar容器提權(quán)到root權(quán)限，然后從用戶的容器里面copy任意文件（即 docker cp命令），只是Argo默認的實現(xiàn)。畢竟它自己也發(fā)現(xiàn)這樣做安全上有點說不過去。

所以呢，它也留了其他方式去copy用戶容器里面的文件。比如：kubectl 也是可以cp容器里面的文件的嘛。其他方式可參見：

https://github.com/argoproj/argo/blob/master/docs/workflow-executors.md

1.3????? 下一步容器怎么拿到上一步容器的結(jié)果？

Argo流程，2個步驟之間，除了傳遞文件，還可以傳遞結(jié)果信息（Information）。如：A->B，那么A容器跑完，B容器可以取得上一個容器的一些Information（不是整個文件）。

一般流程引擎透傳信息，都是中轉(zhuǎn)：

不過顯然Argo自己沒有存儲Information的臨時倉庫，所以它得找個地方記錄這些臨時待中轉(zhuǎn)的information（雖然Argo找了Minio這個對象存儲用來暫存中轉(zhuǎn)文件，但是顯然這貨只能存文件，沒有存Metadata元數(shù)據(jù)功能）。這里Argo又找了Pod里面的Annotation字段，當做臨時中轉(zhuǎn)倉庫。先把信息記這里，下一步容器想要，就來這里取。

相信這里應該是有更好的實現(xiàn)方式的，這種把信息記錄到Annotation的做法，約束比較大的（特別是ETCD的單個對象不能超過1M大小）。

可以考慮使用單獨的Configmap來中轉(zhuǎn)也可以。

2????? KubeFlow-Pipeline項目

KubeFlow-Pipeline項目（簡稱KFP），是Kubeflow社區(qū)開源的一個工作流項目，用于管理、部署端到端的機器學習工作流。KFP提供了一個流程管理方案，方便將機器學習中的應用代碼按照流水線的方式編排部署，形成可重復的工作流。

2.1????? 為什么要在Argo之上重新開發(fā)一套？

部署一套Argo很簡單，啟動一個K8s-Controller就行。可是部署一套Kubeflow-Pipeline系統(tǒng)就復雜多了，總共下來有8個組件。那是Argo什么地方不足，需要新開發(fā)一套KFP，并搞這么復雜呢？主要的原因還在于Argo是基于K8s云原生這套理念，即ETCD充當“數(shù)據(jù)庫”來運行的，導致約束比較大。

像：流程模板，歷史執(zhí)行記錄，這些大量的信息很明顯需要一個持久化層（數(shù)據(jù)庫）來記錄的，單純依賴ETCD會有單條記錄不能超過1M，總記錄大小不能超過8G的約束。

所以一個完整的流程引擎，包含一個數(shù)據(jù)庫也都是很常規(guī)的。因此KFP在這一層做了較大的增強。

另外，在ML領(lǐng)域的用戶界面層，KFP也做了較多的用戶體驗改進。包括可以查看每一步的訓練輸出結(jié)果，直接通過UI進行可視化的圖形展示。

https://www.kubeflow.org/docs/pipelines/sdk/output-viewer/

2.2????? Kubeflow-Pipeline后續(xù)演進點

見：https://github.com/kubeflow/pipelines/issues/3550

Dag引擎組件的水平擴展（HPA）是其重要的一個特性，也是要成為一個成熟引擎所必要的能力。

當前KFP在穩(wěn)定性以及組件的水平擴展上都還有待改進，因此商業(yè)使用還需要一段時間，這將是KFP未來的一個重要目標。

同時，使用權(quán)限過于高的Sidecar容器作為其實現(xiàn)步驟之間元數(shù)據(jù)傳遞的途徑，也會是KFP生產(chǎn)級使用的一道門檻。或許在權(quán)限控制方面，KFP需要思考一下其他規(guī)避途徑，至少需要稍微增強一下。

概括一下：（1）水平擴展（HPA），（2）生產(chǎn)級可靠性，（3）安全增強。

3????? 流程引擎核心&分層

3.1????? DAG核心

一個DAG流程引擎，核心代碼也就7行大概能實現(xiàn)了：

例如下圖示例：遍歷發(fā)現(xiàn)步驟D沒有依賴其他步驟，那么本次可以執(zhí)行D步驟。

所以一般程序員一周時間總能開發(fā)一個“還能用”的流程引擎。但是完整的流程引擎卻并不輕松

3.2????? 世界上為什么有這么多的流程引擎

DAG基礎(chǔ)核心非常簡單，同時，各個領(lǐng)域想要做的事情卻迥然不同。即使一個簡單的步驟，大數(shù)據(jù)步驟說：“這一步要執(zhí)行的SQL語句是xxx”，而K8s任務步驟卻說：“這一步執(zhí)行需要的Docker鏡像是yyy”。

所以，各種各樣的流程引擎就自然的出現(xiàn)了。

舉幾個例子：

AWS：Cloudformation編排，Batch服務，SageMaker-ML Pipeline，Data Pipeline

Azure：Pipeline服務，ML Pipeline，Data Factory

Aliyun：函數(shù)Pipeline服務，ROS資源編排，Batch服務，PAI-Studio

大數(shù)據(jù)領(lǐng)域：Oozie，AirFlow

軟件部署：Puppet，Chef，Ansible

基因分析：DNAnexus，NextFlow，Cromwell

每個領(lǐng)域總能找出一兩個流程引擎，來控制誰先干活誰后干活。

總結(jié)一下：

（1）?????? DAG引擎核心很小

（2）?????? 各領(lǐng)域步驟的描述方式不一樣

這就是為什么各個領(lǐng)域，總會有一個自己的流程引擎，而不像K8s能一統(tǒng)容器平臺一樣，出現(xiàn)一個能一統(tǒng)江湖的流程引擎。

3.3????? DAG引擎分層架構(gòu)

成熟的流程引擎，應該有如下4層架構(gòu)：

第一層：用戶交互層。如：模板語法規(guī)則，Console界面等

第二層：API持久化層。如：模板記錄，歷史執(zhí)行記錄等

第三層：引擎實例層。如：能否水平擴容，流程是否有優(yōu)先級等

第四層：驅(qū)動層。如：一個步驟能干什么活。跑一個容器還是跑一個Spark任務。

基本比較成熟的引擎都符合這種架構(gòu)，例如AirFlow流程引擎，華為云的應用編排（AOS）引擎，數(shù)據(jù)湖工廠（DLF）引擎等都是如此。

目前Argo以及Kubeflow-Pipeline在引擎核心組件的水平擴展上，也即第三層引擎能力層稍有不足。同時其驅(qū)動層，目前也只能對接K8s（即只能跑容器任務）。在選型的時候需要考慮進去。

容器 存儲 Docker

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。