iT邦幫忙

2025 iThome 鐵人賽

DAY 30
0
自我挑戰組

30 天工程師雜學之旅系列 第 30

Kubeflow 入門 (下):核心元件與典型使用方式

  • 分享至 

  • xImage
  •  

一個不小心在鐵人賽最後兩篇又開闢了一個新的主題 而且好像不來個五六篇寫不完哈哈
總之第一次參加鐵人賽 單純自我挑戰 把最近學的用的還有遇到的問題都記錄下來 希望有緣路過有看到的讀者有得到點什麼
kubeflow寫完之後 還是會時不時分享一些東西 沒有意外的話應該會都是devops相關的 有興趣的歡迎追蹤~

前言:承接上篇

在上一篇文章,我們聊到為什麼機器學習需要一個像 Kubeflow 這樣的平台,以及它的核心價值:Portable、Scalable、Composable。這一篇,我們要更深入看看 Kubeflow 的「組成零件」,還有它的典型用法。


Kubeflow 的核心元件

Kubeflow 並不是單一服務,而是一組模組化的元件。常見的有:

  1. Kubeflow Pipelines (KFP)

    • 用來建立、執行、追蹤 ML 工作流。
    • 可以視覺化地看到每個步驟(例如:資料處理、訓練、驗證),並支援版本管理。
    • 適合將 ML 流程自動化,減少手動跑腳本的風險。
    • 在底層,Pipeline 的每個步驟其實都是一個 Kubernetes Job,因此它具備原生的彈性伸縮能力。
  2. Kubeflow Notebooks

    • 提供 JupyterLab 等互動式環境。
    • 資料科學家可以直接在 Kubeflow 中開 Notebook,不需要額外搭建。
    • 好處是環境跟叢集資源綁定,避免「我的電腦跑得動,線上卻不行」的情況。
    • 背後就是一個 Pod + Service:
apiVersion: v1
kind: Service
metadata:
  name: notebook-svc
spec:
  selector:
    app: notebook
  ports:
  - port: 80
    targetPort: 8888
  1. KFServing / KServe
    • 模型部署與推論的解決方案。
    • 支援多框架模型 (TensorFlow, PyTorch, XGBoost, ONNX)。
    • 可以自動水平擴展,甚至支援 GPU 資源管理。
    • 它透過 InferenceService CRD 來定義服務:
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: mnist-model
spec:
  predictor:
    tensorflow:
      storageUri: gs://models/mnist
  1. Katib
    • 自動化超參數調優 (Hyperparameter Tuning)。
    • 使用 Experiment CRD 來描述搜尋空間:
apiVersion: kubeflow.org/v1beta1
kind: Experiment
metadata:
  name: random-example
spec:
  objective:
    type: maximize
    goal: 0.99
    objectiveMetricName: accuracy
  algorithm:
    algorithmName: random
  1. Training Operators
    • 幫助在 Kubernetes 上跑分散式訓練。
    • 例如 TFJob(TensorFlow)、PyTorchJob、MXNetJob。
    • 例如一個 PyTorchJob:
apiVersion: kubeflow.org/v1
kind: PyTorchJob
metadata:
  name: pytorch-job
spec:
  pytorchReplicaSpecs:
    Master:
      replicas: 1
      template:
        spec:
          containers:
          - name: pytorch
            image: pytorch/pytorch:1.10.0
    Worker:
      replicas: 2
      template:
        spec:
          containers:
          - name: pytorch
            image: pytorch/pytorch:1.10.0

一個典型的 Kubeflow 工作流程

我們來想像一個真實場景:

  1. 資料科學家 在 Kubeflow Notebook 上進行實驗,快速嘗試不同的模型架構。
  2. 成功後,他們會把實驗流程轉換成 Kubeflow Pipelines,讓流程可以被自動化、重複執行。
  3. 模型訓練需要大量運算時,會透過 Training Operator 分散到多台 GPU 節點上。
  4. 調參過程可以交給 Katib,自動化探索最佳超參數。
  5. 訓練完成後,模型交給 KServe,自動包裝成 REST API,供應後端服務或應用程式使用。
  6. 透過 Kubeflow Dashboard,團隊可以清楚追蹤整個 lifecycle。

這樣一來,從研究到部署,團隊都在同一平台上協作,不再需要額外橋接環境。


為什麼要建構在 Kubernetes 上?

Kubeflow 選擇 Kubernetes 作為基礎,有幾個關鍵理由:

  • 資源管理:Kubernetes 天生適合管理 CPU/GPU/記憶體等資源。
  • 彈性伸縮:不論是單機測試還是大規模訓練,都能用同一套機制。
  • 可攜性:雲端、本地、混合環境都能一致部署。
  • 生態系整合:可以和 CI/CD、監控 (Prometheus, Grafana)、儲存系統無縫接軌。

使用場景

Kubeflow 常見的應用場景包括:

  • 企業內部 AI 平台:建立統一的 MLOps 平台,降低團隊溝通成本。
  • 學術研究:提供共享環境,讓學生和研究人員在雲端協作。
  • 產業應用:金融的風險模型、醫療的影像診斷、製造業的瑕疵檢測。

小結

如果說 Kubernetes 解決了「應用程式部署與運維」的問題,那麼 Kubeflow 就是解決「機器學習專案從實驗到生產」的問題。
它的核心價值在於:統一平台 + 模組化設計 + 建立在 Kubernetes 生態系之上

而這些價值其實具體落在一個個 Kubernetes Object (Pod、Service、Job、CRD) 上,這讓我們能透過 YAML manifest 更直觀理解 Kubeflow。

接下來的文章,我會進一步分享 Kubeflow 的安裝與基本操作,帶大家從實務出發,一步一步上手。

參考資料:


上一篇
Kubeflow 入門 (上):為什麼機器學習需要一個 MLOps 平台?
系列文
30 天工程師雜學之旅30
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言