Kubernetes 1.35: ویژگی تغییر اندازه Pod در محل (In-Place) حالا به Stable ارتقا پیدا کرده است — و با cpu boost که به بهینه‌سازی منابع کمک می‌کند، یک نقطه عطف مهم برای مدیریت منابع در کلاسترها.


تغییر اندازه Pod در محل: از آلفا تا پایدار با cpu boost


In-Place Pod resizing اکنون امکان تغییر اندازه منابع (requests and limits) را در حال اجرا فراهم می‌کند تا در مواقع اوج بار با cpu boost بتوان منابع را پویا کم یا زیاد کرد و بدون توقف به کار ادامه داد.

Kubernetes 1.35 🎉: ویژگی تغییر اندازه Pod در محل (In-Place) حالا به Stable ارتقا پیدا کرده — یک نقطه عطف مهم برای مدیریت منابع در کلاسترها.

این مسیر طولانی بیش از شش سال طول کشید: ایده اولیه چند سال قبل مطرح شد، این قابلیت برای اولین بار به‌عنوان آلفا در Kubernetes 1.27 معرفی شد و در 1.33 به بتا رسید؛ حالا در 1.35 به وضعیت Stable رسیده است که یعنی آماده استفاده عملی و اعتمادپذیرتر برای محیط‌های تولیدی است.

تغییر اندازه Pod در محل چیست؟ 🤔 قبلاً request و limit مربوط به CPU و memory برای هر کانتینر در یک Pod ثابت بود و تغییر آنها معمولاً مستلزم حذف و ساخت مجدد Pod بود. این فرایند برای سرویس‌های حالت‌دار، بارهای حساس به تأخیر و کارهای دسته‌ای مخرب و پرهزینه بود. حالا با In-Place resizing می‌توانید request و limit را برای یک Pod در حال اجرا تغییر دهید و اغلب نیازی به راه‌اندازی مجدد کانتینتر نیست.

نکات کلیدی فنی: فیلدهای مورد نظر (desired) برای CPU و memory — یعنی request و limit — اکنون قابل ویرایش هستند. وضعیت واقعی منابع در زمان اجرا در فیلد status.containerStatuses[*].resources منعکس می‌شود تا بفهمید در عمل چه منابعی به کانتینرها اختصاص یافته‌اند.

چطور تغییر اندازه را راه‌اندازی کنم؟ با به‌روزرسانی request و limit در spec مربوط به Pod و استفاده از subresource مرتبط می‌توانید درخواست resize را ارسال کنید. مستندات رسمی مثال‌ها و دستورالعمل‌های دقیق را برای تغییر CPU و memory ارائه می‌دهند که برای سناریوهای مختلف مفید است. 📚

این قابلیت چه کمکی به من می‌کند؟ In-Place Pod resizing یک بلوک ساختمانی مهم برای Vertical Autoscaling و بهینه‌سازی منابع در اجراست. وقتی منابع را بتوان بدون وقفهٔ محسوس تنظیم کرد، autoscalerها و اپ‌ها می‌توانند به صورت پویا و کم‌هزینه مقادیر را تغییر دهند؛ مثلاً در زمان اوج بار یا وقتی بار کاهش پیدا می‌کند.

نمونه‌های کاربردی: سرور بازی که باید تعداد بازیکن را مدیریت کند و متناسب با آن منابع را افزایش یا کاهش دهد؛ یا workerهای گرم (warm workers) که می‌شود وقتی بیکار هستند کوچک شوند و در اولین درخواست به سرعت مقیاس شوند؛ یا تخصیص منابع برای JIT compilation هنگام راه‌اندازی. همچنین این قابلیت پنجره‌ای برای ویژگی‌هایی مثل CPU boost (AEP-7862) باز می‌کند تا اپ‌ها بتوانند در زمان راه‌اندازی موقتا CPU بیشتری درخواست کنند و بعداً کاهش دهند.

چه تغییراتی بین بتا (1.33) و پایدار (1.35) آمد؟ تیم توسعه روی تثبیت و بهبود تجربه کاربری کار کرده است. تغییرات مهم شامل این موارد است:

• امکان کاهش memory limit که قبلاً ممنوع بود — حالا مجاز است، ولی kubelet تلاش می‌کند با یک بررسی best-effort از کشته شدن توسط OOM جلوگیری کند (این بررسی تضمینی نیست). 🛡️

• تغییر اندازه‌های معوق اکنون بر اساس اولویت مجدداً تلاش می‌شوند: عامل‌هایی مثل PriorityClass، QoS و مدت‌زمانی که درخواست در صف مانده، در اولویت‌بندی نقش دارند. یک feature gate جدید هم به‌صورت آلفا معرفی شده است تا این منطق را کنترل کند.

• قابلیت مشاهده (observability) بهبود یافته: متریک‌های جدید kubelet و رویدادهای (Pod events) مرتبط با تغییر اندازه اضافه شده تا ردیابی و عیب‌یابی تغییرات منابع ساده‌تر باشد. 🔍

چه چیزهایی در راه است؟ درهای زیادی باز شده و برنامه‌های توسعه‌ای برای بهبودهای بعدی وجود دارد: ادغام عمیق‌تر با مقیاس‌کننده‌های اتوماتیک و دیگر پروژه‌ها برای بهبود کارایی در مقیاس بزرگ، توسعهٔ بیشتر قابلیت‌های مرتبط با CPU boost (مثل VPA integration / AEP-7862)، کار روی مکانیزم‌های «soft-pause» برای agent-sandbox، و افزایش پشتیبانی زمان‌اجرایی (runtime) — مثلاً برخی runtimeها/فریم‌ورک‌ها مانند Java و Python هنوز به‌طور کامل از تغییر اندازه حافظه بدون راه‌اندازی مجدد پشتیبانی نمی‌کنند و گفتگوها برای حل این مسئله ادامه دارد.

اگر گره فضای کافی برای اعمال تغییر اندازه یک Pod با اولویت بالا نداشته باشد، راهکارهایی در نظر گرفته شده‌اند؛ از جمله فعال کردن سیاست‌هایی که یا Podهای با اولویت پایین‌تر را حذف کنند یا گره‌ها را بزرگ‌تر کنند تا نیازها برطرف شود.

همچنین در تلاش برای رفع شرایط مسابقه (race conditions) شناخته شده بین kubelet و scheduler هستیم تا رفتار در شرایط همزمانی پایدارتر شود؛ و بررسی‌هایی هم برای امن‌تر کردن کاهش limit حافظه (با منتقل کردن بررسی مصرف واقعی به سطح runtime) در جریان است.

در نهایت، این ویژگی الان در کنار سایر قابلیت‌ها مثل CPU pinning، memory management و QoS کار می‌کند، اما منابع فراتر از CPU و memory هنوز immutable هستند و توسعه برای گسترش مجموعه منابع قابل تغییر ادامه دارد. اگر پروژه یا نیاز خاصی مرتبط دارید، مشارکت و بازخوردتان می‌تواند جهت توسعه را شکل دهد — مشارکت در بحث‌های فنی و issues می‌تواند خیلی مؤثر باشد. 🙌