تغيير حجم Pods الـ Kubernetes بدون إعادة تشغيل (دليل 2026)

يمكنك تغيير وحدة المعالجة المركزية (CPU) والذاكرة (Memory) لـ Pod قيد التشغيل في مكانه عن طريق تحديث المصدر الفرعي resize الخاص به — kubectl patch pod <name> --subresource resize. يتم تطبيق تغييرات CPU بدون إعادة تشغيل افتراضيًا؛ أما الذاكرة فتعيد تشغيل الحاوية (Container) فقط إذا قمت بضبط resizePolicy: RestartContainer. لا يتم إعادة إنشاء الـ Pod أبدًا.

ملخص

تغيير حجم الـ Pod في مكانه (In-place pod resize) يسمح لك برفع أو خفض طلبات (Requests) وحدود (Limits) الـ CPU والذاكرة للحاوية في Pod قيد التشغيل دون إعادة إنشائه.¹ وصل الميزة إلى المرحلة المستقرة (GA) في Kubernetes v1.35² (تم إصداره في ديسمبر 2025³) وهي مفعلة افتراضيًا من خلال بوابة الميزات InPlacePodVerticalScaling؛ الإصدار الحالي وقت كتابة هذا المقال هو v1.36 "Haru"⁴. يمكنك تفعيل تغيير الحجم عبر المصدر الفرعي resize للـ Pod باستخدام kubectl patch ... --subresource resize (يتطلب علم --subresource إصدار kubectl v1.32+).⁵ يتم تطبيق تغييرات حجم CPU بشفافية؛ بينما تقوم تغييرات حجم الذاكرة بتحديث الـ cgroup في مكانه ما لم تختر إعادة تشغيل الحاوية عبر resizePolicy. لا تتغير فئة QoS أبدًا، وهناك مجموعة محدودة من الـ Pods (مثل Windows، والسياسات الثابتة static-policy، وحاويات init غير القابلة لإعادة التشغيل) لا يمكن تغيير حجمها على الإطلاق.² تم التحقق من هذا الدليل مقابل وثائق Kubernetes الرسمية للإصدارين v1.35/v1.36 اعتبارًا من 16 يونيو 2026.

ما ستتعلمه

• ما هو تغيير حجم الـ Pod في مكانه وأي إصدار من Kubernetes جعله مستقرًا (GA)
• كيفية تغيير حجم CPU الخاص بالـ Pod دون إعادة تشغيله، خطوة بخطوة باستخدام kubectl
• كيفية تغيير حجم الذاكرة، ولماذا قد تظل بحاجة لإعادة تشغيل الحاوية
• ماذا يفعل حقل resizePolicy (الفرق بين NotRequired و RestartContainer)
• هل يغير تغيير الحجم فئة QoS الخاصة بالـ Pod
• كيفية قراءة حالة تغيير الحجم باستخدام حالتي PodResizePending و PodResizeInProgress
• القيود التي تجعل بعض الـ Pods غير قابلة لتغيير الحجم
• كيف ترتبط أدوات القياس التلقائي (HPA، VPA) بتغيير الحجم في المكان
• كيف يختلف تغيير الحجم عن تعديل الـ Deployment

ما هو تغيير حجم الـ Pod في مكانه في Kubernetes؟

تغيير حجم الـ Pod في مكانه هو القدرة على تغيير requests و limits الخاصة بـ CPU والذاكرة لحاوية في Pod قيد التشغيل دون حذف ذلك الـ Pod وإعادة إنشائه.¹ تاريخيًا، كان حقل spec.containers[*].resources غير قابل للتغيير: أي تغيير كان يجبر متحكم حمل العمل (workload controller) على طرح Pods بديلة. تجعل هذه الميزة تلك الحقول قابلة للتغيير لـ CPU والذاكرة، حيث يقوم kubelet بتطبيق التغيير على الحاوية الحية.²

القيم المطلوبة توجد في spec.containers[*].resources كما في السابق؛ أما القيم الفعلية المطبقة حاليًا على الحاوية فيتم الإبلاغ عنها بشكل منفصل في status.containerStatuses[*].resources، حتى تتمكن من معرفة ما إذا كان تغيير الحجم المطلوب قد دخل حيز التنفيذ أم لا.²

