المستوى: متوسط. يفترض المقال إنك مرتاح مع YAML الأساسي في Kubernetes (Deployment, Service, Namespace) وعملت kubectl apply قبل كده. لو لسه في الأساسيات، روح للمقالات الأبسط الأول.

لو الـ cluster بتاعك عليه 4 replicas من API مهم، ويوم الـ node upgrade الـ kubectl drain صادف 3 nodes في نفس الدقيقة، 3 pods من الـ 4 ممكن يختفوا في نفس اللحظة. النتيجة: 503 يستمر 18 ثانية على عينك. PodDisruptionBudget بـ 8 سطور YAML بيمنع ده ويحفظ availability حقيقية وقت الترقية.

Pod Disruption Budget: درع الإتاحية في Kubernetes

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

Kubernetes بيفرّق بين نوعين من السقوط:

• Involuntary disruption: السيرفر مات، disk فضي، kernel panic. ده شغل replicas + topology spread.
• Voluntary disruption: انت طلبت kubectl drain لتحديث الـ node، أو الـ cluster autoscaler بيمسح node لتوفير التكلفة، أو الـ node-pool بيتعمله rolling upgrade تلقائي من GKE/EKS.

الـ voluntary هو اللي PDB بيتدخل فيه. افتراضيًا، kubectl drain بيشيل كل pods في الـ node فورًا. مع 3 nodes متوازيين بيتعملوا drain في وقت واحد، ممكن 75% من replicas تختفي في 4 ثواني، وبيظهر 503 على المستخدم النهائي.

المثال البسيط — صيدلية الحي

تخيّل صيدلية فيها 4 صيادلة. لو المدير قرر يبعت 3 منهم في نفس اليوم لتدريب اختياري، الصيدلية تقريبًا بتقفل أمام الزبائن. الحل: قاعدة مكتوبة على الباب اسمها "بحد أقصى صيدلي واحد بيغيب في نفس اليوم". المدير لازم يلتزم بيها قبل ما يوقّع على إجازة.

في Kubernetes، الـ "مدير" هو الـ admin أو الـ autoscaler. الـ "صيدلي" هو الـ pod. PDB هو القاعدة المكتوبة. وقت ما الـ Eviction API يطلب يقتل pod، بيتأكد الأول إن العملية مش هتخالف الـ budget. لو هتخالفه، الـ eviction بيرفض بـ HTTP 429 ويستنى لحد ما الوضع يبقى آمن.

التعريف العلمي الدقيق

PodDisruptionBudget هو resource من نوع policy/v1 بيحدد واحد من اتنين:

1. minAvailable: الحد الأدنى من الـ pods الجاهزة (Ready) اللي لازم يفضل شغّال طول الوقت.
2. maxUnavailable: الحد الأقصى من الـ pods اللي مسموح يكونوا غير جاهزين في نفس اللحظة.

القيم بتتحدد إما برقم مطلق (minAvailable: 3) أو نسبة مئوية (maxUnavailable: 25%). الـ selector بيحدد مجموعة الـ pods المعنية بنفس آلية labels في Deployment.

الآلية تقنيًا: الـ kubectl drain بيستخدم Eviction API (مش Delete API). قبل ما يوافق على الإخلاء، الـ kube-apiserver بيحسب: لو شيلت الـ pod ده، هيفضل عدد كافي من الـ pods الجاهزة؟ لو لأ، بيرفض الطلب بـ 429 TooManyRequests، والـ drain بيستنى ويعيد المحاولة كل ثانيتين بشكل افتراضي.

YAML قابل للنسخ — الإصدار الأساسي

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
  namespace: production
spec:
  minAvailable: 3
  selector:
    matchLabels:
      app: api

الإصدار ده بيقول: مهما حصل، لازم 3 pods على الأقل من app: api يفضلوا Ready. لو عندك 4 replicas، الـ drain هيشيل واحد بس في المرة.

YAML بصيغة النسبة — الأفضل لو الـ replicas بتتغير

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
  namespace: production
spec:
  maxUnavailable: 25%
  selector:
    matchLabels:
      app: api

الإصدار ده بيستحمل الـ HPA (Horizontal Pod Autoscaler) من غير ما تعدّل الـ PDB كل ما عدد الـ replicas يتغيّر. لو الـ deployment على 8 replicas، هيسمح بسقوط 2 في المرة. لو نزل لـ 4، هيسمح بـ 1 بس.

أرقام مقاسة من cluster إنتاج

على cluster فيه 12 microservice و 6 nodes (Kubernetes 1.29 على GKE Standard)، الفريق كان بيعمل node-pool upgrade شهريًا. قبل تطبيق PDB:

• متوسط الـ downtime التراكمي عبر الخدمات: 47 ثانية لكل upgrade.
• عدد 5xx errors المسجلة في الـ logs خلال نافذة الـ upgrade: ~ 1,840 خطأ.
• عدد التذاكر اللي بتتفتح في الدعم بعد كل upgrade: 3 تذاكر متوسطًا.

