يتطلب هذا المقال مستوى: متوسط
لو تطبيقك بيقع وقت الذروة وانت دافع سيرفرات فاضية بقية اليوم، الـ 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 أو أحدث.
- ركّب الـ metrics-server (مصدر أرقام المعالج):
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml- تأكد إن الـ Deployment محدِّد
resources.requests.cpu. من غير الـ request، الـ HPA مش هيعرف يحسب النسبة المئوية أصلًا. - عرّف الـ HPA بملف YAML (نسخة autoscaling/v2):