Kubeflow：理解模型決策的變化

– 79 分鐘閱讀

監控模型的解釋性指標可以幫助理解模型決策邏輯是否發生變化：

# 模型解釋性監控
import numpy as np
import pandas as pd
import matplotlib.pyplot as plt
from sklearn.inspection import permutation_importance

class ExplainabilityMonitor:
    def __init__(self, model, feature_names, baseline_importance=None):
        """初始化解釋性監控器
        
        Args:
            model: 機器學習模型
            feature_names: 特徵名稱列表
            baseline_importance: 基準特徵重要性
        """
        self.model = model
        self.feature_names = feature_names
        self.baseline_importance = baseline_importance
        self.importance_history = []
        
    def calculate_feature_importance(self, X, y, timestamp=None):
        """計算特徵重要性
        
        Args:
            X: 特徵資料
            y: 標籤資料
            timestamp: 可選的時間戳
        
        Returns:
            importance_results: 包含特徵重要性的字典
        """
        if timestamp is None:
            timestamp = pd.Timestamp.now()
            
        # 使用排列重要性計算特徵重要性
        perm_importance = permutation_importance(
            self.model, X, y, n_repeats=10, random_state=42
        )
        
        # 組織結果
        importance_results = {
            "timestamp": timestamp,
            "feature_importance": {}
        }
        
        for i, feature in enumerate(self.feature_names):
            importance_results["feature_importance"][feature] = {
                "mean_importance": perm_importance.importances_mean[i],
                "std_importance": perm_importance.importances_std[i]
            }
        
        # 記錄歷史
        self.importance_history.append(importance_results)
        
        # 如果有基準重要性，檢查變化
        if self.baseline_importance is not None:
            importance_results["changes"] = self._compare_with_baseline(importance_results)
            
        return importance_results
    
    def _compare_with_baseline(self, current_importance):
        """比較當前特徵重要性與基準"""
        changes = {}
        
        for feature in self.feature_names:
            if feature in self.baseline_importance and feature in current_importance["feature_importance"]:
                baseline_value = self.baseline_importance[feature]["mean_importance"]
                current_value = current_importance["feature_importance"][feature]["mean_importance"]
                
                # 計算相對變化
                if abs(baseline_value) > 1e-10:
                    relative_change = (current_value - baseline_value) / abs(baseline_value)
                else:
                    relative_change = float('inf') if current_value != 0 else 0
                
                changes[feature] = {
                    "baseline_importance": baseline_value,
                    "current_importance": current_value,
                    "relative_change": relative_change
                }
        
        # 檢查變化是否顯著
        significant_changes = {
            feature: info for feature, info in changes.items() 
            if abs(info["relative_change"]) > 0.5  # 閾值可根據需要調整
        }
        
        if significant_changes:
            print("警告: 檢測到以下特徵的重要性發生顯著變化:")
            for feature, info in significant_changes.items():
                change_direction = "增加" if info["relative_change"] > 0 else "減少"
                print(f"  - {feature}: {change_direction} {abs(info['relative_change'])*100:.1f}%")

認識Kubeflow：機器學習工作流程的現代化解決方案

無論你是嘗試將模型推向生產環境的資料科學家，還是致力於讓模型更具可擴充套件性與可靠性的資料工程師，Kubeflow都能提供強大的工具支援。作為一個專為機器學習設計的平台，Kubeflow解決瞭如何將機器學習從研究階段順利轉移到生產環境的關鍵問題。

許多人對Kubeflow存在誤解，認為它僅是Kubernetes和TensorFlow的組合。事實上，Kubeflow的功能遠不止於此，它可用於各種機器學習任務。如果你的組織正在使用Kubernetes，Kubeflow很可能是適合你的工具。

在這篇文章中，玄貓將幫助你評估Kubeflow是否適合你的使用場景。我們將探討使用Kubeflow能夠獲得的好處，相關的成本考量，以及一些替代選項。接著，我們將深入瞭解Kubeflow的設定和如何構建端對端解決方案，讓你熟悉其基本操作。

模型開發生命週期：從資料到洞見的旅程

機器學習或模型開發本質上遵循這樣一條路徑：資料 → 資訊 → 知識 → 洞見。這個從資料生成洞見的過程可以用模型開發生命週期(Model Development Life Cycle, MDLC)來描述。

MDLC是一個常用術語，用於描述訓練和推論之間的流動關係。這是一個持續互動的過程，每當觸發模型更新時，整個週期就會重新啟動。模型開發生命週期涵蓋了從資料探索、特徵準備、模型訓練/調整、模型佈署、模型測試到模型版本控制的所有階段。

Kubeflow在MDLC中的定位

Kubeflow是一套雲原生工具集合，涵蓋MDLC的所有階段。它不僅提供各個階段所需的工具，還能讓這些傳統上分離的工具無縫協作。其中一個重要的元件是管道系統(pipeline system)，讓使用者能夠構建整合式的端對端管道，連線MDLC的所有元件。

Kubeflow同時導向資料科學家和資料工程師，幫助他們建立生產級別的機器學習實作。它可以在本地開發環境或生產叢集上執行。通常，管道會先在本地開發，待準備就緒後再遷移至生產環境。Kubeflow提供了一個統一的系統，利用Kubernetes實作容器化和可擴充套件性，確保管道的可攜性和可重複性。

為什麼要容器化？

容器提供的隔離性使機器學習各階段變得可攜和可重現。容器化應用與機器的其餘部分隔離，並包含所有必要的依賴(從作業系統開始)。這意味著再也不會有「在我的機器上可以執行」或「噢，我們忘了一個，你還需要這個額外的套件」這類別的對話。

容器以可組合的層構建，允許你使用另一個容器作為基礎。例如，如果你想使用一個新的自然語言處理(NLP)函式庫，可以將它加到現有容器之上，而不必每次都從頭開始。這種可組合性讓你能夠重用一個共同的基礎；比如，我們使用的R和Python容器都分享一個基礎的Debian容器。

人們對使用容器的一個常見擔憂是效能開銷。容器的效能開銷取決於你的實作方式，但IBM的研究發現這種開銷相當低，通常比虛擬化更快。在Kubeflow中，安裝可能不會使用的運算元會帶來一些額外開銷。這種開銷在生產叢集上可以忽略不計，但在筆記型電腦上可能會較為明顯。

對有Python經驗的資料科學家來說，可以將容器視為重量級的虛擬環境。除了虛擬環境中熟悉的東西外，容器還包括作業系統、套件以及兩者之間的所有內容。

為什麼選擇Kubernetes是一個開放原始碼系統，用於自動化容器化應用的佈署、擴充套件和管理。它使我們的管道可擴充套件而不犧牲可攜性，使我們能夠避免被鎖定在特定的雲端供應商。

除了能夠從單機切換到分散式叢集外，機器學習管道的不同階段還可以請求不同數量或型別的資源。例如，資料準備步驟可能更受益於在多台機器上執行，而模型訓練可能更受益於在GPU或張量處理單元(TPU)上進行計算。這種靈活性在雲環境中特別有用，因為你可以只在需要時使用昂貴的資源，從而降低成本。

當然，你也可以不使用Kubeflow，在Kubernetes上構建自己的容器化機器學習管道；但Kubeflow的目標是標準化這個過程，使其更加簡單和高效。Kubeflow為你可能用於機器學習實作的工具提供了一個通用介面。它還使你能夠更輕鬆地設定實作以使用TPU等硬體加速器，而無需更改程式碼。

本地叢集如Minikube限於一台機器，但大多數雲叢集可以根據需要動態更改機器的型別和數量。

Kubeflow的設計與核心元件

在機器學習領域，存在各種函式庫、工具集和框架。Kubeflow並不尋求重新發明輪子或提供「一刀切」的解決方案，而是允許機器學習從業者根據特定需求組合和定製自己的技術堆積積疊。它旨在簡化大規模構建和佈署機器學習系統的過程，讓資料科學家能夠將精力集中在模型開發上，而不是基礎設施上。

Kubeflow試圖透過三個特性來解決簡化機器學習的問題：可組合性、可攜性和可擴充套件性。

可組合性

Kubeflow的核心元件來自於機器學習從業者已經熟悉的資料科學工具。這些元件可以獨立使用以促進機器學習的特定階段，或者組合在一起形成端對端的管道。

可攜性

透過根據容器的設計並利用Kubernetes及其雲原生架構，Kubeflow不要求你繫結在任何特定的開發環境。你可以在筆記型電腦上進行實驗和原型設計，然後輕鬆佈署到生產環境。

可擴充套件性

透過使用Kubernetes，Kubeflow可以根據叢集的需求動態擴充套件，透過更改底層容器的數量和大小。這種靈活性使Kubeflow特別適合處理需要大量計算資源的機器學習任務。

Kubeflow的核心功能與使用場景

從我在實際專案中的經驗來看，Kubeflow的強大之處在於它能夠無縫整合機器學習工作流程的各個環節。讓我們更深入地瞭解Kubeflow的一些核心功能：

統一的工作環境

Kubeflow提供了Jupyter Notebook作為主要的開發介面，讓資料科學家能夠在熟悉的環境中工作。這些筆記本可以直接在Kubernetes叢集上執行，使得資源分配更加靈活。

分散式訓練支援

對於大規模型訓練，Kubeflow提供了分散式訓練的原生支援。無論是使用TensorFlow、PyTorch還是其他框架，都能輕鬆設定分散式訓練任務。

模型佈署與服務

Kubeflow Serving讓模型佈署變得簡單高效。支援多種模型格式，並提供A/B測試、金絲雀佈署等進階功能，幫助團隊安全地將新模型推向生產環境。

管道自動化

Kubeflow Pipelines允許將整個機器學習工作流程自動化，從資料準備到模型評估。這大減少了手動操作，提高了重現性和效率。

超引數調整

Katib元件提供了自動化的超引數調整功能，幫助找到最佳的模型設定，而無需手動嘗試不同參陣列合。

中繼資料追蹤

Metadata元件記錄了模型訓練和佈署的所有相關資訊，實作完整的可追溯性，這對於滿足監管要求和除錯問題至關重要。

實際應用場景分析

在實際應用中，Kubeflow能夠顯著改善機器學習團隊的工作效率。以下是幾個典型的使用場景：

從研究到生產的流程最佳化

傳統上，資料科學家在本地環境開發的模型往往難以順利遷移到生產環境。Kubeflow透過容器化和標準化的工作流程，大簡化了這一過程。

多團隊協作

在大型組織中，資料科學團隊和IT維運團隊需要密切協作。Kubeflow提供了一個共同的平台，使這兩個團隊能夠更好地理解彼此的需求和限制。

資源最佳化

機器學習工作流程中的不同階段對資源的需求各不相同。Kubeflow能夠根據實際需要動態分配資源，避免資源浪費，同時確保關鍵任務獲得足夠的計算能力。

法規合規

對於金融、醫療等受監管行業，模型的可解釋性和可追溯性至關重要。Kubeflow的中繼資料追蹤功能有助於滿足這些嚴格的合規要求。

使用Kubeflow的成本與考量

雖然Kubeflow提供了許多優勢，但在決定採用前，還需要考慮以下幾點：

學習曲線

Kubeflow建立在Kubernetes之上，這意味著團隊需要具備一定的Kubernetes知識。對於沒有DevOps經驗的純資料科學團隊，這可能是一個挑戰。

資源需求

雖然Kubeflow可以在本地環境執行，但要充分發揮其優勢，往往需要一個功能完善的Kubernetes叢集，這會帶來一定的基礎設施成本。

維護成本

作為一個快速發展的開放原始碼專案，Kubeflow的各個元件更新頻繁。保持系統更新並處理可能的相容性問題需要持續的維護工作。

適用性評估

對於小型專案或單一模型場景，Kubeflow可能過於複雜。在這種情況下，更簡單的工具可能更加適合。

Kubeflow的替代方案

根據特定需求，以下是一些值得考慮的Kubeflow替代方案：

雲端供應商特定解決方案

如AWS SageMaker、Google AI Platform或Azure Machine Learning。這些服務提供了更緊密整合的體驗，但可能導致供應商鎖定。

輕量級工具

對於較小的團隊或專案，MLflow或DVC等輕量級工具可能提供足夠的功能，同時具有更低的複雜性。

專業平台

對於特定領域的機器學習應用，可能存在更專業的平台，如針對電腦視覺的Roboflow或針對NLP的Hugging Face。

實際上手：Kubeflow的基本設定

要開始使用Kubeflow，首先需要一個執行中的Kubernetes叢集。對於本地測試，可以使用Minikube或Kind；對於生產環境，則可以選擇GKE、EKS或AKS等託管服務。

一旦有了Kubernetes叢集，安裝Kubeflow的最簡單方法是使用官方提供的佈署指令碼。這些指令碼會處理所有必要的設定，讓你能夠快速開始使用Kubeflow的功能。

在我初次設定Kubeflow時，曾遇到一些資源設定的挑戰。建議在開始前仔細評估資源需求，特別是在本地環境中測試時。一個實用的策略是先使用最小設定，然後根據實際需要逐步擴充套件。

Kubeflow作為一個專為機器學習設計的雲原生平台，為解決從研究到生產的挑戰提供了強大的工具集。它的核心優勢在於可組合性、可攜性和可擴充套件性，使資料科學家和工程師能夠更專注於模型開發，而不是基礎設施問題。

雖然Kubeflow帶來了一定的複雜性和學習成本，但對於需要大規模佈署機器學習模型的組織來說，這些投入往往是值得的。透過標準化和自動化機器學習工作流程，Kubeflow能夠顯著提高團隊效率，加速模型從概念到生產的過程。

隨著機器學習在各行各業的應用日益深入，像Kubeflow這樣的工具將扮演越來越重要的角色，幫助組織更有效地利用AI的力量。無論你是正在尋找解決方案的資料科學家，還是負責機器學習基礎設施的工程師，Kubeflow都值得你認真考慮。

Kubeflow的核心價值：擴充套件性、可攜性與組合性

在機器學習開發生命週期(MDLC)中，Kubeflow提供了三個關鍵特性，使其成為現代ML工程的理想選擇：

擴充套件性：應對資料增長的挑戰

