لو Kubernetes HPA بيعمل scale عند 80% CPU بس الـ messages في الـ queue بتتراكم لآلاف الرسائل، مشكلتك إن الـ CPU مش المقياس الصحيح للـ workloads اللي بتستنى أحداث.
المشكلة باختصار
CPU-based autoscaling بيشتغل صح لما الـ load مرتبط مباشرةً بالـ CPU. لكن الـ workloads الحديثة — workers بتقرأ من Kafka، مستهلكين RabbitMQ، معالجات webhooks، consumers من SQS — بتقضي معظم وقتها في I/O wait. ممكن CPU يكون 20% بينما الـ queue فيها 50 ألف رسالة مستنية. HPA الافتراضي مش هيعمل scale، والـ SLA هيكسر قدام عينيك.
تخيّل مطعم فيه سفرجي كسلان
علشان نفهم المشكلة بدون تعقيد: تخيّل مطعم فيه ٣ سفرجية. الطلبات بتتكتب على ورقة وبتتعلّق في الـ kitchen. المدير قاعد يبص على الـ CPU بتاع السفرجية — يعني مدى إرهاقهم الجسدي. الـ CPU عندهم 20% لأنهم معظم الوقت بيستنوا الطباخ يجهّز الأكل. المدير يقرّر: "مفيش حاجة، كله تمام". بس في الحقيقة، عدّاد الطلبات وصل ٢٠٠ طلب مستنى، والزبون قاعد ٤٥ دقيقة.
المشكلة مش في السفرجية، المشكلة في إن المقياس الغلط. لازم المدير يبص على طابور الطلبات نفسه، مش على إرهاق السفرجي. ده بالظبط الفرق بين HPA التقليدي و KEDA.
ليه CPU مش مقياس كافي لـ workers (علمياً)
افرض إن عندك worker بيقرأ من AWS SQS. كل رسالة بتاخد 200ms معالجة: منهم 160ms I/O wait على external API، و 40ms CPU فعلي. لو 3 pods بتعالج 3,000 رسالة/دقيقة، كل pod بيدوّر 16 رسالة/ثانية ويوصل لـ CPU 15% بس.
الـ user مش بيحس بالـ CPU. اللي بيحسه هو إن الطلب اللي عمله قبل ٨ دقايق لسه في الـ queue. لو HPA متضبط عند 70% CPU، مش هيعمل scale أبداً. المشكلة مش في الـ CPU — المشكلة في queue depth بالظبط.
KEDA: المقياس الصحيح للأحداث
KEDA اختصار Kubernetes Event-driven Autoscaling. مشروع graduated من CNCF. بيضيف طبقة فوق HPA تقدر تقرأ من أكتر من 70 مصدر: Kafka, RabbitMQ, SQS, Redis Streams, Prometheus queries, Azure Service Bus, PostgreSQL، وغيرهم كتير. الفكرة بسيطة: انت بتعرّف ScaledObject بيقول "لما الـ queue فيها X رسالة، اعمل scale لـ Y pods".
التثبيت في أمرين
helm repo add kedacore https://kedacore.github.io/charts
helm install keda kedacore/keda \
--namespace keda --create-namespaceبعد دقيقة بالكتير، هتلاقي keda-operator و keda-metrics-apiserver شغّالين في namespace اسمه keda.
مثال شغّال: scaling على RabbitMQ queue
الـ ScaledObject ده بيخلي deployment اسمه order-worker يعمل scale بناءً على عدد الرسائل في queue اسمها orders:
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: order-worker-scaler
namespace: production
spec:
scaleTargetRef:
name: order-worker
minReplicaCount: 2
maxReplicaCount: 30
pollingInterval: 15 # يسأل RabbitMQ كل 15 ثانية
cooldownPeriod: 120 # يستنى دقيقتين قبل scale-down
triggers:
- type: rabbitmq
metadata:
protocol: amqp
queueName: orders
mode: QueueLength
value: "50" # هدف: 50 رسالة لكل pod
authenticationRef:
name: rabbitmq-trigger-authالمنطق: KEDA بيجيب queue length من RabbitMQ كل 15 ثانية. لو فيها 1,000 رسالة والـ target = 50، هيطلب 20 pod. لو المعدل نزل لـ 100 رسالة، هيرجّع الـ pods لـ 2 بعد cooldown.
أرقام قياس من حالة فعلية
حسب case study منشور في مدونة KEDA لمعالجة webhooks تحت ضغط (المصدر في الآخر):
- قبل (HPA بـ CPU عند 70%): الـ queue بتوصل 100K رسالة في الـ peak، الـ end-to-end latency 45 دقيقة، 3 pods ثابتين معظم اليوم.
- بعد (KEDA بـ queue length = 50): الـ latency أقل من دقيقتين في 99% من الوقت، الـ pods بتتراوح بين 3 و 22 حسب الضغط الفعلي.
- زمن الـ scale-up: 15 إلى 20 ثانية (وقت فتح pod جديد + readiness)، scale-down بعد الـ cooldown المحدد.
الـ Trade-offs اللي لازم تعرفها
بتكسب: scaling دقيق على أساس الـ workload الفعلي، والقدرة على scale-to-zero للـ jobs اللي بتشتغل متقطع.
بتخسر: dependency جديدة في الـ cluster (KEDA operator + metrics server ≈ 150MB RAM إجمالاً)، وعبء observability إضافي لأنك لازم تراقب KEDA نفسه مش بس التطبيق. الافتراض هنا إنك عندك Prometheus أو stack مراقبة شغّال بالفعل.
ملحوظة مهمة: scale-to-zero بيسبّب cold start قد يصل لـ 30 ثانية مع الـ image pull والـ readiness probe. مش مناسب لـ user-facing APIs. للـ workers اللي بتستنى messages، مناسب جداً.
متى لا تستخدم KEDA
لو الـ workload CPU-bound فعلاً (ML inference، video transcoding، data compression) — HPA الافتراضي بـ CPU كفاية ومفيش داعي لطبقة إضافية.
لو عندك أقل من 3 pods ومعدل الطلبات ثابت على مدار اليوم — الـ ROI ضعيف والـ complexity مش مبرّرة.
لو الـ SLA بيطلب cold start أقل من 5 ثواني وبتفكر في scale-to-zero — استخدم minReplicaCount ≥ 1 بدل صفر.
الخطوة التالية
افتح الـ cluster بتاعك واعمل kubectl get deploy -A. دوّر على أي deployment بيقرأ من queue أو topic. طبّق ScaledObject عليه بـ maxReplicaCount = 10 كبداية آمنة. راقب لمدة 48 ساعة الـ queue depth وعدد الـ pods في Grafana. لو الـ scaling بيحصل بسرعة زيادة ويعمل flapping، زوّد الـ cooldownPeriod لـ 300 ثانية.
المصادر
- KEDA Documentation — Scaling Deployments: keda.sh/docs/2.14/concepts/scaling-deployments
- KEDA RabbitMQ Scaler Reference: keda.sh/docs/2.14/scalers/rabbitmq-queue
- CNCF Graduated Projects — KEDA: cncf.io/projects/keda
- Kubernetes Horizontal Pod Autoscaler Documentation: kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale
- KEDA Case Studies Hub: keda.sh/community/case-studies