أحمد حايس
الرئيسيةمن أناالدوراتالمدونةالعروض
أحمد حايس

دورات عربية متخصصة في التقنية والبرمجة والذكاء الاصطناعي.

المنصة مبنية على الوضوح، التطبيق، والنتيجة النافعة: شرح مرتب يساعدك تفهم الأدوات، تكتب كودًا أفضل، وتستخدم الذكاء الاصطناعي بوعي داخل العمل الحقيقي.

تعلم أسرعوصول مباشر للدورات والمسارات من الموبايل.
تنقل أوضحالروابط الأساسية والدعم في مكان واحد بدون تشتيت.

المنصة

  • الرئيسية
  • من أنا
  • الدورات
  • العروض
  • المدونة

الدعم

  • الأسئلة الشائعة
  • تواصل معنا
  • سياسة الخصوصية
  • شروط استخدام التطبيق
  • سياسة الاسترجاع
محتاج مسار سريع؟
ابدأ من الدوراتتواصل معناالأسئلة الشائعة

© 2026 أحمد حايس. جميع الحقوق محفوظة.

الرئيسيةالدوراتالعروضالمدونةالدخول
DevOps بالعربي

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

📅 ٨ مايو ٢٠٢٦⏱ 6 دقائق قراءة
Karpenter للمحترف: استبدل Cluster Autoscaler ووفّر 41% من فاتورة EC2

المستوى: محترف — يفترض إنك متعرّف على Kubernetes Pods وNodes وعندك تجربة مع Cluster Autoscaler أو HPA.

لو cluster Kubernetes بتاعك على EKS بياكل $4,200 شهريًا وفيه 38% من الـ nodes فاضية معظم اليوم، Cluster Autoscaler مش غلطان — هو بس بطيء، وبيحجز instance type واحد لكل node group بصرف النظر عن حجم الـ pods. Karpenter بيختار EC2 instance بالظبط على مقاس الـ pods الـ pending، وبيشغّلها في 47 ثانية بدل 4 دقايق.

Karpenter: ازاي توفّر 41% من فاتورة EC2 من غير ما تلمس كودك

المشكلة باختصار

Cluster Autoscaler (CA) مبني على فكرة "Node Groups" — أنت بتعرّف مسبقًا حجم الـ instance type (مثلًا m5.xlarge) لكل group. لمّا pod بقى pending، CA بيطلب نسخة تانية من نفس الحجم بالظبط. لو الـ pod محتاج 2 vCPU و 4GB RAM، CA هيشغّل m5.xlarge كامل (4 vCPU + 16GB)، ويسيب نص الموارد فاضية بتدفع تمنها لـ AWS.

على cluster بـ 60 microservice، الفرق بيتراكم بسرعة. قسنا على عميل مارس 2026: $4,180 شهريًا فاتورة EC2، 38% utilization فعلي، يعني الـ $1,587 منهم بيتحرقوا في الفاضي.

صفوف خوادم في مركز بيانات AWS تمثّل بيئة EC2 Auto Scaling مع Karpenter

مثال للمبتدئ — موقف العربيات قدام العمارة

تخيّل مقاول بيدير مكتب توصيلات. قاله مديره: "ركّب 10 سواقين، كل واحد عنده عربية ميكروباص لـ 14 راكب". لو طلبت توصيلة لشخص واحد، السوّاق هييجي بميكروباص فيه 13 كرسي فاضي. الراكب مبسوط، لكن صاحب الشركة بيدفع بنزين 14 كرسي علشان يحرّك واحد.

ده بالظبط Cluster Autoscaler. الحل البديهي: خلّي عندك تشكيلة عربيات — موتوسيكل، تاكسي 4 راكب، فان 8، ميكروباص 14 — والحاجب بصص على الطلب اللحظي ويبعت الحجم المناسب. ده Karpenter.

التعريف العلمي

Karpenter open-source controller من AWS، أطلقته في نوفمبر 2021 ووصل GA مع الإصدار v1.0 في أغسطس 2024 (المصدر الرسمي: AWS Containers Blog، Aug 13, 2024). بيعمل provisioning مباشر لـ EC2 instances من خلال Kubernetes API، بدون ما يمر على AWS Auto Scaling Groups.

الـ control loop بيتنفّذ كل 10 ثواني: يقرأ الـ pending pods، يحسب الـ resource requests، يقارن بأكتر من 700 EC2 instance type متاحين في الـ region، يختار أرخص توليفة تغطّي الطلب، وبيبعت RunInstances API call مباشرة لـ EC2.

الفكرة الجوهرية اسمها bin-packing optimization — مسألة كلاسيكية في علوم الحاسب موصوفة في Garey & Johnson 1979: "إزاي تحط أكبر كتلة من العناصر المختلفة الحجم في أقل عدد من الصناديق". Karpenter بيطبّقها على pods و EC2 nodes، مع احترام الـ topologySpreadConstraints والـ taints والـ affinity rules.

الإعداد العملي على EKS

الخطوات دي بتفترض إن عندك EKS cluster شغّال + IAM permissions كاملة + AWS CLI مكوّن. الزمن الإجمالي: 25–30 دقيقة.

  1. تركيب Karpenter بـ Helm في namespace منفصل.
  2. إنشاء IAM Role لـ Karpenter يقدر يعمل RunInstances وTerminateInstances.
  3. تعريف NodePool — اللي بيحدّد الـ constraints المسموحة (instance families، architectures، Spot vs On-Demand).
  4. تعريف EC2NodeClass — اللي بيحدّد الـ AMI والـ subnets والـ security groups.
  5. حذف Cluster Autoscaler القديم وتحريك الـ workloads تدريجيًا.

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

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

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

رف خوادم بكابلات شبكة منظّمة يوضّح تعدّد أحجام EC2 instances اللي Karpenter بيختار من بينها

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

قياس على 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.

هل استفدت من المقال؟

اطّلع على المزيد من المقالات والدروس المجانية من نفس المسار المعرفي.

تصفّح المدونة