นี่คือเอกสารอ้างอิงฉบับยาว สำหรับสรุปห้านาที ดูบล็อกคู่ขนาน
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 ของ pipeline | Kubeflow Pipelines 2.x | DAG ของสเต็ปแบบคอนเทนเนอร์; ติดตาม runs |
| Distributed training | Kubeflow Trainer (TrainJob) | PyTorch / JAX / XGBoost / DeepSpeed jobs |
| คิว GPU | Kueue (+ optional Volcano) | แบ่งปันอย่างเป็นธรรม, gang scheduling, โควตา |
| Model serving | KServe | InferenceService ที่สเกลอัตโนมัติ; แบ่ง canary |
| Autoscaling | KEDA + HPA | สเกลตามอีเวนต์ รวม scale-to-zero |
| Delivery & rollback | Argo CD | Git เป็นแหล่งความจริงของ manifests |
| Observability | Prometheus / 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
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 ที่คอมไพล์แล้วเป็นทรัพยากรคลัสเตอร์ได้ เวิร์กโฟลว์กลายเป็น:
- เขียน pipeline ด้วย Python (KFP SDK)
- คอมไพล์เป็น YAML
- คอมมิตไปที่
ml-apps/pipelines/... - Argo CD ซิงก์; เรียก runs ผ่าน UI, API หรือ CronWorkflow ที่เก็บใน Git เช่นกัน
ตั้งขีดจำกัด CPU, หน่วยความจำ และ GPU บนสเต็ปเสมอ สเต็ป training ที่ไม่มีขอบเขตจะรบกวนคลัสเตอร์ multi-tenant เร็วกว่าโมเดลแย่ใด ๆ
7. การโปรโมตโมเดล: registry → Git → Argo CD
นี่คือจุดส่งต่อสำคัญ:
- รัน training จบ; เมตริก evaluation ถึงเกณฑ์
- Model Registry บันทึกเวอร์ชันใหม่พร้อม URI + เมทาดาทา (accuracy, fairness, signer)
- ระบบอัตโนมัติ (หรือคน) เปิด PR ที่อัปเดต
storageUri(และแท็กอิมเมจ / runtime) ใน serving overlay - หลัง 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
- ติดตั้ง Argo CD; สร้างโปรเจกต์
ml-platformและml-apps - ติดตั้ง Kubeflow แบบ GitOps ด้วย sync waves; ตรวจ UI ของ KFP และ CRDs ของ KServe
- ตั้ง object storage + Model Registry; บันทึกข้อตกลง URI
- ออนบอร์ด pipeline เส้นทางทองคำหนึ่งเส้น (train → evaluate → register)
- เพิ่ม InferenceService หนึ่งตัวภายใต้ Argo CD โดยเริ่มจาก staging overlay
- เปิดการโปรโมต canary; ซ้อม
git revert - เพิ่มโควตา Kueue และแดชบอร์ด GPU FinOps ก่อน rollout หลายทีม
12. แพตเทิร์นที่ควรเลี่ยง
- คอมมิตไฟล์น้ำหนัก 4 GB เข้า Git LFS “เพื่อความสะดวก”
- ปล่อยให้ notebooks
kubectl applyInferenceServices ในโปรดักชัน - 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