مستوى المقال: متوسط — لازم تكون عارف Kubernetes basics (Pod, Deployment, kubectl) قبل ما تبدأ. وقت القراءة المتوقع: 9 دقايق.

لو شغّال cluster Kubernetes فيه 6 replicas من خدمة الـ checkout بتاعتك، ويوم Cloud provider بيعمل node maintenance، أمر kubectl drain على نود واحدة ممكن يشيل 4 pods دفعة واحدة. خدمتك بتقع 38 ثانية في عز اليوم. Pod Disruption Budget — اختصارًا PDB — بـ 12 سطر YAML بيقفل الباب ده. هتعرف هنا بالظبط إزاي، بأرقام حقيقية، ومتى الـ PDB نفسه بيبقى فخ.

ليه Kubernetes ممكن يطفي نص خدمتك في عز اليوم

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

Kubernetes افتراضيًا بيوازن بين 3 أهداف: scheduling سريع، استخدام أمثل للنودز، وتنفيذ أوامر cluster operator زي drain و upgrade. لما تيجي تعمل kubectl drain node-3 علشان تنزّل نسخة جديدة من الـ kernel أو تعمل scale-down للنودز، الـ kubelet بيرسل eviction request لكل pod موجود على النود. لو 4 من أصل 6 pods الخاصة بخدمة الـ checkout كانوا قاعدين على node-3، انت فجأة بقيت بـ 2 pods فقط تخدم نفس الترافيك. النتيجة: 5xx errors للمستخدمين لحد ما الـ pods الجديدة تستوي على نودز تانية وتجتاز الـ readiness probe.

مثال محل الفلافل — قبل ما نروح للتعريف العلمي

تخيّل إن عندك محل فلافل، وفيه 6 طباخين شغّالين على 3 طاولات. كل طاولة فيها طباخين اتنين. الأكلة العادية: 6 طلبات بالتوازي.

المدير قرر يغيّر زيت طاولة كاملة، فطلب من الطباخين اللي عليها يقوموا فورًا. مفيش قاعدة مكتوبة بتقول "أقل عدد طباخين يفضل شغّال هو 4". النتيجة؟ المحل بقى عنده 4 طباخين بس، الزبون بيستنى دقيقتين بدل 20 ثانية، والشكاوى بتطلع على Google Reviews.

الحل الصح هو قاعدة مكتوبة على باب المطبخ: "ممنوع يقوم أكتر من 2 طباخين في نفس الوقت". المدير لما يجي يغيّر الزيت، يخلّي طاولة واحدة الأول، يستنّى الطباخين الجداد ييجوا، وبعدين يحرك على التانية. ده بالظبط هو الـ PDB — مش بيمنع الصيانة، بس بينظّمها.

تعريف PDB من توثيق Kubernetes الرسمي

Pod Disruption Budget هو object من نوع policy/v1.PodDisruptionBudget بيحدد لـ Kubernetes إما أقل عدد من الـ pods لازم يفضلوا متاحين (minAvailable)، أو أقصى عدد ممكن يبقى مش متاح (maxUnavailable)، أثناء أي Voluntary Disruption. التعريف الكامل في Kubernetes 1.32 Docs — Specifying a Disruption Budget.

الفرق بين Voluntary و Involuntary Disruption

• Voluntary disruption: حاجة بتعملها انت أو cluster operator بإرادة — kubectl drain، rolling update، cluster autoscaler scale-down، أو deletion عبر eviction API. PDB بيحمي من دي.
• Involuntary disruption: حاجة خارجة عن السيطرة — node crash، kernel panic، hardware failure، AWS spot instance termination. PDB مش بيحمي من دي. علشان كده بتحتاج replicas كافية + topologySpreadConstraints + multi-AZ deployment.

12 سطر YAML بيحلّ المشكلة

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: checkout-pdb
  namespace: production
spec:
  minAvailable: 4
  selector:
    matchLabels:
      app: checkout
  unhealthyPodEvictionPolicy: AlwaysAllow

الـ YAML ده بيقول: "في namespace اسمه production، أي pod ليه label اسمه app=checkout، لازم يفضل منهم 4 شغّالين متاحين على الأقل". لما تيجي تعمل drain، الـ Eviction API بترفض الأمر لو هينزّل العدد تحت 4، وبترجّع رسالة Cannot evict pod as it would violate the pod's disruption budget. الـ operator بيستنّى لحد ما الـ replicas الجديدة تبقى Ready، ثم يكمّل.

الـ unhealthyPodEvictionPolicy: ليه مهم

الحقل ده اتضاف رسميًا في Kubernetes 1.27 (Beta) و 1.31 (Stable) عبر KEP-3017. القيمة الافتراضية IfHealthyBudget بترفض شيل الـ pod حتى لو كان نفسه crashing — وده بيدخّل cluster في deadlock مشهور: pod بيكرّر CrashLoopBackOff، الـ PDB بترفض إخلاءه، الـ drain عالق ساعات. القيمة AlwaysAllow بتسمح بإخلاء الـ pods اللي مش Ready أصلاً، فالـ drain يكمّل والـ scheduler بيرتّب pods جديدة على نود تانية.

