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: