Workstation Logo
โซลูชัน AI
เวิร์กสเตชัน AIAI SME PackagesAI ส่วนตัวคลัสเตอร์ GPUEdge AIแล็บ AI องค์กรAI ตามอุตสาหกรรมWSL ProxyRing Promoter
ผลิตภัณฑ์
AI SME PackagesCRMการตลาดOpenAI AgentsWSL ProxyRing Promoter
เกี่ยวกับเรา
พาร์ทเนอร์เรื่องราวลูกค้า
บทความ
เอกสาร
บล็อก
ติดต่อเราLogin
Workstation

AI workstations, AI Multi Agentic Software, GPU infrastructure, and intelligent agent solutions for modern businesses.

UK: 77-79 Marlowes, Hemel Hempstead HP1 1LF

Brussels: Workstation SRL, Rue Vanderkindere 34, 1180 Uccle
BE 0751.518.683

AI Solutions

AI WorkstationsAI SME PackagesPrivate AIGPU ClustersEdge AIEnterprise AIWSL ProxyRing Promoter

Resources

ArticlesDocumentationBlogSearch

Company

About UsPartnersContact

© 2026 Workstation AI. All rights reserved.

PrivacyCookies
Home / Articles / Technology
MLOpsKubernetesDevOps

Kubeflow + Argo CD: GitOps MLOps บน Kubernetes

แผนที่สถาปัตยกรรมสำหรับ Kubeflow Pipelines, Trainer, KServe และ Kueue กับ Argo CD GitOps: โครง Git, sync waves, ประตูโปรโมต, canary serving, GPU FinOps และเช็คลิสต์ rollout

July 20, 2026Technology5 min read

นี่คือเอกสารอ้างอิงฉบับยาว สำหรับสรุปห้านาที ดูบล็อกคู่ขนาน

Kubeflow และ Argo CD GitOps MLOps บน Kubernetes

1. บทนำ: MLOps ต้องการสอง control planes

แมชชีนเลิร์นนิงบน Kubernetes ล้มเหลวได้สองแบบที่คาดได้ ทีมมักจัดการ training เป็น Jobs แบบ ad-hoc ที่ไม่มี lineage หรือจัดการ serving เป็น kubectl apply ครั้งเดียวโดยไม่มี audit trail Kubeflow และ Argo CD แก้ปัญหาคนละครึ่งของปัญหานี้

Kubeflow คือ ML control plane: pipelines, distributed training, experiment tracking, model registry และ KServe ส่วน Argo CD คือ delivery control plane: GitOps แบบ pull เพื่อให้สถานะคลัสเตอร์ตรงกับ Git — รวมแพลตฟอร์ม Kubeflow เองและทุก InferenceService ในโปรดักชัน

บทความนี้เป็นคู่มือสถาปัตยกรรมเชิงปฏิบัติสำหรับวิศวกรแพลตฟอร์มและ MLOps สมมติว่าคุ้นเคย Kubernetes และเข้าใจ GitOps พื้นฐานแล้ว (ดูโพสต์ continuous delivery ของ Argo CD & Fluxก่อนหน้า) ที่นี่เราโฟกัสว่าสองระบบเข้ากันอย่างไรสำหรับเวิร์กโหลด ML ในปี 2026

2. แผนที่ Kubernetes MLOps ปี 2026

ขั้นตอนวงจรชีวิต เครื่องมือ บทบาท
การจัด orchestration ของ pipelineKubeflow Pipelines 2.xDAG ของสเต็ปแบบคอนเทนเนอร์; ติดตาม runs
Distributed trainingKubeflow Trainer (TrainJob)PyTorch / JAX / XGBoost / DeepSpeed jobs
คิว GPUKueue (+ optional Volcano)แบ่งปันอย่างเป็นธรรม, gang scheduling, โควตา
Model servingKServeInferenceService ที่สเกลอัตโนมัติ; แบ่ง canary
AutoscalingKEDA + HPAสเกลตามอีเวนต์ รวม scale-to-zero
Delivery & rollbackArgo CDGit เป็นแหล่งความจริงของ manifests
ObservabilityPrometheus / Grafana / drift toolsสัญญาณ infra + คุณภาพโมเดล

Argo Workflows ยังปรากฏใต้ฝากระโปรงของบาง pipeline backends แต่ควรมองในแง่ Kubeflow Pipelines IR / v2 สำหรับการเขียน และ Argo CD สำหรับ continuous delivery ของทรัพยากร Kubernetes — อย่าสับสน “Argo Workflows” กับ “Argo CD”

3. ความเป็นเจ้าของที่ชัด: Kubeflow ทำอะไร vs Argo CD ทำอะไร

