Kubernetes HPA: خلّي تطبيقك يوسّع نفسه تلقائيًا حسب الحِمل

يتطلب هذا المقال مستوى: متوسط

لو تطبيقك بيقع وقت الذروة وانت دافع سيرفرات فاضية بقية اليوم، الـ Horizontal Pod Autoscaler بيحل المشكلتين مع بعض: بيزوّد عدد الـ Pods لمّا الحِمل يعلى، وبيرجّعه لمّا يهدأ. النتيجة إنك تدفع على قد ما بتستهلك فعلاً، من غير ما تقعد تراقب بإيدك.

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

لو ثبّتّ عدد الـ Pods يدويًا، قدامك خيارين وحشين. لو ثبّتّه على العدد الأقصى، بتدفع تكلفة الذروة 24 ساعة حتى والموقع فاضي. لو ثبّتّه على العدد الأدنى، أول موجة ضغط بتوقّعك: زمن الاستجابة بيقفز والـ 5xx بيبدأ يظهر. الـ HPA بيكسر المفاضلة دي لإنه بيخلّي العدد نفسه متغيّر حسب رقم حقيقي زي استهلاك المعالج.

الفكرة ببساطة: كاشير السوبر ماركت

تخيّل سوبر ماركت فيه 3 كاشير. الصبح الزحمة بسيطة، فـ 3 كفاية والطابور ماشي. بعد العصر الزحمة بتزيد، فالمدير بيفتح كاشير رابع وخامس عشان الطابور ميطولش. بالليل الزحمة بتقل، فبيقفل الزيادة ويرجّع 3. الـ HPA هو المدير ده بالظبط: بيبصّ على طول الطابور (استهلاك المعالج)، ويقرّر يفتح Pods زيادة ولا يقفلها.

وبشكل علمي دقيق: الـ HPA مورد (object) في Kubernetes بيراقب مقياسًا محددًا عبر كل Pods الـ Deployment، ويقارنه بقيمة هدف (target)، ثم يعدّل عدد النسخ (replicas) عشان يقرّب المقياس الفعلي من الهدف.

إزاي الـ HPA بيشتغل فعليًا

محرّك القرار حلقة تحكّم بتتكرر كل 15 ثانية افتراضيًا. في كل دورة بيقرأ استهلاك كل Pod من الـ metrics-server، ويحسب العدد المطلوب بالمعادلة دي:

desiredReplicas = ceil[ currentReplicas × ( currentMetric / desiredMetric ) ]

يعني لو شغّال 3 Pods ومتوسط المعالج 92% والهدف 70%، العدد المطلوب = ceil(3 × 92 / 70) = ceil(3.94) = 4 Pods. لو الضغط زاد أكتر، بيكمّل تزويد لحد ما يوصل للـ maxReplicas.

التطبيق العملي خطوة بخطوة

الشرح مبني على فرضية إن عندك Deployment اسمه web شغّال على Kubernetes 1.23 أو أحدث.

1. ركّب الـ metrics-server (مصدر أرقام المعالج):

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

1. تأكد إن الـ Deployment محدِّد resources.requests.cpu. من غير الـ request، الـ HPA مش هيعرف يحسب النسبة المئوية أصلًا.
2. عرّف الـ HPA بملف YAML (نسخة autoscaling/v2):

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 3
  maxReplicas: 12
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300

1. طبّقه وراقبه:

kubectl apply -f web-hpa.yaml
kubectl get hpa web-hpa --watch

1. اختبر التوسّع بضغط مصطنع:

kubectl run -it --rm load --image=busybox --restart=Never -- \
  /bin/sh -c "while true; do wget -q -O- http://web; done"

هتشوف عمود REPLICAS في مخرجات الـ watch بيطلع من 3 لـ 8 لـ 11 خلال دقيقة تقريبًا، وبعد ما توقف الضغط بيرجع تدريجيًا بسبب نافذة التهدئة.

أرقام من سيناريو واقعي

خدها على متجر إلكتروني بـ 50 ألف زائر/يوم، والترافيك بيتضاعف 5 مرات في نص ساعة وقت عرض فلاش. بالإعداد الثابت على 12 Pod كنت بتدفع طاقة الذروة طول اليوم. بإعداد HPA (min 3 / max 12): متوسط التشغيل اليومي نزل لحوالي 4 Pods، يعني وفّرت قرابة 65% من تكلفة الحوسبة على الطبقة دي. ووقت العرض، لمّا اتوسّع لـ 11 Pod، فضل الـ p95 حوالي 220 مللي ثانية بدل ما كان بيقفز لثوانٍ ويرمي أخطاء.

خد بالك من زمن رد الفعل: الـ metrics-server بياخد لحد 15 ثانية عشان يحدّث الأرقام، والـ HPA بيقرأ كل 15 ثانية، وإقلاع الـ Pod الجديد بياخد وقته. المجموع ممكن يوصل 40 لـ 60 ثانية من أول ما الحِمل يعلى لحد ما تدخل طاقة جديدة فعليًا.

الـ trade-offs اللي لازم تعرفها

بتكسب مرونة وتوفير تكلفة، بتخسر سرعة استجابة فورية وشوية تعقيد. النقاط المهمة:

• الـ HPA دقيق بقدر دقة الـ requests. لو الـ request غلط، النسبة المئوية غلط، والتوسّع كله غلط.
• في تأخير 40 لـ 60 ثانية في التوسّع لأعلى. الموجة المفاجئة الأقل من دقيقة بتضرب الـ Pods القديمة الأول.
• خطر التذبذب (توسّع وتقليص متكرر). نافذة stabilizationWindowSeconds (افتراضي 300 ثانية للتقليص) بتهدّيه.
• المعالج مش دايمًا المقياس الصح. لو تطبيقك مقيّد بالـ I/O أو الطابور، استخدم مقاييس مخصّصة زي طول قائمة الرسائل أو عدد الطلبات في الثانية.

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

مش كل حِمل ينفع معاه التوسّع الأفقي:

• أحمال ذات حالة (stateful) مش بتتوسّع أفقيًا بسهولة، زي قاعدة بيانات بكاتب واحد.
• Pods بطيئة الإقلاع (تسخين JVM دقيقتين مثلًا). التوسّع بيوصل متأخر؛ الأفضل توفير زائد أو أدوات تنبّؤية زي KEDA.
• موجات أقل من ثانية. حلقة الـ HPA كل 15 ثانية، أبطأ من إنها تلحق.
• لو عنق الزجاجة تحتك (اتصالات قاعدة البيانات مثلًا)، زيادة الـ Pods بتزوّد المشكلة مش بتحلّها. عالج الاختناق الأصلي الأول.

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

افتح Deployment واحد عندك دلوقتي وتأكد إنه محدِّد resources.requests.cpu، بعدين طبّق ملف الـ HPA أعلاه بـ min 2 و max 5، وشغّل kubectl get hpa --watch وانت بتعمل ضغط بسيط. لو عمود REPLICAS اتحرّك، يبقى شغّال عندك.

مصادر

• توثيق Kubernetes الرسمي — Horizontal Pod Autoscaling: kubernetes.io
• تفاصيل خوارزمية الحساب: Algorithm details
• سلوك التوسّع القابل للضبط (behavior / stabilization window): Configurable scaling behavior
• مشروع metrics-server: github.com/kubernetes-sigs/metrics-server