Kubeflow + Argo CD: GitOps MLOps على Kubernetes

هذا هو المرجع الطويل. لمراجعة في خمس دقائق، انظر المدونة المرافقة.

1. مقدمة: MLOps يحتاج مستويي تحكم

يفشل التعلم الآلي على Kubernetes بطريقتين متوقعتين. تعامل الفرق التدريب إما كمجموعة Jobs مخصصة بلا lineage، أو الـ serving كـ kubectl apply لمرة واحدة بلا مسار تدقيق. يعالج Kubeflow و Argo CD نصفَي المشكلة المتقابلين.

Kubeflow هو مستوى التحكم لـ ML: pipelines وتدريب موزّع وتتبع تجارب و model registry و KServe. Argo CD هو مستوى التحكم للتسليم: GitOps قائم على السحب بحيث تطابق حالة العنقود Git — بما في ذلك منصة Kubeflow نفسها وكل InferenceService إنتاجي.

هذه المقالة دليل معماري عملي لمهندسي المنصة و MLOps. تفترض ألفة بـ Kubernetes وفهمًا أساسيًا لـ GitOps (انظر مقالنا السابق عن التسليم المستمر مع Argo CD & Flux). نركز هنا على كيفية تكامل النظامين لأحمال ML في 2026.

2. خريطة MLOps على Kubernetes لعام 2026

ما زال Argo Workflows يظهر خلف الكواليس لبعض backends الـ pipelines، لكن فكّر بـ Kubeflow Pipelines IR / v2 للتأليف و Argo CD للتسليم المستمر لموارد Kubernetes — ولا تخلط بين «Argo Workflows» و«Argo CD».

3. ملكية واضحة: ما يفعله Kubeflow مقابل ما يفعله Argo CD

3.1 يملكه Kubeflow

• تأليف وتشغيل DAGs للتدريب / ETL / التقييم
• دورة حياة وظائف GPU وبيانات وصفية للتجارب
• تسجيل إصدارات النماذج و lineage في Model Registry
• تعريف كيف يمكن تقديم النموذج (runtime والموارد) — غالبًا عبر manifests مولَّدة

3.2 يملكه Argo CD

• تثبيت وترقية مكوّنات Kubeflow (منصة GitOps)
• مزامنة تعريفات pipelines و CronWorkflows التي تبدأ التدريب
• ترقية تغييرات InferenceService عبر البيئات
• استرجاع فوري وقابل للتدقيق عبر سجل Git

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 منفصلة. يفتح علماء البيانات PRs ضد ml-apps؛ يملك مهندسو المنصة ml-platform. استخدم Argo CD Projects + RBAC حتى لا يعيد PR سيئ لـ pipeline كتابة مستوى تحكم Kubeflow.

5. إدارة Kubeflow باستخدام Argo CD

تثبيتات Kubeflow اليدوية هشة: كثير من CRDs وقيود ترتيب ومسارات ترقية. عامل المنصة كـ Application في Argo CD (أو ApplicationSet) مع:

• Sync waves — شهادات وتخزين و MySQL/Postgres (أو قاعدة مُدارة) وبيانات اعتماد MinIO/S3 ثم KFP / Trainer / KServe
• Health checks — انتظر CRDs و webhooks قبل مزامنة التطبيقات التابعة
• خدمات مُدارة في الإنتاج — استبدل MySQL/MinIO داخل العنقود بـ Cloud SQL/RDS و S3 عندما تتجاوز العرض التوضيحي الشامل

مسودة 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 الأصلية، يمكن إدارة pipelines المُجمَّعة كموارد عنقود. يصبح المسار:

1. تأليف الـ pipeline في Python (KFP SDK)
2. تجميع إلى YAML
3. الالتزام إلى ml-apps/pipelines/...
4. يزامن Argo CD؛ تُشغَّل الـ runs عبر UI أو API أو CronWorkflow المخزَّن أيضًا في Git

عيّن دائمًا حدود CPU والذاكرة و GPU على الخطوات. خطوات تدريب بلا حدود ستُعطّل العناقيد متعددة المستأجرين أسرع من أي نموذج سيئ.

7. ترقية النموذج: registry → Git → Argo CD

هذا هو التسليم الحرج:

1. ينتهي تشغيل التدريب؛ تستوفي مقاييس التقييم العتبات.
2. يسجّل Model Registry إصدارًا جديدًا مع URI + بيانات وصفية (accuracy و fairness و signer).
3. تفتح الأتمتة (أو إنسان) PR يحدّث storageUri (وسم الصورة / runtime) في طبقة serving.
4. بعد الدمج، ينشر Argo CD عبر KServe. فضّل canary: عيّن canaryTrafficPercent إلى 10٪، راقب معدل الخطأ وزمن الاستجابة، ثم رقِّ.

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

الاسترجاع ليس نقرة لوحة تحكم — إنه git revert لتغيير URI ذلك. يعيد Argo CD العنقود إلى الحالة المرغوبة السابقة.

8. وحدات GPU والحصص و FinOps

• استخدم Kueue حتى تنتظر TrainJobs سعة GPU عادلة بدل الفشل أو الاشتراك الزائد.
• افصل node pools للتدريب مقابل الاستدلال الحساس لزمن الاستجابة عند الإمكان.
• تتبّع التكلفة لكل تشغيل pipeline (GPU-seconds × السعر). لا يُلغي GitOps الـ FinOps — بل يجعل الإنفاق منسوبًا إلى commit وإصدار نموذج.
• لـ MIG / time-slicing على NVIDIA، وثّق استراتيجية التقسيم في مستودع المنصة حتى تبقى إعدادات DevicePlugin المُدارة بـ Argo CD متسقة.

9. الأمن وتعدد المستأجرين

• تعزل Kubeflow Profiles الفرق؛ اربطها بـ Argo CD Projects.
• خزّن بيانات اعتماد السحابة في Sealed Secrets / External Secrets — لا ConfigMaps صريحة في Git أبدًا.
• اطلب بوابات بيانات وصفية للـ registry (مثل fairness_score و sign_off_user) قبل أن يفتح بوت الترقية PR إنتاجيًا.
• سياسات الشبكة: لا تحتاج وظائف التدريب إلى egress غير مقيّد؛ تحتاج pods الـ serving فقط إلى تخزين النماذج والعملاء.

10. المراقبة أبعد من مقاييس الـ pods

Prometheus على استخدام GPU ضروري لكنه غير كافٍ. اربط:

• تنبيهات فشل pipeline (حالة التشغيل، لا Deployment CrashLoop فقط)
• SLO للـ serving: زمن الاستجابة ومعدل الخطأ والتشبّع
• مراقبات انحراف البيانات/النموذج التي يمكنها فتح تذكرة أو إعادة تشغيل CronWorkflow للتدريب

عند إطلاق الانحراف، يجب أن يبقى مسار الإصلاح GitOps: تشغيل جديد → URI جديد → PR → مزامنة Argo CD — لا استبدال يدوي على العقدة.

11. قائمة تحقق النشر

1. ثبّت Argo CD؛ أنشئ مشروعي ml-platform و ml-apps.
2. ثبّت Kubeflow بـ GitOps مع sync waves؛ تحقّق من واجهة KFP و CRDs الخاصة بـ KServe.
3. أنشئ object storage + Model Registry؛ وثّق اصطلاحات URI.
4. أدخل مسار pipeline ذهبيًا واحدًا (train → evaluate → register).
5. أضف InferenceService واحدًا تحت Argo CD مع طبقة staging أولًا.
6. فعّل ترقية canary؛ مارس تمرين git revert.
7. أضف حصص Kueue ولوحات GPU FinOps قبل النشر متعدد الفرق.

12. أنماط مضادة

• الالتزام بملفات أوزان بحجم 4 غيغابايت إلى Git LFS «للراحة»
• السماح لـ notebooks بتنفيذ kubectl apply على InferenceServices الإنتاجية
• Application واحدة في Argo CD تمزج المنصة وكل pipelines الفرق (نصف قطر الانفجار)
• لا حدود موارد على خطوات التدريب
• الخلط بين Argo Workflows (التنفيذ) و Argo CD (مزامنة الحالة المرغوبة)
• تجاوز staging — الترقية مباشرة من تجربة على الحاسوب إلى حركة إنتاج

13. متى لا تستخدم هذه الحزمة

الشركات الصغيرة والمتوسطة التي تشغّل LLM خاصًا واحدًا على workstation (انظر AI SME Packages) لا تحتاج Kubeflow + Argo CD في اليوم الأول. أدخل هذه المعمارية عندما يكون لديك نماذج متعددة ومستخدمون متزامنون لـ GPU وضبط تغييرات منظَّم أو عدة بيئات يجب أن تبقى متطابقة.

14. خاتمة

Kubeflow و Argo CD متكاملان. يجعل Kubeflow عمل ML قابلًا للتشغيل وإعادة الإنتاج على Kubernetes. يجعل Argo CD بنية ML و serving النماذج تصريحية وقابلة للتدقيق وعكسية. النمط الرابح بسيط: القطع الأثرية في object storage والمؤشرات و YAML في Git والتدريب في Kubeflow والتسليم والاسترجاع في Argo CD.

المدونة المرافقة هي الملخص القابل للمشاركة؛ هذه المقالة مرجع لمراجعات تصميم المنصة.

نُشر بواسطة Workstation (workstation.co.uk).

لقطة SEO لهذه المقالة

• عنوان SEO: Kubeflow + Argo CD: GitOps MLOps على Kubernetes
• Meta description: كيف تجمع Kubeflow Pipelines و Model Registry و KServe مع Argo CD GitOps لـ ML قابل للتدريب والتدقيق وآمن عند الاسترجاع على 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 للمنصة مقابل التطبيقات وبوابات الترقية و canary serving وحصص GPU والاسترجاع عبر git revert. من هندسة Workstation.