با نزدیک شدن به انتشار Kubernetes نسخه 1.35، تغییرات مهمی در هسته و قابلیتهای مربوط به عملیات خوشه اعلام شده که باید بهعنوان یک SRE یا مهندس DevOps از آنها مطلع باشید 🚀. بهویژه نقش Kubelet در مدیریت نودها و زمانبندی نیز در این نسخه مورد توجه است. همچنین برخی امکانات منسوخ یا حذف میشوند و چند ویژگی جدید یا بهبود یافته به دسترس خواهد آمد — هدف این است که نگهداری خوشهها سادهتر، پایدارتر و امنتر شود.
Kubelet و تغییرات Kubernetes v1.35
کلیدواژهٔ اصلی این مطلب: Kubelet است.
با نزدیک شدن به انتشار Kubernetes نسخه 1.35، تغییرات مهمی در هسته و قابلیتهای مربوط به عملیات خوشه اعلام شده که باید بهعنوان یک SRE یا مهندس DevOps از آنها مطلع باشید 🚀. برخی از امکانات منسوخ یا حذف میشوند و چند ویژگی جدید یا بهبود یافته به دسترس خواهد آمد — هدف این است که نگهداری خوشهها سادهتر، پایدارتر و امنتر شود.
حذف پشتیبانی از cgroup v1 در گرههای لینوکس ⚠️: از مدتها قبل پشتیبانی از cgroup v2 پایدار شده و جایگزین مناسبی برای cgroup v1 است. cgroup v2 ساختار سلسلهمراتبی یکپارچهتری ارائه میدهد و جداسازی منابع بهتری فراهم میکند؛ به همین دلیل پشتیبانی از cgroup v1 در v1.35 حذف میشود. اثر عملی برای محیطهای قدیمیتر این است که kubelet روی گرههایی که تنها cgroup v1 فعال دارند، بالا نمیآید — بنابراین باید گرهها را به سیستمهایی با cgroup v2 فعال ارتقا دهید. برای هماهنگی بیشتر و جزئیات سازگاری، پس از انتشار رسمی اطلاعیههای تکمیلی منتشر خواهد شد.
منسوخ شدن حالت ipvs در kube-proxy 🔧: نگهداری حالت ipvs بهدلیل پیچیدگیهای فنی و دیون فنی ناشی از تفاوتهای عملکردی با سایر حالتها دشوار شده است. برای سادهسازی کدبیس kube-proxy، حالت ipvs در v1.35 منسوخ اعلام شده است. برای گرههای لینوکسی، حالت پیشنهادی و پیشفرض به سمت nftables مایل است — اگر از ipvs استفاده میکنید، این فرصت خوبی است که مسیر مهاجرت خود را برنامهریزی کنید. (KEP-5495)
هشدار نهایی درباره Containerd v1.x 🚨: Kubernetes v1.35 آخرین نسخهای است که پشتیبانی از containerd 1.7 (و خانواده containerd v1.x) را ارائه میکند. اگر هنوز روی containerd 1.x هستید، تا قبل از ارتقای Kubernetes به نسخه بعدی باید به containerd 2.0 یا بالاتر مهاجرت کنید. برای شناسایی گرههای دارای runtime قدیمی میتوانید متریک kubelet_cri_losing_support را مانیتور کنید؛ این متریک کمک میکند گرههایی که بهزودی پشتیبانیشان قطع میشود را پیدا کنید. (KEP-4033)
اعلامشدن ویژگیهای Node برای بهبود زمانبندی 📣: framework جدیدی با نام “declared node features” معرفی شده که به گره اجازه میدهد قابلیتهای خود را صریحاً گزارش کند (فیلد جدید .status.declaredFeatures). این اطلاعات توسط kube-scheduler، admission controllers و اجزای ثالث قابل استفاده است تا از زمانبندی Podها روی گرههای ناسازگار جلوگیری شود. این کار خطای ناشی از اختلاف نسخه بین control plane و گرهها را کاهش میدهد، نیاز به label/taint دستی را کم میکند و با Cluster Autoscaler هم ادغام میشود. هدف: افزایش قابلاطمینان بودن زمانبندی در محیطهای نسخه ناهمگن. (KEP-5328)
فارغالتحصیلی Update-in-place برای منابع Pod به GA ⚙️: امکان بهروزرسانی منابع cpu و memory برای Podهای در حال اجرا بدون راهاندازی مجدد Containers (UpdateContainerResources) اکنون به سطح GA رسیده است. این قابلیت که از آلفا در 1.27 و بتا در 1.33 تکامل یافته، موجب میشود مقیاس عمودی نرمتر و بدون اختلال انجام شود — مخصوصاً برای برنامههای حالتدار که بازآفرینی Podها دردسرساز است. API CRI مربوط نیز برای ویندوز و runtimeهای آینده گسترش یافته تا وضعیت منابع را بهصورت realtime گزارش کند. (KEP-1287)
صدور گواهیهای کوتاهمدت برای Podها 🔒: KEP-4317 امکان صدور و نصب گواهیهای TLS مخصوص هر Pod را بهصورت بومی و خودکار فراهم میکند. با استفاده از این مکانیزم، kubelet میتواند برای Podها گواهی درخواست و آن را از طریق یک volume منتشر کند؛ این کار چرخش خودکار گواهی را نیز تسهیل میکند و راهاندازی سرویسمشها و سیاستهای شبکه بدون-trust را سادهتر میسازد. این ویژگی آلفا در 1.34 معرفی شده و هدفگذاری برای بتا در 1.35 است.
پشتیبانی از مقادیر عددی در taints/tolerations و عملگرهای مقایسهای 🔢: اکنون میتوانید از عملگرهای مقایسهای عددی (مثل Gt) در taints/tolerations استفاده کنید تا مثلاً Podها فقط روی گرههایی با مقدار عددی خاصی (مثلاً SLA > 950) برنامهریزی شوند. این روش نسبت به Node Affinity انعطافپذیری بیشتری دارد و از اثر NoExecute هم پشتیبانی میکند تا در صورت افت مقدار گره، Pod بهصورت خودکار حذف شود.
گامهای امنیتی با User namespaces برای جداکردن UIDها 🛡️: KEP-127 اجازه میدهد که فضای نام کاربری لینوکس برای قرنطینه شناسههای کاربر/گروه کانتینر از میزبان استفاده شود. بدین صورت UID 0 داخل namespace میتواند بهعنوان یک UID غیرمجاز و با شماره بزرگ روی میزبان نمایش داده شود — این مدل سطح حمله را کاهش میدهد و به سمت کانتینرهای واقعاً بدون-root حرکت میکند. این ویژگی از آلفا در 1.25 شروع و تا بتا در 1.30 پیش رفته و همچنان در حال بالغ شدن است.
حجمهای مبتنی بر تصاویر OCI برای تزریق دادهها و مدلها 📦: نوع volume جدیدی که از تصاویر OCI پشتیبانی میکند اجازه میدهد مصنوعات داده یا باینریها مستقیماً از registry به عنوان یک volume به Podها تزریق شوند. این الگو جدا کردن دادهها از تصویر اپلیکیشن را ساده میکند، توزیع مدلها یا دادههای ML را با ابزارهای استاندارد registry ممکن میسازد و نیاز به init containerها یا اسکریپتهای پیچیده راهاندازی را حذف میکند. نوع حجم تصویر از 1.31 معرفی شده و از 1.33 در حالت بتا بوده و احتمالاً در 1.35 بهصورت پیشفرض فعال خواهد شد. (KEP-4639)
نکات عملی و جمعبندی ✅: این تغییرات ترکیبی روی پایداری، امنیت و سادگی عملیات تأثیرگذار هستند. کارهایی که بهعنوان SRE/DevOps باید الآن در برنامهتان بگذارید: بررسی و برنامهریزی مهاجرت از cgroup v1، ارزیابی استفاده از ipvs و مهاجرت به nftables در صورت لزوم، ارتقاء containerd به 2.x، و آشنایی با قابلیتهای جدید مانند declared node features، Update-in-place resources و native pod certificates تا از مزایای پایداری و امنیت بهرهمند شوید. اگر میخواهید میتوانم برای هر مورد چکلیست مهاجرت و بررسی کمینه مورد نیاز گرهها/کنترلپلن بنویسم — کافیست بگویید کدام بخش برای خوشه شما اولویت دارد 😉.
