لو خدمتك بتاكل من Kafka topic فيه 184,000 رسالة متراكمة، وفي نفس الوقت الـ HPA بيقولك "CPU عند 35%، مفيش داعي للـ scale"، انت بتدفع ضريبة معمارية اسمها الفصل بين سبب العمل وقياس العمل. KEDA بيحل ده في 18 سطر YAML.
KEDA: لما الـ Pod Autoscaling يبقى مربوط بالحدث الحقيقي مش بـ CPU
المقال ده هيوصّلك لحاجة محددة: ScaledObject شغّال على EKS 1.30 يقرأ Kafka consumer lag ويـ scale الخدمة من 0 لـ 18 pod تلقائيًا، مع أرقام مقاسة من إنتاج فعلي وثلاث حالات لما KEDA يبقى الاختيار الغلط.
المشكلة باختصار
الـ Horizontal Pod Autoscaler الافتراضي في Kubernetes بيـ scale حسب CPU أو memory. ده شغّال كويس لخدمة HTTP عادية، لكنه بيفشل في 4 سيناريوهات شائعة جداً في الإنتاج الحديث:
- Kafka / RabbitMQ consumers — الـ consumer ممكن يكون "بيشتغل" بـ 35% CPU وعنده 100K رسالة متراكمة. CPU مش مؤشر اللي بيحصل في الـ queue.
- Batch jobs — لازم تكون 0 pods لما مفيش شغل، و 30 pod لما يكون فيه شغل. HPA مش بيعمل scale to zero.
- خدمات معتمدة على cron — الحمل يتوقّع في توقيت محدد، مش لما CPU يطلع.
- خدمات بـ blocking I/O — الـ Pod بيستنى DB أو external API، الـ CPU منخفض، لكن latency بيطلع.
الفجوة دي مكلّفة. فريق بـ 22 microservice على EKS قاس عندنا متوسط 7 دقايق تأخير في معالجة الـ events بسبب lag في الـ HPA reaction time لما الحمل ييجي من Kafka. ده ترجم لـ 14 ألف رسالة chargeback متأخرة في الشهر، وفاتورة EC2 over-provisioned بـ 41% لتعويض البطء.
قبل ما ندخل تقني: مثال بسيط لو دي أول مرة تسمع عن KEDA
تخيّل إنك صاحب محل بيتزا. عندك 3 عمّال بيشتغلوا طول الوقت سواء فيه طلبات ولا لأ. مرة في الأسبوع، بيجي طلب 80 بيتزا لحفلة. الـ 3 عمّال هياخدوا 4 ساعات يخلّصوها، والزبون هيلغي الطلب.
الـ HPA التقليدي زي مدير بيراقب "العمّال متعرّقين ولا لأ؟" — لو متعرّقين، يستدعي زيادة. لكن العمّال مش بيتعرقوا وهم بيستنوا الفرن، فالمدير مش بيستدعي حد. الـ طلبات هي اللي طالعة، مش "تعرّق العمّال".
KEDA زي مدير تاني بيقف عند باب المطبخ ويعدّ الطلبات الـ pending. لو فجأة طلع 80 طلب في الـ queue، يستدعي 12 عامل إضافي فوراً. لما الـ queue يفضى، يصرفهم ويرجع لـ 0 إذا لازم. القرار اتربط بالـ سبب الحقيقي للعمل (الطلبات)، مش بـ أثر جانبي (التعرّق).
الشرح العلمي: External Metrics و KEDA Architecture
Kubernetes منذ الإصدار 1.10 يدعم ثلاث مصادر للـ metrics في الـ HPA:
- Resource metrics — CPU و memory من kubelet/metrics-server.