أي إصدار من Kubernetes جعل تغيير حجم الـ Pod في مكانه مستقرًا (GA)؟

تخرجت ميزة تغيير حجم الـ Pod في مكانه إلى المرحلة المستقرة (GA) في Kubernetes v1.35.² ظهرت لأول مرة كنسخة تجريبية أولية (alpha) في v1.27 (مايو 2023)⁶، وانتقلت إلى النسخة التجريبية (beta) وأصبحت مفعلة افتراضيًا في v1.33 (مايو 2025)⁷، ووصلت إلى GA في v1.35، الذي تم إصداره في 17 ديسمبر 2025.³ بوابة الميزات المتحكمة هي InPlacePodVerticalScaling. إصدار Kubernetes الحالي وقت كتابة هذا المقال هو v1.36 "Haru" (22 أبريل 2026).⁴

لاحظ نقطة واحدة قد تسبب ارتباكًا: تغيير الحجم على مستوى الحاوية (هذا الدليل) هو GA في v1.35، بينما تغيير حجم الموارد على مستوى الـ Pod — أي تغيير إجمالي spec.resources للـ Pod بالكامل — هو ميزة منفصلة وأحدث وهي في مرحلة beta في v1.36.⁸

كيف يمكنني تغيير حجم CPU الخاص بالـ Pod دون إعادة تشغيله؟

استخدم kubectl patch ضد المصدر الفرعي resize للـ Pod. يتم تطبيق تغييرات CPU افتراضيًا في المكان، لذا لا تحدث إعادة تشغيل.² أولاً، قم بإنشاء Pod صغير:

# resize-demo.yaml
apiVersion: v1
kind: Pod
metadata:
  name: resize-demo
spec:
  containers:
    - name: app
      image: nginx:1.30
      resizePolicy:
        - resourceName: cpu
          restartPolicy: NotRequired
        - resourceName: memory
          restartPolicy: NotRequired
      resources:
        requests:
          cpu: "250m"
          memory: "256Mi"
        limits:
          cpu: "500m"
          memory: "512Mi"

kubectl apply -f resize-demo.yaml

الآن قم بزيادة CPU في الـ Pod قيد التشغيل من خلال المصدر الفرعي resize:

kubectl patch pod resize-demo --subresource resize --patch \
  '{"spec":{"containers":[{"name":"app","resources":{"requests":{"cpu":"800m"},"limits":{"cpu":"800m"}}}]}}'

تأكد من أن الحاوية لم يتم إعادة تشغيلها وأن قيمة CPU الجديدة مفعلة:

# يظل restartCount كما هو
kubectl get pod resize-demo -o jsonpath='{.status.containerStatuses[0].restartCount}{"\n"}'

# الموارد المطبقة فعليًا، على عكس المواصفات المطلوبة (spec)
kubectl get pod resize-demo \
  -o jsonpath='{.status.containerStatuses[0].resources}{"\n"}'

يتطلب علم --subresource resize عميل kubectl بإصدار v1.32 أو أحدث؛ استخدمه مع عنقود (cluster) بإصدار v1.35+ للحصول على سلوك GA.⁵

كيف يمكنني تغيير حجم ذاكرة الـ Pod، ولماذا قد تظل بحاجة لإعادة تشغيل؟

يعمل تغيير حجم الذاكرة بنفس الطريقة — تحديث المصدر الفرعي resize — ولكن ما إذا كانت الحاوية ستعيد التشغيل يعتمد على resizePolicy الخاص بها للذاكرة.² مع القيمة الافتراضية NotRequired، يقوم kubelet فقط بتحديث الـ memory cgroup في مكانه. مع RestartContainer، يقوم kubelet بإعادة تشغيل تلك الحاوية (لا يتم إعادة إنشاء الـ Pod) حتى تتمكن العملية من إعادة قراءة إعدادات الذاكرة الخاصة بها:

kubectl patch pod resize-demo --subresource resize --patch \
  '{"spec":{"containers":[{"name":"app","resources":{"requests":{"memory":"512Mi"},"limits":{"memory":"1Gi"}}}]}}'