3.1 Kubeflow เป็นเจ้าของ

  • เขียนและรัน DAGs ของ training / ETL / evaluation
  • วงจรชีวิตจ็อบ GPU และเมทาดาทาของทดลอง
  • ลงทะเบียนเวอร์ชันโมเดลและ lineage ใน Model Registry
  • กำหนดว่าโมเดลอาจถูก serve อย่างไร (runtime, ทรัพยากร) — มักผ่าน manifests ที่สร้างอัตโนมัติ

3.2 Argo CD เป็นเจ้าของ

  • ติดตั้งและอัปเกรดคอมโพเนนต์ Kubeflow (แพลตฟอร์ม GitOps)
  • ซิงก์คำจำกัดความ pipeline และ CronWorkflows ที่เริ่ม training
  • โปรโมตการเปลี่ยนแปลง InferenceService ข้ามสภาพแวดล้อม
  • rollback ทันทีและตรวจสอบได้ผ่านประวัติ Git
กฎเข้มงวด ไบนารีขนาดใหญ่ (datasets, checkpoints, น้ำหนัก ONNX/SafeTensors) ห้ามใส่ใน Git เก็บไว้ใน S3/GCS/MinIO/PVC Git เก็บพอยน์เตอร์ (storageUri, digest, tags) และ YAML ของ Kubernetes ที่ Argo CD นำไปใช้

4. โครง Git ที่แนะนำ

ml-platform/                 # Argo CD App: install Kubeflow once
  overlays/
    staging/
    production/
ml-apps/                     # Argo CD App-of-Apps or projects
  pipelines/
    fraud-detector/
  serving/
    fraud-detector/
      base/inferenceservice.yaml
      overlays/
        staging/
        production/
  components/                # reusable KFP components (OCI or YAML)

แยกการซิงก์ platform กับ application นักวิทยาศาสตร์ข้อมูลเปิด PR กับ ml-apps; วิศวกรแพลตฟอร์มเป็นเจ้าของ ml-platform ใช้ Argo CD Projects + RBAC เพื่อไม่ให้ PR pipeline ที่ผิดพลาดเขียนทับ control plane ของ Kubeflow

5. จัดการ Kubeflow ด้วย Argo CD

การติดตั้ง Kubeflow แบบมือเปราะบาง: CRD จำนวนมาก ข้อจำกัดลำดับ และเส้นทางอัปเกรด ถือแพลตฟอร์มเป็น Argo CD Application (หรือ ApplicationSet) พร้อม:

  • Sync waves — ใบรับรอง, storage, MySQL/Postgres (หรือ DB แบบ managed), ข้อมูลรับรอง MinIO/S3 แล้วจึง KFP / Trainer / KServe
  • Health checks — รอ CRDs และ webhooks ก่อนซิงก์แอปที่ขึ้นต่อกัน
  • บริการ managed ในโปรดักชัน — แทนที่ MySQL/MinIO ในคลัสเตอร์ด้วย Cloud SQL/RDS และ S3 เมื่อโตเกินเดโมแบบ all-in-one

ร่าง Application ตัวอย่าง (เชิงอธิบาย):

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: kubeflow-platform
  namespace: argocd
  annotations:
    argocd.argoproj.io/sync-wave: "0"
spec:
  project: ml-platform
  source:
    repoURL: https://git.example.com/org/ml-platform.git
    targetRevision: main
    path: overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: kubeflow
  syncPolicy:
    automated:
      prune: false
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
      - ServerSideApply=true

6. Pipelines ในฐานะทรัพยากร GitOps

ด้วย Kubeflow Pipelines v2 / Kubernetes-native APIs สามารถจัดการ pipelines ที่คอมไพล์แล้วเป็นทรัพยากรคลัสเตอร์ได้ เวิร์กโฟลว์กลายเป็น:

  1. เขียน pipeline ด้วย Python (KFP SDK)
  2. คอมไพล์เป็น YAML
  3. คอมมิตไปที่ ml-apps/pipelines/...
  4. Argo CD ซิงก์; เรียก runs ผ่าน UI, API หรือ CronWorkflow ที่เก็บใน Git เช่นกัน

ตั้งขีดจำกัด CPU, หน่วยความจำ และ GPU บนสเต็ปเสมอ สเต็ป training ที่ไม่มีขอบเขตจะรบกวนคลัสเตอร์ multi-tenant เร็วกว่าโมเดลแย่ใด ๆ

7. การโปรโมตโมเดล: registry → Git → Argo CD

