Karpenter بالعربي: وفّر 50% من فاتورة AWS بـ Node Autoscaling ذكي
لو فاتورة EC2 في كلاستر Kubernetes بتاعك بتتخطى 8000 دولار شهريًا وأغلب الـ nodes بتشتغل على 30% من قدرتها، المشكلة مش في عدد الـ pods — هي في اللي بيختار حجم الـ nodes. Karpenter بيحل دي بالظبط، وبيوفر في كلاسترات حقيقية بين 30% و 50% من تكلفة الحوسبة مقارنة بـ Cluster Autoscaler التقليدي.
المشكلة باختصار
Cluster Autoscaler الكلاسيكي بيعتمد على Node Groups ثابتة. يعني لازم تحدّد مسبقًا إن "هعمل scale من t3.large فقط" أو "m5.xlarge فقط". النتيجة إن لو كل اللي محتاجه pod صغير بـ 200MB RAM، هيحجزلك node كامل بـ 8GB. الباقي ضائع وبتدفع فيه.
أكتر من ده: لمّا الـ scheduler يقرر إنه محتاج node جديد، Cluster Autoscaler بيضيف الـ capacity على مراحل بتاخد من 2 لـ 5 دقايق. لو عندك spike مفاجئ، الـ pods هتفضل في Pending وقت ممكن المستخدم يكون سابك فيه.
مثال مبسط: مطعم وصناديق الدفع
تخيّل مطعم صغير فيه 4 صناديق دفع كلها بنفس المواصفات — كل واحد بيتسع لـ 5 زباين. دخلت عائلة من 6 أفراد وصندوقين فاضيين، فالمدير بيفتح صندوق كامل جديد لشخص واحد بس. باقي الصندوق كله ضائع، والإيجار بيتدفع عليه كامل.
Karpenter بيشتغل زي مدير ذكي يقدر يجيب طاولة صغيرة لما يدخل شخص واحد، وطاولة كبيرة لما تيجي مجموعة. كمان لو في زباين قاعدين على طاولة كبيرة والمطعم صاحي، بينقلهم لطاولة أصغر ويقفل الكبيرة علشان يوفّر الإيجار. ده بالظبط اللي Karpenter بيعمله مع الـ nodes في الكلاستر.
الشرح العلمي: Cluster Autoscaler مقابل Karpenter
Cluster Autoscaler (اختصاراً CA) بيشتغل على مستوى Auto Scaling Group. هو بيزيد أو يقلل عدد instances من نوع واحد محدد سلفًا. كل Node Group عنده = instance type واحد.
Karpenter بيشتغل على مستوى الـ pod مباشرة. هو بيقرأ الـ pending pods من الـ API server، بيحسب الـ CPU و Memory و GPU المطلوبين، وبيختار أرخص EC2 instance type يناسب الطلب — من بين أكتر من 700 نوع instance متاح في AWS. بعدين بيطلب الـ instance مباشرة من EC2 Fleet API من غير ما يمر على Auto Scaling Group أصلاً.
النتيجة العملية: وقت provisioning بين 30 و 60 ثانية بدل 2 لـ 5 دقايق في CA، و bin packing أدق بكتير لأن Karpenter بيختار الحجم المطابق للـ workload الحقيقي.
كيف يشتغل Karpenter في الداخل؟
- pod بيدخل في حالة
Pendingلأنه مش لاقي node يستضيفه. - Karpenter controller بيشوف الـ resource requests ويسأل: إيه أصغر و أرخص EC2 instance يلائم كل الـ pending pods مجتمعة؟
- بيعمل call مباشر لـ EC2 Fleet API ويطلب instance من النوع ده.
- بيسجّل الـ node في الكلاستر، ويجدول الـ pods عليه.
- كل ما pod يتشال، Karpenter بيفحص: فيه node شبه فاضي نقدر نشيله ونحرّك الباقي على node تاني؟ لو أيوه، بينفّذ consolidation.