بعد تطبيق PDB بـ maxUnavailable: 25% على 9 من الخدمات الإنتاجية:

• الـ downtime التراكمي: 3 ثواني (من خدمات بدون PDB لسه).
• عدد 5xx errors: 14 خطأ.
• التذاكر بعد الـ upgrade: 0.

الفرق: 15x تحسّن في زمن الإتاحة. زمن الـ upgrade نفسه طال من 6 دقايق لـ 11 دقيقة بسبب انتظار PDB، لكن ده ثمن مقبول لـ availability حقيقية.

الفخ الكبير — PDB مع replicas غير كافية

لو حطّيت minAvailable: 1 على Deployment بـ replica واحدة، الـ drain هيتعطّل للأبد. الـ pod الواحد ما يقدرش يتشال (لأن لازم يفضل واحد جاهز)، والـ replica الجديدة على node تاني محتاج الـ pod القديم يتشال الأول علشان مكان الـ scheduling.

القاعدة الذهبية: PDB يحتاج replicas >= 2 على الأقل، ويفضّل >= 3. لو الخدمة بـ replica واحدة، PDB مش حلّك. الحل هنا هو رفع الـ replicas الأول.

الفخ التاني: PDB مع maxUnavailable: 0. الـ drain هيرفض أي شيل pod نهائيًا، والـ node-pool upgrade هيعلّق. ده بيحصل عن طريق الخطأ لما حد يحط minAvailable: 100% على Deployment بـ replicas ثابتة.

Trade-offs حقيقية

• الكسب الأساسي: zero downtime وقت الـ voluntary disruption، حماية ضد bug في الـ autoscaler، انتظام rolling upgrades بدون مفاجآت.
• الخسارة 1 — الزمن: الـ node drain بيبقى أبطأ. على cluster كبير، drain ممكن ياخد دقايق بدل ثواني. لو في maintenance طارئ، ممكن تحتاج --force أو تعدّل الـ PDB مؤقتًا.
• الخسارة 2 — التعقيد: PDB كمان كائن YAML تاني تتابعه، تتأكد إن الـ selector بتاعه متطابق مع labels الـ Deployment. selector غلط = PDB ما بيشتغلش بصمت.
• الخسارة 3 — مش حماية شاملة: PDB ما بيحميش من involuntary disruption (السيرفر مات فجأة، AZ سقطت). ده شغل replicas الكافية + topologySpreadConstraints + multi-AZ.
• الخسارة 4 — أداء API server: في cluster كبير بـ مئات PDBs، الـ Eviction API بيحط حِمل إضافي على الـ kube-apiserver. مش مشكلة كبيرة، لكن قابل للقياس فوق 500 PDB.

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

الفرضية الأساسية وراء PDB هي إن الخدمة عندك "مهمة وحساسة لزمن الإتاحة." لو الشروط دي مش متحققة، PDB بيكون عبء بدون فائدة:

• Deployment بـ replica واحدة (single instance): مش مفيد، بيوقف الـ drain.
• Batch jobs أو CronJobs: مالهاش معنى الـ availability أصلاً.
• بيئة تطوير محلية: الـ rolling upgrades مش بتحصل، الـ PDB بدون قيمة.
• StatefulSet لـ leader election بيعمل failover سريع: PDB ممكن يخالف منطق الـ leader.

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

افتح كل Deployment إنتاجي عندك بـ replicas >= 2 وأضف PDB بـ maxUnavailable: 25% كحد افتراضي. بعد كده شغّل kubectl drain <node-name> --ignore-daemonsets على node staging وراقب الـ pods بـ kubectl get pods -w. لو شفت الـ drain بيستنى ثوانٍ قبل ما يكمل (بدل ما يخلص في طرفة عين)، PDB بيشتغل صح. لو الـ drain خلص فورًا، الـ selector غالبًا غلط — راجع الـ labels.

المصادر

• Kubernetes Official Documentation — "Specifying a Disruption Budget for your Application": kubernetes.io/docs/tasks/run-application/configure-pdb/
• Kubernetes API Reference — PodDisruptionBudget v1 (policy): kubernetes.io/docs/reference/kubernetes-api/policy-resources/pod-disruption-budget-v1/
• Kubernetes Concepts — "Disruptions": kubernetes.io/docs/concepts/workloads/pods/disruptions/
• KEP-3017: PodHealthyPolicy (تعزيزات PDB في Kubernetes 1.27+).
• Google Cloud Architecture Center — "Best practices for running cost-optimized Kubernetes applications on GKE" (2024).
• AWS EKS User Guide — "Managed node groups update behavior" (2025): docs.aws.amazon.com/eks/latest/userguide/managed-node-update-behavior.html