ليه الـ Pod بيموت بـ OOMKilled في Kubernetes وإزاي تمنعه

apiVersion: apps/v1
kind: Deployment
metadata:
  name: reports
spec:
  replicas: 6
  template:
    spec:
      containers:
        - name: app
          image: reports:1.4
          resources:
            requests:
              memory: "256Mi"
              cpu: "250m"
            limits:
              memory: "512Mi"
              cpu: "500m"

وبعد ما تطبّق، اتأكد من سبب أي موت بالأمر ده:

الأرقام: قبل وبعد على الخدمة الحقيقية

قبل الضبط (بدون limits): نسخة واحدة وصلت 6.8Gi، النود عمل OOM على مستواه، 4 خدمات اترمت، ~12,000 طلب 5xx، و9 دقايق downtime.

بعد ما حطينا requests: 256Mi و limits: 512Mi: لما النسخة المعطوبة كرّرت المشكلة، النظام قتلها هي بس عند 512Mi ورجّعها، الجيران فضلوا ثابتين، والـ 5xx في الحادثة التالية نزل لـ ~40 طلب. ده الفرق بين خدمة بتعزل عطلها وخدمة بتنشره على الكل.

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

• limit واطي جدًا: بتكسب حماية الجيران، بتخسر استقرار الخدمة نفسها لو الرقم أقل من الـ peak الطبيعي، فتلاقي OOMKilled متكرر.
• request عالي جدًا: بتكسب أولوية واستقرار في الجدولة، بتخسر كثافة على النود — بتحجز ذاكرة ممكن تفضل فاضية، يعني فاتورة أعلى.
• requests = limits: بيدّيك QoS class اسمها Guaranteed (أعلى أولوية وأقل احتمال للترحيل)، مقابل صفر مرونة لأي burst مؤقت.
• غلطة شائعة في الـ CPU: الـ trade-off هنا مختلف تمامًا. limit الـ CPU بيعمل throttling (تبطيء) مش قتل. ناس كتير بتحط CPU limit واطي وتلاقي الخدمة بطيئة وتدوّر على السبب في كل حتة غير الصح.

متى متحطش limit على الذاكرة

لو عندك workload بـ burst ذاكرة مؤقت وآمن (مثلاً معالجة دفعة كل ساعة) وانت متأكد من المراقبة إن النود فيه متسع، الـ memory limit الصارم ممكن يقتلها بدون أي داعي حقيقي. الافتراض إن عندك observability بتوريك الـ peak الفعلي قبل ما تقرر. وعلى نود مخصص لخدمة واحدة بس، الـ limit بيبقى أقل أهمية بكتير. أما الـ CPU limit تحديدًا فكتير من فرق الإنتاج بتشيله وتسيب الـ CPU request بس، لأن الـ throttling في الخدمات الحساسة للـ latency بيضر أكتر ما بينفع.

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

شغّل kubectl top pod على أهم خدمة عندك تحت حمل حقيقي ليوم كامل، سجّل أعلى رقم ذاكرة، حط requests = الرقم الطبيعي و limits = 1.5 ضعفه، طبّق، وبعد كام يوم اعمل kubectl describe pod وشوف فيه OOMKilled ولا لأ. لو فيه، ارفع الـ limit شوية وكرّر.

المصادر

• Kubernetes Docs — Resource Management for Pods and Containers
• Kubernetes Docs — Configure Quality of Service for Pods (QoS classes)
• Kubernetes Docs — Assign Memory Resources to Containers and Pods
• Linux Kernel Docs — Control Group v2 (memory controller)