ArgoWorkflows 深入解析與 Kubernetes 工作流程協調

Kubernetes 已成為現代應用佈署的標準平台，而 Argo Workflows 作為其原生工作流程引擎，提供了一種便捷的方式來管理複雜的應用佈署流程。Argo Workflows 允許使用者以 YAML 檔案定義工作流程，並將其作為 Kubernetes CRD 提交至叢集。每個步驟都以容器化的方式執行，確保了環境一致性和隔離性。透過 Argo Workflows，開發者可以輕鬆地將資料處理、機器學習訓練等任務自動化，並利用 Kubernetes 的彈性擴充套件能力，提升整體效率。然而，YAML 檔案的維護和 Kubernetes 的學習曲線也為使用者帶來一定的挑戰。為此，Metaflow 等工具的出現，提供了以 Python 程式碼定義工作流程的替代方案，簡化了開發流程，並降低了使用門檻。

探討開源工作流程協調系統：Argo Workflows 詳解

在現代的資料科學和軟體開發領域中，工作流程協調系統扮演著至關重要的角色。Argo Workflows 作為一個開源的工作流程協調系統，專為 Kubernetes 環境設計，提供了一種高效、靈活的方式來管理和執行複雜的工作流程。本篇文章將探討 Argo Workflows 的核心概念、使用案例、關鍵特徵及其在生產環境中的佈署優勢。

Argo Workflows 的運作機制

Argo Workflows 的運作機制如圖 9.6 所示。首先，資料科學家 Vena 定義了一個工作流程及其步驟/任務，將其以 Kubernetes CRD（Custom Resource Definition）物件的形式呈現，通常以 YAML 檔案的形式存在。接著，她將這個工作流程提交給 Argo Workflows，其控制器會在 Kubernetes 叢集中建立相應的 CRD 物件。隨後，Kubernetes pods 會動態啟動，以執行工作流程中的步驟/任務。

值得注意的是，每個步驟的執行都是完全隔離的，透過容器和 pod 實作；每個步驟使用檔案來表示其輸入和輸出值。Argo Workflows 能夠自動將依賴的檔案掛載到步驟的容器中。

使用案例：自動化資料處理工作流程

為了更好地理解 Argo Workflows 的應用，讓我們來看一個具體的使用案例。在這個案例中，我們使用 Argo Workflows 來自動化執行與前一章 Airflow 節中相同的資料處理工作。該工作流程包括檢查新資料、轉換資料、將資料儲存到資料函式庫的新表中，以及透過 Slack 通知資料科學團隊。以下是 Argo Workflows 的定義範例：

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: data-processing-
spec:
  entrypoint: argo-steps-workflow-example
  templates:
  - name: argo-steps-workflow-example
    steps:
    - - name: check-new-data
        template: data-checker
    - - name: transform-data
        template: data-converter
        arguments:
          artifacts:
          - name: data-paths
            from: "{{steps.check-new-data.outputs.artifacts.new-data-paths}}"
    - - name: save-into-db
        template: postgres-operator
    - - name: notify-data-science-team
        template: slack-messenger
  - name: data-checker
    container:
      image: docker/data-checker:latest
      command: [scan, /datastore/ds/]
    outputs:
      artifacts:
      - name: new-data-paths
        path: /tmp/data_paths.txt
  # ... 其他範本定義 ...

內容解密：

1. 工作流程定義：Argo Workflows 的核心概念是工作流程（Workflow）和範本（Template）。工作流程物件代表了一個工作流程的例項，包含其定義和執行狀態。範本定義了要執行的指令，可以視為函式。
2. 步驟之間的引數傳遞：在上述範例中，check-new-data 步驟的輸出（新資料檔案路徑）被儲存到 /tmp/data_paths.txt，並作為輸出值。接著，transform-data 步驟將 check-new-data 的輸出繫結到其輸入，實作了步驟之間的引數傳遞。
3. 執行和監控：提交工作流程後，可以使用 Argo Workflows UI 或命令列工具（如 argo list、argo get）來檢視工作流程執行的詳細資訊。同時，由於 Argo Workflows 原生支援 Kubernetes，也可以使用 Kubernetes CLI 命令（如 kubectl get crd、kubectl describe workflow）進行監控。

