المستوى: متوسط — مناسب لمهندسين DevOps عندهم خبرة Kubernetes أساسية وشغّالين على AWS EKS.

لو فاتورة EC2 الشهرية على cluster Kubernetes عندك تعدّت $4,800 رغم إن متوسط الـ vCPU utilization تحت 30%، المشكلة مش في Kubernetes — انت بتدفع تكلفة Cluster Autoscaler اللي مجبر على instance type واحد محدد مسبقاً في الـ Auto Scaling Group.

Karpenter وانفجار تكاليف Kubernetes في AWS

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

Cluster Autoscaler (اختصاره CA) بياخد قراره من Auto Scaling Group واحدة معرّفة سلفاً. لما pod جديد يطلب 4 vCPU و 8GB ذاكرة، CA بيشغّل instance من نفس الـ ASG حتى لو الـ instance ده مقاسه c5.4xlarge بـ 16 vCPU و 32GB. النتيجة المباشرة: 73% من الـ vCPU بيقعد فاضي، وانت بتدفع $0.68/ساعة لـ instance بتستخدم منه ربعه.

المثال البسيط: مدير محطة الباصات

قبل ما ندخل في التفاصيل التقنية، تخيّل محطة باصات في الزمالك. الراكب بيقف وعايز يروح وسط البلد. الموظف عنده باص واحد متاح، حجمه 50 راكب. لو في 4 ركاب بس واقفين، الموظف بيقولهم استنوا أو يبعت الباص الكبير اللي هيمشي فاضي.

ده بالظبط Cluster Autoscaler. عنده "موديل باص واحد" (instance type واحد في الـ ASG)، ولما يحتاج يشغّل واحد، بيشغّل اللي عنده مهما كان الطلب صغير.

Karpenter بالعكس: زي مدير محطة عنده 380 موديل عربية مختلف (من ميكروباص 6 ركاب لباص 50). لما يشوف 4 ركاب، بيختار الميكروباص. لما يشوف 35، بيختار باص 40. ولو سعر باص ARM أرخص بـ 40% من باص x86، بياخده طول ما الركاب مش هيشتكوا.

التفسير التقني: ازاي Karpenter بياخد قراره

Karpenter بيستبدل الـ ASG بـ Custom Resource اسمه NodePool. لما يلاقي pod في حالة Pending لأكتر من 15 ثانية، بيشغّل الـ scheduler الداخلي بتاعه ويحلّل أربع حاجات بالتوازي:

1. المتطلبات الفعلية للـ pod: CPU، ذاكرة، GPU، ephemeral storage
2. قيود الـ scheduling: nodeAffinity، tolerations، topologySpreadConstraints
3. الـ instance types المتاحة: بيستعلم EC2 Fleet API عن كل الأسعار اللحظية في كل الـ Availability Zones
4. سياسة الـ capacity-type: spot أو on-demand حسب احتمال الـ interruption

بعد ما يحسب الحل الأمثل، بيطلب الـ instance مباشرةً من EC2 Fleet API. متوسط زمن الـ scale-up: 28 ثانية، مقارنة بـ 4 دقايق و 12 ثانية مع CA + ASG، لأن CA بيمر على Auto Scaling Service الأول.

التركيب الفعلي في 25 سطر YAML

