Pod Disruption Budget للمتوسط: امنع downtime وقت الـ Kubernetes Cluster Upgrade

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

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

الإصدار ده بيستحمل الـ 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