Karpenter للمحترف: نهاية Cluster Autoscaler وبداية Provisioning الذكي
المستوى: محترف — هذا المقال يفترض إنك بتشغّل EKS في إنتاج، عندك خبرة عملية بـ Cluster Autoscaler و Node Groups و Spot Instances، وبتفهم الفرق بين requests و limits في Kubernetes.
لو فاتورة EC2 الخاصة بالـ EKS بتاعك بتعدّي $14,200 شهرياً، و Cluster Autoscaler بياخد 4 دقائق علشان pod واحد pending يلاقي نود يقعد عليه، انت بتدفع ضريبتين في نفس الوقت: ضريبة الـ over-provisioning في الـ ASGs، وضريبة الـ scheduling latency. Karpenter v1.0 من AWS بيشيل الاتنين في إعداد واحد، وبيوفّر 38% من فاتورة EC2 على workload إنتاج فعلي بـ 142 microservice على EKS 1.30.
المشكلة باختصار
Cluster Autoscaler (CA) بيعتمد على Auto Scaling Groups (ASGs) في AWS. كل ASG ليها instance type واحد أو list محدودة، وعملية الـ scale-up بتمر بـ EC2 ASG ثم cloud-init ثم kubelet ثم cluster join. الزمن الكلي من قرار الـ scale لحد ما الـ pod يشتغل: 3 إلى 5 دقائق في أفضل الحالات.
وبالنسبة للتكلفة، انت بتختار instance type واحد لكل ASG، فحتى لو الـ workload محتاج 200m CPU و 256Mi RAM بس، الـ ASG هتجيب m5.xlarge كاملة بـ 4 vCPU و 16Gi RAM. الموقف ده بيخلّيك تشتغل بمنطق "اختار instance type متوسط ومسامح في الـ waste"، وده اللي بيخلّي الـ cluster utilization الفعلية بتقعد بين 38% و 45% في أغلب إنتاجات EKS.
ليه Karpenter مختلف: تخصيص بدون Node Groups
Karpenter بيلغي طبقة الـ ASG بالكامل. لما يلاقي pod في حالة Pending، بيقرا الـ resource requests و nodeSelector و taints و topology constraints، وبيحسب الـ instance type الأمثل من بين ~700 instance type متاحة في الـ region، ثم بيعمل CreateFleet API call لـ EC2 مباشرة.
تشبيه للمبتدئ علشان الفكرة تثبت قبل ما ندخل في التفاصيل: تخيّل انك مدير مطعم. Cluster Autoscaler يشبه انك جايب 5 طرابيز بـ 6 كراسي ثابتة عشان أي حد يدخل يلاقي مكان جاهز. لو دخل 2 أشخاص بس، 4 كراسي ضايعة كل الوقت. Karpenter يشبه انك بتجيب الطاولة والكراسي المناسبة بالظبط لحظة ما العميل يدخل من الباب. لو دخل 3 أشخاص بطفل، بتجيب طاولة بـ 3 كراسي زائد كرسي عالي. مفيش طاولة فاضية ومفيش انتظار.
على المستوى التقني: Karpenter Controller بيشتغل كـ Kubernetes Custom Controller. بيعمل watch على الـ PodScheduled condition، ولما يلاقي Pending pod، بيـ simulate الـ scheduling decision بنفسه، وبيختار الـ SKU اللي يحقق الـ requirements بأقل تكلفة لحظية. الـ flow بياخد 40-60 ثانية من Pending لـ Running، مقارنة بـ 180-300 ثانية في CA لأنه بيعدّي على طبقتين أقل.
الإعداد العملي: NodePool و EC2NodeClass
Karpenter v1.0 بيستخدم Custom Resources اتنين فقط: NodePool (سياسة الـ scheduling) و EC2NodeClass (تكوين الـ instance). إعداد production-ready لـ EKS 1.30 كالتالي:
