Flagger: progressive delivery بدل rolling update الأعمى

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

الـ rolling update العادي في Kubernetes بيحوّل الترافيك بالكامل بمجرد ما الـ pod يبقى ready. لو في bug بيظهر تحت ضغط حقيقي بس، هتكتشفه وأنت بتستقبل 100% من المستخدمين على النسخة المعطوبة. الـ rollback اليدوي بياخد في المتوسط 6 إلى 12 دقيقة من ساعة ما حد يلاحظ لحد ما الـ kubectl rollout undo يخلّص.

Flagger بيحل ده بطريقة اسمها progressive delivery. يدخّل 5% من الترافيك على النسخة الجديدة، يسأل Prometheus كل دقيقة عن success rate وlatency، لو الأرقام تمام يزوّد لـ 10% بعدين 20% وهكذا. لو وقع تحت الـ threshold، يرجّع الترافيك للـ primary تلقائيًا في أقل من دقيقة.

الفكرة بمثال بسيط قبل التعريف العلمي

تخيّل مطعم فتح صنف جديد. المدير مش هياخد كل الطلبات وهو شكّاك في الطبق. هيجرّبه على أول 5 طلبات، يشوف ردود الفعل، لو كويسة يعرضه على 10 طاولات، وبعدين 20. لو أي طاولة شكت من الطعم، يوقف تقديم الطبق ويرجّع القديم لباقي المطعم.

ده بالظبط اللي Flagger بيعمله. بالتفاصيل:

• Canary Resource: ملف YAML بيقول لـ Flagger إزاي يدير الـ rollout. هو الأساس اللي كل حاجة بتتبني عليه.
• Success rate: نسبة الطلبات اللي رجعت HTTP 2xx/3xx من إجمالي الطلبات. مثلًا لو 99 طلب من 100 نجحوا، success rate = 99%.
• P99 latency: أبطأ 1% من الطلبات بتاخد كام ثانية. لو P99 = 500ms، يعني 99% من المستخدمين خدمتهم وصلت في أقل من نص ثانية.
• Primary vs Canary: Primary هو الـ deployment الحالي اللي شغال. Canary هو النسخة الجديدة اللي لسه بتتجرب.
• Step Weight: كل كام دقيقة يزيد كام % من الترافيك للـ canary.

إعداد عملي خطوة بخطوة

الافتراض إن عندك كلاستر Kubernetes و Istio أو Linkerd شغالين، وPrometheus موجود. لو مش مستخدم service mesh، Flagger بيدعم NGINX Ingress بنفس الفكرة تقريبًا.

1. ثبّت Flagger operator على الكلاستر عبر Helm.
2. اربطه بـ Prometheus عشان يقدر يسأل عن metrics.
3. اكتب Canary resource يحدد الـ thresholds و الـ steps.
4. كل push جديد للصورة هيبدأ الـ canary أوتوماتيكيًا، بدون تدخل من أحد.

helm repo add flagger https://flagger.app
helm install flagger flagger/flagger \
  --namespace flagger-system \
  --create-namespace \
  --set meshProvider=istio \
  --set metricsServer=http://prometheus.istio-system:9090

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

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: checkout-api
  namespace: production
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: checkout-api
  service:
    port: 80
    targetPort: 8080
  analysis:
    interval: 1m
    threshold: 5
    maxWeight: 50
    stepWeight: 5
    metrics:
      - name: request-success-rate
        thresholdRange:
          min: 99
        interval: 1m
      - name: request-duration
        thresholdRange:
          max: 500
        interval: 1m
    webhooks:
      - name: load-test
        url: http://flagger-loadtester.test/
        metadata:
          cmd: "hey -z 1m -q 10 -c 2 http://checkout-api.production/"

ركز في القيم دي: 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