Argo CD Self-Heal: امنع Drift في Kubernetes

هتخرج من المقال بإعداد عملي يخلي Argo CD يكتشف أي Drift في Kubernetes ويرجع الكلاستر للحالة الموجودة في Git بدل ما تعتمد على مراجعة يدوية متأخرة.

مستوى القارئ: متوسط

المشكلة باختصار

الـ Drift معناه إن الحالة الفعلية في الكلاستر بقت مختلفة عن الحالة المطلوبة في Git. مثال بسيط: حد عدّل عدد replicas يدويًا بـ kubectl scale عشان يلحق ضغط مفاجئ، وبعد ساعة محدش فاكر إن التعديل حصل. Git بيقول 3 replicas، والكلاستر شغال على 8. اللي بيحصل فعلاً إنك بتفقد مصدر الحقيقة.

في فريق عنده 12 خدمة على Kubernetes وحوالي 50K زائر يوميًا، تعديل يدوي واحد على production ممكن يسبب incident صعب تتبعه. المشكلة مش إن kubectl سيئ. المشكلة إن التغيير خرج من المسار اللي عليه مراجعة، تاريخ، وrollback واضح.

الفكرة الأساسية: Git هو المصدر، Argo CD هو المراقب

ركز: GitOps مش معناه إن كل حاجة بقت آلية وخلاص. معناه إن الحالة المطلوبة موجودة في Git، وأداة زي Argo CD تقارنها بالحالة الحية داخل Kubernetes. لما الفرق يظهر، التطبيق يتحول إلى OutOfSync. هنا تبدأ تختار: هل عايز Argo CD يكتفي بالتنبيه، ولا يرجّع الحالة تلقائيًا؟

طبقًا لتوثيق Argo CD، الـ automated sync يقدر يزامن التطبيق لما يكتشف فرقًا بين manifests في Git والحالة الحية. وميزة selfHeal تحديدًا تخلي التغييرات اليدوية في الكلاستر تتحرك ناحية الحالة المطلوبة مرة أخرى.

الإعداد العملي

الافتراض إن عندك Argo CD شغال، والتطبيق متعرف كـ Application. أفضل طريقة تبدأ بيها هي تفعيل automated sync مع prune وselfHeal، لكن على خدمة غير حرجة الأول.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: payments-api
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/example/platform-manifests.git
    targetRevision: main
    path: apps/payments-api
  destination:
    server: https://kubernetes.default.svc
    namespace: payments
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

بعد النشر، جرّب Drift متعمد على بيئة staging:

kubectl -n payments scale deployment/payments-api --replicas=8
argocd app get payments-api

# بعد دورة reconcile، لازم تشوف التطبيق رجع للحالة الموجودة في Git
kubectl -n payments get deploy payments-api -o jsonpath='{.spec.replicas}'

لو Git بيقول replicas = 3، المتوقع إن Argo CD يرجعها إلى 3. في الإعدادات الافتراضية الحديثة، زمن المصالحة غالبًا يدور حول دقيقتين مع jitter قد يصل للإجمالي حوالي 3 دقائق. لو selfHeal شغال، فيه محاولات أقرب لإصلاح الانحراف حسب إعداد controller.

الـ trade-off هنا

المكسب واضح: أقل Drift يدوي، وproduction أقرب دائمًا لما تمت مراجعته في Git. في فريق متوسط، ده ممكن يقلل وقت تشخيص incident من 30 دقيقة إلى 10 دقائق لأنك بتبدأ من سؤال واحد: هل Git مطابق للكلاستر؟

الثمن إنك لازم تشدد مراجعة Pull Requests وتستخدم sync windows للخدمات الحساسة. لو حد عمل hotfix يدوي على production، Argo CD ممكن يرجعه قبل ما الفريق يوثّقه في Git. الطريقة دي بتفشل لما ثقافة الفريق لسه مبنية على تعديلات مباشرة في الكلاستر بدون process واضح.

كمان prune: true قوي. هو يمسح الموارد التي لم تعد موجودة في Git. بتكسب تنظيف تلقائي، وتخسر هامش الأمان لو repo اتحدث بالغلط. لذلك ابدأ بـ staging، ثم خدمة production واحدة، وبعدها وسّع التطبيق.

متى لا تستخدم هذه الطريقة

لا تستخدم selfHeal مباشرة على كل production لو عندك controllers أخرى بتعدل نفس الموارد بشكل طبيعي. مثال: HPA يعدل replicas، أو webhook يضيف حقول runtime، أو operator يدير CRDs بتتغير باستمرار. في الحالات دي استخدم ignoreDifferences أو راجع تصميم الموارد قبل التفعيل.

لا تستخدمها أيضًا لو فريقك لسه بيعمل emergency fixes يدويًا بدون تحويلها إلى Git خلال دقائق. هنا self-heal هيبان كأنه بيكسر شغل الناس، لكنه في الحقيقة بيكشف إن مصدر الحقيقة غير محترم.

مصادر اعتمد عليها المقال

• توثيق Argo CD الرسمي لسياسة Automated Sync وSelf-Healing.
• توثيق Argo CD الرسمي لتخصيص Diffing وignoreDifferences.
• توثيق Compare Options في Argo CD للتعامل مع الموارد الزائدة.

الخطوة التالية

افتح تطبيق staging واحد في Argo CD، فعّل selfHeal: true، واعمل Drift متعمد بـ kubectl scale. لو رجع خلال 3 دقائق تقريبًا، وثّق القرار وابدأ بخدمة production واحدة فقط.