Argo Workflows 的關鍵特徵

Argo Workflows 提供以下關鍵特徵：

• 低成本安裝和維護：Argo Workflows 原生執行在 Kubernetes 上，因此可以使用 Kubernetes 的工具進行故障排除。
• 靈活性和隔離性：透過將程式碼容器化，Argo Workflows 提供了極大的靈活性和隔離性，使得程式碼可以在任何 worker 上執行，無需擔心環境組態問題。
• 生產佈署的便捷性：由於程式碼是以 Docker 映像的形式存在，因此在本地測試的程式碼可以直接用於 Argo Workflows，無需進行額外的轉換，大大降低了生產佈署的成本。

總之，Argo Workflows 為 Kubernetes 環境下的工作流程協調提供了一個強大、靈活且易於使用的解決方案。其對容器化的支援和與 Kubernetes 的緊密整合，使其成為現代資料科學和軟體開發領域中一個極具吸引力的選擇。

使用 Argo Workflows 和 Metaflow 最佳化工作流程管理

Argo Workflows 的優勢與侷限性

Argo Workflows 是一款強大的工作流程管理工具，能夠在 Kubernetes 環境中執行複雜的工作流程。它的主要優勢包括：

• 安裝簡便：只需幾個 kubectl 命令即可完成安裝
• 穩健的工作流程執行：利用 Kubernetes Pod 的隔離特性，支援 Cron 工作流程和任務重試
• 範本化和可組合性：範本類別似於函式，支援不同範本的組合，提高了團隊間的協作效率
• 功能全面的 UI：提供方便的使用者介面來管理工作流程的整個生命週期
• 高度靈活和適用性：定義了 REST API 來管理系統和新增新功能，工作流程任務以 Docker 映像定義，使其具有高度的可定製性

然而，Argo Workflows 也存在一些侷限性：

• 需要編寫和維護 YAML 檔案：隨著工作流程數量的增加和邏輯變得更加複雜，YAML 檔案可能會變得冗長和混亂
• 需要具備 Kubernetes 專業知識：對於新手來說，需要花費大量時間學習 Kubernetes 的概念和實踐
• 任務執行延遲：每次任務執行都需要啟動新的 Kubernetes Pod，這可能會引入幾秒鐘或幾分鐘的延遲

詳細分析 Argo Workflows 的任務執行延遲問題

在 Argo Workflows 中，每個新任務都會啟動一個新的 Kubernetes Pod 來執行。這種設計雖然提供了良好的隔離性和可擴充套件性，但也引入了任務執行延遲的問題。對於需要毫秒級回應時間的即時模型預測工作流程來說，Argo Workflows 可能不是最佳選擇。

Metaflow：人性化的 Python 函式庫

Metaflow 是一款專注於 MLOps 的 Python 函式庫，最初由 Netflix 開發並於 2019 年開源。它的設計理念是減少人類在深度學習專案開發中的時間成本（營運成本）。Metaflow 的主要特點包括：

• 簡化工作流程構建：在原型設計和生產環境之間提供統一的開發體驗
• 統一的工作流程執行體驗：無論是在本地還是在生產環境中，工作流程都可以以相同的方式執行

Metaflow 的核心功能

Metaflow 允許使用者透過註解 Python 程式碼（DAG Python 類別）來定義工作流程。然後，Metaflow 函式庫會根據這些註解自動建立/封裝工作流程。除了無縫的工作流程建立和測試之外，Metaflow 還提供了其他有用的功能，如工作流程/步驟版本控制和步驟輸入/輸出儲存。

使用 Metaflow 自動化資料處理工作

以下是一個使用 Metaflow 自動化資料處理工作的範例：

# 定義工作流程 DAG 在一個 Python 類別中
class DataProcessWorkflow(FlowSpec):
    # 定義 "data source" 作為工作流程的輸入引數
    data_source = Parameter(
        "datasource_path", help="資料處理的資料儲存位置", required=True
    )

    @step
    def start(self):
        # 在所有步驟中都可以使用引數 "self.data_source"
        self.newdata_path = dataUtil.fetch_new_data(self.data_source)
        self.next(self.transform_data)

    @step
    def transform_data(self):
        self.new_data = dataUtil.convert(self.newdata_path)
        # 在資料轉換後分支出兩個平行分支
        self.next(self.save_to_db, self.notify_data_science_team)

    @step
    def save_to_db(self):
        dataUtil.store_data(self.new_data)
        self.next(self.join)

    @step
    def notify_data_science_team(self):
        slackUtil.send_notification(messageUtil.build_message(self.new_data))
        self.next(self.join)

    # 合併兩個平行分支步驟：notify_data_science_team 和 save_to_db

詳細解說 Metaflow 程式碼的作用與邏輯

1. 定義工作流程類別：DataProcessWorkflow 類別繼承自 FlowSpec，用於定義資料處理工作流程。
2. 輸入引數：data_source 引數指定了資料儲存的位置，是工作流程的輸入。
3. 步驟定義：使用 @step 修飾符定義了多個步驟，包括 start、transform_data、save_to_db 和 notify_data_science_team。
4. 步驟之間的轉換：使用 self.next() 方法指定了步驟之間的轉換順序。
5. 資料處理邏輯：在每個步驟中，執行特定的資料處理邏輯，例如取得新資料、轉換資料、儲存資料和傳送通知。

此圖示說明瞭 Metaflow 如何提供統一的開發體驗

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title ArgoWorkflows 深入解析與 Kubernetes 工作流程協調

package "Kubernetes Cluster" {
    package "Control Plane" {
        component [API Server] as api
        component [Controller Manager] as cm
        component [Scheduler] as sched
        database [etcd] as etcd
    }

    package "Worker Nodes" {
        component [Kubelet] as kubelet
        component [Kube-proxy] as proxy
        package "Pods" {
            component [Container 1] as c1
            component [Container 2] as c2
        }
    }
}

api --> etcd : 儲存狀態
api --> cm : 控制迴圈
api --> sched : 調度決策
api --> kubelet : 指令下達
kubelet --> c1
kubelet --> c2
proxy --> c1 : 網路代理
proxy --> c2

note right of api
  核心 API 入口
  所有操作經由此處
end note

@enduml

此圖示展示了 Metaflow 如何在本地和生產環境中提供統一的開發體驗。透過 Metaflow 的註解和函式庫，可以簡化工作流程的構建和管理。

9.3 開放原始碼工作流程協調系統實務探討

在探討開放原始碼工作流程協調系統的世界中，我們發現Metaflow提供了一種新穎的工作流程建構方法。透過使用程式碼註解（code annotations），開發者能夠輕鬆地將工作流程DAG（有向無環圖）與原型設計程式碼結合。

使用Metaflow建構工作流程

Metaflow的強大之處在於其能夠直接在程式碼中定義工作流程，而無需將程式碼重新封裝成不同的格式，如Docker映像檔。以下是一個簡單的工作流程範例：

@step
def join(self, inputs):
    self.next(self.end)

@step
def end(self, inputs):
    # 結束工作流程
    pass

if __name__ == "__main__":
    DataProcessWorkflow()

內容解密：

1. @step註解：用於標記工作流程中的步驟。
2. self.next函式：用於連線步驟，定義工作流程的執行順序。
3. DataProcessWorkflow類別：代表整個工作流程。

這個範例展示瞭如何使用Metaflow註解來定義一個簡單的工作流程DAG，如圖9.8所示。

Metaflow的關鍵特性

Metaflow提供了一系列關鍵特性，使其成為機器學習專案的理想選擇：

• 結構化程式碼為工作流程：透過註解Python程式碼來建立工作流程，簡化了工作流程的建構。
• 可重現性：Metaflow保留了執行每個工作流程步驟所需的資料、程式碼和外部依賴項的不可變快照。
• 版本控制：透過對工作流程中的所有程式碼和資料進行雜湊處理，實作了版本控制。
• 強壯的工作流程執行：提供了依賴管理機制，並支援任務重試。
• 機器學習的可用性設計：統一了原型設計和生產環境的API，使相同的程式碼可以在不同環境中無縫執行。
• 無縫擴充套件性：與Kubernetes和AWS Batch整合，允許輕鬆定義所需的計算資源，並平行化工作流程步驟。