اختر minAvailable ولا maxUnavailable

• لو الـ replicas ثابت (مثلًا 6 دائمًا): استخدم minAvailable: 4. أوضح للقراءة.
• لو الـ replicas متغير (HPA شغّال): استخدم maxUnavailable: 25% علشان النسبة تتعدّل تلقائيًا مع الـ scale up/down.
• ممنوع تكتب minAvailable و maxUnavailable سوا — Kubernetes هيرفض الـ resource في الـ admission.

أرقام مقاسة على إنتاج

على cluster GKE Standard فيه 24 microservice و14K طلب/دقيقة في ساعة الذروة:

• قبل PDB: كل node upgrade شهري كان بيسبب 28-48 ثانية من 5xx errors لخدمتين على الأقل. متوسط P95 latency أثناء الـ drain: 4.2 ثانية. عدد التذاكر من فريق الدعم بعد كل upgrade: 11.
• بعد PDB (minAvailable: replicas - 1 لكل deployment ≥ 3 replicas): صفر 5xx مرتبطة بـ voluntary drain على مدار 6 شهور. P95 latency أثناء الـ drain: 320ms.
• التكلفة الإضافية: صفر CPU و صفر memory — PDB resource مجرد قاعدة في etcd بيحجم 800 byte. الـ overhead الحقيقي هو إن الـ node upgrade بقى ياخد 14 دقيقة بدل 6.

نمط الأرقام دي موثّق نظريًا في Kubernetes Disruptions Concepts وعمليًا في Google SRE Book — Embracing Risk الفصل اللي بيتكلم عن error budgets و planned maintenance.

4 trade-offs خفية لازم تعرفها قبل ما تنشر PDB

1. PDB ممكن يقفل node upgrade للأبد. لو حطيت minAvailable: 100% أو عدد replicas مساوي للحد الأدنى بالظبط، الـ drain هيفشل ويرجع رسالة الـ violation. الحل: replicas ≥ minAvailable + 1، على الأقل واحد فايض دايمًا.
2. الـ HPA مش بياخد PDB في حسبته. لو HPA قرر يـ scale down من 10 لـ 4 وانت كاتب minAvailable: 6، الـ scale-down عالق وتفضل تدفع تكلفة 4 pods أنت مش محتاجهم. خلّي PDB دايمًا أقل من minReplicas في الـ HPA.
3. PDB بيشتغل على Eviction API بس، مش delete. لو حد عمل kubectl delete pod <name> --force --grace-period=0، PDB بيتجاهلها تمامًا. الحماية فعّالة فقط مع drain والـ controllers الرسمية. علشان كده RBAC على pods/delete مهم بنفس قدر الـ PDB.
4. الـ PDB مالوش معنى مع DaemonSet. الـ DaemonSet ليه pod واحد لكل node بطبيعته، فـ minAvailable أو maxUnavailable مالوش معنى — drain هيشيله بأي حال. استخدم terminationGracePeriodSeconds و pre-stop hook مناسب بدل.

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

• Workload بـ replica واحد بس (مثلًا job، cronjob، أو singleton بدون leader election). PDB هنا بيقفل أي maintenance على النود اللي عليها الـ pod. الحل الصح: replicas ≥ 2 + leader election، أو خلّي الـ workload Stateless ويترمي على نود تاني بدون PDB.
• StatefulSet مع leader election بطيء. PDB ممكن يدخّلك في deadlock مع podAntiAffinity اللي بيمنع الـ pod الجديد من الـ scheduling على نفس النود. استخدم parallelPodManagement: Parallel أو خلّي minAvailable = N-1 فقط، مش أكتر.
• Dev/staging clusters قصيرة العمر. الـ PDB بيعقّد cluster lifecycle بدون فايدة في بيئة مش بتخدم ترافيك حقيقي. خلّيها للـ production فقط.

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

افتح أي deployment في الـ namespace الإنتاجي بتاعك دلوقتي. لو عدد replicas ≥ 3 وملوش PDB مرتبط بيه، أضف PDB بـ minAvailable: replicas - 1 في 5 دقايق. شغّل kubectl get events --field-selector reason=Evicted -n production --watch خلال أول drain جاي، وقارن مع آخر صيانة قبل التعديل. لو لسه شايف 5xx، المشكلة في الـ readiness probe مش في PDB — ابعت الـ output في تعليق على المقال.

المصادر

• Kubernetes Docs — Specifying a Disruption Budget for your Application (v1.32)
• Kubernetes Docs — Disruptions (Voluntary vs Involuntary)
• KEP-3017 — Pod Healthy Policy for PodDisruptionBudget
• Kubernetes Blog — Unhealthy Pod Eviction Policy for PDBs (v1.27 Beta)
• Google SRE Book — Embracing Risk