Karpenter للمحترف: استبدل Cluster Autoscaler ووفّر 41% من فاتورة EC2

YAML شغّال على Karpenter v1.0+ و Kubernetes 1.29:

السطر اللي بيوفّر الفلوس فعلاً هو consolidationPolicy: WhenEmptyOrUnderutilized. كل 30 ثانية، Karpenter بيراجع: "هل لو نقلت الـ pods من node 50% utilization لـ node تاني، أقدر أقفل الأول؟" لو الإجابة نعم، بيعمل graceful drain ويوفّر الـ instance.

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

قياس على cluster عميل (e-commerce، 60 microservice، traffic ~ 12K req/sec في الذروة، 800 req/sec في الـ off-peak):

• فاتورة EC2 الشهرية: $4,180 → $2,470 (توفير 41%).
• زمن استجابة لـ pod جديد: 4 دقيقة 12 ثانية → 47 ثانية (P50).
• متوسط CPU utilization على الـ cluster: 38% → 71%.
• عدد الـ instance types المستخدمة في وقت واحد: 2 (مع CA) → 11 (مع Karpenter).
• نسبة Spot instances: من 0% لـ 62% بدون أي downtime ملحوظ في الـ application metrics.

المرجع للأرقام المماثلة على نطاق أكبر: AWS Containers Blog – Applying Spot at Anthropic and others، وتجارب Adobe المنشورة في KubeCon EU 2024.

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

1. Pod scheduling أصعب في الـ debugging. Cluster Autoscaler بيشغّل instance type ثابت، يعني لو الـ pod مش بيتحط، السبب واضح. Karpenter بيختار من 700 SKU، فالـ events على الـ pod ممكن تقول "no compatible instance" بدون تفاصيل ليه. الحل: استخدم kubectl describe nodepool + لوگات karpenter controller.
2. Spot interruptions بتزيد. لو 62% من الـ workload على Spot، هتشوف terminations كل 6–8 ساعات في المتوسط. ده مش مشكلة لو عندك PodDisruptionBudget صح، لكنه كارثة على stateful workloads بدون replication.
3. Consolidation بيعمل churn. الـ pods بتتحرّك بين nodes كل ساعة–ساعتين. لو في caching محلي على الـ node (مثلًا local SSD)، الـ cache بيضيع. consolidateAfter أعلى (5 دقائق+) بيقلّل المشكلة دي.
4. الأرقام بتعتمد على الـ workload mix. Cluster homogeneous (كل pods نفس الحجم تقريبًا) ممكن يشوف توفير 10–15% بس، مش 41%. الـ heterogeneous workloads هي اللي بتستفيد فعلاً.

متى ما تستخدمش Karpenter

الأداة دي مش إجابة لكل cluster:

• لو الـ cluster على GKE أو AKS وليس EKS — Karpenter كان AWS-only لحد 2024، فيه دعم Azure تجريبي بس مش production-ready زي EKS.
• لو فاتورة EC2 الشهرية أقل من $1,000 — الوقت اللي هتقضيه في الإعداد والمراقبة أغلى من اللي هتوفّره.
• لو عندك compliance requirements بتلزمك بـ instance type محدد (مثلًا r5.metal لـ workload بتاع DB حساس) — Karpenter ممكن يختار حاجة تانية بدون ما تاخد بالك.
• لو فريقك مش متعوّد على Spot interruptions و graceful shutdowns — هتعدّي بمواقف 3 الفجر مش لطيفة.

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

افتح الـ AWS Cost Explorer، فلتر على الـ cluster بتاعك للـ 30 يوم اللي فاتت، واحسب نسبة الـ EC2 من إجمالي الفاتورة. لو طلعت فوق 60% والـ utilization تحت 50% (تقدر تشوفه من Container Insights)، Karpenter بيوفّرلك في حدود الـ 30–45%. ابدأ بـ NodePool واحد على staging، شغّله أسبوع، وقارن الأرقام قبل ما تنقل الـ production.

المصادر

• AWS Containers Blog — Announcing Karpenter 1.0 GA (Aug 2024).
• Karpenter Official Docs — NodePools concept.
• Garey M.R., Johnson D.S. — Computers and Intractability: A Guide to the Theory of NP-Completeness, W.H. Freeman, 1979 (مرجع bin-packing).
• KubeCon EU 2024 — Adobe Karpenter at scale talk.
• AWS Pricing Calculator — calculator.aws (للمقارنات السعرية).
• Cloud Native Computing Foundation Project Page — cncf.io/projects/karpenter.