لو عندك staging cluster بيشتغل 24/7 وبيتكلّف 400 دولار شهريًا رغم إن الفريق مش بيستخدمه إلا 4 ساعات في اليوم، الـ upgrade ده هيرجّعلك قرابة 70% من الفاتورة بإعداد واحد. Kubernetes 1.36 نزل النهاردة 22 أبريل 2026 بـ HPA scale-to-zero افتراضي بعد 7 سنين من التجربة.
Kubernetes 1.36 وقرار HPA scale-to-zero
المشكلة باختصار
الـ Horizontal Pod Autoscaler قبل 1.36 كان محتاج Pod واحد على الأقل شغّال علشان يجيب metrics ويقرر الـ scaling. يعني حتى لو الـ queue فاضية ومفيش طلبات، في Pod بيشتغل وبيحرق موارد. نتيجة ده: staging environments وتست clusters وbatch workloads بتفضل شغّالة 24/7 على الفاضي.
إيه اللي اتغيّر فعلاً في 1.36
الـ feature gate اسمها HPAScaleToZero ظهرت أول مرة في v1.16 سنة 2019 كـ alpha. استنّت 7 سنين، دلوقتي بقت stable وشغّالة افتراضيًا. الفرق بالظبط: HPA بقى يقدر يعتمد على external metrics زي طول الـ queue في RabbitMQ أو SQS، بدل ما يتحصر في metrics الـ Pod نفسه.
الفكرة ببساطة: تخيّل موظف في محل بيفتح الباب كل صبح ويقعد على الكاونتر. الموظف ده بياخد مرتّب حتى لو مفيش زبون دخل طول النهار. الـ scale-to-zero معناه إن لو مفيش زبون، الموظف يروح بيته — ولما حد يدق على الجرس، يرجع. الـ "جرس" هنا هو external metric زي queue length أو HTTP request واصل على ingress controller.
بشكل أدق تقني: الميكانيزم بيعتمد على KEP-2589 اللي خلى HPA يقبل External و Object metrics كمصدر قرار، من غير ما يطلب وجود Pod شغال علشان يحسب. الـ control plane بيشوف الـ external metric المباشر، ولو وصل للـ threshold بيعمل scale-up من 0 لـ minReplicas اللي انت حددته فوق الصفر، وبعدها HPA بيرجع يحسب بالطريقة العادية.
الإعداد الفعلي: HPA YAML قابل للنسخ
لو عندك KEDA مركّب أو أي external metrics adapter، الإعداد بقى بسيط:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: worker-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: queue-worker
minReplicas: 0
maxReplicas: 20
metrics:
- type: External
external:
metric:
name: rabbitmq_queue_length
target:
type: AverageValue
averageValue: "10"
اللي اتغيّر: minReplicas: 0 بقى قيمة صالحة من غير أي feature gate مفعّل يدوي. قبل كده كنت لازم تعدّل kube-apiserver بـ --feature-gates=HPAScaleToZero=true، واللي كتير من الـ managed services زي EKS و GKE ما كانتش بتسمح بيه أصلًا.
سيناريو واقعي بأرقام
افترض إن عندك staging cluster فيه 6 deployments كلها شغّالة بـ 2 replicas على m5.large. ده بيتكلّف حوالي 420 دولار شهريًا على AWS EKS قبل أي تخفيضات. الفريق بيشتغل 8 ساعات في اليوم من السبت للخميس، يعني الاستخدام الفعلي حوالي 28% من الوقت، والـ 72% الباقية الـ Pods قاعدة على الفاضي بتستهلك compute.