Metaflow的限制

雖然Metaflow在機器學習專案中表現出色，但仍有一些限制：

• 不支援條件分支：Metaflow的步驟註解不支援條件分支。
• 缺乏作業排程器：Metaflow本身不包含作業排程器，但可以與其他支援作業排程的協調系統整合。
• 與AWS緊密耦合：Metaflow的一些重要功能與AWS緊密相關，但由於它是開放原始碼專案，因此可以擴充套件到非AWS替代方案。

何時使用Metaflow

對於非機器學習專案，Airflow和Argo Workflows都是優秀的選擇。如果專案執行在Kubernetes上，且團隊熟悉Docker，那麼Argo Workflows是一個不錯的選擇。對於機器學習專案，Metaflow是高度推薦的，因為它不僅是一個協調工具，更是一個專注於節省資料科學家在機器學習開發週期中時間的MLOps工具。

從研究到生產：深度學習系統的路徑

在探討深度學習系統的各個服務之後，本章將對整個流程進行高層次的回顧，並將前幾章的內容串聯起來。我們將重點關注深度學習產品開發週期的三個階段：深度學習研究、原型設計和生產化。

生產化的定義

生產化是指將深度學習模型轉化為可供客戶使用的產品的過程。一個值得生產的模型需要具備以下條件：

• 能夠處理客戶請求
• 承受一定的請求負載
• 優雅地處理異常情況，例如錯誤的輸入和請求過載

研究、原型設計和生產化的流程

圖10.2展示了從研究到生產化的三個主要階段。研究和原型設計階段需要快速迭代和模型訓練實驗，主要透過筆記本環境進行互動。資料科學家和研究人員使用資料集管理服務來跟蹤訓練資料集，並利用訓練服務和超引數最佳化函式庫/服務進行模型訓練和實驗。

研究階段

1. 建立新的筆記本：開始一個新的研究專案。
2. 下載資料集：取得所需的資料集。
3. 原型建模程式碼：撰寫初始的建模程式碼。
4. 訓練模型：使用訓練服務訓練模型。

原型設計階段

1. 資料探索/預處理：對資料進行探索和預處理。
2. 原型建模程式碼：根據研究階段的結果，進一步開發建模程式碼。
3. 訓練模型：繼續訓練和改進模型。

當訓練資料的形狀和程式碼趨於穩定時，研究和原型設計階段即告完成，模型準備好進行生產化。

生產化

在生產化階段，幾乎所有的深度學習系統服務都會被呼叫：

• 資料集管理服務：管理訓練資料。
• 工作流程管理服務：啟動和跟蹤訓練工作流程。
• 訓練服務：執行和管理模型訓練任務。
• 後設資料和工件儲存：儲存和跟蹤程式碼工件、訓練模型及其後設資料。
• 模型服務：將訓練好的模型提供給推理請求流量。

生產化的步驟

1. 分割程式碼為元件：將程式碼分割為可管理的元件。
2. 封裝程式碼：將程式碼封裝以便於佈署。
3. 註冊程式碼包：註冊封裝好的程式碼。
4. 設定工作流程：設定工作流程以自動化模型的訓練和佈署。
5. 執行工作流程和測試推理：執行工作流程並測試模型的推理能力。

佈署策略

在生產化之後，下一步是佈署。本章將探討多種模型佈署策略，以支援在生產環境中更新模型到新版本，以及進行實驗。

佈署策略的重點

• 模型服務：所有推理請求都透過模型服務提供。

透過瞭解從研究到生產的完整流程，您將能夠更好地理解之前章節中討論的第一原理如何影響使用該系統的不同角色的工作。本章的內容將幫助您根據不同的情況調整自己的設計。

影像辨識產品開發例項

本章將使用影像辨識產品的開發作為範例來說明上述所有步驟的實際應用。