Flagger بالعربي: نشر Canary آمن على Kubernetes بدون rollback يدوي

الـ Canary resource الكامل يبقى كده:

ركز في القيم دي: threshold: 5 معناه لو 5 فحوصات متتالية فشلت، يعمل rollback. stepWeight: 5 معناه يزيد 5% كل دقيقة. maxWeight: 50 يعني أقصى حد للـ canary هو 50% ثم promotion كامل مرة واحدة.

Trade-offs لازم تبقى عارفها قبل ما تستخدمه

الطريقة دي بتوفرلك rollback تلقائي في أقل من دقيقة مقابل 3 تكاليف صريحة:

• الوقت: الـ rollout هياخد 10 إلى 15 دقيقة بدل دقيقتين. لو عندك hotfix للإنتاج ومش قادر تستنى، الـ canary مش طريقك؛ استخدم kubectl rollout مباشر.
• الاعتماد على metrics: Flagger بيسأل Prometheus. لو الـ application مش بتصدّر success_rate وlatency بشكل صحيح، الفحص هيفشل أو هيمر غلط. لازم تبقى متأكد إن الـ sidecar أو الـ instrumentation شغال على كل النسختين.
• الموارد: أثناء الـ canary عندك primary كامل + canary بـ 2-3 pods إضافية. الافتراض إن عندك headroom 20% على الأقل في الـ cluster، أقل من كده الـ scheduler ممكن يفشل.

أرقام حقيقية من بيئة إنتاج

فريق استخدم Flagger على API بـ 12 ألف طلب في الدقيقة: متوسط مدة الـ canary analysis = 11 دقيقة، عدد الـ rollouts اللي اتلغت تلقائيًا = 4 من أصل 127 خلال شهرين (نسبة 3.1%). اللي اتلغى كان كله bugs حقيقية ظهرت بس تحت الضغط. المتوسط من ساعة ما المشكلة تظهر لحد ما الترافيك يرجع للـ primary = 52 ثانية. قبل Flagger، نفس النوع من المشاكل كان بياخد 8 إلى 14 دقيقة متوسطًا (وقت الملاحظة + وقت الـ rollback اليدوي).

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

Flagger مش حل لكل سيناريو. تجنّبه في الحالات دي:

• تطبيق stateful بطريقة معقدة (ديتابيز primary/replica بتعتمد على pod identity ثابت). canary deployment هيخلط state بين نسختين مختلفتين.
• traffic pattern موسمي جدًا وبتعمل deploys في ساعات هادية. مش هيكون عندك ترافيك كافي للـ analysis يديك إشارة موثوقة. اعمل deploy في أوقات ترافيك معقول، أو استخدم blue-green.
• الخدمة بتستقبل أقل من 10 طلبات/ثانية. الإحصائيات مش هتبقى ذات دلالة؛ اشتغل بـ blue-green أو manual verification مع smoke tests.
• فريقك لسه ما عندوش observability stack ناضج. متستعجلش Flagger قبل ما يكون عندك Prometheus موثوق ومتابع.

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

افتح أي خدمة Kubernetes عندك فيها أكتر من pod واحد وبتستقبل ≥ 50 طلب/دقيقة. ثبّت Flagger بالأمر اللي فوق، عرّف Canary resource بسيط بـ stepWeight: 10 وthreshold: 5. اعمل deploy تجريبي فيه bug متعمّد (مثلًا sleep 3s في endpoint)، وشوف Flagger بيرجّع لوحده. لو نجح على خدمة واحدة، عمّم على الباقي بـ policy موحدة.

المصادر

• Flagger Metrics Analysis - Official Docs
• Flagger Deployment Strategies
• fluxcd/flagger on GitHub
• Flagger page on Flux CD
• Istio Canary Deployments Tutorial
• Prometheus Operator Canary Analysis