في المرة الأولى التي واجه فيها notes-api حركة حقيقية على cluster مشترك، حدث أمران خلال ساعة. مهمّة دفعية (batch job) على الـ node نفسه استهلكت كل الذاكرة، فطُرد أحد Pods notes-api. ثم رفعت قفزة في الحركة استهلاك المعالج إلى أقصاه، وصار زمن الاستجابة بالثواني، وبقي عدد الـ Pods ثلاثة بالضبط لأن أحدًا لم يخبر Kubernetes بأنه يستطيع إضافة المزيد. الإخفاقان جاءا من الفجوة نفسها: لم يكن Kubernetes يعرف ما يحتاج إليه notes-api.
\nيستطيع كل container التصريح برقمين لكل مورد:
\n - name: api\n image: ghcr.io/skylane/notes-api:1.4.0\n resources:\n requests:\n cpu: 250m\n memory: 256Mi\n limits:\n memory: 512Mi250m تعني 250 millicores، أي ربع نواة معالج.يتصرّف الموردان بشكل مختلف جدًا حين يبلغ الـ container حدّه:
\nkubectl describe pod السبب OOMKilled ورمز الخروج 137، ويُعاد تشغيل الـ container.إذا ضبطت limit دون request، ينسخ Kubernetes الـ limit إلى الـ request. أما الـ request الأكبر من الـ limit فيُرفض مباشرة.
\n\nفي Node.js، أعطِ V8 سقفًا للـ heap تحت حدّ ذاكرة الـ container، مثلًا NODE_OPTIONS=--max-old-space-size=384 مع حدّ 512Mi. عندها يعمل جامع النفايات بجهد كلما امتلأت الذاكرة، بدلًا من أن تنهي النواة العملية دون إنذار.
لا تخمّن. شغّل notes-api تحت حمل واقعي وقِس:
\nkubectl top pods -l app.kubernetes.io/name=notes-apiيحتاج kubectl top إلى metrics-server، الذي تتضمّنه كثير من الـ clusters المُدارة أو تقدّمه كإضافة (add-on)؛ وفي kind تثبّته بنفسك. اضبط request المعالج قرب الاستهلاك المعتاد تحت الحمل العادي، واضبط request الذاكرة وحدّها مع هامش فوق الذروة التي لاحظتها. راجع الأرقام بعد الإصدارات الكبيرة. الـ requests المرتفعة جدًا تهدر المال على حجوزات خاملة؛ والمنخفضة جدًا تجعل الـ Pods تُحشر على nodes لا تستطيع حملها فعلًا.
من الـ requests والـ limits، يشتقّ Kubernetes فئة جودة الخدمة (Quality of Service class) لكل Pod:
\n| الفئة | \nالقاعدة | \nتُطرد عند ضغط ذاكرة الـ node | \n
|---|---|---|
| Guaranteed | \nلكل container requests للمعالج والذاكرة مساوية للـ limits | \nأخيرًا | \n
| Burstable | \nrequest أو limit واحد على الأقل مضبوط، لكنها ليست Guaranteed | \nبعد BestEffort، بدءًا بالـ Pods الأكثر تجاوزًا للـ requests الخاصة بها | \n
| BestEffort | \nلا requests ولا limits في أي مكان | \nأولًا | \n
notes-api في الأعلى من فئة Burstable. والمهمّة الدفعية التي سبّبت الطرد كانت BestEffort، فمع وجود الـ requests كانت ستُطرد قبل notes-api. تشغيل أحمال الإنتاج كـ BestEffort يعني أنك تتطوّع بها لتكون أول ما يُطرد.
\nالـ HorizontalPodAutoscaler (HPA) يعدّل عدد نسخ الـ Deployment بناءً على المقاييس. إنه حلقة تحكّم أخرى: كل 15 ثانية تقريبًا يقارن الاستهلاك الملحوظ بالهدف ويحسب عدد النسخ الذي سيعيد الاستهلاك إلى الهدف.
\napiVersion: autoscaling/v2\nkind: HorizontalPodAutoscaler\nmetadata:\n name: notes-api\n namespace: notes\nspec:\n scaleTargetRef:\n apiVersion: apps/v1\n kind: Deployment\n name: notes-api\n minReplicas: 3\n maxReplicas: 12\n metrics:\n - type: Resource\n resource:\n name: cpu\n target:\n type: Utilization\n averageUtilization: 70\n behavior:\n scaleDown:\n stabilizationWindowSeconds: 300القيمة averageUtilization: 70 تعني «أبقِ متوسط استهلاك المعالج عند 70% من request المعالج». مع request قدره 250m، هذا نحو 175m لكل Pod. عند ستة Pods بمتوسط 350m، يحسب الـ HPA 6 × 350 / 175 = 12 فيوسّع إلى الحدّ الأقصى. والكتلة behavior تجعل التقليص ينتظر خمس دقائق من الحمل المنخفض باستمرار، حتى لا يُزيل هدوءٌ عابر سعةً ستحتاج إليها بعد دقيقة. والدقائق الخمس هي القيمة الافتراضية أصلًا؛ لكن كتابتها صراحةً تجعل القرار ظاهرًا وسهل الضبط.
راقبه وهو يعمل بـ kubectl get hpa notes-api --watch أثناء تشغيل اختبار حمل. إذا أظهر عمود الأهداف <unknown>، فإمّا أن الـ containers ليس لها request للمعالج، أو أن metrics-server لا يعمل.
المعالج يناسب notes-api لأن عمله معالجة طلبات مرتبطة بالمعالج. أما الخدمات التي يظهر حملها في مكان آخر، مثل عمق الطابور أو عدد الطلبات في الثانية، فتستطيع التوسّع على مقاييس مخصّصة أو خارجية عبر قائمة metrics نفسها، مع adapter مثبّت في الـ cluster.
لدى notes-api الآن الموارد التي يحتاج إليها، وينمو مع الحمل. الدرس التالي يغيّر الـ image بأمان: التحديثات المتدرّجة، والتراجع، وتغليف كل شيء بـ Helm.
\n","toc":[{"id":"sec-1","text":"الـ Requests والـ Limits","level":2},{"id":"sec-2","text":"اختيار الأرقام","level":2},{"id":"sec-3","text":"فئات QoS والطرد","level":2},{"id":"sec-4","text":"التوسّع الأفقي التلقائي للـ Pods","level":2}],"takeaways":["الـ requests هي ما يحجزه الـ scheduler للـ container؛ والـ limits هي السقف المفروض وقت التشغيل.","تجاوز حدّ المعالج يخنق الـ container؛ وتجاوز حدّ الذاكرة يجعله يُقتل بـ OOM مع رمز الخروج 137.","فئة QoS تُشتقّ من الـ requests والـ limits: Guaranteed (متساوية لكل container)، وBurstable (بعضها مضبوط)، وBestEffort (لا شيء)، والـ Pods من فئة BestEffort تُطرد أولًا.","هدف استخدام المعالج في الـ HPA نسبة مئوية من request المعالج، فلا يعمل على containers ليس لها request.","حين يدير HPA كائن Deployment، احذفreplicas من manifest الـ Deployment حتى لا يتصارع kubectl apply مع الـ autoscaler."],"further":[{"title":"Resource Management for Pods and Containers","url":"https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/"},{"title":"Pod Quality of Service Classes","url":"https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/"},{"title":"Horizontal Pod Autoscaling","url":"https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/"}],"quiz":[{"q":"Pod من notes-api يُعاد تشغيله عدّة مرات في اليوم. ويعرض kubectl describe pod السبب Reason: OOMKilled وExit Code: 137. ماذا حدث؟
OOMKilled كسبب."},{"text":"استهلك الـ container ذاكرة أكثر من حدّه، فأنهاه الـ OOM killer في النواة.","why":"صحيح. ارفع حدّ الذاكرة ليناسب الاستهلاك الحقيقي، أو ابحث عن التسرّب؛ وفي Node.js ضع أيضًا سقفًا للـ heap في V8 تحت الحدّ."},{"text":"نفدت مساحة القرص المخصّصة للسجلات على الـ node.","why":"ضغط القرص يؤدّي إلى الطرد (eviction) بسبب مختلف، لا إلى قتل بسبب نفاد الذاكرة."}],"answer":2},{"q":"يستهدف HPA استخدامًا للمعالج بنسبة 70%، ويعرض kubectl get hpa القيمة cpu: <unknown>/70%. ما السبب الأرجح؟
autoscaling/v2، الذي لا يدعم المعالج.","why":"autoscaling/v2 يدعم المعالج والذاكرة والمقاييس المخصّصة والخارجية."},{"text":"containers notes-api ليس لها request للمعالج، فلا يمكن حساب نسبة الاستخدام (أو أن metrics-server غير مثبّت).","why":"صحيح. نسبة الاستخدام هي الاستهلاك مقسومًا على الـ request. لا request، لا نسبة. وتحقّق أيضًا من أن metrics-server يعمل."},{"text":"minReplicas أعلى من عدد النسخ الحالي.","why":"هذا يجعل الـ HPA يوسّع حتى الحدّ الأدنى؛ ولا يجعل المقاييس مجهولة."},{"text":"في الـ Deployment نسخ أكثر من أن يديرها الـ HPA.","why":"لا يوجد حدّ كهذا؛ يستطيع الـ HPA إدارة أي عدد ضمن حدوده."}],"answer":1},{"q":"يضبط notes-api القيم requests: {cpu: 250m, memory: 256Mi} وlimits: {memory: 512Mi}. ما فئة QoS التي يحصل عليها الـ Pod؟
الـ manifest الخاص بـ Deployment notes-api يقول replicas: 3، ووسّعه HPA إلى 9 أثناء ذروة حركة. ماذا يحدث حين يشغّل الـ CI الأمر kubectl apply -f k8s/؟
replicas من الـ manifest حالما يتولّاه HPA."},{"text":"لا شيء؛ الـ HPA يقفل حقل النسخ.","why":"الـ HPA يكتب في الحقل، لكنه لا يقفله. أي شيء آخر يكتب فيه يفوز حتى قرار الـ HPA التالي."},{"text":"يفشل apply بخطأ تعارض.","why":"مع الـ apply العادي من جهة العميل لا يوجد خطأ؛ إنه يكتب فوق القيمة بصمت، وهذا ما يجعل الأمر خطيرًا."},{"text":"يتغيّر minReplicas في الـ HPA إلى 3.","why":"تطبيق Deployment لا يعدّل كائن الـ HPA أبدًا."}],"answer":0}],"exercise":{"kind":"spot-bug","language":"yaml","code":"apiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: notes-api\nspec:\n replicas: 3\n # …selector and template labels as before\n template:\n spec:\n containers:\n - name: api\n image: ghcr.io/skylane/notes-api:1.4.0\n resources:\n limits:\n memory: 512Mi\n---\napiVersion: autoscaling/v2\nkind: HorizontalPodAutoscaler\nmetadata:\n name: notes-api\nspec:\n scaleTargetRef:\n apiVersion: apps/v1\n kind: Deployment\n name: notes-api\n minReplicas: 3\n maxReplicas: 12\n metrics:\n - type: Resource\n resource:\n name: cpu\n target:\n type: Utilization\n averageUtilization: 70","bugLines":[6,14],"title":"الـ autoscaler الذي لا يوسّع أبدًا","prompt":"يعرض kubectl get hpa notes-api القيمة cpu: <unknown>/70% مع أن metrics-server يعمل، وفي الأيام المزدحمة يهبط عدد النسخ إلى 3 في كل مرة ينشر فيها الـ CI. اختر السطرين الاثنين المسؤولين.
kubectl apply؟"],"explanation":"السطر 14: الـ container يضبط حدًّا للذاكرة فقط، فلا يوجد request للمعالج، ولا يستطيع الـ HPA حساب الاستخدام كنسبة منه. أضف الـ requests:
\n resources:\n requests:\n cpu: 250m\n memory: 256Mi\n limits:\n memory: 512Miالسطر 6: وجود replicas: 3 في الـ manifest يعني أن كل kubectl apply يعيد ضبط العدد، متصارعًا مع الـ HPA. احذف الحقل حالما يدير HPA الـ Deployment؛ فالحدّ الأدنى صار في minReplicas.