الخطأ الشائع: العديد من بيئات التشغيل (runtimes) تحدد حجم الـ heap الخاص بها مرة واحدة عند بدء التشغيل. على سبيل المثال، JVM الذي تم تشغيله بـ -Xmx ثابت، لن يستخدم ذاكرة إضافية لمجرد أن حد الـ cgroup قد زاد — بل يحتاج إلى إعادة تشغيل لالتقاط السقف الجديد. بالنسبة لأحمال العمل هذه، قم بضبط restartPolicy: RestartContainer على مورد الذاكرة حتى يدخل تغيير الحجم حيز التنفيذ فعليًا.⁹ أصبح تقليل حدود الذاكرة — الذي كان محظورًا سابقًا — مسموحًا به خلال فترة الـ beta (في v1.34): يبذل kubelet قصارى جهده لتجنب عمليات القتل بسبب نقص الذاكرة (OOM-kills)، وإذا كانت الحاوية تستخدم بالفعل أكثر من الحد المقترح، يظل تغيير الحجم قيد التنفيذ بدلاً من تطبيقه.²¹⁰

ما هو حقل resizePolicy (NotRequired مقابل RestartContainer)؟

resizePolicy هي قائمة لكل مورد في الحاوية تخبر kubelet بكيفية تطبيق تغيير الحجم.² يقرن كل إدخال اسم مورد resourceName (cpu أو memory) مع سياسة إعادة تشغيل restartPolicy:

إذا حذفت resizePolicy، فسيتم تعيينها افتراضيًا إلى NotRequired لكل من CPU والذاكرة.² نظرًا لأن هذا الوضع الافتراضي يزيد الذاكرة بصمت دون إعادة تشغيل العملية، كن صريحًا بشأن سياسة الذاكرة عندما يحتاج تطبيقك إلى إعادة تشغيل لاستخدامها.

هل يؤدي تغيير حجم الـ pod إلى تغيير فئة QoS الخاصة به؟

لا. فئة جودة الخدمة (Quality of Service) للـ pod — سواء كانت Guaranteed، أو Burstable، أو BestEffort — تكون ثابتة عند إنشاء الـ pod ولا يمكن لتغيير الحجم تغييرها.² يجب أن تظل قيمك الجديدة مستوفية للفئة الأصلية: يجب أن يحافظ الـ pod من فئة Guaranteed على تساوي requests مع limits لكل من CPU والذاكرة بعد تغيير الحجم، وإلا سيتم رفض الطلب.¹¹ وهذا هو السبب في أنك تحتاج أحيانًا إلى تعديل كل من requests و limits معًا، كما في مثال CPU أعلاه.

كيف يمكنني التحقق من حالة تغيير الحجم؟

راقب حالتين (conditions) للـ pod والموارد الفعلية المطبقة.² يظهر تغيير الحجم الذي لا يمكن إكماله فورًا كـ PodResizePending، مع ذكر السبب:

• Infeasible — لا يمكن تلبية الطلب أبدًا على هذه العقدة (على سبيل المثال، يتجاوز سعة العقدة، أو يستخدم الـ pod سياسة إدارة موارد ثابتة).²
• Deferred — تغيير الحجم ممكن من حيث المبدأ ولكن لا يمكن القيام به الآن (تفتقر العقدة إلى مساحة خالية)، لذا يقوم kubelet بإعادة تقييمه لاحقًا، مع تحديد الأولويات حسب PriorityClass وفئة QoS ومدة انتظار طلب تغيير الحجم.²

بينما يقوم kubelet بتطبيق تغيير حجم مقبول، يظهر الـ pod حالة PodResizeInProgress.² افحص كل شيء باستخدام:

kubectl describe pod resize-demo        # تعرض الحالات والأحداث
kubectl get pod resize-demo \
  -o jsonpath='{.status.containerStatuses[0].resources}{"\n"}'   # القيم الفعلية

قارن status.containerStatuses[*].resources (الفعلي) مقابل spec.containers[*].resources (المطلوب) للتأكد من تطبيق التغيير.²

