KEDA بالعربي: scale-to-zero للـ Workers ووفّر 30% من فاتورة Kubernetes

helm repo add kedacore https://kedacore.github.io/charts
helm repo update
helm install keda kedacore/keda --namespace keda --create-namespace
kubectl get pods -n keda

بعدها نطبّق الـ ScaledObject ده:

الأرقام هنا مدروسة: lagThreshold: 1000 يعني لكل 1000 رسالة متراكمة هيبقى فيه pod زيادة. لو الـ lag وصل 10 آلاف، هتلاقي 10 pods شغالة. لو نزل صفر لمدة دقيقتين، هيروح Pods كلها.

قياس الأثر: من 3 Pods دائمة لـ 0.8 متوسط

في workload حقيقي ينتج حوالي 2 مليون event/يوم موزّعة بشكل غير منتظم (peak بعد الظهر، خمول بالليل):

• قبل KEDA: 3 replicas × 0.5 vCPU × 24 ساعة = 36 vCPU-hour/يوم ≈ 108 دولار شهريًا.
• بعد KEDA: متوسط 0.8 replica × 0.5 vCPU × 24 ساعة ≈ 28.8 دولار شهريًا.
• توفير فعلي: ~73% على هذا الـ worker تحديدًا. المتوسط عبر 12 worker عندنا كان 30-35%.

الرقم ده متوافق مع ما نشرته Microsoft وKedify في case studies إنتاج (30% خفض compute على batch workloads).

الـ trade-offs اللي لازم تفهمها قبل ما تطبق

مافيش wins مجانية. الـ scale-to-zero بيكلفك تلات حاجات:

• Cold start latency: أول رسالة بعد فترة خمول ممكن تستنى 5-30 ثانية (polling + image pull + app warmup). لو ده غير مقبول، خلي minReplicaCount: 1.
• Polling overhead: كل ScaledObject بيعمل query للمصدر كل 15-30 ثانية. لو عندك 200 ScaledObject على نفس الـ Kafka cluster، هتضيف load ملحوظ. حل: ارفع pollingInterval لـ 60 على الـ scalers القليلة الحساسية.
• Flapping: لو الـ lag بيتأرجح فوق وتحت الـ threshold، الـ pods تتفتح وتتقفل كتير. الحل: زوّد cooldownPeriod لـ 300 ثانية على الأقل، واستخدم HPA Stabilization Window.

متى لا تستخدم KEDA scale-to-zero

الأسلوب ده بيفشل في الحالات دي:

• HTTP APIs حساسة للـ latency (أقل من 200 ms P95): الـ cold start هيكسر الـ SLO.
• Stateful services بتاخد دقايق تعمل warmup للـ cache المحلي.
• خدمات بتستقبل traffic مستمر ومعدّله تحت عتبة الـ scale-down أصلًا (الـ HPA العادي كافي).
• بيئات بها quota على API calls للمصدر الخارجي (مثل AWS SQS LongPoll محدود).

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

افتح أضعف worker عندك (اللي بياخد أقل CPU لأطول فترة) وطبّق عليه ScaledObject بـ minReplicaCount: 0 و cooldownPeriod: 300. راقبه 48 ساعة على Grafana: لو الـ lag الأقصى بعد scale-out مقبول (أقل من SLA القسم عندك)، عمّمه على باقي الـ workers. لو الـ cold start كسر SLA، خلي minReplicaCount: 1 واكتفي بالـ upper bound.

المصادر

• KEDA Official Docs — Scaling Deployments, StatefulSets & Custom Resources
• KEDA Kafka Scaler Reference
• Microsoft Open Source Blog — Intro to KEDA
• Kedify — KEDA vs HPA Production Comparison
• CloudRaft — Kubernetes Autoscaling Guide (HPA, VPA, KEDA)
• Devtron — Autoscaling using KEDA based on Kafka Lag