流水線（Pipeline）是把一個重復的過程分解為若干個子過程，使每個子過程與其他子過程并行進行的技術。本文主要介紹了誕生于云原生時代的流水線框架 Argo。
什么是流水線？
在計算機中，流水線是把一個重復的過程分解為若干個子過程，使每個子過程與其他子過程并行進行的技術，也叫 Pipeline。由于這種 s工作方式與工廠中的生產流水線十分相似， 因此也被稱為流水線技術。從本質上講，流水線技術是一種時間并行技術。以“構建鏡像”過程為例：
在每一次構建鏡像中，我們都需要拉下代碼倉庫中的代碼，進行代碼編譯，構建鏡像，最后推往鏡像倉庫。在每一次代碼更改過后，這一過程都是不變的。使用流水線工具可以極大的提升這一過程的效率，只需要進行簡單的配置便可以輕松的完成重復性的工作。這樣的過程也被稱之為 CI。
上圖流程中使用的是 Jenkins。Jenkins 作為老牌流水線框架被大家所熟知。在云原生時代，Jenkins 推出了 Jenkins X 作為基于 Kubernetes 的新一代流水線，另外云原生時代還誕生了兩大流水線框架—— Argo 和 Tekton。本文就詳細介紹了 Argo 的相關內容。
Argo
Argo Workflows 是一個開源的容器原生的工作流引擎，可以在 Kubernetes 上編排并行作業。Argo Workflows 實現為 Kubernetes CRD。
Quick Start
Argo 基于 Kubernetes，可以直接使用 kubectl 安裝，安裝的組件主要包括了一些 CRD 以及對應的 controller 和一個 server。
注意，上述安裝只會執行同 namespace 內的 Workflow，cluster install 詳見文檔。文檔地址：
https://github.com/argoproj/argo/blob/master/docs/installation.md
三級定義
要了解 Argo 定義的 CRD，先從其中的三級定義入手。概念上的從大到小分別為 WorkflowTemplate、Workflow、template，這些資源的命名有些相似，要注意分辨。
Template
從最簡單的 template 說起，一個 template 有多種類型，分別為 container、script、dag、steps、resource 以及 suspend。對于 template，我們可以簡單地將其理解為一個 Pod ——container/script/resource 類型的 template 都會去實際控制一個 Pod，而 dag/steps 類型的 template 則是由多個基礎類型的 template （container/script/resource）組成的。
- container：最常見的模板類型，與 Kubernetes container spec 保持一致。
- script：該類型基于 Container，支持用戶在 template 定義一段腳本，另有一個 Source 字段來表示腳本的運行環境。
- resource：該類型支持我們在 template 中對 kubernetes 的資源進行操作，有一個 action 字段可以指定操作類型，如 create, Apply, delete 等，并且支持設定相關的成功與失敗條件用于判斷該 template 的成功與失敗。
- suspend：Suspend template 將在一段時間內或在手動恢復執行之前暫停執行?？梢詮?CLI （使用 argo resume）、API 或 UI 恢復執行。
- steps：Steps Template 允許用戶以一系列步驟定義任務。在 Steps 中，[--] 代表順序執行，[-] 代表并行執行。
- dag：DAG template 允許用戶將任務定義為帶依賴的有向無環圖。在 DAG 中，通過 dependencies設置在特定任務開始之前必須完成的其他任務。沒有任何依賴項的任務將立即運行。有關 DAG 的詳細邏輯可見源碼 https://github.com/argoproj/argo/blob/master/workflow/controller/dag.go#L204。
Workflow
在一個 Workflow 中，其 spec 中有一個名為 templates 這個字段，在其中至少需要一個 template 作為其組成的任務。
一個最簡單的 hello world 例子如下：
在這個例子中，該 Workflow 的 templates 字段中指定了一個類型為 container 的 template，使用了 whalesay 鏡像。
下面是一個稍微復雜的 workflow：
WorkflowTemplate
WorkflowTemplate 相當于 Workflow 的模板庫，和 Workflow 一樣，也由 template 組成。用戶在創建完 WorkflowTemplate 后，可以通過直接提交它們來執行 Workflow。
Workflow Overview
在了解了 Argo 的三級定義后，我們首先來深入一下 Argo 中最為關鍵的定義，Workflow。Workflow 是 Argo 中最重要的資源，有兩個重要的功能：
- 定義了要執行的工作流。
- 存儲了工作流的狀態。
由于這些雙重職責，Workflow 應該被視為一個 Active 的對象。它不僅是一個靜態定義，也是上述定義的一個“實例”。
Workflow Template 的定義與 Workflow 幾乎一致，除了類型不同。正因為 Workflow 既可以是一個定義也可以是一個實例，所以才需要 WorkflowTemplate 作為 Workflow 的模板，WorkflowTemplate 在定義后可以通過提交（Submit）來創建一個 Workflow。
而 Workflow 由一個 entrypoint 及一系列 template 組成，entrypoint 定義了這個 workflow 執行的入口，而 template 會實際去執行一個 Pod，其中，用戶定義的內容會在 Pod 中以 Main Container 體現。此外，還有兩個 Sidecar 來輔助運行。
Sidecar
在 Argo 中，這些 Sidecar 的鏡像都是 argoexec。Argo 通過這個 executor 來完成一些流程控制。
Init
當用戶的 template 中需要使用到 inputs 中的 artifact 或者是 script 類型時（script 類型需要注入腳本），Argo 都會為這個 pod 加上一個 Init Container —— 其鏡像為 argoexec，命令是 argoexec init。
在這個 Init Container 中，主要工作就是加載 artifact：
Wait
除了 Resource 類型外的 template，Argo 都會注入一個 Wait Container，用于等待 Main Container 的完成并結束所有 Sidecar。這個 Wait Container 的鏡像同樣為 argoexec，命令是 argoexec wait。（Resource 類型的不需要是因為 Resource 類型的 template 直接使用 argoexec 作為 Main Container 運行）
Inputs and Outputs
在運行 Workflow 時，一個常見的場景是輸出產物的傳遞。通常，一個 Step 的輸出產物可以用作后續步驟的輸入產物。在 Argo 中，產物可以通過 Artifact 或是 Parameter 傳遞。
Artifact
要使用 Argo 的 Artifact，首先必須配置和使用 Artifact 存儲倉庫。具體的配置方式可以通過修改存有 Artifact Repository 信息的默認 Config Map 或者在 Workflow 中顯示指定，詳見 配置文檔，在此不做贅述。下表為 Argo 支持的倉庫類型。
一個簡單的使用了 Artifact 的例子如下：
默認情況下，Artifact 被打包為 tar 包和 gzip 包，我們也可以使用 archive 字段指定存檔策略。
在上面的例子里，名為 whalesay 的 template 使用 cowsay 命令生成一個名為 /tmp/hello-world.txt 的文件，然后將該文件作為一個名為 hello-art 的 Artifact 輸出。名為 print-message 的 template 接受一個名為 message 的輸入 Artifact，在 /tmp/message 的路徑上解包它，然后使用 cat 命令打印 /tmp/message 的內容。
在前面 Sidecar 介紹中提到過，Init Container 主要用于拉取 Artifact 產物。這些 Sidecar 正是產物傳遞的關鍵。下面，我們通過介紹另一種產物傳遞的方式來體驗 Argo 中傳遞產物的關鍵。
Scripts
先來看一個簡單的例子：
在上面的例子中，有兩個類型為 script 的 template，script 允許使用 source 規范腳本主體。這將創建一個包含腳本主體的臨時文件，然后將臨時文件的名稱作為最后一個參數傳遞給 command（執行腳本主體的解釋器），這樣便可以方便的執行不同類型的腳本（bash、Python、js etc）。
Script template 會將腳本的標準輸出分配給一個名為 result 的特殊輸出參數從而被其他 template 調用。在這里，通過 {{
steps.generate.outputs.result}} 即可獲取到名為 generate 的 template 的腳本輸出。
{{xxx}} 是 Argo 固定的變量替換格式：
關于變量的格式詳見文檔，文檔地址：
https://github.com/argoproj/argo/blob/master/docs/variables.md關于變量替換的邏輯詳見源碼，源碼地址：
https://github.com/argoproj/argo/blob/master/workflow/common/util.go#L305
那么，容器內部應該如何獲取這個腳本輸出呢？
我們回到 Sidecar，在 Wait Container 中，有這樣一段邏輯：
再來看看這個 Wait Container 的 Volume Mount 情況：
現在就十分明確了，Wait Container 通過掛載 Docker.sock 以及 service account，獲取到 Main Container 中的輸出結果，并保存到 Workflow 中。當然，因為 Workflow 中保存了大量的信息，當一個 Workflow 的 Step 過多時，整個 Workflow 的結構會過于龐大。
Parameter
Parameter 提供了一種通用機制，可以將步驟的結果用作參數。Parameter 的工作原理與腳本結果類似，除了輸出參數的值會被設置為生成文件的內容，而不是 stdout 的內容。如：
Volume
這并不是 Argo 處理產物傳遞的一種標準方式，但是通過共享存儲，我們顯然也能達到共通產物的結果。當然，如果使用 Volume，我們則無需借助 Inputs 和 Outputs。
在 Workflow 的 Spec 中，我們定義一個 Volume 模板：
并在其他的 template 中 mount 該 volume：
其他流程控制功能
循環
在編寫 Workflow 時，能夠循環迭代一組輸入通常是非常有用的，如下例所示:
在源碼實現中，將會去判斷 withItems，如果存在，則對其中的每個元素進行一次 step 的擴展。
條件判斷
通過 when 關鍵字指定：
錯誤重嘗
遞歸
Template 可以遞歸地相互調用，這是一個非常實用的功能。例如在機器學習場景中：可以設定準確率必須滿足一個值，否則就持續進行訓練。在下面這個拋硬幣例子中，我們可以持續拋硬幣，直到出現正面才結束整個工作流。
以下是兩次執行的結果，第一次執行直接拋到正面，結束流程；第二次重復三次后才拋到正面，結束流程。
退出處理
退出處理是一個指定在 workflow 結束時執行的 template，無論成功或失敗。
對比 Tekton
相較于 Tekton 而言，Argo 的流程控制功能更加豐富。擁有著循環、遞歸等功能，這對于一些機器學習的場景都是十分適用的。而 Argo 社區對自己的定位也是 MLOps、AIOps、Data/Batch Processing，這也正是 Kubeflow Pipeline 底層基于 Argo 的原因（盡管 KFP 也在做 Tekton 的 backend）。
但是在權限控制方面，Argo 做的就不如 Tekton，我個人認為，Tekton 的結構定義更為清晰。二者各有優劣，可以根據自己的需求進行選擇。