隨著資料集不斷擴大，擴充套件性變得至關重要。Kubeflow根據Kubernetes構建，繼承了其強大的容器協調能力，能夠輕鬆應對從單機到數百節點的擴充套件需求。在我實際佈署大規模型訓練時，這種擴充套件能力讓團隊能夠專注於模型最佳化而非基礎設施擴充問題。

可攜性：避免供應商鎖定

Kubeflow的可攜性讓你擁有在不同環境間遷移工作流程的自由。它可以在本地筆記型電腦、私有資料中心或任何主要雲端供應商的環境中執行，避免了傳統ML平台常見的供應商鎖定問題。這種靈活性在混合雲環境中尤為重要，讓開發者能根據成本和效能需求靈活調整佈署策略。

組合性：最佳工具組合的自由

Kubeflow的模組化設計允許你混搭使用最適合特定任務的工具。這種組合性意味著你可以將TensorFlow用於某些模型，同時在其他場景中使用PyTorch或XGBoost，而不必重新設計整個工作流程架構。

Kubeflow的核心元件與MDLC支援

資料探索：Jupyter筆記本整合

機器學習生命週期始於資料探索—繪製圖表、分割資料、操作資料以尋找潛在洞見。Kubeflow緊密整合了Jupyter筆記本，這是機器學習實踐者偏愛的開放原始碼工具，提供了直觀的資料探索環境。

在Kubeflow中，你可以啟動Jupyter例項，直接與叢集及其他元件互動。例如，你可以在筆記型電腦上編寫TensorFlow分散式訓練程式碼片段，然後只需點選幾下就能啟動訓練叢集。這種無縫整合大幅減少了從實驗到生產的轉換成本。

資料與特徵準備

機器學習演算法需要高品質資料才能有效運作。Kubeflow支援多種資料處理工具：

  • Apache Spark：處理大規模資料的業界標準工具
  • TensorFlow Transform：與TensorFlow Serving整合，簡化推論過程

這些資料準備元件能處理各種格式和規模的資料，並且資料探索環境無縫協作。值得注意的是，Kubeflow Pipelines對Apache Beam與Apache Flink的支援正在積極開發中，這將進一步擴充套件其資料處理能力。

模型訓練：多框架支援

完成特徵準備後，就可以構建和訓練模型了。Kubeflow支援多種分散式訓練框架：

  • TensorFlow
  • PyTorch
  • Apache MXNet
  • XGBoost
  • Chainer
  • Caffe2
  • 訊息傳遞介面(MPI)

這種多框架支援讓團隊能夠選擇最適合特定問題的工具，而不必因為平台限制而妥協。在處理自然語言處理任務時，我可以選擇PyTorch的靈活性；而在處理結構化資料時，可以無縫切換到XGBoost的高效率。

超引數調整：自動化最佳化流程

在機器學習中，超引數是控制訓練過程的變數，如學習率、隱藏層數量、神經元數量等。這些引數不是訓練資料的一部分，但對模型效能有顯著影響。

Kubeflow提供了強大的超引數調整功能。使用者可以從一個初始模型開始，定義超引數搜尋空間，然後Kubeflow會自動處理剩下的工作—啟動使用不同超引數的訓練任務、收集指標，並將結果儲存到模型資料函式庫以便比較效能。

這種自動化調參能力極大地提高了模型開發效率，讓資料科學家能專注於更具創造性的工作，而非手動調整引數。

模型驗證：確保生產可靠性

在將模型投入生產前，瞭解其可能的表現至關重要。Kubeflow中用於超引數調整的工具也可進行交叉驗證。當更新現有模型時，可以在模型推論中使用A/B測試和多臂老虎機等技術進行線上驗證。

這種全面的驗證機制確保了模型在佈署到生產環境前已經過充分測試，降低了線上故障的風險。

推論與預測：無縫佈署能力

訓練完模型後，下一步是在叢集中佈署模型以處理預測請求。Kubeflow讓資料科學家能夠大規模地在生產環境中佈署機器學習模型。目前，Kubeflow提供了多框架模型服務元件(KFServing)，以及TensorFlow Serving和Seldon Core等現有解決方案。

在Kubeflow上佈署各種型別的模型相當直觀。在大多數情況下，無需自行構建或自定義容器—只需指向模型儲存位置，伺服器就會準備好處理請求。這種簡化的佈署流程大降低了從開發到生產的障礙。

模型佈署後，需要對其效能進行監控並可能進行更新。Kubeflow的雲原生設計使這種監控和更新成為可能。

Kubeflow Pipelines：實作工作流程自動化

完成MDLC的各個方面後，我們希望實作這些實驗的可重用性和治理。為此，Kubeflow將MDLC視為機器學習管道，並將其實作為一個圖，其中每個節點都是工作流程中的一個階段。

Kubeflow Pipelines是一個允許使用者輕鬆組合可重用工作流程的元件。其特點包括：

  • 用於多步驟工作流程的協調引擎
  • 用於與管道元件互動的SDK
  • 允許使用者視覺化和跟蹤實驗，並且協作者分享結果的使用者介面

Kubeflow Pipelines的核心優勢在於將機器學習工作流程標準化和自動化。透過將每個步驟（如資料預處理、模型訓練、評估等）定義為管道中的一個元件，資料科學家可以：

  1. 建立可重複執行的端對端工作流程
  2. 追蹤每次實驗的引數和結果
  3. 比較不同實驗間的效能差異
  4. 在團隊中分享最佳實踐和工作流程

這極大地提高了團隊協作效率和模型開發速度，同時也為模型開發提供了更好的可追溯性和治理能力。

元件概覽與擴充套件性

Kubeflow內建了MDLC所有部分的元件：資料準備、特徵準備、模型訓練、資料探索、超引數調整、模型推論，以及協調一切的管道。然而，你不僅限於Kubeflow自帶的元件。你可以在這些元件的基礎上構建，甚至替換它們。

這種靈活性是Kubeflow的一大優勢，但如果你發現自己想要替換Kubeflow的許多部分，可能需要探索其他可用的替代方案。

Kubeflow的替代方案

在研究社群中，存在多種提供與Kubeflow不同功能的替代方案。最近的研究主要集中在模型開發和訓練方面，在基礎設施、理論和系統方面都取得了重大進步。

然而，預測和模型服務方面相對受到的關注較少。因此，資料科學實踐者經常需要將各種關鍵系統元件整合在一起，以支援不同工作負載和不斷發展的框架的服務和推論。

考慮到對持續可用性和水平擴充套件性的需求，Kubeflow等解決方案作為強大的架構抽象工具和令人信服的研究範圍，在整個行業中越來越受歡迎。

Clipper (RiseLabs)

Kubeflow的一個有趣替代方案是Clipper，這是RiseLabs開發的通用低延遲預測服務系統。為了簡化佈署、最佳化和推論，Clipper採用了分層架構系統。透過各種最佳化和模組化設計，Clipper在三個不同推論成本的TensorFlow模型上實作了與TensorFlow Serving相當的低延遲和高吞吐量預測。

Clipper分為兩個抽象層，分別名為模型選擇層和模型抽象層。模型選擇層非常先進，它使用自適應線上模型選擇策略和各種整合技術。由於模型在應用程式整個生命週期中不斷從反饋中學習，模型選擇層可以自校準失敗的模型，而無需直接與策略層互動。

Clipper的模組化架構和對容器化的關注，與Kubeflow類別似，使得快取和批處理機制可以跨框架分享，同時還能享受可擴充套件性、並發性以及增加新模型框架的靈活性帶來的好處。

從理論發展為功能完整的端對端系統，Clipper在科學社群中獲得了關注，其架構設計的各個部分已被整合到最近引入的機器學習系統中。

Kubeflow的實際應用與價值

在實際專案中，Kubeflow的價值體現在幾個關鍵方面：

標準化機器學習工作流程

Kubeflow為機器學習開發提供了標準化的工作流程，從資料準備到模型佈署的每個步驟都有明確定義。這種標準化大減少了團隊間的溝通成本，並使新成員能夠快速適應現有專案。

在一個跨國金融科技專案中，玄貓見證了Kubeflow如何將模型開發時間從數週縮短到數天，主要得益於其標準化的工作流程和可重用的元件。

簡化基礎設施管理

傳統上，機器學習工程師需要花費大量時間處理基礎設施問題，如資源分配、相依性管理和服務擴充套件。Kubeflow將這些複雜性抽象化，讓資料科學家能夠專注於模型開發和業務問題解決。

促進團隊協作

Kubeflow的管道功能和版本控制能力使得團隊成員可以輕鬆分享和複製實驗結果。這種透明性促進了知識分享和最佳實踐的傳播，尤其在大型組織中價值顯著。

降低生產佈署門檻

將模型從實驗環境佈署到生產環境一直是機器學習專案的痛點。Kubeflow透過提供一致的環境和自動化的佈署流程，大降低了這一門檻。模型訓練完成後，只需幾個命令就能將其佈署為可擴充套件的服務。

展望未來：Kubeflow的發展方向

隨著機器學習技術和雲原生態系統的不斷演進，Kubeflow也在持續發展。未來幾年，我們可能會看到以下趨勢：

  1. 更強的自動化能力：自動特徵工程、神經架構搜尋和持續模型最佳化等自動化功能將進一步簡化機器學習工作流程

  2. 更深入的監控和可觀察性：更全面的模型監控、解釋性和效能分析工具，幫助團隊更好地理解和維護生產中的模型

  3. 更廣泛的生態系統整合：與資料治理、模型稽核和合規工具的更深度整合，滿足企業級AI系統的需求

  4. 更輕量級的佈署選項：針對邊緣計算和資源受限環境的最佳化佈署方案

Kubeflow作為連線資料科學和雲原生技術的橋樑，其重要性只會隨著這兩個領域的融合而增加。對於希望在現代基礎設施上構建可擴充套件機器學習系統的組織來說，掌握Kubeflow將是一項關鍵能力。

機器學習的未來是雲原生的，而Kubeflow正站在這一趨勢的最前沿。無論你是資料科學家、ML工程師還是平台架構師，瞭解和利用Kubeflow都能為你的AI旅程提供堅實的基礎。

Kubeflow生態系統的替代選擇

在機器學習基礎架構不斷發展的今日，Kubeflow已成為許多團隊的主要選擇，但它並非唯一的解決方案。瞭解市場上的替代方案有助於我們根據具體需求做出更明智的技術選擇。

MLflow：Databricks的開放原始碼機器學習平台

MLflow是由Databricks開發的開放原始碼機器學習開發平台，採用了許多與Clipper相似的架構正規化，包括其框架無關的特性。MLflow專注於三個主要元件：Tracking、Projects和Models。

MLflow的核心元件

MLflow Tracking提供API和配套UI，用於記錄引數、程式碼版本、指標和輸出檔案。這在機器學習中極為重要，因為追蹤引數、指標和成品是確保實驗可重現性的關鍵。

MLflow Projects為可重用的資料科學程式碼提供標準格式，透過YAML檔案定義，可利用版本控制的程式碼和Anaconda進行相依性管理。這種專案格式使分享可重現的資料科學程式碼變得簡單，而可重現性對機器學習實踐者至關重要。

MLflow Models是一種將機器學習模型封裝為多種格式的約定。每個MLflow模型都被儲存為包含任意檔案和MLmodel描述檔的目錄。MLflow還提供模型登入檔，顯示佈署模型與其建立中繼資料之間的血緣關係。

與Kubeflow一樣，MLflow仍在積極開發中，並擁有活躍的社群支援。

MLflow的優勢與特色

MLflow的設計理念與Kubeflow有所不同。玄貓在實際專案中發現，MLflow對於資料科學家更為友好，入門檻較低，特別是對於不熟悉Kubernetes的團隊。它的追蹤功能非常強大，能夠輕鬆比較不同實驗結果，這在模型最佳化階段極為有用。

然而，MLflow在大規模佈署和複雜工作流程協調方面，可能不如根據Kubernetes的Kubeflow靈活。選擇時需考慮團隊的技術背景和專案規模。

企業內部機器學習平台

由於機器學習開發面臨的挑戰，許多大型組織已開始構建內部平台來管理其機器學習生命週期。例如：

  • Bloomberg 的 Data Science Platform
  • Facebook 的 FBLearner Flow
  • Google 的 TensorFlow Extended (TFX)
  • Uber 的 Michelangelo
  • IBM 的 Watson Studio

這些平台都專注於管理資料準備、模型訓練和佈署等環節，但都是針對各公司特定需求量身定製的解決方案。

隨著機器學習基礎設施領域不斷演進和成熟，我們期待像Kubeflow這樣的開放原始碼專案能為機器學習開發帶來急需的簡化和抽象化。

案例研究：多樣化的機器學習應用

機器學習可以使用多種不同型別的資料，而你採用的方法和工具可能各不相同。為了展示Kubeflow的功能，我選擇了具有非常不同資料特性和最佳實踐的案例研究。在可能的情況下，我會使用這些案例研究的資料來探索Kubeflow及其某些元件。

MNIST手寫數字識別

在機器學習領域，MNIST（Modified National Institute of Standards and Technology）通常指的是用於分類別的手寫數字資料集。數字資料相對較小的規模以及作為範例的普遍使用，使我們能夠探索各種工具。從某種意義上說，MNIST已成為機器學習的標準「Hello World」範例之一。

MNIST案例的優勢在於其簡單性和廣泛接受度，這使它成為Kubeflow入門的理想選擇。在處理這類別資料時，我發現從簡單模型開始，逐步增加複雜度是個好方法，這也讓新手更容易理解整個流程。

郵件列表資料分析

提出好問題是一門藝術。你是否曾經在郵件列表中發布求助訊息，卻沒有人回應？不同型別的問題有何區別？我們將研究一些Apache軟體基金會的公開郵件列表資料，並嘗試建立一個預測訊息是否會得到回答的模型。

這個例子可以透過選擇我們想要檢視的專案和時間段來進行擴充套件和縮減，因此我們可以使用各種工具來解決它。郵件列表資料特別有趣，因為它結合了文字分析和分類別問題，適合展示Kubeflow處理非結構化資料的能力。

產品推薦系統

推薦系統是機器學習最常見與最容易理解的應用之一，從Amazon的產品推薦到Netflix的電影建議都是經典案例。大多數推薦系統實作都根據協同過濾—假設如果A與B在一系列問題上有相同意見，那麼A更有可能在其他問題上與B分享相同意見，而非隨機選擇的第三人。