นี่คือจุดส่งต่อสำคัญ:

  1. รัน training จบ; เมตริก evaluation ถึงเกณฑ์
  2. Model Registry บันทึกเวอร์ชันใหม่พร้อม URI + เมทาดาทา (accuracy, fairness, signer)
  3. ระบบอัตโนมัติ (หรือคน) เปิด PR ที่อัปเดต storageUri (และแท็กอิมเมจ / runtime) ใน serving overlay
  4. หลัง merge Argo CD โรลเอาต์ KServe ควรใช้ canary: ตั้ง canaryTrafficPercent เป็น 10% ดู error rate และ latency แล้วค่อยโปรโมต
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: fraud-detector
spec:
  predictor:
    model:
      modelFormat:
        name: sklearn
      storageUri: s3://models/fraud/v1.4.2/
      resources:
        requests:
          cpu: "1"
          memory: 2Gi
        limits:
          cpu: "2"
          memory: 4Gi

rollback ไม่ใช่การคลิกแดชบอร์ด — คือ git revert ของการเปลี่ยน URI นั้น Argo CD จะคืนคลัสเตอร์สู่ desired state ก่อนหน้า

8. GPUs, โควตา และ FinOps

  • ใช้ Kueue ให้ TrainJobs รอความจุ GPU อย่างเป็นธรรม แทนที่จะล้มเหลวหรือ oversubscribe
  • แยก node pools สำหรับ training กับ inference ที่อ่อนไหวต่อ latency เมื่อทำได้
  • ติดตามต้นทุนต่อ pipeline run (GPU-seconds × อัตรา) GitOps ไม่ได้ลบ FinOps — มันทำให้การใช้จ่ายโยงกับ commit และเวอร์ชันโมเดลได้
  • สำหรับ MIG / time-slicing บน NVIDIA บันทึกกลยุทธ์พาร์ติชันในรีโปแพลตฟอร์มเพื่อให้คอนฟิก DevicePlugin ที่ Argo CD จัดการคงความสอดคล้อง

9. ความปลอดภัยและ multi-tenancy

  • Kubeflow Profiles แยกทีม; แมปไปยัง Argo CD Projects
  • เก็บข้อมูลรับรองคลาวด์ใน Sealed Secrets / External Secrets — ห้าม ConfigMaps แบบ plain ใน Git
  • บังคับเกตเมทาดาทาของ registry (เช่น fairness_score, sign_off_user) ก่อนที่บอทโปรโมตจะเปิด PR โปรดักชันได้
  • Network policies: จ็อบ training ไม่ควรต้องการ egress ไม่จำกัด; serving pods ต้องการเพียงที่เก็บโมเดลและไคลเอนต์

10. Observability นอกเหนือเมตริกของ pod

Prometheus เรื่องการใช้ GPU จำเป็นแต่ไม่พอ เชื่อม:

  • การแจ้งเตือน pipeline ล้มเหลว (สถานะ run ไม่ใช่แค่ Deployment CrashLoop)
  • Serving SLO: latency, error rate, saturation
  • มอนิเตอร์ drift ของข้อมูล/โมเดลที่เปิดทิกเก็ตหรือเรียก training CronWorkflow ใหม่ได้

เมื่อ drift ทำงาน เส้นทางแก้ไขยังต้องเป็น GitOps: รันใหม่ → URI ใหม่ → PR → ซิงก์ Argo CD — ไม่ใช่เขียนทับบนโหนดด้วยมือ

11. เช็คลิสต์ rollout

  1. ติดตั้ง Argo CD; สร้างโปรเจกต์ ml-platform และ ml-apps
  2. ติดตั้ง Kubeflow แบบ GitOps ด้วย sync waves; ตรวจ UI ของ KFP และ CRDs ของ KServe
  3. ตั้ง object storage + Model Registry; บันทึกข้อตกลง URI
  4. ออนบอร์ด pipeline เส้นทางทองคำหนึ่งเส้น (train → evaluate → register)
  5. เพิ่ม InferenceService หนึ่งตัวภายใต้ Argo CD โดยเริ่มจาก staging overlay
  6. เปิดการโปรโมต canary; ซ้อม git revert
  7. เพิ่มโควตา Kueue และแดชบอร์ด GPU FinOps ก่อน rollout หลายทีม

12. แพตเทิร์นที่ควรเลี่ยง

  • คอมมิตไฟล์น้ำหนัก 4 GB เข้า Git LFS “เพื่อความสะดวก”
  • ปล่อยให้ notebooks kubectl apply InferenceServices ในโปรดักชัน
  • Argo CD Application เดียวที่ผสมแพลตฟอร์มกับทุก pipeline ของทีม (blast radius)
  • ไม่มี resource limits บนสเต็ป training
  • สับสน Argo Workflows (การรัน) กับ Argo CD (ซิงก์สถานะที่ต้องการ)
  • ข้าม staging — โปรโมตตรงจากทดลองบนแล็ปท็อปสู่ทราฟฟิกโปรดักชัน