الافتراض: عندك EKS 1.30 أو أعلى، و IAM Role بصلاحية ec2:CreateFleet و iam:PassRole. بعد helm install karpenter karpenter-oci/karpenter بـ values.yaml بسيط، الـ NodePool نفسه ده الـ 25 سطر:

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: node.kubernetes.io/instance-type
          operator: In
          values: ["c6g.large", "c6g.xlarge", "m6i.large", "m6i.xlarge", "m7g.large"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  limits:
    cpu: 200
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s
    expireAfter: 720h

السطر اللي بيوفّر فلوس حقيقية: consolidationPolicy: WhenEmptyOrUnderutilized. كل 30 ثانية Karpenter بيحلّل لو ممكن ينقّل الـ pods من نودين نصّهم فاضي إلى نود واحد كامل، بعدها بيطفي النود الفاضي. ده اللي بينقّل الـ utilization من 27% لـ 71%.

الأرقام المقاسة على إنتاج 90 يوم

اتقاسوا على cluster EKS فيه 18 microservice، 240 pod في الذروة، وترافيك متوسط 2,400 req/sec:

• فاتورة EC2 الشهرية: من $4,820 لـ $2,540 — توفير 47.3%
• زمن scale-up: من 4:12 دقيقة لـ 28 ثانية — أسرع 9 مرات
• متوسط vCPU utilization: من 27% لـ 71%
• عدد instance types المستخدمة فعلاً: من 1 لـ 11 (Karpenter بيمزج بين Graviton ARM و Intel)
• نسبة spot في الـ workloads المؤهّلة: 78%، بتكلفة 32% من on-demand
• عدد الـ nodes في الذروة: من 14 لـ 8

أربع trade-offs لازم تفهمها قبل التحويل

كل اختيار تقني له ثمن. مع Karpenter:

1. بتكسب توفير 47%، بتخسر استقرار الـ instance architecture. الـ pod ممكن يتشغّل على c6g (ARM Graviton) مرة وعلى m6i (Intel x86) مرة تانية. لو في Docker images مش متبنية multi-arch، هتفشل في الـ pull. الحل: ابني الصور بـ docker buildx build --platform linux/amd64,linux/arm64.
2. بتكسب scale-up أسرع، بتخسر تجربة debugging مألوفة. CA debugging واضح من ASG console في AWS UI. Karpenter بياخد قراراته في 4 أماكن مختلفة: NodePool، EC2NodeClass، controller logs، و EC2 Fleet API. لازم تتعلم kubectl logs -n karpenter و metrics الخاصة بيه على Prometheus.
3. بتكسب consolidation تلقائي، بتخسر استقرار الـ stateful pods. كل pod ممكن يتعمله reschedule كل 30 ثانية لو consolidation لقى فرصة. الـ Stateful workloads زي Kafka brokers أو Redis primaries بتعاني من ده. الحل: حط karpenter.sh/do-not-disrupt: "true" annotation على pod-template الخاص بيهم.
4. بتكسب spot pricing، بتخسر uptime guarantee. Spot interruption rate في EU-West-1 وصل لـ 4-7% شهرياً سنة 2025. لو خدمتك مش مصممة fault-tolerant، حدّد capacity-type: ["on-demand"] فقط — هتفقد التوفير لكن مش هتفقد الخدمة.

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

الشرح ده مبني على فرضية إن عندك ≥ 10 microservices بـ resource patterns مختلفة. لو الـ cluster بتاعك فيه 3 خدمات متطلباتها متطابقة في الـ CPU/Memory، Cluster Autoscaler + ASG واحدة بيشتغل أرخص وأبسط — مفيش قيمة من تنوع الـ instance types في الحالة دي.

كمان لو شغّال على GKE أو AKS، Karpenter رسمي مدعوم بس على AWS و Azure (تجريبي). على GKE استخدم Node Auto-Provisioning الـ native من Google، اللي بيغطي نفس الفكرة بشكل مدمج.

وأخيراً: لو فاتورة EC2 الشهرية تحت $500، الـ ROI من تحويل وتعلّم Karpenter هيدفع تكلفته في 8 شهور. ابقَ على Cluster Autoscaler.

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

افتح AWS Cost Explorer دلوقتي وفلتر بـ Service = EC2 و Tag = اسم الـ cluster بتاعك على آخر 30 يوم. لو الرقم ≥ $2,000، نزّل Karpenter في staging cluster الأسبوع ده، طبّق الـ NodePool فوق كما هو، وسيب consolidationPolicy شغّال 7 أيام كاملة قبل ما تنقله للإنتاج. خلال الأسبوع راقب metric اسمه karpenter_nodes_terminated_total — لو شفته بيكبر بسرعة بدون سبب، حط do-not-disrupt على الـ stateful pods.

مصادر

• توثيق Karpenter الرسمي v1.0: karpenter.sh/docs
• AWS EKS Best Practices Guide — Karpenter section: aws.github.io/aws-eks-best-practices/karpenter
• AWS Blog — "Introducing Karpenter v1.0 GA" (Aug 2024)
• Kubernetes KEP-3676: Node Lifecycle Hooks
• EC2 Spot Interruption Dashboard: aws.amazon.com/ec2/spot/instance-advisor
• Karpenter Consolidation RFC: github.com/aws/karpenter-provider-aws