這種方法建立在一個發展成熟的演算法基礎上，有相當多的實作，包括TensorFlow/Keras實作。根據評分的模型面臨的問題之一是，對於非標度目標值的資料，如購買或頻率資料，它們不能輕易標準化。

將此類別資料轉換為可用於協同過濾的評分矩陣是關鍵挑戰。我們的範例利用了Data Driven Investor的資料和程式碼。我們將使用這個例子來探索如何在Jupyter中構建初始模型，然後繼續構建生產管道。

推薦系統的技術挑戰

在實作推薦系統時，玄貓發現資料稀疏性是最大的挑戰之一。當使用者與產品的互動資料非常稀疏時，傳統協同過濾方法效果不佳。解決方案通常是結合內容特徵和協同過濾，即所謂的混合推薦系統。

另一個關鍵挑戰是冷啟動問題—如何為新使用者或新產品提供合理推薦。在Kubeflow環境中，我通常會佈署A/B測試架構來持續評估不同推薦策略的效果，這可以透過Kubeflow的服務元件輕鬆實作。

CT掃描影像處理

在撰寫本文時，全球正經歷COVID-19疫情。AI研究人員被召集應用方法和技術來協助醫療提供者理解疾病。一些研究表明，CT掃描在早期檢測方面比RT-PCR測試（傳統COVID測試）更有效。然而，診斷用CT掃描使用低劑量輻射，因此「嘈雜」—也就是說，使用更多輻射時CT掃描會更清晰。

一篇新論文提出了一種開放原始碼解決方案，完全使用開放原始碼專案中現成的方法對CT掃描進行降噪（而非專有的FDA批准解決方案）。我實作這種方法來說明如何從學術文章到實際解決方案，展示Kubeflow對建立可重現和可分享研究的價值，並為任何希望為抗擊COVID-19做出貢獻的讀者提供起點。

醫學影像處理的特殊考量

醫學影像處理與一般電腦視覺任務有顯著不同。在CT掃描降噪專案中，玄貓注意到資料隱私是最大的挑戰之一。醫療資料受到嚴格的隱私法規保護，這使得模型開發和測試變得複雜。

Kubeflow在這方面提供了優勢，因為它允許將模型帶到資料所在位置，而不是將敏感資料移動到中央位置。此外，醫學影像處理通常需要高效能計算資源，特別是使用深度學習方法時。Kubeflow的分散式訓練功能在這種情況下非常有價值。

開始使用Kubeflow

如果你決定使用Kubeflow開始你的機器學習之旅，這個介紹應該已經讓你對Kubeflow及其功能有了初步瞭解。然而，就像所有的冒險一樣，可能會有一個時刻，你的書不足以帶你度過難關。

幸運的是，有一系列社群資源可以讓你與其他走在類別似道路上的人互動。我鼓勵你註冊Kubeflow Slack工作區，這是討論較為活躍的區域之一。還有Kubeflow討論郵件列表和Kubeflow專案頁面。

如果你想快速端對端地探索Kubeflow，有一些Google codelabs可以幫助你。接下來，我們將安裝Kubeflow並使用它訓練和提供一個相對簡單的機器學習模型，以便讓你瞭解基礎知識。

Kubeflow入門：環境設定

歡迎踏入Kubeflow的精彩世界！

首先，我們將在你的機器上或雲端供應商上設定Kubeflow。然後我們將深入一個全面的範例。這個範例的目標是盡快訓練模型並開始服務。在第一部分的某些部分，可能會感覺我們在指導你無腦地輸入命令。雖然我們希望你跟著做，但強烈建議你在讀完本文後重新回顧這些命令，思考你的理解有多少成長。

我將提供在本地機器上設定和測試範例的說明，以及在真實叢集上執行相同操作的連結。雖然我會指出驅動所有這一切的設定檔案和OCI容器，但它們不是本文的重點。本文的重點是一個你可以在家中跟著做的端對端範例。

Kubeflow建立在Kubernetes上的一個好處是能夠在本地進行初始開發和探索，之後再轉移到更強大的分散式工具。你的相同管道可以在本地開發，然後轉移到更強大的環境中。

Kubeflow本地開發的優勢與限制

在實際工作中，玄貓發現Kubeflow的本地開發環境對於快速原型設計和學習非常有價值。然而，需要注意的是，本地環境通常資源有限，不適合訓練大型模型或處理大量資料。

對於初學者，我建議使用Minikube或Kind等輕量級Kubernetes發行版在本地執行Kubeflow。這些工具提供了一個很好的學習環境，而與設定相對簡單。一旦你熟悉了基本概念，就可以考慮遷移到雲端環境，如GKE、EKS或AKS，以獲得更多計算資源。

在本地開發時，特別要注意資源限制，合理設定CPU和記憶體請求，以避免系統過載。同時，永續性儲存區的設定也需要特別注意，因為不同環境之間的儲存實作可能有很大差異。

機器學習平台的選擇取決於你的特定需求、技術背景和資源限制。無論你選擇Kubeflow、MLflow還是其他解決方案，理解這些工具的核心概念和設計理念將幫助你更有效地利用它們來構建和佈署機器學習模型。

隨著機器學習基礎設施領域的不斷發展，我們有理由期待更多創新解決方案的出現，這些解決方案將使機器學習工作流程更加簡化和標準化。同時，熟悉現有工具的優缺點將幫助你在這個快速發展的領域中做出明智的技術選擇。

無論你是剛開始探索機器學習操作化(MLOps)，還是尋求改進現有工作流程，瞭解不同機器學習平台的特點和使用場景都將為你提供寶貴的參考。希望本文能幫助你在這個複雜而令人興奮的技術領域中找到最適合你需求的解決方案。

Kubeflow安裝與環境設定全攻略

在機器學習專案規模化的過程中，工作流程管理變得極為重要。Kubeflow作為專為機器學習開發的開放原始碼平台，提供了強大的工具來簡化和自動化ML工作流程。在這篇文章中，玄貓將帶你瞭解如何安裝Kubeflow及其依賴項，並設定一個高效的開發環境。

多種佈署選擇：本地或雲端皆可

雖然許多教學建議在本地安裝Kubeflow進行初步嘗試，但這並非唯一選擇。事實上，你可以輕鬆地在雲端提供商的平台上或企業內部的Kubernetes叢集中開始你的Kubeflow之旅。

若你希望快速入門，Google Cloud Platform (GCP)的一鍵佈署應用是個不錯的選擇。GCP提供了簡化的佈署流程，讓你能夠迅速開始使用Kubeflow的功能。

Kubeflow核心依賴安裝

在我們討論Kubeflow的最大需求（Kubernetes叢集）之前，先來設定必要的工具。Kubeflow本身相當獨立，但需要kubectl作為與Kubernetes通訊的工具。其餘依賴項都封裝在容器中，無需額外安裝。

無論你使用本地還是遠端Kubernetes叢集，在本地安裝開發工具都能簡化你的工作流程。

安裝kubectl

kubectl是與Kubernetes叢集通訊的命令列工具，也是Kubeflow的核心依賴。它有多種安裝方式：

Ubuntu使用snap安裝：

sudo snap install kubectl --classic

Mac使用Homebrew安裝：

brew install kubernetes-cli

對於其他系統或安裝偏好，可以參考Kubernetes官方檔案，也可以直接下載二進位檔案安裝。

安裝Kubeflow

安裝完基本依賴後，就可以從GitHub安裝Kubeflow了：

PLATFORM=$(uname) # 檢測系統型別，Linux或Darwin(macOS)
export PLATFORM
mkdir -p ~/bin

# 設定
export KUBEFLOW_TAG=1.0.1
# 你也可以指定不同版本

KUBEFLOW_BASE="https://api.github.com/repos/kubeflow/kfctl/releases"
# 或直接存取 https://github.com/kubeflow/kfctl/releases

KFCTL_URL=$(curl -s ${KUBEFLOW_BASE} |\
grep http |\
grep "${KUBEFLOW_TAG}" |\
grep -i "${PLATFORM}" |\
cut -d : -f 2,3 |\
tr -d '\" ' )

