--- title: تغيير حجم Pods الـ Kubernetes بدون إعادة تشغيل (دليل 2026) description: 'تغيير حجم الـ CPU والـ memory لـ pod Kubernetes شغال بدون إعادة تشغيله باستخدام الـ in-place resize: أوامر kubectl، والـ resizePolicy، وقواعد الـ QoS، والمحددات.' url: https://nerdleveltech.com/ar/resize-kubernetes-pods-without-restart language: ar date: '2026-06-16' category: cloud-devops tags: - kubernetes - in-place pod resize - vertical scaling - kubectl - cloud-devops - autoscaling - resizePolicy markdown_url: https://nerdleveltech.com/ar/resize-kubernetes-pods-without-restart.md attribution: 'Source: NerdLevelTech — https://nerdleveltech.com/ar/resize-kubernetes-pods-without-restart' terms: https://nerdleveltech.com/llms.txt --- # تغيير حجم Pods الـ Kubernetes بدون إعادة تشغيل (دليل 2026) يمكنك تغيير وحدة المعالجة المركزية (CPU) والذاكرة (Memory) لـ Pod قيد التشغيل في مكانه عن طريق تحديث المصدر الفرعي `resize` الخاص به — `kubectl patch pod --subresource resize`. يتم تطبيق تغييرات CPU بدون إعادة تشغيل افتراضيًا؛ أما الذاكرة فتعيد تشغيل الحاوية (Container) فقط إذا قمت بضبط `resizePolicy: RestartContainer`. لا يتم إعادة إنشاء الـ Pod أبدًا. ## ملخص تغيير حجم الـ Pod في مكانه (In-place pod resize) يسمح لك برفع أو خفض طلبات (Requests) وحدود (Limits) الـ CPU والذاكرة للحاوية في Pod **قيد التشغيل** دون إعادة إنشائه.[^ga] وصل الميزة إلى **المرحلة المستقرة (GA) في Kubernetes v1.35**[^docs] (تم إصداره في ديسمبر 2025[^releases]) وهي مفعلة افتراضيًا من خلال بوابة الميزات `InPlacePodVerticalScaling`؛ الإصدار الحالي وقت كتابة هذا المقال هو **v1.36 "Haru"**[^v136]. يمكنك تفعيل تغيير الحجم عبر المصدر الفرعي `resize` للـ Pod باستخدام `kubectl patch ... --subresource resize` (يتطلب علم `--subresource` إصدار kubectl v1.32+).[^subres] يتم تطبيق تغييرات حجم CPU بشفافية؛ بينما تقوم تغييرات حجم الذاكرة بتحديث الـ cgroup في مكانه ما لم تختر إعادة تشغيل الحاوية عبر `resizePolicy`. لا تتغير فئة QoS أبدًا، وهناك مجموعة محدودة من الـ Pods (مثل Windows، والسياسات الثابتة static-policy، وحاويات init غير القابلة لإعادة التشغيل) لا يمكن تغيير حجمها على الإطلاق.[^docs] تم التحقق من هذا الدليل مقابل وثائق 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 وإعادة إنشائه.[^ga] تاريخيًا، كان حقل `spec.containers[*].resources` غير قابل للتغيير: أي تغيير كان يجبر متحكم حمل العمل (workload controller) على طرح Pods بديلة. تجعل هذه الميزة تلك الحقول قابلة للتغيير لـ CPU والذاكرة، حيث يقوم kubelet بتطبيق التغيير على الحاوية الحية.[^docs] القيم المطلوبة توجد في `spec.containers[*].resources` كما في السابق؛ أما القيم **الفعلية** المطبقة حاليًا على الحاوية فيتم الإبلاغ عنها بشكل منفصل في `status.containerStatuses[*].resources`، حتى تتمكن من معرفة ما إذا كان تغيير الحجم المطلوب قد دخل حيز التنفيذ أم لا.[^docs] ## أي إصدار من Kubernetes جعل تغيير حجم الـ Pod في مكانه مستقرًا (GA)؟ تخرجت ميزة تغيير حجم الـ Pod في مكانه إلى **المرحلة المستقرة (GA) في Kubernetes v1.35**.[^docs] ظهرت لأول مرة كنسخة تجريبية أولية (alpha) في v1.27 (مايو 2023)[^alpha]، وانتقلت إلى النسخة التجريبية (beta) وأصبحت مفعلة افتراضيًا في v1.33 (مايو 2025)[^beta]، ووصلت إلى GA في v1.35، الذي تم إصداره في 17 ديسمبر 2025.[^releases] بوابة الميزات المتحكمة هي `InPlacePodVerticalScaling`. إصدار Kubernetes الحالي وقت كتابة هذا المقال هو v1.36 "Haru" (22 أبريل 2026).[^v136] لاحظ نقطة واحدة قد تسبب ارتباكًا: تغيير الحجم على **مستوى الحاوية** (هذا الدليل) هو GA في v1.35، بينما تغيير حجم الموارد على **مستوى الـ Pod** — أي تغيير إجمالي `spec.resources` للـ Pod بالكامل — هو ميزة منفصلة وأحدث وهي في مرحلة beta في v1.36.[^podlevel] ## كيف يمكنني تغيير حجم CPU الخاص بالـ Pod دون إعادة تشغيله؟ استخدم `kubectl patch` ضد المصدر الفرعي `resize` للـ Pod. يتم تطبيق تغييرات CPU افتراضيًا في المكان، لذا لا تحدث إعادة تشغيل.[^docs] أولاً، قم بإنشاء Pod صغير: ```yaml # 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" ``` ```bash kubectl apply -f resize-demo.yaml ``` الآن قم بزيادة CPU في الـ Pod قيد التشغيل من خلال المصدر الفرعي `resize`: ```bash kubectl patch pod resize-demo --subresource resize --patch \ '{"spec":{"containers":[{"name":"app","resources":{"requests":{"cpu":"800m"},"limits":{"cpu":"800m"}}}]}}' ``` تأكد من أن الحاوية لم يتم إعادة تشغيلها وأن قيمة CPU الجديدة مفعلة: ```bash # يظل 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.[^subres] ## كيف يمكنني تغيير حجم ذاكرة الـ Pod، ولماذا قد تظل بحاجة لإعادة تشغيل؟ يعمل تغيير حجم الذاكرة بنفس الطريقة — تحديث المصدر الفرعي `resize` — ولكن ما إذا كانت الحاوية ستعيد التشغيل يعتمد على `resizePolicy` الخاص بها للذاكرة.[^docs] مع القيمة الافتراضية `NotRequired`، يقوم kubelet فقط بتحديث الـ memory cgroup في مكانه. مع `RestartContainer`، يقوم kubelet بإعادة تشغيل **تلك الحاوية** (لا يتم إعادة إنشاء الـ Pod) حتى تتمكن العملية من إعادة قراءة إعدادات الذاكرة الخاصة بها: ```bash 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` على مورد الذاكرة حتى يدخل تغيير الحجم حيز التنفيذ فعليًا.[^cncf] أصبح **تقليل حدود الذاكرة** — الذي كان محظورًا سابقًا — مسموحًا به خلال فترة الـ beta (في v1.34): يبذل kubelet قصارى جهده لتجنب عمليات القتل بسبب نقص الذاكرة (OOM-kills)، وإذا كانت الحاوية تستخدم بالفعل أكثر من الحد المقترح، يظل تغيير الحجم قيد التنفيذ بدلاً من تطبيقه.[^docs][^memdec] ## ما هو حقل resizePolicy (NotRequired مقابل RestartContainer)؟ `resizePolicy` هي قائمة لكل مورد في الحاوية تخبر kubelet بكيفية تطبيق تغيير الحجم.[^docs] يقرن كل إدخال اسم مورد `resourceName` (`cpu` أو `memory`) مع سياسة إعادة تشغيل `restartPolicy`: | `restartPolicy` | السلوك | الاستخدام الشائع | | ----------------------- | ------------------------------------------------- | ------------------------------------------------------------------ | | `NotRequired` (افتراضي) | تطبيق التغيير على الحاوية النشطة دون إعادة تشغيل | CPU؛ الذاكرة للتطبيقات التي تقرأ حدود cgroup ديناميكيًا | | `RestartContainer` | إعادة تشغيل الحاوية (وليس الـ pod) لتطبيق التغيير | الذاكرة للتطبيقات التي تخصص الموارد عند بدء التشغيل (مثل JVM heap) | إذا حذفت `resizePolicy`، فسيتم تعيينها افتراضيًا إلى `NotRequired` لكل من **CPU** والذاكرة.[^docs] نظرًا لأن هذا الوضع الافتراضي يزيد الذاكرة بصمت دون إعادة تشغيل العملية، كن صريحًا بشأن سياسة الذاكرة عندما يحتاج تطبيقك إلى إعادة تشغيل لاستخدامها. ## هل يؤدي تغيير حجم الـ pod إلى تغيير فئة QoS الخاصة به؟ لا. فئة جودة الخدمة (Quality of Service) للـ pod — سواء كانت `Guaranteed`، أو `Burstable`، أو `BestEffort` — تكون ثابتة عند إنشاء الـ pod ولا يمكن لتغيير الحجم تغييرها.[^docs] يجب أن تظل قيمك الجديدة مستوفية للفئة الأصلية: يجب أن يحافظ الـ pod من فئة `Guaranteed` على تساوي `requests` مع `limits` لكل من CPU والذاكرة بعد تغيير الحجم، وإلا سيتم رفض الطلب.[^qos] وهذا هو السبب في أنك تحتاج أحيانًا إلى تعديل كل من `requests` و `limits` معًا، كما في مثال CPU أعلاه. ## كيف يمكنني التحقق من حالة تغيير الحجم؟ راقب حالتين (conditions) للـ pod والموارد الفعلية المطبقة.[^docs] يظهر تغيير الحجم الذي لا يمكن إكماله فورًا كـ `PodResizePending`، مع ذكر السبب: - `Infeasible` — لا يمكن تلبية الطلب أبدًا على هذه العقدة (على سبيل المثال، يتجاوز سعة العقدة، أو يستخدم الـ pod سياسة إدارة موارد ثابتة).[^docs] - `Deferred` — تغيير الحجم ممكن من حيث المبدأ ولكن لا يمكن القيام به الآن (تفتقر العقدة إلى مساحة خالية)، لذا يقوم kubelet بإعادة تقييمه لاحقًا، مع تحديد الأولويات حسب PriorityClass وفئة QoS ومدة انتظار طلب تغيير الحجم.[^docs] بينما يقوم kubelet بتطبيق تغيير حجم مقبول، يظهر الـ pod حالة `PodResizeInProgress`.[^docs] افحص كل شيء باستخدام: ```bash kubectl describe pod resize-demo # تعرض الحالات والأحداث kubectl get pod resize-demo \ -o jsonpath='{.status.containerStatuses[0].resources}{"\n"}' # القيم الفعلية ``` قارن `status.containerStatuses[*].resources` (الفعلي) مقابل `spec.containers[*].resources` (المطلوب) للتأكد من تطبيق التغيير.[^docs] ## ما هي قيود تغيير حجم الـ pod في مكانه؟ تم تحديد نطاق الميزة عمدًا. بدءًا من الإصدار v1.35/v1.36، لا يمكنك:[^docs] - تغيير حجم أي شيء بخلاف **CPU والذاكرة** في مكانه. - تغيير **فئة QoS** للـ pod. - تغيير حجم **حاويات البدء غير القابلة لإعادة التشغيل (non-restartable init containers)** أو الحاويات المؤقتة (يمكن تغيير حجم الحاويات الجانبية "sidecar" القابلة لإعادة التشغيل). - تغيير حجم الـ pods المقيدة بسياسات **مدير CPU الثابت أو مدير الذاكرة الثابت** — يتم وضع علامة `Infeasible` على عمليات تغيير الحجم هذه. - استخدامها على **Windows pods**، فهي غير مدعومة. تغيير الحجم الذي يتجاوز سعة العقدة القابلة للتخصيص يظل أيضًا معلقًا كـ `Infeasible` حتى توفر مساحة أو يتم تقليل الطلب.[^docs] ## هل يمكنني استخدام القياس التلقائي مع تغيير الحجم في مكانه (HPA أو VPA)؟ لا علاقة لـ Horizontal Pod Autoscaler بالأمر: فهو يغير **عدد** النسخ المتماثلة، وليس موارد pod واحد، ولا يستخدم تغيير الحجم في مكانه.[^docs] القياس الرأسي (Vertical autoscaling) هو المكان الذي يناسبه تغيير الحجم في مكانه. يمكن لـ Vertical Pod Autoscaler تطبيق التوصيات من خلال وضع `InPlaceOrRecreate` الذي يغير الحجم في مكانه عندما يكون ذلك ممكنًا ويعود إلى الإخلاء وإعادة الإنشاء (evict-and-recreate) بخلاف ذلك — ولكن هذا الوضع في مرحلة **alpha** (خلف بوابة ميزة VPA، ومعطل افتراضيًا) اعتبارًا من عام 2026، لذا تعامل معه كأمر تجريبي وليس جاهزًا للإنتاج.[^vpa] ## كيف يختلف تغيير الحجم عن تعديل Deployment؟ تعديل `resources` في Deployment (أو أي قالب pod) يغير القالب، مما يؤدي إلى **استبدال تدريجي (rolling replacement)**: يقوم Kubernetes بتشغيل pods جديدة بالموارد الجديدة وإيقاف القديمة. أما المورد الفرعي `resize` فيقوم بتعديل الـ pod **الذي يعمل بالفعل**، دون إنشاء pod جديد — وبالنسبة لـ CPU، أو الذاكرة تحت سياسة `NotRequired` — دون إعادة تشغيل على الإطلاق.[^docs] بالنسبة لضبط حجم أعباء العمل طويلة الأمد أو التي تحتفظ بالحالة (stateful) في "اليوم الثاني" (day-2)، فإن هذا الاختلاف هو الهدف الأساسي. إذا كنت تريد عملية نشر محكومة بدلاً من ذلك، فراجع دليلنا حول [عمليات النشر بدون وقت توقف في Kubernetes](https://nerdleveltech.com/kubernetes-zero-downtime-deployments-tutorial). ## الأسئلة الشائعة **أي إصدار من Kubernetes يدعم تغيير حجم الـ pod في مكانه؟** تغيير الحجم في مكانه على مستوى الحاوية هو GA (مستقر) ومفعل افتراضيًا من الإصدار Kubernetes v1.35 فصاعدًا؛ كان في مرحلة beta في v1.33 و alpha في v1.27.[^docs][^beta][^alpha] **كيف يمكنني تغيير حجم CPU للـ pod دون إعادة تشغيله؟** قم بتعديل المورد الفرعي `resize` للـ pod: `kubectl patch pod --subresource resize --patch '{"spec":{"containers":[{"name":"","resources":{"requests":{"cpu":"800m"},"limits":{"cpu":"800m"}}}]}}'`. يتم تطبيق تغيير حجم CPU في مكانه افتراضيًا.[^docs][^subres] **هل تؤدي إعادة تحجيم الذاكرة إلى إعادة تشغيل الحاوية؟** فقط إذا كانت سياسة `resizePolicy` الخاصة بالحاوية للذاكرة هي `RestartContainer`. القيمة الافتراضية `NotRequired` تقوم بتحديث cgroup بدون إعادة تشغيل، مما قد يترك مخصصات وقت البدء (مثل JVM heap) على الحجم القديم.[^docs][^cncf] **هل تؤدي إعادة التحجيم في المكان (in-place) إلى تغيير فئة QoS للـ pod؟** لا. يتم تعيين فئة QoS عند الإنشاء وهي غير قابلة للتغيير؛ ويجب أن تظل القيم التي تمت إعادة تحجيمها ملتزمة بقواعد الفئة الأصلية.[^docs][^qos] **ماذا تعني حالة `Infeasible`؟** تعني حالة `PodResizePending` مع سبب `Infeasible` أن الطلب لا يمكن تلبيته على العقدة (node) — فهو يتجاوز السعة أو أن الـ pod يستخدم سياسة مدير موارد ثابتة. أما `Deferred` فتعني أنه سيتم إعادة المحاولة لاحقاً عندما تتوفر مساحة.[^docs][^ga] **هل يمكنني تقليص حد الذاكرة للـ pod الآن؟** نعم. كانت عمليات تقليل حد الذاكرة محظورة سابقاً ولكن أصبحت مسموحة خلال فترة البيتا (v1.34)؛ ويقوم kubelet بمحاولة قصارى جهده لتجنب عمليات القتل بسبب نقص الذاكرة (OOM-kills)، ويمنع إعادة التحجيم أثناء تقدمها إذا كان الاستخدام الحالي يتجاوز الحد الجديد.[^docs][^memdec] **هل يتم إعادة إنشاء الـ pod أثناء إعادة التحجيم؟** لا. لا يتم إعادة إنشاء الـ pod أبداً. على الأكثر، يتم إعادة تشغيل حاوية واحدة فقط، وفقط عندما تتطلب سياسة `resizePolicy` ذلك.[^docs] ## الخلاصة تعمل ميزة إعادة تحجيم الـ pod في المكان على تحويل المعالج والذاكرة إلى شيء يمكنك ضبطه على pod يعمل بالفعل بدلاً من أن يكون سبباً في إعادة تشغيل عبء العمل بالكامل. ابدأ بتعيين `resizePolicy` بشكل صريح لكل مورد، وقم بإجراء التغييرات من خلال المورد الفرعي `resize`، وراقب `status.containerStatuses[*].resources` بالإضافة إلى حالات `PodResize*` للتأكد من تطبيقها. إنها تتوافق بشكل طبيعي مع [الحاويات الجانبية (sidecar) الأصلية](https://nerdleveltech.com/Kubernetes-native-sidecar-containers) للحاويات المساعدة في ضبط الموارد، ومع [دليل الهجرة إلى Gateway API](https://nerdleveltech.com/migrate-ingress-to-Kubernetes-gateway-API-tutorial) كجزء من مجموعة أدوات Kubernetes الحديثة الأوسع. بالنسبة للتحجيم التلقائي، راقب وضع "في المكان" الخاص بـ VPA، ولكن لا تعتمد عليه في بيئات الإنتاج حتى يخرج من المرحلة التجريبية (alpha). [^ga]: مدونة Kubernetes، "Kubernetes v1.35: وصول ميزة إعادة تحجيم الـ Pod في المكان إلى المرحلة المستقرة" (2025-12-19). [^docs]: توثيق Kubernetes، "إعادة تحجيم موارد المعالج والذاكرة المخصصة للحاويات" (حالة الميزة: Kubernetes v1.35 \[مستقرة]؛ تم التعديل في 2026-06-01). [^releases]: Kubernetes، "الإصدارات" و"إصدارات التصحيح" (v1.35 صدر في 2025-12-17؛ أحدث تصحيح 1.35.5، 2026-05-12). [^v136]: مدونة Kubernetes، "نظرة سريعة على Kubernetes v1.36" (2026-03-30)؛ v1.36 "Haru" صدر في 2026-04-22. [^subres]: Kubernetes/Kubernetes مشكلة رقم 128278، "\[FG:InPlacePodVerticalScaling] أمر kubectl فرعي لتغيير حجم موارد الـ pod" — `--subresource resize` مدعوم في patch/edit (kubectl v1.32+). [^alpha]: مدونة Kubernetes، "Kubernetes 1.27: تغيير حجم الموارد في المكان لـ Kubernetes Pods (نسخة ألفا)" (2023-05-12). [^beta]: مدونة Kubernetes، "Kubernetes v1.33: ترقية تغيير حجم الـ Pod في المكان إلى نسخة بيتا" (2025-05-16). [^podlevel]: توثيق Kubernetes، "تغيير حجم موارد CPU والذاكرة المخصصة للـ Pods" (حالة الميزة: Kubernetes v1.36 \[بيتا]). [^cncf]: مدونة CNCF، "متى يقوم Kubernetes بإعادة تشغيل الـ pod الخاص بك — ومتى لا يفعل ذلك" (2026-03-17). [^memdec]: Kubernetes/تحسينات، KEP-1287 "تحديث موارد الـ Pod في المكان" — تم إضافة دعم تقليل حد الذاكرة ومعالجة OOM بأفضل جهد في نسخة v1.34 بيتا. [^qos]: توثيق Kubernetes، "فئات جودة الخدمة (QoS) للـ Pod." [^vpa]: توثيق Kubernetes، "التوسيع التلقائي الرأسي للـ Pod (Vertical Pod Autoscaling)،" ومشكلة Kubernetes/autoscaler رقم 8805 (VPA `InPlaceOrRecreate`، نسخة ألفا اعتباراً من 2026).