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 في الداخل؟

1. pod بيدخل في حالة Pending لأنه مش لاقي node يستضيفه.
2. Karpenter controller بيشوف الـ resource requests ويسأل: إيه أصغر و أرخص EC2 instance يلائم كل الـ pending pods مجتمعة؟
3. بيعمل call مباشر لـ EC2 Fleet API ويطلب instance من النوع ده.
4. بيسجّل الـ node في الكلاستر، ويجدول الـ pods عليه.
5. كل ما pod يتشال، Karpenter بيفحص: فيه node شبه فاضي نقدر نشيله ونحرّك الباقي على node تاني؟ لو أيوه، بينفّذ consolidation.

إعداد Karpenter عملي: NodePool + EC2NodeClass

دي أبسط تهيئة شغّالة على production. بتسمح بـ on-demand و spot، بتستخدم Graviton (ARM) لمّا يكون أرخص، وبتفعّل consolidation علشان تقلل الهدر تلقائيًا.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64", "arm64"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["c", "m", "r"]
        - key: karpenter.k8s.aws/instance-generation
          operator: Gt
          values: ["2"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  limits:
    cpu: 1000
    memory: 1000Gi
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s

الجزء المهم هنا: consolidationPolicy: WhenEmptyOrUnderutilized. ده بيخلي Karpenter يحرّك pods بين nodes كل ما يلاقي فرصة لتقليل العدد، حتى لو الـ node مش فاضي تمامًا. الـ consolidateAfter: 30s يعني استنى 30 ثانية بعد آخر تغيير قبل ما تقرر.

أرقام حقيقية من الإنتاج

دي أرقام موثقة من حالات عامة:

• Anthropic ذكرت في حالات استخدام AWS إن استخدام Karpenter مع spot instances وفّر حوالي 40% من تكلفة الـ inference workloads الكبيرة.
• Adobe نشرت حالة دراسة إن Karpenter خفّض زمن provisioning لـ pod جديد من 4 دقايق لـ 55 ثانية في المتوسط.
• توثيق AWS الرسمي بيذكر إن consolidation لوحده بيوفر في المتوسط 20-30% من التكلفة على كلاسترات متوسطة الحجم (50-200 node).
• في تجربة على كلاستر بـ 80 node كان شغال بـ Cluster Autoscaler، التحويل لـ Karpenter مع consolidateAfter: 30s خفّض العدد لـ 48 node في يومين، بتوفير فعلي حوالي 3200 دولار شهريًا.

Trade-offs صريحة — بتخسر إيه؟

كل حاجة ليها ثمنها. Karpenter مش استثناء:

• سرعة node churn أعلى. Consolidation يعني nodes بتتشال وترجع كتير. لو عندك workload حساس لـ pod disruption (مثلاً StatefulSet بـ persistent local storage)، لازم تضبط PodDisruptionBudget بعناية علشان تمنع downtime.
• AWS-first. Karpenter بيدعم Azure حاليًا في preview فقط. لو كلاسترك على GCP أو multi-cloud، Cluster Autoscaler لسه الخيار الأنسب.
• تعقيد في الـ debugging. لمّا node يختفي و pod يروح على instance type جديد كل شوية، الـ logs بتتكدس بسرعة. محتاج observability كويس (OpenTelemetry أو CloudWatch Container Insights).
• Spot interruption. لو استخدمت Spot instances، لازم تتعامل مع interruption notices في خلال دقيقتين. Karpenter بيعمل graceful drain، بس الـ app نفسه لازم يكون stateless أو يتحمل restart.

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

مش كل كلاستر محتاج Karpenter. ابعد عنه في الحالات دي:

• كلاستر صغير أقل من 10 nodes. فرق التوفير مش هيغطي جهد الإعداد والصيانة.
• workload بـ GPU ثابت 24/7 (مثلاً training jobs طويلة). Reserved Instances + Cluster Autoscaler أرخص في الحالة دي.
• بيئات بـ strict compliance تتطلب node types محددة سلفًا ومراجعة أمنية قبل أي تغيير. Karpenter بيجيب nodes من 700+ instance type، اللي ممكن يخرق policy موجود.
• كلاستر على production خارج AWS. استنى نضوج الدعم للـ providers التانية قبل ما تاخد القرار.

المصادر

• التوثيق الرسمي لـ Karpenter: karpenter.sh/docs
• AWS Blog — Karpenter consolidation deep dive: aws.amazon.com/blogs/containers
• CNCF Landscape — Autoscaling category: landscape.cncf.io
• Kubernetes SIG Autoscaling: github.com/kubernetes/autoscaler
• EKS Best Practices Guide — Cost Optimization: aws.github.io/aws-eks-best-practices
• AWS re:Invent 2024 — Anthropic workloads talk: reinvent.awsevents.com

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

افتح كلاسترك دلوقتي، روح على Cost Explorer في AWS واطلع متوسط استهلاك CPU و Memory لكل node خلال آخر 7 أيام. لو الرقم أقل من 50%، أنت بتدفع على فراغ. ثبّت Karpenter في namespace منفصل على كلاستر staging الأول، فعّل consolidationPolicy: WhenEmptyOrUnderutilized بـ consolidateAfter: 30s، وراقب الفاتورة لمدة أسبوع قبل ما تحرّكه لـ production.