لو عندك 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.

بعد الترحيل لـ 1.36 وتفعيل scale-to-zero على الـ 6 deployments مع KEDA يحسّس ingress requests:

• الفاتورة الجديدة التقديرية: 140 دولار شهريًا.
• التوفير الفعلي: حوالي 66%. الرقم 70% بيتحقق بس لو الـ idle time أعلى من 75% (يعني عطلة رسمية طويلة أو فريق صغير).
• الـ cold start penalty: أول request لما deployment scaled-to-zero بياخد بين 8 و 15 ثانية لحد ما Pod يكون ready — حسب حجم الـ image ومكان الـ registry.

الـ trade-offs اللي لازم تاخد بالك منها

الـ scale-to-zero بتكسب فلوس، بتخسر استجابة فورية. كل request جاي على deployment scaled-to-zero بيستنى: pull image لو مش موجود على الـ node، container startup، init containers، readiness probe. المجموع بين 5 و 30 ثانية حسب حجم الـ image وbootstrap logic.

ده معناه تلات قرارات واضحة:

1. Production APIs الحسّاسة لوقت الاستجابة: ممنوع. خلّي minReplicas=2 على الأقل علشان يفضل في redundancy.
2. Batch workers وqueues: مثالي. زيادة 10 ثواني على job بياخد أصلًا 5 دقايق مش مشكلة.
3. Internal tools وstaging: مثالي. المطوّر هيستنى 10 ثواني أول request في الصبح، مش قصة كبيرة في مقابل توفير مئات الدولارات.

الافتراض هنا: عندك external metrics source (KEDA أو Prometheus adapter) مركّب. من غير ده، HPA مش هيعرف إزاي يرجع من صفر لواحد، لأن مفيش Pod يجيب منه الـ metric، والـ deployment هيفضل عالق على صفر.

باقي الـ 80 enhancement في 1.36

scale-to-zero مش الحاجة الوحيدة في النسخة. في حاجات تانية تستاهل المتابعة:

• User namespaces stable: عزل UID/GID بين الـ container والـ host. ده بيقلّل أثر container escape vulnerabilities بشكل ملموس، خصوصًا للـ multi-tenant clusters.
• OCI volumes stable: تقدر تعمل mount لـ OCI artifact مباشرة كـ volume. مفيد جدًا للـ AI models والـ large datasets اللي مكانش لها حل أنيق قبل كده.
• 26 alpha feature جديدة: مش للإنتاج لسه، بس ورقة المتابعة للكوارتر الجاي لو بتبني platform.

متى لا تستخدم scale-to-zero

مش كل workload يستاهل التبنّي. تجنّبه في الحالات دي:

• APIs بتخدم traffic بمعدل أقل من 1 request في الدقيقة لكن لازمها استجابة تحت 500ms.
• Workloads بتعتمد على in-memory cache كبير — الـ cold start هيمسح الـ cache كل مرة ويخلي كل طلب بطيء.
• Deployments عندها init containers بياخدوا وقت طويل (database migrations، model loading مثلًا).
• Clusters مفيهاش external metrics adapter مركّب — هتتعلّق على صفر ومش هترجع من أصلها.

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

لو عندك EKS أو GKE أو AKS، الـ upgrade لـ 1.36 هياخد أسابيع لحد ما يوصل الـ managed control plane بتاعك. في الوقت ده، اعمل حاجتين: حدّد 2 إلى 3 deployments من staging أو batch workers اللي ممكن يتحملوا cold start؛ وركّب KEDA لو مش مركّب عندك. لما الـ cluster يترقى، تفعيل scale-to-zero بقى سطر YAML واحد: minReplicas: 0. ابعت الأرقام اللي طلعت معاك بعد أول شهر، الفرق بيبان في الـ billing dashboard مباشرة.

المصادر

• Kubernetes 1.36 CHANGELOG الرسمي على GitHub — kubernetes/kubernetes CHANGELOG-1.36.md
• Kubernetes Enhancement Proposal رقم 2589 — HPAScaleToZero
• Perfect Scale: Kubernetes v1.36 Sneak Peek (أبريل 2026)
• Palark Tech Blog: Kubernetes 1.36 — Deep Dive into New Alpha Features
• Cloudsmith: Kubernetes 1.36 — What You Need to Know
• Dev.to — Kubernetes 1.36 Scale-to-Zero: Cut Your K8s Bill by 70%
• KEDA Documentation — External Metrics Adapter