ما هي قيود تغيير حجم الـ pod في مكانه؟

تم تحديد نطاق الميزة عمدًا. بدءًا من الإصدار v1.35/v1.36، لا يمكنك:²

• تغيير حجم أي شيء بخلاف CPU والذاكرة في مكانه.
• تغيير فئة QoS للـ pod.
• تغيير حجم حاويات البدء غير القابلة لإعادة التشغيل (non-restartable init containers) أو الحاويات المؤقتة (يمكن تغيير حجم الحاويات الجانبية "sidecar" القابلة لإعادة التشغيل).
• تغيير حجم الـ pods المقيدة بسياسات مدير CPU الثابت أو مدير الذاكرة الثابت — يتم وضع علامة Infeasible على عمليات تغيير الحجم هذه.
• استخدامها على Windows pods، فهي غير مدعومة.

تغيير الحجم الذي يتجاوز سعة العقدة القابلة للتخصيص يظل أيضًا معلقًا كـ Infeasible حتى توفر مساحة أو يتم تقليل الطلب.²

هل يمكنني استخدام القياس التلقائي مع تغيير الحجم في مكانه (HPA أو VPA)؟

لا علاقة لـ Horizontal Pod Autoscaler بالأمر: فهو يغير عدد النسخ المتماثلة، وليس موارد pod واحد، ولا يستخدم تغيير الحجم في مكانه.² القياس الرأسي (Vertical autoscaling) هو المكان الذي يناسبه تغيير الحجم في مكانه. يمكن لـ Vertical Pod Autoscaler تطبيق التوصيات من خلال وضع InPlaceOrRecreate الذي يغير الحجم في مكانه عندما يكون ذلك ممكنًا ويعود إلى الإخلاء وإعادة الإنشاء (evict-and-recreate) بخلاف ذلك — ولكن هذا الوضع في مرحلة alpha (خلف بوابة ميزة VPA، ومعطل افتراضيًا) اعتبارًا من عام 2026، لذا تعامل معه كأمر تجريبي وليس جاهزًا للإنتاج.¹²

كيف يختلف تغيير الحجم عن تعديل Deployment؟

تعديل resources في Deployment (أو أي قالب pod) يغير القالب، مما يؤدي إلى استبدال تدريجي (rolling replacement): يقوم Kubernetes بتشغيل pods جديدة بالموارد الجديدة وإيقاف القديمة. أما المورد الفرعي resize فيقوم بتعديل الـ pod الذي يعمل بالفعل، دون إنشاء pod جديد — وبالنسبة لـ CPU، أو الذاكرة تحت سياسة NotRequired — دون إعادة تشغيل على الإطلاق.² بالنسبة لضبط حجم أعباء العمل طويلة الأمد أو التي تحتفظ بالحالة (stateful) في "اليوم الثاني" (day-2)، فإن هذا الاختلاف هو الهدف الأساسي. إذا كنت تريد عملية نشر محكومة بدلاً من ذلك، فراجع دليلنا حول عمليات النشر بدون وقت توقف في Kubernetes.

الخلاصة

تعمل ميزة إعادة تحجيم الـ pod في المكان على تحويل المعالج والذاكرة إلى شيء يمكنك ضبطه على pod يعمل بالفعل بدلاً من أن يكون سبباً في إعادة تشغيل عبء العمل بالكامل. ابدأ بتعيين resizePolicy بشكل صريح لكل مورد، وقم بإجراء التغييرات من خلال المورد الفرعي resize، وراقب status.containerStatuses[*].resources بالإضافة إلى حالات PodResize* للتأكد من تطبيقها. إنها تتوافق بشكل طبيعي مع الحاويات الجانبية (sidecar) الأصلية للحاويات المساعدة في ضبط الموارد، ومع دليل الهجرة إلى Gateway API كجزء من مجموعة أدوات Kubernetes الحديثة الأوسع. بالنسبة للتحجيم التلقائي، راقب وضع "في المكان" الخاص بـ VPA، ولكن لا تعتمد عليه في بيئات الإنتاج حتى يخرج من المرحلة التجريبية (alpha).