wget "${KFCTL_URL}"
KFCTL_FILE=${KFCTL_URL##*/}
tar -xvf "${KFCTL_FILE}"
mv ./kfctl ~/bin/
rm "${KFCTL_FILE}"

# 建議將scripts目錄增加到PATH
export PATH=$PATH:~/bin

這個指令碼的工作原理是：

  1. 檢測你的作業系統型別（Linux或macOS）
  2. 設定Kubeflow版本
  3. 從GitHub API取得對應版本和平台的下載URL
  4. 下載kfctl工具（Kubeflow的命令列工具）
  5. 解壓縮並移動到~/bin目錄
  6. 更新PATH環境變數以便直接使用kfctl

安裝完成後，執行kfctl version確認安裝成功並驗證版本。

設定本地Kubernetes環境

Kubeflow的一大優勢是能夠在本地和生產環境中執行相同的軟體。為支援這一點，你需要安裝本地版本的Kubernetes。雖然有幾種選擇，但玄貓認為Minikube是最簡單的方案。

Minikube允許你使用本地電腦模擬一個Kubernetes叢集。其他常見的本地Kubeflow版本包括：

  • microk8s：支援多種Linux平台
  • MiniKF：使用Vagrant啟動虛擬機器來執行帶有Kubeflow的Kubernetes

雖然本地Kubernetes叢集並非絕對必要，但許多資料科學家和開發人員發現本地測試環境非常有用。

Minikube設定

Minikube是可以執行Kubeflow的本地Kubernetes版本。Kubernetes官方檔案和Kubeflow專用頁面都提供了Minikube的安裝。

Minikube自動設定最常見的失敗原因是缺少虛擬機器管理程式或Docker。無論你使用什麼作業系統，VirtualBox應該都能工作；但其他選項如Linux上的KVM2、Windows上的Hyper-V和macOS上的HyperKit也都可以使用。

啟動Minikube時，請確保分配足夠的記憶體和磁碟空間：

minikube start --cpus 16 --memory 12g --disk-size 15g

注意：你不需要實際擁有16個CPU核心，這只是Minikube將使用的虛擬CPU數量。

設定Kubeflow開發環境

Kubeflow的管道系統是用Python構建的，本地安裝SDK將使你能夠更快地構建管道。不過，即使你無法在本地安裝軟體，仍然可以使用Kubeflow的Jupyter環境來構建管道。

設定Pipeline SDK

首先需要安裝Python。許多人發現為不同專案建立隔離的虛擬環境很有用：

virtualenv kfvenv --python python3
source kfvenv/bin/activate

這段程式碼建立了一個名為kfvenv的Python虛擬環境，並使用Python 3作為直譯器。source命令啟用該虛擬環境，使所有Python相關命令都在這個隔離環境中執行，避免與系統Python或其他專案衝突。

現在你可以使用pip命令安裝Kubeflow Pipelines包及其依賴：

URL=https://storage.googleapis.com/ml-pipeline/release/latest/kfp.tar.gz
pip install "${URL}" --upgrade

如果使用虛擬環境，每次想使用Pipeline SDK時都需要先啟用它。

除了SDK外，Kubeflow還提供了許多元件。克隆標準元件的固定版本可以幫助我們建立更可靠的管道：

git clone --single-branch --branch 0.3.0 https://github.com/kubeflow/pipelines.git

設定Docker環境

Docker是Kubeflow基礎設施的重要部分，它允許你自定義並增加函式庫和其他功能到自己的容器中。在Linux上可以透過標準套件管理器安裝Docker，在macOS上可以使用Homebrew。

除了安裝Docker，你還需要一個儲存容器映像的地方，即容器登入檔（Container Registry）。這個登入檔將被你的Kubeflow叢集存取。Docker公司提供了Docker Hub，RedHat提供了Quay，這些都是可以使用的雲中立平台。或者，你也可以使用雲提供商的容器登入檔。

雲廠商特定的容器登入檔通常對儲存在那裡的映像提供更高的安全性，並可以自動設定你的Kubernetes叢集，使其具有取得這些映像所需的許可權。在玄貓的範例中，假設你已經透過環境變數$CONTAINER_REGISTRY在shell中設定了容器登入檔。

如果使用非Google Cloud Platform的登入檔，需要按照Kaniko設定Kubeflow Pipelines容器構建器，以便它能夠存取你的登入檔。

測試Docker設定

要確保Docker安裝正確設定，可以編寫一個簡單的Dockerfile並將其推播到登入檔。對於Dockerfile，使用FROM命令指示新容器根據Kubeflow的TensorFlow筆記本容器映像：

FROM gcr.io/kubeflow-images-public/tensorflow-2.1.0-notebook-cpu:1.0.0

然後構建並推播容器：

IMAGE="${CONTAINER_REGISTRY}/kubeflow/test:v1"
docker build -t "${IMAGE}" -f Dockerfile .
docker push "${IMAGE}"

這段程式碼執行了兩個關鍵操作：

  1. docker build - 使用當前目錄的Dockerfile建立一個新的容器映像，並給它一個標籤（包含登入檔位置、名稱和版本）
  2. docker push - 將構建好的映像上載到指定的容器登入檔，使其可以被Kubeflow叢集使用

有了這些設定，你現在已經準備好開始定製Kubeflow中的容器和元件以滿足你的需求。在未來的專案中，玄貓會使用這種模式在需要時增加工具。

YAML編輯工具

雖然Kubeflow在很大程度上抽象了Kubernetes的細節，但有時檢視或修改設定仍然很有用。Kubernetes的大部分設定都以YAML格式表示，因此設定工具來輕鬆檢視和編輯YAML檔案將很有益處。

大多數整合開發環境（IDE）都提供了某種編輯YAML的工具，但你可能需要安裝外掛來獲得語法突顯和驗證等功能。VSCode、PyCharm和其他主流IDE都有不錯的YAML支援，特別是在安裝相關外掛後。

實用佈署策略與工作流程最佳化

在設定Kubeflow環境時，有幾點實用策略值得考慮：

階段式佈署策略

玄貓發現，採用階段式的佈署策略通常能夠減少初始設定的複雜性。可以考慮以下步驟：

  1. 先在本地Minikube環境中熟悉Kubeflow的基本功能
  2. 開發和測試初始管道
  3. 然後再考慮移至生產級別的Kubernetes叢集

這種方式允許你在不需要處理雲端許可權和網路設定的情況下熟悉平台。

資源考量

在實際佈署中，資源分配是一個重要考量。無論是本地還是雲端環境，確保為Kubeflow分配足夠的資源至關重要：

  • 對於本地Minikube，至少需要8GB RAM和4個CPU核心才能流暢執行基本功能
  • 對於生產環境，建議使用自動擴充套件的節點組，以適應不同工作負載需求

容器登入檔策略

選擇適合你工作流程的容器登入檔時，考慮這些因素：

  • 網路延遲：盡可能選擇與Kubernetes叢集在同一區域的登入檔
  • 許可權管理：評估需要存取容器的人員和服務
  • 成本結構：不同登入檔有不同的計費模式（儲存、流量、API呼叫等）

開發工作流程整合

為了提高效率，將Kubeflow開發環境與現有工作流程整合：

  • 考慮使用CI/CD管道自動構建和推播容器
  • 利用版本控制系統管理Pipeline定義和設定
  • 建立團隊分享的元件函式庫，避免重複開發常用功能

Kubeflow的強大之處在於它能夠無縫連線實驗環境和生產環境。透過精心設定開發環境，你可以大減少從實驗到生產的過渡摩擦。

常見問題與解決方案

在設定Kubeflow環境的過程中，玄貓發現以下幾個常見問題及其解決方法：

記憶體不足問題

當Minikube或Kubernetes節點記憶體不足時，Kubeflow元件可能會失敗或表現不穩定。解決方法是增加分配的記憶體，並確保設定了適當的資源限制。

容器映像提取失敗

如果遇到容器映像提取失敗的問題，通常是由於許可權問題或網路連線問題。確保：

  • 容器登入檔的認證設定正確
  • Kubernetes叢集有適當的網路存取許可權
  • 映像名稱和標籤拼寫正確

kubectl連線問題

如果kubectl無法連線到叢集，檢查：

  • kubeconfig檔案是否正確設定
  • 叢集API伺服器是否可存取
  • 認證憑證是否有效

透過掌握這些安裝和設定步驟，你已經準備好開始Kubeflow之旅。無論你是在本地環境中進行實驗，還是在雲端環境中佈署生產工作負載，這些基礎設定都將確保你的機器學習工作流程順利執行。

在接下來的實踐中，你將發現Kubeflow如何簡化機器學習模型的開發、訓練和佈署過程，使你能夠更專注於解決實際問題，而不是被基礎設施挑戰所困擾。

Kubeflow開發環境準備：YAML編輯工具選擇

在開始使用Kubeflow前，選擇一個合適的YAML編輯工具能大幅提升開發效率。YAML是Kubernetes生態系統中的核心設定語言，也是Kubeflow設定的基礎。

主流IDE的YAML支援

各大IDE都提供了不錯的YAML編輯支援：

  • IntelliJ：提供專門的YAML外掛，支援語法高亮和自動完成
  • Emacs：可以安裝yaml-mode（透過MELPA套件函式庫取得），提供強大的編輯功能
  • Atom：透過安裝YAML套件來取得語法高亮功能
  • VSCode：內建YAML支援，配合Kubernetes外掛效果更佳

不必為了更好的YAML編輯體驗而放棄你熟悉的IDE，大多數開發環境都有相應的YAML外掛。此外，你還可以使用YAMLlint網站來檢查你的YAML語法是否正確，這是一個非常實用的線上工具。

建立第一個Kubeflow專案

Kubeflow的佈署核心是使用kfctl程式，它需要一個清單檔案來設定如何構建Kubeflow環境。不同的雲端供應商有不同的清單檔案。

基礎專案建立步驟

讓我們從一個簡單的範例開始，使用標準設定建立一個專案。在這個專案中，我們將構建一個簡單的端對端管道，用於MNIST手寫數字識別——這是機器學習領域的"Hello World"。

以下是建立專案的基本步驟：

# 選擇適合你平台的設定檔案
# 可以從 https://github.com/kubeflow/manifests/tree/[version]/kfdef 下載

# 對於使用Istio的通用Kubernetes環境：
MANIFEST_BRANCH=${MANIFEST_BRANCH:-v1.0-branch}
export MANIFEST_BRANCH
MANIFEST_VERSION=${MANIFEST_VERSION:-v1.0.1}
export MANIFEST_VERSION

KF_PROJECT_NAME=${KF_PROJECT_NAME:-hello-kf-${PLATFORM}}
export KF_PROJECT_NAME
mkdir "${KF_PROJECT_NAME}"
pushd "${KF_PROJECT_NAME}"

manifest_root=https://raw.githubusercontent.com/kubeflow/manifests/
# 在大多數環境中，這將建立使用Istio的"標準"Kubeflow安裝
FILE_NAME=kfctl_k8s_istio.${MANIFEST_VERSION}.yaml
KFDEF=${manifest_root}${MANIFEST_BRANCH}/kfdef/${FILE_NAME}

kfctl apply -f $KFDEF -V
echo $?
popd

上述指令碼執行以下操作：

  1. 設定Kubeflow清單的分支和版本變數
  2. 建立並進入一個新的專案目錄
  3. 構建Kubeflow清單URL路徑
  4. 使用kfctl apply命令應用設定，啟動Kubeflow佈署

這個指令碼假設你已經有一個執行中的Kubernetes叢集（如本地的Minikube）。在執行kfctl apply時，你會看到許多狀態訊息，甚至可能有一些錯誤訊息。只要最後輸出為0，就可以安全地忽略大多數錯誤，因為它們會自動重試。

需要注意的是，此佈署過程可能需要長達30分鐘的時間。如果你決定直接使用雲端供應商，Kubeflow安裝中有相關的入門訊息。

確認Kubeflow佈署完成

Kubeflow的使用者介面可能在Kubeflow完全佈署之前就已啟動，此時存取它可能意味著你沒有正確的名稱空間。為確保Kubeflow已準備就緒，執行以下命令：

kubectl get pods --all-namespaces -w

等待所有的pod變為RUNNING或COMPLETED狀態。如果你看到pod被強制終止，請確保你啟動的叢集有足夠的RAM和磁碟空間。如果無法在本地啟動足夠大的叢集，可以考慮使用雲端供應商。

訓練與佈署模型

在傳統的機器學習文獻中，訓練階段通常受到最多關注，而佈署和模型管理則相對較少。在實際工作中，我們假設你已經知道如何選擇正確的模型/演算法，或者與懂得這些的人合作。這裡我們將更多地關注佈署和模型管理。

訓練模型與監控進度

下一步是使用Kubeflow Pipeline訓練模型。我們將使用一個預先建立的訓練容器，它會下載訓練資料並訓練模型。

以下是一個使用預構建工作流程的例子，它會訓練一個RandomForestClassifier：

dsl-compile --py train_pipeline.py --output job.yaml

如果遇到問題，可以查閱Kubeflow故障排除。

存取Kubeflow介面

Kubeflow UI的存取方式有幾種不同的方法：

  1. 本地佈署：最簡單的方法是使用連線埠轉發

    kubectl port-forward svc/istio-ingressgateway -n istio-system 7777:80

    然後存取 localhost:7777

  2. GCP佈署：存取 https://<deployment_name>.endpoints.<project_name>.cloud.goog

  3. 其他佈署：執行 kubectl get ingress -n istio-system 取得閘道器服務地址

進入Kubeflow介面後，點選"pipelines"（或在根URL後增加_/pipeline/），你就能看到Pipelines網頁介面。

上載與執行Pipeline

從Pipelines介面，我們可以上載我們的pipeline。上載完成後，可以使用相同的網頁介面建立pipeline執行。點選已上載的pipeline後，你就能建立執行。

模型測試與查詢

最後，讓我們查詢我們的模型並監控結果。進行"理智檢查"（sanity check）是確保模型在理論上合理預測的簡單測試。

例如，我們嘗試猜測寫的是什麼數字。如果我們的模型回傳答案如77、橙色Kool-Aid或ERROR，這些都不符合理智檢查。我們期望看到0到9之間的數字。在將模型投入生產之前進行理智檢查總是明智的選擇。

模型存取與查詢

網頁UI和模型服務透過相同的Istio閘道器公開。因此，模型將在以下地址可用：

http://<WEBUI_URL>/seldon<mnist-classifier/api<v0.1/predictions

如果你使用Google IAP，iap_curl專案可能對於發出請求很有幫助。

模型查詢範例

以下是一個Python指令碼範例，它可以從MNIST資料集中提取影像，將其轉換為向量，顯示影像，並將其傳送到模型：

import requests
import numpy as np
from tensorflow.examples.tutorials.mnist import input_data
from matplotlib import pyplot as plt

def download_mnist():
    return input_data.read_data_sets("MNIST_data/", one_hot=True)

def gen_image(arr):
    two_d = (np.reshape(arr, (28, 28)) * 255).astype(np.uint8)
    plt.imshow(two_d, cmap=plt.cm.gray_r, interpolation='nearest')
    return plt

mnist = download_mnist()
batch_xs, batch_ys = mnist.train.next_batch(1)
chosen = 0
gen_image(batch_xs[chosen]).show()

data = batch_xs[chosen].reshape((1, 784))
features = ["X" + str(i + 1) for i in range(0, 784)]
request = {"data": {"names": features, "ndarray": data.tolist()}}

deploymentName = "mnist-classifier"
uri = "http://" + AMBASSADOR_API_IP + "/seldon/" + \
    deploymentName + "/api/v0.1/predictions"

response = requests.post(uri, json=request)

這個指令碼執行以下操作：

  1. 下載MNIST資料集
  2. 從訓練集中取得一個樣本
  3. 顯示選擇的手寫數字影像
  4. 將影像轉換為適合模型輸入的格式
  5. 構建請求體並傳送到佈署的模型
  6. 接收模型的預測結果

例如，當我們輸入一個手寫的數字3時，模型回傳如下結果：

{
  'data': {
    'names': ['class:0', 'class:1', 'class:2', 'class:3', 'class:4', 
              'class:5', 'class:6', 'class:7', 'class:8', 'class:9'],
    'ndarray': [
      [0.03333333333333333, 0.26666666666666666, 0.03333333333333333,
       0.13333333333333333, 0.1, 0.06666666666666667, 0.1,
       0.26666666666666666, 0.0, 0.0]
    ]
  },
  'meta': {'puid': 'tb02ff58vcinl82jmkkoe80u4r', 'routing': {}, 'tags': {}}
}

從結果中我們可以看到，即使我們寫了一個相當清晰的3，模型的最佳猜測是1和7之間的平局（各佔26.7%的機率）。實際上數字3的機率只有13.3%。這並不令人驚訝，因為RandomForestClassifier對手寫識別並不是最佳選擇。

選擇RandomForestClassifier有兩個原因：

  1. 用於後續展示模型可解釋性
  2. 讓你可以嘗試更合理的模型並比較效能

Kubeflow工作流程的優勢

使用Kubeflow來管理機器學習工作流程提供了許多優勢：

標準化佈署流程

Kubeflow提供了標準化的流程來佈署機器學習模型，無論是在本地開發環境還是生產環境中。這種標準化大減少了從開發到生產的摩擦。

可重複的實驗

透過定義為pipeline的工作流程可以被準確地重複執行，確保實驗的可重現性，這對科學研究和企業應用都至關重要。

資源最佳化

Kubeflow能夠有效地管理Kubernetes資源，確保訓練和推理工作負載獲得適當的計算資源，同時避免資源浪費。

視覺化與監控

Kubeflow的網頁介面提供了直觀的視覺化和監控工具，使資料科學家和工程師能夠輕鬆跟蹤實驗進度和結果。

進階Kubeflow應用

雖然我們在這裡演示了一個簡單的例子，但Kubeflow的功能遠不止於此。進階應用包括：

自動化機器學習流程

使用Kubeflow Pipelines可以自動化整個機器學習流程，從資料預處理到模型訓練和評估，再到最終佈署。

分散式訓練

對於大型模型，Kubeflow支援在多個節點上進行分散式訓練，大減少訓練時間。

模型服務與A/B測試

Kubeflow可以同時佈署多個模型版本，支援A/B測試和漸進式佈署策略。

模型監控與再訓練

Kubeflow還可以監控已佈署模型的效能，並在必要時觸發再訓練流程，確保模型始終處於最佳狀態。

在實際應用中，Kubeflow的強大功能夠幫助團隊更高效地管理機器學習專案，從實驗階段順利過渡到生產佈署。隨著對Kubeflow的深入瞭解，你將能夠充分利用這個平台來加速機器學習工作流程，提高生產力和模型品質。

機器學習模型的佈署往往比訓練更具挑戰性，而Kubeflow提供了一個強大的框架來應對這些挑戰。透過本文介紹的基本步驟，你已經瞭解瞭如何使用Kubeflow建立專案、訓練模型並進行佈署。這僅是開始，Kubeflow的生態系統還有更多功能等待你去探索。

從本地佈署邁向雲端：Kubeflow擴充套件性解析

許多開發者初次接觸Kubeflow時，通常會在本地Kubernetes叢集上進行實驗。然而，Kubeflow真正的優勢在於它能夠透過Kubernetes實作高度擴充套件。Kubernetes具備在單一機器或多台伺服器上執行的能力，某些環境甚至可以根據需求動態增加資源。

雖然Kubernetes已成為業界標準，但根據不同的雲端提供商，Kubeflow的設定步驟可能會有所差異。Kubeflow的入門提供了針對GCP、AWS、Azure、IBM Cloud和OpenShift的安裝說明。一旦在你的Kubernetes叢集上安裝完Kubeflow，你可以嘗試重新執行相同的範例，親身體驗相同程式碼在不同環境中的執行情況。

雲端佈署的額外考量

在雲端提供商上佈署Kubeflow時，系統可能會建立不只是Kubernetes資源的其他服務，這些也需要適當管理。例如，在Google雲端平台上，你可以透過佈署管理器(Deployment Manager)刪除這些輔助服務。

這種跨平台的一致性是Kubeflow的核心優勢之一。玄貓在實際專案中發現，一旦掌握了Kubeflow的核心概念，從開發環境到生產環境的遷移變得相對順暢，大降低了MLOps的複雜度。

Kubeflow架構設計：核心元件解析

在深入瞭解各個元件之前，讓我們先巨集觀地看一下Kubeflow的整體架構。Kubeflow由多個專注於機器學習工作流程不同階段的元件組成，這些元件協同工作，構成了一個完整的機器學習平台。

中央儀錶板：Kubeflow的統一入口

中央儀錶板是與Kubeflow互動的主要介面，它允許你存取大多數Kubeflow元件。根據你的Kubernetes提供商不同，可能需要等待長達半小時才能讓入口(Ingress)變得可用。

從中央儀錶板的首頁，你可以存取Kubeflow的Pipeline、Notebooks、Katib(超引數調整)和成品儲存函式庫(Artifact Store)。這種統一的介面設計大提高了開發效率，讓資料科學家和機器學習工程師能夠專注於模型開發而非基礎設施管理。

值得注意的是，雖然名稱空間(namespace)建立通常是自動的，但如果系統沒有為你建立工作名稱空間，你需要按照Kubeflow的「手動設定檔案建立」進行操作。

Notebooks (JupyterHub)：原型開發與實驗的根本

大多數機器學習專案的第一步是某種形式的原型設計和實驗。Kubeflow為此提供的工具是JupyterHub—一個多使用者中心，可以生成、管理和代理多個單使用者Jupyter筆記本例項。

Jupyter筆記本支援整個計算過程：開發、記錄和執行程式碼，以及傳達結果。這種互動式的開發環境特別適合機器學習的迭代過程。

建立和管理筆記本伺服器

要建立新的筆記本伺服器，你需要指定伺服器名稱和名稱空間，選擇映像(可以是CPU最佳化、GPU最佳化或自定義映像)，並指定資源需求—包括CPU/記憶體、工作空間、資料卷、自定義設定等。一旦伺服器建立完成，你就可以連線並開始建立和編輯筆記本。

筆記本環境中的叢集操作

為了讓資料科學家無需離開筆記本環境就能執行叢集操作，Kubeflow在提供的筆記本映像中增加了kubectl，這使開發者能夠使用筆記本建立和管理Kubernetes資源。Jupyter筆記本Pod在特殊服務帳戶default-editor下執行，該帳戶擁有對以下Kubernetes資源的名稱空間範圍許可權：

  • Pods
  • Deployments
  • Services
  • 工作s
  • TF工作s
  • PyTorch工作s

你可以將此帳戶繫結到自定義角色，以限制/擴充套件筆記本伺服器的許可權。這允許筆記本開發者在不離開筆記本環境的情況下執行所有(由角色允許的)Kubernetes命令。例如，可以透過在Jupyter筆記本中直接執行以下命令來建立新的Kubernetes資源：

!kubectl create -f myspec.yaml

你的YAML檔案內容將決定建立什麼資源。如果你不習慣建立Kubernetes資源，不用擔心—Kubeflow的管道包含工具可以為你生成這些資源。

為了進一步增強Jupyter的功能，Kubeflow還在筆記本中提供對Pipeline和中繼資料管理等重要Kubeflow元件的支援。Jupyter筆記本還可以直接啟動分散式訓練作業。

訓練運算元：生產級機器學習的基礎

JupyterHub是進行初步資料實驗和原型設計的絕佳工具。然而，當需要在生產環境中進行訓練時，Kubeflow提供了多種訓練元件來自動執行機器學習演算法，包括：

  • Chainer訓練
  • MPI訓練
  • Apache MXNet訓練
  • PyTorch訓練
  • TensorFlow訓練

在Kubeflow中，分散式訓練作業由特定應用的控制器管理，這些控制器被稱為運算元(operators)。這些運算元擴充套件了Kubernetes API，用於建立、管理和操作資源狀態。

運算元的工作原理

以分散式TensorFlow訓練作業為例，使用者只需提供描述所需狀態(工作節點數量、引數伺服器等)的規格，TensorFlow運算元元件就會負責管理訓練作業的生命週期。

這些運算元實作了自動化重要的佈署概念，如可擴充套件性、可觀察性和容錯移轉。它們還可以被Pipeline使用，將其執行與系統其他元件的執行連結起來。

在實際應用中，玄貓發現這些專用運算元大簡化了分散式訓練的複雜性，讓開發團隊能夠專注於模型本身而非基礎設施細節。特別是在處理大規模型時，這種抽象層帶來的便利性尤為明顯。

Kubeflow Pipelines：協調機器學習工作流程

除了提供實作特定功能的專用引數外，Kubeflow還有Pipeline，它允許你協調機器學習應用的執行。這一實作根據Argo Workflows，這是一個開放原始碼的、容器原生的Kubernetes工作流程引擎。Kubeflow安裝時會包含所有Argo元件。

Pipeline的核心元件

在高層次上，Pipeline的執行包含以下元件：

Python SDK
使用Kubeflow Pipelines領域特定語言(DSL)建立元件或指定Pipeline。

DSL編譯器
DSL編譯器將Pipeline的Python程式碼轉換為靜態設定(YAML)。

Pipeline服務
Pipeline服務從靜態設定建立Pipeline執行例項。

Kubernetes資源
Pipeline服務呼叫Kubernetes API伺服器建立必要的Kubernetes自定義資源定義(CRD)來執行Pipeline。

協調控制器
一組協調控制器執行完成Pipeline執行所需的容器，這些容器在虛擬機器上的Kubernetes Pod中執行。一個例子是Argo Workflow控制器，它協調任務驅動的工作流程。

資料儲存機制

Kubernetes Pod儲存兩種型別的資料：

中繼資料
包括實驗、作業、執行、單一標量指標(通常為排序和過濾目的而聚合)等。Kubeflow Pipelines將中繼資料儲存在MySQL資料函式庫中。

成品
包括Pipeline包、檢視、大規模指標(如時間序列，通常用於調查單個執行的效能和除錯)等。Kubeflow Pipelines將成品儲存在像MinIO伺服器或Google Cloud Storage這樣的成品儲存函式庫中。

這段程式碼展示瞭如何在Jupyter筆記本中直接執行Kubernetes命令。!符號是Jupyter的特殊語法，它允許在筆記本單元中執行shell命令。在這個例子中，命令會使用kubectl工具根據myspec.yaml檔案中定義的規格建立Kubernetes資源。這使得資料科學家可以在不離開筆記本環境的情況下管理Kubernetes資源，大提高了工作流程的效率。

Pipeline工作流程與實踐應用

Kubeflow Pipeline提供了一個強大的框架，用於構建和管理可重複使用的端對端機器學習工作流程。在實際應用中，Pipeline通常包含資料準備、特徵工程、模型訓練、評估和佈署等多個步驟。

Pipeline的優勢

使用Kubeflow Pipeline進行機器學習工作流程管理有幾個關鍵優勢：

  1. 自動化與可重複性 - 整個工作流程可以被編碼，確保每次執行都遵循相同的步驟，減少人為錯誤。

  2. 元件化設計 - 每個Pipeline步驟都是獨立的容器，可以單獨開發、測試和版本控制。

  3. 資源隔離 - 每個步驟在自己的容器中執行，確保資源隔離和相依性管理。

  4. 視覺化與監控 - Kubeflow提供了直觀的介面來監控Pipeline執行和檢查結果。

  5. 可擴充套件性 - 從單機到大規模分散式環境，Pipeline可以無縫擴充套件。

實際案例分析

在一個典型的機器學習專案中，我們可能會建立一個包含以下步驟的Pipeline：

  1. 資料提取與驗證
  2. 資料預處理與特徵工程
  3. 模型訓練（可能包括超引數調優）
  4. 模型評估
  5. 模型佈署

使用Kubeflow Pipeline DSL，我們可以將這些步驟編碼為一個完整的工作流程：

@dsl.pipeline(
    name="ML Training Pipeline",
    description="End-to-end ML training pipeline"
)
def ml_pipeline(data_path: str, model_name: str, epochs: int = 10):
    # 資料提取與驗證
    data_op = dsl.ContainerOp(
        name="data-extraction",
        image="data-extraction:latest",
        arguments=["--data-path", data_path]
    )
    
    # 資料預處理
    preprocess_op = dsl.ContainerOp(
        name="preprocessing",
        image="data-preprocessing:latest",
        arguments=["--data", data_op.output]
    )
    
    # 模型訓練
    train_op = dsl.ContainerOp(
        name="model-training",
        image="model-training:latest",
        arguments=[
            "--data", preprocess_op.output,
            "--model-name", model_name,
            "--epochs", epochs
        ]
    )
    
    # 模型評估
    eval_op = dsl.ContainerOp(
        name="model-evaluation",
        image="model-evaluation:latest",
        arguments=["--model", train_op.output]
    )
    
    # 模型佈署（僅當評估結果超過閾值時）
    with dsl.Condition(eval_op.output >= 0.8):
        deploy_op = dsl.ContainerOp(
            name="model-deployment",
            image="model-deployment:latest",
            arguments=["--model", train_op.output]
        )

這個範例展示瞭如何使用Kubeflow Pipeline DSL定義一個端對端的機器學習工作流程。整個流程被封裝在一個Python函式中，並使用@dsl.pipeline裝飾器標記為Pipeline。

Pipeline接受三個引數：資料路徑、模型名稱和訓練輪數（預設為10）。每個步驟都被定義為一個ContainerOp，指定了容器映像和引數。步驟之間的依賴關係透過輸出引數自動建立（例如，預處理步驟依賴於資料提取步驟的輸出）。

特別值得注意的是條件佈署步驟，它使用dsl.Condition確保只有當模型評估結果超過閾值（在這裡是0.8）時才執行佈署操作。這種條件執行能力使Pipeline能夠根據中間結果做出決策，實作更人工智慧的工作流程。

中繼資料管理：追蹤實驗與模型

在機器學習工作流程中，有效管理中繼資料對於確保實驗的可重複性和模型的可追溯性至關重要。Kubeflow提供了強大的中繼資料管理功能，可以跟蹤實驗、模型和資料集的所有相關訊息。

中繼資料的重要性

中繼資料管理解決了幾個關鍵挑戰：

  1. 實驗追蹤 - 記錄不同實驗的引數、結果和效能指標
  2. 模型譜系 - 追蹤模型的完整生命週期，從訓練資料到佈署
  3. 資源關聯 - 建立資料、程式碼、設定和結果之間的關聯
  4. 合規與稽核 - 支援監管要求和內部稽核流程

Kubeflow中繼資料元件

Kubeflow的中繼資料管理系統主要包含以下部分：

  1. 中繼資料API - 提供建立、查詢和管理中繼資料的介面
  2. 中繼資料儲存 - 通常使用關係型資料函式庫（如MySQL）儲存結構化中繼資料
  3. 中繼資料UI - 透過中央儀錶板提供視覺化和互動式中繼資料探索
  4. SDK整合 - 與Pipeline和Notebooks無縫整合的Python SDK

實用中繼資料記錄模式

在實際專案中，玄貓發現以下中繼資料記錄模式特別有效：

from kfp.components import InputPath, OutputPath

def train_model(
    data_path: InputPath("Dataset"),
    model_path: OutputPath("Model"),
    hyperparameters_path: InputPath("HyperParameters"),
    metrics_path: OutputPath("Metrics"),
    model_config: dict
):
    """訓練模型並記錄相關中繼資料"""
    import json
    import pickle
    import numpy as np
    from sklearn.ensemble import RandomForestClassifier
    from sklearn.metrics import accuracy_score
    
    # 載入資料和超引數
    with open(data_path, 'rb') as f:
        X_train, X_test, y_train, y_test = pickle.load(f)
    
    with open(hyperparameters_path, 'r') as f:
        hyperparams = json.load(f)
    
    # 合併設定和超引數
    params = {**model_config, **hyperparams}
    
    # 訓練模型
    model = RandomForestClassifier(
        n_estimators=params['n_estimators'],
        max_depth=params['max_depth'],
        random_state=42
    )
    model.fit(X_train, y_train)
    
    # 評估模型
    y_pred = model.predict(X_test)
    accuracy = accuracy_score(y_test, y_pred)
    
    # 儲存模型
    with open(model_path, 'wb') as f:
        pickle.dump(model, f)
    
    # 記錄指標和引數作為中繼資料
    metrics = {
        'accuracy': float(accuracy),
        'feature_importance': model.feature_importances_.tolist(),
        'training_samples': len(X_train)
    }
    
    with open(metrics_path, 'w') as f:
        json.dump({**metrics, **params}, f)

這個範例展示瞭如何在Kubeflow Pipeline元件中記錄中繼資料。該函式使用Kubeflow Pipeline的InputPath和OutputPath型別來處理資料和模型檔案。

這種方法的優點在於：

  1. 明確定義了輸入和輸出路徑，Kubeflow會自動追蹤這些資源
  2. 將模型設定和超引數作為中繼資料儲存
  3. 記錄了準確率、特徵重要性和訓練樣本數等關鍵指標
  4. 將所有引數和指標合併為單一JSON檔案，便於後續分析

在實際工作流程中，這些中繼資料可以被Pipeline系統收集並顯示在UI中，使團隊成員能夠比較不同實驗的結果，並瞭解哪些引數設定產生了最佳模型。

超引數調優與實驗追蹤

機器學習模型的效能很大程度上取決於超引數的選擇。Kubeflow提供了Katib元件來自動化超引數調優過程，幫助開發者找到最佳的模型設定。

Katib的工作原理

Katib是一個超引數調優和神經架構搜尋(NAS)框架，它實作了多種先進的搜尋演算法，包括：

  1. 隨機搜尋
  2. 網格搜尋
  3. 貝葉斯最佳化
  4. 超頻最佳化
  5. 早期停止策略

Katib透過建立多個平行訓練作業，每個作業使用不同的超引數設定，然後根據指定的目標指標（如準確率或損失）找出最佳設定。

實用Katib設定範例

以下是一個使用Katib進行超引數調優的YAML設定範例：

apiVersion: "kubeflow.org/v1beta1"
kind: Experiment
metadata:
  name: random-forest-tuning
  namespace: kubeflow-user
spec:
  objective:
    type: maximize
    goal: 0.9
    objectiveMetricName: accuracy
    additionalMetricNames:
      - f1_score
  algorithm:
    algorithmName: random
  parallelTrialCount: 3
  maxTrialCount: 12
  maxFailedTrialCount: 3
  parameters:
    - name: n_estimators
      parameterType: int
      feasibleSpace:
        min: "10"
        max: "200"
        step: "10"
    - name: max_depth
      parameterType: int
      feasibleSpace:
        min: "3"
        max: "15"
        step: "1"
    - name: min_samples_split
      parameterType: int
      feasibleSpace:
        min: "2"
        max: "10"
    - name: min_samples_leaf
      parameterType: int
      feasibleSpace:
        min: "1"
        max: "5"
  trialTemplate:
    primaryContainerName: training
    trialParameters:
      - name: n_estimators
        description: "Number of trees in the forest"
        reference: "{{.Trial.Parameters.n_estimators}}"
      - name: max_depth
        description: "Maximum depth of the trees"
        reference: "{{.Trial.Parameters.max_depth}}"
      - name: min_samples_split
        description: "Minimum samples required to split"
        reference: "{{.Trial.Parameters.min_samples_split}}"
      - name: min_samples_leaf
        description: "Minimum samples required at a leaf"
        reference: "{{.Trial.Parameters.min_samples_leaf}}"
    trialSpec:
      apiVersion: batch/v1
      kind: 工作
      spec:
        template:
          spec:
            containers:
              - name: training
                image: my-registry/rf-training:latest
                command:
                  - "python"
                  - "/app/train.py"
                  - "--n_estimators=${trialParameters.n_estimators}"
                  - "--max_depth=${trialParameters.max_depth}"
                  - "--min_samples_split=${trialParameters.min_samples_split}"
                  - "--min_samples_leaf=${trialParameters.min_samples_leaf}"
                  - "--metric-path=/metrics/accuracy"
            restartPolicy: Never

這個YAML設定義了一個Katib超引數調優實驗，目標是最大化隨機森林模型的準確率。設定包含以下關鍵部分：

  1. 目標(objective) - 定義了最佳化目標（最大化準確率）和目標閾值(0.9)
  2. 演算法(algorithm) - 使用隨機搜尋演算法
  3. 平行度(parallelTrialCount) - 同時執行3個試驗
  4. 最大試驗數(maxTrialCount) - 總共執行12個試驗
  5. 引數空間(parameters) - 定義了四個需要調優的超引數及其取值範圍
  6. 試驗範本(trialTemplate) - 定義瞭如何使用引數建立訓練作業

這種宣告式設定使得超引數搜尋過程完全自動化。Katib將建立多個Kubernetes作業，每個作業使用不同的參陣列合執行訓練容器，然後收集和比較結果以找出最佳設定。

在實際應用中，玄貓發現將Katib與Pipeline結合使用特別有效 - 可以建立一個Pipeline，首先使用Katib找到最佳超引數，然後使用這些引數訓練最終模型並佈署它。

模型服務與佈署

訓練好模型後，下一步是將其佈署為可用的服務。Kubeflow提供了KFServing（現在也稱為KServe）元件，專門用於機器學習模型的佈署和服務。

KFServing的優勢

KFServing提供了多項強大功能：

  1. 多框架支援 - 原生支援TensorFlow、PyTorch、scikit-learn、XGBoost等框架
  2. 無縫擴充套件 - 根據請求負載自動擴充套件，包括縮減到零
  3. 推論圖 - 支援預處理、後處理和模型組合的複雜推論圖
  4. 金絲雀佈署 - 支援漸進式佈署和A/B測試
  5. 批次推論 - 除了實時推論外，還支援批次推論作業
  6. 模型監控 - 內建指標收集和監控能力

模型佈署範例

以下是使用KFServing佈署TensorFlow模型的YAML設定範例：

apiVersion: "serving.kubeflow.org/v1beta1"
kind: "InferenceService"
metadata:
  name: "mnist-classifier"
  namespace: kubeflow-user
spec:
  predictor:
    tensorflow:
      storageUri: "s3://my-bucket/mnist/model"
      resources:
        limits:
          cpu: "1"
          memory: "2Gi"
      runtimeVersion: "2.6.0"
  transformer:
    containers:
      - image: "my-registry/mnist-transformer:v1"
        name: transformer
        resources:
          limits:
            cpu: "1"
            memory: "1Gi"

這個YAML設定義了一個KFServing推論服務，用於佈署MNIST數字分類別模型。設定包含兩個主要部分：

  1. 預測器(predictor) - 指定了模型的儲存位置(S3儲存桶)、執行時版本和資源限制
  2. 轉換器(transformer) - 定義了一個預處理容器，用於處理輸入資料

KFServing會自動建立必要的Kubernetes資源來佈署這個服務，包括Deployment、Service和HorizontalPodAutoscaler。一旦佈署完成，服務就可以透過REST API或gRPC介面接收推論請求。

在實際佈署中，玄貓通常會增加以下增強功能：

  1. 多版本佈署 - 同時佈署模型的多個版本，並控制流量分配
  2. 請求記錄 - 啟用請求日誌記錄，用於後續分析和偏差檢測
  3. 指標匯出 - 設定Prometheus指標匯出，用於效能監控
apiVersion: "serving.kubeflow.org/v1beta1"
kind: "InferenceService"
metadata:
  name: "mnist-classifier"
  namespace: kubeflow-user
  annotations:
    serving.kubeflow.org/enable-prometheus-metrics: "true"
spec:
  predictor:
    canaryTrafficPercent: 20
    tensorflow:
      storageUri: "s3://my-bucket/mnist/model/v2"
      resources:
        limits:
          cpu: "1"
          memory: "2Gi"
  default:
    tensorflow:
      storageUri: "s3://my-bucket/mnist/model/v1"
      resources:
        limits:
          cpu: "1"
          memory: "2Gi"
  logger:
    mode: all
    url: "http://logging-service.monitoring/log"

構建完整的機器學習平台

Kubeflow的真正威力在於它能夠將所有這些元件整合為一個完整的機器學習平台，支援從實驗到生產的整個機器學習生命週期。

整合工作流程範例

以下是一個端對端機器學習工作流程的範例，展示瞭如何使用Kubeflow的各個元件：

  1. 資料科學家使用Jupyter筆記本進行初步探索和原型設計
  2. 使用Katib進行超引數調優，找到最佳模型設定
  3. 建立Pipeline自動化整個訓練過程，包括資料準備、訓練和評估
  4. 使用中繼資料服務追蹤所有實驗和模型
  5. 使用KFServing佈署模型為生產服務
  6. 設定監控追蹤模型效能和資料漂移

平台擴充套件與整合

Kubeflow設計為可擴充套件的平台，可以與其他工具和系統整合：

  1. CI/CD系統 - 與Jenkins、GitLab CI或GitHub Actions整合，實作模型的持續整合和佈署
  2. 資料管理工具 - 與Delta Lake、Hudi或其他資料湖解決方案整合
  3. 監控系統 - 與Prometheus、Grafana和ELK堆積積堆積疊整合，實作全面監控
  4. 安全工具 - 與企業安全系統整合，確保合規性和資料保護

企業級考量

在企業環境中佈署

Kubeflow管道：實作可重複的機器學習流程

Kubeflow管道（Kubeflow Pipelines）是Kubeflow生態系統中的核心元件，它讓機器學習工作變得可重複與能夠有效處理新資料。在實際開發過程中，我發現Kubeflow管道最大的價值在於它提供了一種直覺的方式來組織和自動化複雜的機器學習工作流程。

管道的核心優勢

Kubeflow管道提供了一個根據Python的直覺化領域特定語言（DSL），使你能夠輕鬆撰寫機器學習管道。這些管道會被編譯成Kubernetes工作流程引擎（目前是Argo Workflows）可以執行的格式。實際使用中，這種設計讓開發者能夠專注於機器學習邏輯，而不必過度關注底層的Kubernetes細節。

Kubeflow管道的元件使協調不同工具變得簡單，這對於建立端對端的機器學習專案至關重要。在實踐中，這解決了機器學習專案中最痛苦的問題之一：不同工具間的整合與協調。

更重要的是，Kubeflow能夠追蹤資料和中繼資料，這大幅改善了我們理解工作的方式。例如，透過這些人工產物（artifacts），我們可以更好地理解資料的結構和模式。管道還能夠暴露底層機器學習演算法的引數，讓Kubeflow能夠執行調整和最佳化。

超引數調整：尋找最佳模型設定

尋找訓練模型的最佳超參陣列合是一項具有挑戰性的任務。傳統方法如網格搜尋（grid search）不僅耗時，而與相當繁瑣。在我的實踐經驗中，超引數調整往往是模型開發過程中最耗費時間與容易被低估的環節。

Katib：Kubeflow的超引數調整引擎

Kubeflow提供了一個名為Katib的元件，使用者可以在Kubernetes叢集上輕鬆執行超引數最佳化。Katib的靈感來自Google Vizier，一個黑盒最佳化框架。它利用貝葉斯最佳化等先進搜尋演算法來尋找最佳超引數設定。

Katib支援超引數調整，並且可以與任何深度學習框架一起使用，包括TensorFlow、MXNet和PyTorch。這種框架無關性是它最大的優勢之一，讓開發團隊可以靈活選擇最適合的工具，而不必被特定技術繫結。

Katib的核心概念

與Google Vizier類別似，Katib根據四個主要概念：

實驗（Experiment）

一個在可行空間上的單一最佳化執行。每個實驗包含描述可行空間的設定，以及一組試驗（trials）。在實驗過程中，目標函式f(x)被假設為不變的。

試驗（Trial）

引數值的列表x，將導致f(x)的單一評估。試驗可以是「已完成」的（表示已經被評估並且目標值f(x)已被分配給它），否則它是「待定」的。一個試驗對應一個作業（job）。

作業（工作）

負責評估待定試驗並計算其目標值的過程。在實際應用中，這通常是一個訓練模型的Kubernetes作業。

建議（Suggestion）

構建引數集的演算法。目前，Katib支援以下探索演算法：

  • 隨機（Random）
  • 網格（Grid）
  • Hyperband
  • 貝葉斯最佳化（Bayesian optimization）

使用這些核心概念，你可以顯著提高模型的效能。由於Katib不繫結於單一機器學習函式庫，你可以最小的修改探索新演算法和工具。

模型推論：將模型佈署到生產環境

在機器學習工作流程中，將訓練好的模型佈署到生產環境是一個關鍵步驟，而這往往是最具挑戰性的環節之一。Kubeflow透過提供多種模型服務選項，使在生產環境中大規模佈署機器學習模型變得簡單。

多樣化的模型服務選項

Kubeflow提供了多種模型服務選項，包括：

  • TFServing（用於TensorFlow模型）
  • Seldon serving（框架無關的服務解決方案）
  • PyTorch serving（專為PyTorch模型設計）
  • TensorRT（針對NVIDIA GPU最佳化的高效能推論引擎）

此外，Kubeflow還提供了一個統一實作——KFServing，它將自動擴充套件、網路、健康檢查和伺服器設定等模型推論關注點進行了抽象和泛化。

KFServing的技術基礎

KFServing的整體實作根據Istio和Knative serving（Kubernetes上的無伺服器容器）。根據Knative檔案的定義，Knative serving專案提供了以下中介軟體原語：

  • 快速佈署無伺服器容器
  • 自動向上和向下擴充套件到零
  • 為Istio元件提供路由和網路程式設計

由於模型服務本質上是有突發性的，快速擴充套件和縮減規模非常重要。Knative serving透過自動將請求路由到較新的模型佈署，簡化了對持續模型更新的支援。這需要將未使用的模型縮減到零（最小化資源利用），同時保持它們可用於回復。

由於Knative是雲原生的，它受益於其底層基礎設施堆積積堆疊，因此提供了Kubernetes中存在的所有監控功能，如日誌記錄、追蹤和監控。KFServing還利用Knative eventing為可插拔事件源提供可選支援。

KFServing的元件架構

與Seldon類別似，每個KFServing佈署都是一個協調器，將以下元件連線在一起：

前處理器（Preprocessor）

一個可選元件，負責將輸入資料轉換為模型服務所需的內容/格式。在實際應用中，這可能包括影像調整大小、文字標記化或特徵標準化等操作。

預測器（Predictor）

一個必須的元件，負責實際的模型服務。這是KFServing佈署的核心，它載入模型並處理推論請求。

後處理器（Postprocessor）

一個可選元件，負責將模型服務結果轉換/豐富為輸出所需的內容/格式。這可能包括將原始預測分數轉換為人類可讀的標籤，或增加額外的上下文訊息。

除了這些主要元件外，還可以有其他增強整體模型服務實作的附加元件，但它們在主要執行管道之外。異常檢測和模型可解釋性等工具可以在這個環境中執行，而不會減慢整個系統。

雖然所有這些單獨的元件和技術已經存在很長時間，但將它們整合到Kubeflow的服務系統中，大降低了將新模型投入生產的複雜性。

中繼資料管理：追蹤模型建立的關鍵訊息

除了直接支援ML操作的元件外，Kubeflow還提供了幾個支援元件，其中繼資料管理是一個重要的部分。

ML中繼資料的重要性

Kubeflow的一個重要元件是中繼資料管理，它提供了捕捉和追蹤有關模型建立的訊息的能力。許多組織每天構建數百個模型，但管理所有與模型相關的資訊非常困難。ML中繼資料既是基礎設施，也是一個函式庫，用於記錄和檢索與ML開發人員和資料科學家工作流程相關的中繼資料。

可追蹤的關鍵訊息

可以在中繼資料元件中註冊的訊息包括：

  • 用於模型建立的資料源
  • 透過管道的元件/步驟生成的人工產物
  • 這些元件/步驟的執行
  • 管道和相關的血統訊息

ML中繼資料追蹤ML工作流程中所有元件和步驟的輸入和輸出及其血統。這些資料支援了幾個重要功能。

中繼資料操作範例

以下是ML中繼資料操作的一些實際應用範例：

  • 列出特定型別的所有人工產物：例如，列出所有已訓練的模型。
  • 比較同一型別的兩個人工產物：比較兩個實驗的結果，識別效能差異。
  • 顯示所有相關執行及其輸入和輸出人工產物的DAG：視覺化實驗的工作流程，用於除錯和發現。
  • 顯示人工產物是如何建立的：檢視哪些資料進入了模型，執行資料保留計劃。
  • 識別使用給定人工產物建立的所有人工產物：標記從包含錯誤資料的特定資料集訓練的所有模型。
  • 確定之前是否在相同輸入上執行過執行：確定元件/步驟是否已經完成相同的工作，可以直接重用先前的輸出。
  • 記錄和查詢工作流程執行的上下文：追蹤工作流程執行的所有者和使用的更改；按實驗分組血統；按專案管理人工產物。

中繼資料架構

中繼資料系統的設計使得機器學習工作流程中的所有元件能夠無縫協作。它記錄了資料如何被轉換、模型如何被訓練以及結果如何被評估的完整歷史。這種可追溯性對於確保模型的可重現性和可靠性至關重要。

Kubeflow的整合魔力

Kubeflow的魔力在於使所有這些傳統上獨立的元件協同工作。雖然Kubeflow當然不是唯一將機器學習領域的不同部分整合在一起的系統，但它在支援廣泛元件方面的靈活性是獨特的。

此外，由於它執行在標準Kubernetes上，你可以根據需要增加自己的元件。這種工具整合的魔力很大程度上發生在Kubeflow的管道內部，但一些支援元件對於允許這些工具互動至關重要。

支援元件：構建Kubeflow生態系統的根本

雖然這些元件並非由Kubeflow明確暴露，但它們在整個Kubeflow生態系統中扮演著重要角色。讓我們簡要討論其中之一。

MinIO：管道架構的基礎

管道架構的基礎是分享儲存。現今的常見做法是將資料儲存在外部儲存中。不同的雲提供商有不同的解決方案，如Amazon S3、Azure Data Storage、Google Cloud Storage等。當處理不同雲環境時，這種多樣性可能會帶來挑戰。

MinIO在Kubeflow中提供了一個一致的儲存介面，它可以在多台伺服器上執行，同時暴露一個一致的端點。這使得Kubeflow管道能夠在不同的雲環境中以相同的方式處理資料儲存，簡化了跨平台佈署的複雜性。

在實際應用中，MinIO的這種抽象層讓開發者可以專注於機器學習工作流程的邏輯，而不必擔心底層儲存的細節。這對於構建可移植和可重複的機器學習解決方案至關重要。

Kubeflow透過整合這些支援元件，建立了一個完整的機器學習平台，使資料科學家和機器學習工程師能夠專注於他們的核心工作——構建和佈署高品質的機器學習模型，而不必過度關注底層基礎設施的複雜性。

機器學習專案的成功不僅取決於演算法的選擇和模型的效能，還取決於整個工作流程的可管理性和可擴充套件性。Kubeflow透過提供這些元件和整合能力，幫助團隊建立更加健壯和可維護的機器學習系統。

在實際工作中，我發現Kubeflow最大的價值在於它能夠標準化機器學習工作流程，使團隊成員能夠更有效地協作，並且使專案更容易維護和擴充套件。無論是進行實驗性研究還是構建生產級系統，Kubeflow都提供了必要的工具和框架來支援整個機器學習生命週期。

MinIO：Kubeflow的分散式儲存根本

在建構機器學習平台時，資料儲存是一個關鍵挑戰。為瞭解決這個問題，Kubeflow整合了MinIO作為其預設的儲存解決方案。從我多年的實踐經驗來看，適當的儲存方案對機器學習工作流程的效率有著決定性影響。

MinIO的核心特性與佈署模式

MinIO是一個高效能的分散式物件儲存伺服器，專為大規模私有雲基礎設施設計。它不僅適用於私有雲，還能作為公共API的一致性閘道器。在實際應用中，我發現MinIO的靈活性是其最大優勢之一，它支援多種佈署設定：

  1. 單容器模式：這是Kubeflow的預設設定，MinIO使用Kubernetes內建的持久化儲存在單個容器中執行。

  2. 分散式佈署：這種模式允許將多個儲存卷合併為單一物件儲存服務，能夠承受多節點故障同時確保資料完整性（故障容忍度取決於複製設定）。

  3. 閘道器模式：MinIO閘道器可在Azure Blob儲存、Google Cloud儲存、Gluster或NAS儲存之上提供S3相容API。個人認為，這是最靈活的選項，可建立不受規模限制的雲端獨立實作。

設定與存取MinIO

雖然Kubeflow的預設MinIO設定能夠運作，但在實際生產環境中，通常需要進一步設定。Kubeflow安裝時會同時佈署MinIO伺服器和UI介面。

要存取MinIO的UI介面並探索儲存內容，可以使用連線埠轉發或暴露一個入口(ingress)。以下是設定連線埠轉發的方法：

# 設定連線埠轉發
kubectl port-forward -n kubeflow svc/minio-service 9000:9000 &

存取時，可以使用Kubeflow的預設憑證(minio/minio123)登入。

安裝MinIO命令列工具

除了Web介面外，還可以安裝MinIO CLI(mc)從工作站透過命令列存取MinIO。根據作業系統的不同，安裝方式也略有差異：

macOS使用者可以使用Homebrew：

# 在Mac上安裝MinIO
brew install minio/stable/minio

Linux Ubuntu使用者可以使用以下命令：

# 在Linux上安裝MinIO
pushd ~/bin
wget https://dl.min.io/client/mc/release/linux-amd64/mc
chmod a+x mc

這些命令在不同作業系統上安裝MinIO命令列客戶端。對於macOS，使用Homebrew套件管理器安裝；對於Linux，直接下載二進位檔案並賦予執行許可權。這樣使用者就可以從命令列直接與MinIO服務互動。

安裝完成後，需要設定MinIO客戶端以連線到Kubeflow的MinIO例項：

# 設定MinIO客戶端連線到Kubeflow的MinIO
mc config host add minio http://localhost:9000 minio minio123

設定完成後，就可以建立新的儲存桶(bucket)或修改設定：

# 使用MinIO建立一個儲存桶
mc mb minio/my-ml-datasets

這些命令首先設定MinIO客戶端，將本地MinIO服務增加為名為"minio"的主機，指定端點URL和登入憑證。然後使用mc mb(make bucket)命令建立一個新的儲存桶，用於存放機器學習資料集。這些操作讓使用者能夠透過命令列輕鬆管理MinIO中的資料。

MinIO的API與安全性考量

MinIO同時提供原生API和S3相容API。對我們來說，S3相容API尤為重要，因為大多數軟體（如TensorFlow和Spark）都能與S3互動。

需要注意的是，如果要在根據Hadoop（主要是Java開發）的系統中使用MinIO，則需要Hadoop 2.8或更高版本。

Kubeflow安裝時硬編碼了MinIO憑證（minio/minio123），雖然可以直接在應用程式中使用，但這並不是最佳實踐。從安全形度考慮，將憑證儲存在應用程式內部可能導致安全漏洞。更好的做法是使用Kubernetes的Secret，特別是當你可能切換到標準S3時。

以下是為MinIO或S3設定Secret的方法：

# MinIO Secret範例
apiVersion: v1
kind: Secret
metadata:
  name: minioaccess
  namespace: mynamespace
data:
  AWS_ACCESS_KEY_ID: xxxxxxxxxx
  AWS_SECRET_ACCESS_KEY: xxxxxxxxxxxxxxxxxxxxx

這個YAML定義了一個Kubernetes Secret物件，用於安全儲存MinIO或S3的存取憑證。在Kubernetes中，Secret中的值需要Base64編碼。這種方式將憑證與應用程式分離，提高了安全性。可以透過echo -n xxx | base64命令生成Base64編碼的值。

將此YAML儲存為minioaccess.yaml，然後使用以下命令佈署Secret：

kubectl apply -f minioaccess.yaml

瞭解了資料在管道階段之間的通訊後，接下來讓我探討元件之間的網路通訊。

Istio：Kubeflow的服務網格基礎

Kubeflow的另一個重要支援元件是Istio——一個服務網格，提供服務發現、負載平衡、故障還原、指標、監控、速率限制、存取控制和端對端認證等關鍵功能。

Istio的核心概念與架構

Istio作為服務網格，透明地層疊於Kubernetes叢集之上。它可以整合到任何日誌平台、遙測或策略系統中，並促進統一的方式來保護、連線和監控微服務。

Istio的實作將每個服務例項與一個側車網路代理(sidecar proxy)並置。個別服務例項的所有網路流量（HTTP、REST、gRPC等）都透過其本地側車代理流向適當的目的地。因此，服務例項不需要感知整個網路，只需要知道其本地代理。實際上，分散式系統網路已從服務程式員的視角中抽象出來。

從架構上看，Istio的實作在邏輯上分為資料平面和控制平面：

  • 資料平面由一組人工智慧代理組成，這些代理調解和控制Pod之間的所有網路通訊
  • 控制平面管理和設定代理以路由流量

Istio的主要元件

Istio的主要元件包括：

Envoy

Istio的資料平面根據Envoy代理，提供故障處理（如健康檢查和有界重試）、動態服務發現和負載平衡等功能。Envoy具有許多內建功能，包括：

  • 動態服務發現
  • 負載平衡
  • TLS終止
  • HTTP/2和gRPC代理
  • 斷路器
  • 健康檢查
  • 根據百分比流量分割的分階段佈署
  • 故障注入
  • 豐富的指標

Mixer

Mixer在服務網格中執行存取控制和使用策略，並從Envoy代理和其他服務收集遙測資料。代理提取請求級屬性，並將其傳送給Mixer進行評估。

Pilot

Pilot為Envoy側車提供服務發現和人工智慧路由的流量管理功能（如A/B測試、金絲雀佈署）以及彈性（超時、重試、斷路器等）。這是透過將控制流量行為的高階路由規則轉換為Envoy特定設定，並在執行時將其傳播到側車來實作的。

Galley

Galley是Istio的設定驗證、攝取、處理和分發元件。它負責將其他Istio元件與從底層平台取得使用者設定的細節隔離開來。

Citadel

Citadel透過提供身份和憑證管理，實作強大的服務到服務和終端使用者身份驗證。它允許在服務網格中升級未加密的流量。使用Citadel，操作者可以根據服務身份而非相對不穩定的第3層或第4層網路識別符號來執行策略。

Istio在Kubeflow中的應用

Kubeflow使用Istio為Kubeflow UI提供代理，並適當與安全地路由請求。Kubeflow的KFServing利用Knative，而Knative需要Istio這樣的服務網格。

在實際佈署中，玄貓發現Istio為Kubeflow提供了關鍵的網路抽象層，使得複雜的機器學習工作流程能夠以微服務的方式高效執行。特別是在需要處理大量模型佈署和服務請求的環境中，Istio的流量管理和安全功能顯得尤為重要。

Knative：無伺服器架構的支柱

Kubeflow使用的另一個隱藏支援元件是Knative。首先讓我介紹最重要的部分：Knative Serving。

Knative Serving：無伺服器應用的佈署與服務

Knative Serving建立在Kubernetes和Istio之上，支援無伺服器應用程式的佈署和服務。Knative Serving專案提供中介軟體原語，實作：

  • 快速佈署無伺服器容器
  • 自動擴充套件（包括縮減到零）
  • 為Istio元件提供路由和網路程式設計
  • 已佈署程式碼和設定的時間點快照

Knative Serving被實作為一組Kubernetes自定義資源定義(CRD)。這些物件用於定義和控制無伺服器工作負載的行為：

Service

service.serving.knative.dev資源整體管理工作負載。它協調其他物件的建立和執行，確保應用程式具有設定、路由，以及服務每次更新時的新修訂版本。Service可以定義為始終將流量路由到最新版本或特定版本。

Knative在Kubeflow中的價值

在Kubeflow環境中，Knative的價值主要體現在模型服務方面。透過Knative，Kubeflow能夠實作模型的按需擴充套件，這對於機器學習工作負載的不穩定特性尤為重要。當沒有預測請求時，服務可以縮減到零，節省資源；而當請求增加時，又能迅速擴充套件以滿足需求。

從我的實踐經驗來看，Knative為Kubeflow帶來的無伺服器能力，極大地簡化了模型佈署和服務的管理，使機器學習工程師能夠專注於模型開發，而不必過多關注底層基礎設施的細節。

整合視角：MinIO、Istio與Knative如何協同工作

從系統架構的角度來看，這三個支援元件各自解決了Kubeflow中的特定挑戰，但它們的真正價值在於協同工作時所創造的整體解決方案：

  1. 資料流動：MinIO提供了資料儲存層，使模型訓練資料和結果能夠持久化並在不同元件間分享。

  2. 服務通訊：Istio管理服務間的網路通訊，提供安全、可靠的服務發現和負載平衡。

  3. 計算擴充套件：Knative實作了無伺服器模式，使計算資源能夠根據需求自動擴充套件。

在實際的機器學習工作流程中，這三者協同工作的例子可能是：資料科學家將訓練資料儲存在MinIO中，透過Kubeflow Pipelines訓練模型，然後使用KFServing（根據Knative）佈署模型，同時Istio管理服務間的通訊和安全性。

安全性考量與最佳實踐

在設定這些支援元件時，安全性是一個關鍵考量因素。以下是一些最佳實踐：

  1. MinIO安全：

    • 避免使用預設憑證
    • 使用Kubernetes Secrets管理存取金鑰
    • 考慮啟用TLS加密

  2. Istio安全：

    • 利用Citadel實作服務間的mTLS通訊
    • 實施適當的RBAC策略
    • 定期更新Istio以修補安全漏洞

  3. Knative安全：

    • 審慎設定自動擴充套件策略，防止資源濫用
    • 實施適當的資源限制
    • 考慮使用服務帳戶隔離不同的服務

MinIO、Istio和Knative是Kubeflow的關鍵支援元件，共同為機器學習平台提供了強大的基礎設施支援。MinIO解決了資料儲存挑戰，Istio管理服務間的通訊，而Knative則提供了無伺服器能力。

在實際佈署Kubeflow時，理解這些元件的工作原理和設定方法至關重要。雖然Kubeflow的預設設定可以滿足入門需求，但在生產環境中，通常需要根據具體需求進行調整和最佳化。

透過適當設定這些支援元件，可以構建一個可擴充套件、安全與高效的機器學習平台，使資料科學家和機器學習工程師能夠專注於模型開發和佈署，而不必過多關注底層基礎設施的細節。

Kubeflow 架構與核心元件詳解

在機器學習工作流程的實際佈署中，Kubeflow 已成為主流的雲原生解決方案。當我們深入研究 Kubeflow 的架構時，會發現它由多個精心設計的元件構成，這些元件協同工作，提供完整的機器學習平台體驗。本文將帶你深入瞭解 Kubeflow 的核心設計理念與關鍵元件。

Knative：Kubeflow 的底層服務架構

Knative 作為 Kubeflow 的關鍵支援元件，提供了無伺服器運算能力，讓機器學習工作負載能夠按需擴充套件。Knative 主要由三個核心資源組成：

Route 資源

route.serving.knative.dev 資源負責將網路端點對映到一個或多個修訂版本。這種設計允許多種流量管理策略，包括：

  • 分數流量分配 - 可以將不同比例的流量導向不同版本的服務
  • 命名路由 - 為不同的服務版本提供專用的存取路徑

這種靈活的流量管理機制對於模型的金絲雀佈署和 A/B 測試尤為重要。

Configuration 資源

configuration.serving.knative.dev 資源維護佈署的期望狀態。它遵循 Twelve-Factor App 方法論，實作了程式碼和設定的清晰分離。這種分離使得機器學習工程師可以獨立管理模型程式碼和設定引數，提高了系統的可維護性。

當修改設定時，系統會自動建立一個新的修訂版本，便於版本控制和回復。

Revision 資源

revision.serving.knative.dev 資源代表工作負載在每次修改時的程式碼和設定的時間點快照。它具有以下特性：

  • 不可變性 - 修訂版本是不可變的物件，確保佈署的一致性
  • 永續性 - 可以根據需要長期保留修訂版本
  • 自動擴充套件 - 能夠根據傳入流量自動擴充套件和縮減

這種設計特別適合機器學習模型服務，因為它允許在不中斷服務的情況下佈署新模型，並根據實際負載自動調整資源。

Apache Spark：大資料處理引擎

從 Kubeflow 1.0 開始，平台內建了 Spark 運算元，用於執行 Spark 作業。除了原生支援外，Kubeflow 還提供與 Google 的 Dataproc 和 Amazon 的 EMR 這兩個代管雲端服務的整合。

在我的實踐中發現，Kubeflow 中的 Spark 元件主要專注於生產用途，不太適合探索性分析。對於探索性工作，我建議直接在 Jupyter notebook 中使用 Spark。

Spark 在機器學習管道中的主要價值在於：

  • 處理超出單機容量的大型資料集
  • 作為機器學習管道中的資料或特徵準備階段
  • 提供分散式計算能力，加速資料處理

雖然 Spark 有自己的機器學習函式庫，但在 Kubeflow 環境中，它更常被用作資料準備工具而非主要的模型訓練平台。

Kubeflow 多使用者隔離機制

Kubeflow 的最新版本引入了多使用者隔離功能，這使得不同團隊和使用者可以分享同一資源池，同時保護各自的資源不被他人意外檢視或更改。這種隔離機制根據以下核心概念：

管理員

管理員負責建立和維護 Kubeflow 叢集，並有許可權授予他人存取許可權。在實際佈署中，通常由 DevOps 或平台工程團隊擔任此角色。

使用者

使用者是被授予叢集中某些資源存取許可權的人。使用者需要由管理員授權，才能存取系統資源。

設定檔案

設定檔案是使用者擁有的所有 Kubernetes 名稱空間和資源的分組。它定義了使用者可以存取哪些資源以及如何存取。

截至 1.0 版本，Kubeflow 的 Jupyter notebook 服務是第一個與多使用者隔離完全整合的應用。筆記本及其建立受到管理員或設定檔案所有者設定的設定檔案存取策略控制。

這種設計有幾個明顯優勢：

  1. 使用者可以在自己的名稱空間中獨立工作
  2. 每個使用者可以使用自己的 Jupyter 伺服器和筆記本
  3. 透過身份驗證的使用者在首次登入時會自動建立設定檔案
  4. 筆記本建立的資源（如訓練作業和佈署）會繼承相同的存取許可權

如果需要與他人分享伺服器或筆記本存取許可權，可以透過貢獻者管理頁面增加協作者的電子郵件。這種機制確保了資源分享的安全性和可控性。

Kubeflow 的程式碼倉函式庫

Kubeflow 由多個不同元件組成，這些元件託管在 Kubeflow GitHub 組織下。最重要的倉函式庫包括：

  • kfctl：託管在 kfctl 倉函式庫中，負責 Kubeflow 的安裝和管理
  • Kubeflow Pipelines：在 pipelines 倉函式庫中，提供預建元件可以節省開發時間

pipelines 倉函式庫特別重要，因為它的預建元件可以大縮短開發時間。使用其他元件不需要顯式安裝，但檢視元件問題（如 Katib 中的問題）可以幫助解決遇到的問題。

在我的專案中，經常參考這些倉函式庫來尋找最佳實踐和解決方案，特別是在處理複雜的機器學習工作流程時。

Kubeflow Pipelines 深入剖析

Kubeflow Pipelines 是 Kubeflow 的核心元件，負責協調機器學習應用。協調的必要性在於典型的機器學習實作通常涉及多種工具的組合，用於資料準備、模型訓練、效能評估和佈署。

Pipelines 平台組成

Kubeflow Pipelines 平台由以下部分組成：

  1. 使用者介面：用於管理和跟蹤管道及其執行情況
  2. 執行引擎：負責排程管道的執行
  3. SDK：用於在 Python 中定義、構建和佈署管道
  4. 筆記本支援：用於使用 SDK 和管道執行

探索預置範例管道

Kubeflow 安裝時附帶了一些範例管道，可以在 Pipeline 網頁 UI 中找到。值得注意的是，在撰寫時，只有基本到條件執行管道是通用的，而其餘的只能在 Google Kubernetes Engine (GKE) 上執行。

當點選特定管道時，UI 會顯示其執行圖或原始碼選項卡會顯示管道的編譯程式碼，這是一個 Argo YAML 檔案。

Kubeflow Pipelines 的介面設計非常直觀，允許使用者視覺化整個機器學習工作流程。執行圖形檢視特別有用，因為它提供了管道各階段之間關係的清晰視覺表示，幫助使用者理解資料和模型如何在不同處理階段之間流動。

而原始碼檢視則展示了底層的 Argo 工作流程定義，這對於想要了解管道如何在 Kubernetes 上實際執行的高階使用者特別有價值。在我的實踐中，經常在這兩種檢視之間切換，以便同時瞭解高層工作流程結構和底層實作細節。

結合 Kubeflow 元件構建端對端機器學習系統

透過瞭解 Kubeflow 的不同元件及其如何協同工作，我們可以開始構想如何將機器學習任務和工作流程轉化為 Kubeflow 實作。

在實際應用中，Kubeflow 的中央儀錶板為我們提供了存取其網路元件的入口。JupyterHub 促進了模型開發的探索階段，而各種內建的訓練運算元則支援模型的訓練過程。Kubeflow Pipelines 將所有這些元件連線起來，而 Katib 則提供了在管道上進行超引數調優的能力。

對於模型服務，Kubeflow 提供了多種選項，包括 KF Serving 和 Seldon。同時，Kubeflow 的機器學習中繼資料和工件跟蹤系統確保了整個過程的可追溯性和再現性。

在底層，Knative 和 Istio 等支援元件使所有這些功能成為可能，提供了必要的網路、擴充套件和服務發現能力。

透過理解 Kubeflow 的不同部分以及整體設計，我們可以更有效地將機器學習任務轉化為 Kubeflow 工作流程，從而實作更高效、更可靠的機器學習系統開發和佈署。

在接下來的實際應用中，我們將探討這些元件，並瞭解如何將它們應用到具體的機器學習使用案例中。特別是 Kubeflow Pipelines，作為整合所有元件的核心，將是我們關注的重點。透過掌握 Pipelines 的工作原理和使用方法，我們可以構建強大的端對端機器學習工作流程，實作從資料處理到模型佈署的全流程自動化。

Kubeflow Pipelines：機器學習工作流程自動化的關鍵

Kubeflow 作為機器學習平台的重要組成部分，其中 Pipelines 功能可謂是整個系統的核心。當我初次接觸 Kubeflow Pipelines 時，就被它能夠將複雜的機器學習工作流程自動化的能力所吸引。在這篇文章中，我將帶領大家深入瞭解 Kubeflow Pipelines 的基礎知識，從使用介面到實際開發，讓你能夠快速上手這個強大的工具。

Pipelines 使用者介面探索

Kubeflow Pipelines 提供了一個直觀的使用者介面，讓我們能夠輕鬆管理和執行各種機器學習工作流程。要啟動特定的 pipeline，只需點選該 pipeline 名稱，系統就會顯示 Pipeline 檢視，呈現整個工作流程的結構。

當你準備執行 pipeline 時，點選「Create Run」按鈕並按照螢幕上的指示操作即可。在執行過程中，你需要選擇一個「實驗」(Experiment)。這裡的「實驗」其實只是 Kubeflow 為了方便管理 pipeline 執行（runs）而設計的分組機制。如果不確定選擇哪個，可以直接使用 Kubeflow 安裝時自動建立的「Default」實驗。

此外，如果只想執行 pipeline 一次，請在執行型別中選擇「One-off」。關於定期執行 pipeline 的方法，我們會在後續內容中詳細討論。

使用 Python 構建簡單的 Pipeline

瞭解如何執行預編譯的 Kubeflow Pipelines 後，接下來讓我們探索如何建立自己的 pipeline。Kubeflow Pipelines 實際上是以 YAML 檔案形式儲存，並由名為 Argo 的程式執行。幸運的是，Kubeflow 提供了 Python 領域特定語言（DSL）用於編寫 pipeline，使得開發過程變得更加直觀。

這個 DSL 是機器學習工作流程操作的 Python 表示形式，專為機器學習工作負載設計。更棒的是，它允許使用一些簡單的 Python 函式作為 pipeline 階段，無需明確構建容器。

Pipeline 的本質

pipeline 本質上是一個容器執行圖。除了指定哪些容器應該按什麼順序執行外，它還允許使用者向整個 pipeline 和參與的容器之間傳遞引數。

使用 Python SDK 時，對於每個容器，我們必須：

  1. 建立容器 - 可以是簡單的 Python 函式，或任何 Docker 容器
  2. 建立參照該容器的操作，以及命令列引數、資料掛載和傳遞給容器的變數
  3. 設定操作順序，定義哪些可以平行執行，哪些必須在進入下一步之前完成
  4. 將這個用 Python 定義的 pipeline 編譯成 Kubeflow Pipelines 可以使用的 YAML 檔案

使用輕量級 Python 函式

在我們的第一個 Kubeflow 操作中，我將使用一種稱為「輕量級 Python 函式」的技術。別被「輕量級」這個詞誤導了，這種方法非常實用。在輕量級 Python 函式中，我們定義一個 Python 函式，然後讓 Kubeflow 負責將該函式封裝到容器中並建立操作。

為了簡單起見，讓我們宣告最簡單的函式 - echo 函式。這是一個接收單一輸入（整數）並回傳該輸入的函式：

import kfp

def simple_echo(i: int) -> int:
    return i

這段程式碼定義了一個名為 simple_echo 的函式，它接受一個整數引數 i 並直接回傳這個值。注意函式名使用蛇形命名法（snake_case）而非駝峰命名法（camelCase），這是因為在撰寫本文時，Kubeflow Pipelines 存在一個特性（或者說是 bug），使用駝峰命名法（如 simpleEcho）會產生錯誤。

接下來，我們需要將 simple_echo 函式包裝成 Kubeflow Pipeline 操作。這裡可以使用 kfp.components.func_to_container_op 方法，它會回傳一個具有強型別簽名的工廠函式：

simpleStronglyTypedFunction = kfp.components.func_to_container_op(simple_echo)

當我們在下一步建立 pipeline 時，這個工廠函式將構建一個 ContainerOp，它會在容器中執行原始函式（simple_echo）：

foo = simpleStronglyTypedFunction(1)
type(foo)  # 輸出: kfp.dsl._container_op.ContainerOp

這段程式碼將我們的 simple_echo 函式轉換為 Kubeflow Pipelines 可以使用的容器操作。func_to_container_op 方法會自動處理將函式封裝到容器中的複雜過程。當我們呼叫 simpleStronglyTypedFunction(1) 時，它會建立一個 ContainerOp 物件，這個物件代表了在 Kubeflow Pipelines 中的一個執行步驟。

值得注意的是，如果你的程式碼可以透過 GPU 加速，只需在 ContainerOp 後增加 .set_gpu_limit(GPU_數量) 即可標記該階段使用 GPU 資源。

現在，讓我們將 ContainerOp（在這個例子中只有一個）組合成一個 pipeline。這個 pipeline 將接受一個引數（我們要回顯的數字）。pipeline 還有一些關聯的中繼資料。雖然回顯數字可能是引數的一個簡單使用案例，但在實際應用中，你會包含可能需要稍後調整的變數，例如機器學習演算法的超引數。

最後，我們將 pipeline 編譯成壓縮的 YAML 檔案，然後可以上載到 Pipelines UI：

@kfp.dsl.pipeline(
    name='Simple Echo',
    description='This is an echo pipeline. It echoes numbers.'
)
def echo_pipeline(param_1: kfp.dsl.PipelineParam):
    my_step = simpleStronglyTypedFunction(i=param_1)

kfp.compiler.Compiler().compile(echo_pipeline, 'echo-pipeline.zip')

這段程式碼定義了一個完整的 Kubeflow Pipeline。我們使用 @kfp.dsl.pipeline 裝飾器來標記 echo_pipeline 函式為一個 pipeline 定義，並提供名稱和描述。pipeline 函式接受一個引數 param_1，這個引數會傳遞給我們的 simpleStronglyTypedFunction。

最後，我們使用 kfp.compiler.Compiler().compile() 方法將 pipeline 編譯成 YAML 格式，並儲存為 zip 檔案。這個檔案可以直接上載到 Kubeflow Pipelines UI 中執行。

實際上，也可以直接從筆記本執行 pipeline，我們將在下個例子中展示這一點。

玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。