Karpenter للمتوسط: وفّر 47% من فاتورة EC2 في 25 سطر 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.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