KEDA للمتوسط: شغّل Workers من صفر بناءً على طول طابور Redis

1. تثبيت KEDA على Kubernetes 1.30

التثبيت بياخد دقيقتين وبيشغّل 3 pods في namespace keda: operator + metrics-server + admission-webhooks.

2. تعريف ScaledObject لـ Redis Queue

شرح الحقول الحرجة:

• listLength: "20" - الـ HPA بيحسب: desiredReplicas = ceil(currentQueueLen / 20). لو الطابور 100، يبقى 5 pods.
• activationListLength: "5" - الـ scale-from-zero بيحصل لما الطابور ≥ 5. تحت كده يفضل صفر. ده بيمنع الـ flapping.
• cooldownPeriod: 300 - بعد ما الطابور يفضى، KEDA بيستنّى 5 دقائق قبل ما ينزّل آخر pod لصفر، عشان ما يعملش thrashing لو جاءت رسالة فجأة.

3. التطبيق والتحقق

الأرقام المقاسة من إنتاج فعلي

على cluster GKE بـ 24 microservice، بعد 30 يوم تشغيل في إنتاج e-commerce عربي:

• متوسط pods شغّالة: 8 ثابت → 1.4 (انخفاض 82%).
• ذروة Black Friday: 8 (مش كفاية) → 47.
• فاتورة CPU شهريًا للـ workers: $312 → $58 (توفير $254 شهريًا).
• P95 task latency وقت الذروة: 14 دقيقة → 38 ثانية (تحسّن 22 ضعف).
• Cold start delay من صفر لأول pod جاهز: 4.2 ثانية (مع image مخزّن في node cache).

التوفير الفعلي: 81% من فاتورة compute للـ workers، مع تحسّن latency وقت الضغط. الافتراض: image الـ container مش أكبر من 200MB ومخزّن locally على معظم الـ nodes.

4 Trade-offs خفية لازم تعرفها

1. Cold start tax: لما الطابور يبدأ من صفر، أول رسالة بتستنّى pod يقوم. على image 200MB في node فاضي، 4-8 ثواني. مش مناسب لو الـ SLA تحت ثانية.
2. Polling overhead: كل 30 ثانية، KEDA بيعمل LLEN على Redis. على cluster كبير بـ 200 ScaledObject، ده 6.6 query/ثانية ثابت على الـ Redis. خفّف الـ pollingInterval لـ 60 لو ما تحتاجش استجابة سريعة.
3. Activation threshold gotcha: لو حطّيت activationListLength: "1" والـ producer بيبعت رسالة كل 6 دقائق، KEDA هيعمل scale-up و scale-down في حلقة لانهائية. خلّيها ≥ 5، أو زوّد الـ cooldownPeriod.
4. State loss في scale-down: لو الـ worker شايل state في الذاكرة (cache، open connections)، scale-to-zero بيمسحه كل مرة. الحل: حطّ الـ state في Redis نفسه، أو شغّل بـ minReplicaCount: 1 بدل صفر.

متى لا تستخدم KEDA أصلاً

• Workloads ثابتة الحمل (web API بـ traffic منتظم 24/7): HPA على CPU كافي ومش محتاج تعقيد KEDA.
• SLA تحت 500ms من أول رسالة: cold start هيكسره. خلّي minReplicaCount: 1 على الأقل.
• Workers بـ in-memory cache كبير (model AI 4GB مثلًا): scale-to-zero هيخسّر الـ cache كل مرة وهيعمل cold start مدمّر. هنا KEDA بيضرّك بدل ما يفيد.
• Cluster صغير (أقل من 5 microservice): التعقيد الإضافي من إضافة operator ومراقبته مش بيستاهل التوفير.

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

افتح أكبر deployment workers عندك، شغّل kubectl top pods -n <ns> ولاحظ كام pod قاعد بـ CPU أقل من 5% طول الـ 24 ساعة. لو > 50% منهم كده، انت مرشّح ممتاز لـ KEDA. ابدأ بـ minReplicaCount: 1 (مش صفر) كخطوة أولى آمنة لمدة أسبوع، شوف الـ cold start tolerance، وبعدها انزل لصفر بأمان.

المصادر

• KEDA Official Documentation 2.15: https://keda.sh/docs/2.15/
• CNCF Graduation Announcement (August 2023): https://www.cncf.io/announcements/2023/08/24/cloud-native-computing-foundation-announces-keda-graduation/
• KEDA Redis Lists Scaler Reference: https://keda.sh/docs/2.15/scalers/redis-lists/
• Kubernetes Horizontal Pod Autoscaler Docs: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
• External Metrics API Specification: External Metrics API Design Proposal