13. เมื่อใดไม่ควรใช้สแต็กนี้

SME ที่รัน LLM ส่วนตัวตัวเดียวบน workstation (ดูAI SME Packagesของเรา) ไม่จำเป็นต้องมี Kubeflow + Argo CD ในวันที่หนึ่ง แนะนำสถาปัตยกรรมนี้เมื่อมีหลายโมเดล ผู้ใช้ GPU พร้อมกัน การควบคุมการเปลี่ยนแปลงตามกฎระเบียบ หรือหลายสภาพแวดล้อมที่ต้องเหมือนกัน

14. บทสรุป

Kubeflow และ Argo CD เสริมกัน Kubeflow ทำให้งาน ML รันได้และทำซ้ำได้ บน Kubernetes Argo CD ทำให้โครงสร้างพื้นฐาน ML และ model serving เป็น declarative ตรวจสอบได้ และย้อนกลับได้ แพตเทิร์นที่ชนะเรียบง่าย: อาร์ติแฟกต์ใน object storage พอยน์เตอร์และ YAML ใน Git ฝึกใน Kubeflow ส่งมอบและ rollback ใน Argo CD

บล็อกคู่ขนานคือสรุปที่แชร์ได้; บทความนี้คือเอกสารอ้างอิงสำหรับ platform design reviews

เผยแพร่โดย Workstation (workstation.co.uk)


สแนปชอต SEO ของบทความนี้

  • ชื่อ SEO: Kubeflow + Argo CD: GitOps MLOps บน Kubernetes
  • Meta description: วิธีรวม Kubeflow Pipelines, Model Registry และ KServe กับ Argo CD GitOps สำหรับ ML ที่ฝึกได้ ตรวจสอบได้ และปลอดภัยเมื่อ rollback บน Kubernetes
  • คีย์เวิร์ดหลัก: Kubeflow Argo CD, GitOps MLOps, KServe InferenceService, Kubeflow Pipelines GitOps, ML on Kubernetes
  • Twitter / X: Kubeflow ฝึก Argo CD ส่งมอบ โมเดลอยู่ใน object storage; Git เก็บ URIs คู่มือ GitOps MLOps ฉบับเต็มจาก Workstation
  • LinkedIn: เราเผยแพร่การเจาะลึกเรื่องการจับคู่ Kubeflow กับ Argo CD: โครง Git แบบ platform vs apps ประตูโปรโมต canary serving โควตา GPU และ rollback ผ่าน git revert จากทีมวิศวกรรม Workstation
Share this article

More in Technology

Ring Promoter: CI/CD สมัยใหม่ที่คุณไม่ควรพลาดสำหรับการปรับใช้ที่ขับเคลื่อนด้วย AI

Ring Promoter: CI/CD สมัยใหม่ที่คุณไม่ควรพลาดสำหรับการปรับใช้ที่ขับเคลื่อนด้วย AI

ข้อมูลสรุปทางเทคนิค: ส่วนควบคุมการเลื่อนระดับริง, ความสมบูรณ์ที่ตรวจสอบเวอร์ชัน, โปรแกรมปรับใช้ kubectl / GitHub Actions / k8sjob และเวิร์กโฟลว์การปรับใช้ที่ขับเคลื่อนด้วย AI

Read more
พร็อกซี Workstation WSL: เกตเวย์ API, CDN และ Agent Edge

พร็อกซี Workstation WSL: เกตเวย์ API, CDN และ Agent Edge

ข้อมูลสรุปด้านเทคนิค: เกตเวย์ฮอตเส้นทาง OpenResty, แคช CDN, WAF, POPs/DNS, การจัดการ MCP และแผนงาน Agent Gateway / MCP Gateway

Read more
KubePilot: CoPilot, Pilot & AutoPilot สำหรับเหตุการณ์ Kubernetes ที่เร็วขึ้น

KubePilot: CoPilot, Pilot & AutoPilot สำหรับเหตุการณ์ Kubernetes ที่เร็วขึ้น

บทสรุปทางเทคนิค: วงจรเหตุการณ์สามโหมด, การติดตั้ง (แหล่งที่มา/พวงมาลัย/นักเทียบท่า/iOS), รางนิรภัย AutoPilot, MCP, Runbooks และรายการตรวจสอบการผลิต

Read more