انتشار Kubernetes 1.34 با قابلیت‌های جدید برای مدیریت هوشمند منابع و افزایش امنیت خوشه‌ها

در حالی که Kubernetes طی دهه گذشته به تدریج از یک ابزار آزمایشی به ستون فقرات زیرساخت‌های ابری تبدیل شده است، نسخه ۱.۳۴ اکنون آغازگر فصل جدیدی در بلوغ آن محسوب می‌شود. این نسخه رسماً با شعار «Of Wind & Will» معرفی شده و نه افزودن لایه‌های پیچیده، بلکه تقویت قابلیت‌های موجود را هدف گرفته است؛ یعنی تمرکز بر نزدیک‌تر کردن امکانات Kubernetes به واقعیت‌های عملیاتی روزمره: کنترل بهتر منابع، امنیت قوی‌تر و کاهش هزینه‌های عملیاتی. در ادامه با نُه ویژگی کلیدی این نسخه آشنا می‌شویم که می‌توانند نحوه مدیریت خوشه‌های Kubernetes را متحول کنند.

نسخه ۱.۳۴ Kubernetes نشان می‌دهد که این پروژه دیگر در مرحله نوآوری صرف نیست؛ بلکه وارد دوره‌ای از بلوغ عملیاتی شده است. به جای افزودن ویژگی‌های پیچیده جدید، تمرکز این نسخه بر پر کردن شکاف‌ها در عملکرد، امنیت و هزینه است. ویژگی‌هایی مانند DRA، اعطای توکن‌های کوتاه‌مدت، سیاست‌های admission داخلی و قابلیت تغییر کلاس ذخیره‌سازی در زمان اجرا، همگی با هدف نزدیک کردن Kubernetes به واقعیت‌های زیرساخت‌های تولیدی طراحی شده‌اند.

در وب‌سایت روز صفر، ما تغییرات نسخه ۱.۳۴ را نه به‌عنوان تغییری صرف فنی، بلکه به‌عنوان نقطه عطفی در مسیر تحول زیرساخت ابری می‌بینیم. به‌زودی تحلیل‌های منطبق بر تجربه عملی، راهنمای مهاجرت به این نسخه و درس‌آموخته‌ها را منتشر خواهیم کرد تا کاربران و تیم‌های فناوری بتوانند با اطمینان و آگاهی کامل به سوی آینده حرکت کنند. در ادامه به بررسی تغییرات کلیدی در نسخه ۱.۳۴ پرداخته‌ایم.

تخصیص منابع پویا (Dynamic Resource Allocation) – پایان «قرعه کشی GPU»

یکی از مشکلات اساسی در محیط‌های محاسباتی سنگین مانند هوش مصنوعی یا خوشه‌های محاسباتی قدرتمند، تخصیص هوشمند GPU است. تا پیش از این، درخواست «۱ GPU» به معنای انتخاب هر GPU موجود قابل تخصیص بود، بدون توجه به ویژگی‌هایی مانند NVLink یا ظرفیت حافظه. در نسخه ۱.۳۴، ویژگی Dynamic Resource Allocation (DRA) به حالت GA ارتقا یافته است که به کمک آن تخصیص منابع به شکلی مبتنی بر کلاس‌های DeviceClass انجام می‌شود. به این معنا که کارکرد خوشه به سطحی هوشمند ارتقا می‌یابد و عملکرد و به‌کارگیری منابع بهینه‌تر خواهد بود.

برای فعال کردن این ویژگی، باید gate ویژگی DynamicResourceAllocation را در کامپوننت‌های API Server، controller-manager، scheduler و kubelet فعال کنید و همچنین افزونه دستگاه (device plugin) سازگار با DRA را فراهم کنید. سپس درخواست‌ها از طریق اشیاء ResourceClaim ارسال می‌شوند که به DeviceClass اشاره دارند.

پشتیبانی از Swap Memory (در حالت Beta)

در نسخه جدید Kubernetes بالاخره به پشتیبانی از swap در نودها توجه شده است؛ قابلیتی که تا کنون در اغلب سناریوها غیرفعال بود تا از افزایش تأخیرهای ناخواسته جلوگیری شود. در ۱.۳۴، ماژول swap با محدودیت‌های مشخصی فعال می‌شود: پادهای با اولویت Guaranteed امکان استفاده از swap ندارند؛ پادهای BestEffort نیز محدود هستند؛ اما پادهای Burstable می‌توانند متناسب با میزان حافظه درخواست‌شان از swap استفاده کنند.

برای استفاده از Swap، باید ابتدا در سطح نود آن را پیکربندی کرده و سپس flag مربوط به kubelet را فعال کنید (مثل NodeSwap=true). همچنین بهتر است swap روی پارتیشنی مجزا و رمزگذاری‌شده باشد تا امنیت حفظ شود.

اطلاعات Stall فشار (PSI) به مثابه شاخص واقعی عملکرد (Beta)

گاهی ممکن است منابعی از قبیل CPU یا حافظه در سطح استفاده کامل به نظر برسند؛ اما عملکرد کند باشد زیرا تسک‌ها منتظر دستیابی به منابع I/O یا حافظه هستند. برای این منظور، نسخه ۱.۳۴ از Pressure Stall Information (PSI) پشتیبانی می‌کند، که نشان می‌دهد تسک‌ها چه زمانی و چه میزانی منتظر منابع بوده‌اند.

با فعال کردن KubeletPSI=true در kubelet، داده‌های Stall قابل دسترسی می‌شوند و می‌توان از آن‌ها به‌عنوان شاخصی هوشمند برای مقیاس خودکار استفاده کرد. این رویکرد به جای مقیاس بر اساس استفاده خام (utilization)، مقیاس بر اساس درد واقعی برنامه را ممکن می‌کند.

سیاست‌های Mutating Admissions ادغام‌شده؛ سریع‌تر، ساده‌تر، امن‌تر (Beta)

تا پیش از این، اعمال سیاست‌های mutation (مانند اطمینان از اجرای پادها به‌صورت غیر-root) به واسطه webhookهای خارجی انجام می‌شد که اضافه بار شبکه، پیچیدگی TLS و وابستگی به سرویس‌های خارجی ایجاد می‌کرد. در نسخه ۱.۳۴، این منطق مستقیماً داخل API Server اجرا می‌شود بدون نیاز به webhook جداگانه. به این ترتیب، سرعت و پایداری افزایش می‌یابد و عملیات امن‌تر اجرا می‌شود.

برای نمونه، می‌توانید یک سیاست بنویسید که همه پادها را به‌صورت runAsNonRoot اجرا کند. این سیاست بدون تأخیر شبکه و وابستگی خارجی اجرا می‌شود.

احراز هویت بر اساس سلکتور (Selector-Based Authorization) – پیاده‌سازی حداقل دسترسی حقیقی (GA)

در نسخه‌های پیشین، kubeletها اجازه لیست‌کردن همه پادها در کل خوشه را داشتند حتی اگر نیاز به دسترسی به پادهای نود خودشان داشته باشند. این موضوع در صورتی که نام گره یا دسترسی به kubelet لو برود، تهدید بزرگی است. در نسخه ۱.۳۴، کنترل دسترسی بر اساس fieldSelector و labelSelector امکان‌پذیر شده و kubelet فقط مجاز است درخواست‌هایی را که مشخصاً به گره خودش مرتبط‌اند، اجرا کند. این تدبیر حوزه اثر تهدید آسیب‌پذیری را کوچکتر می‌کند.

همچنین webhookها و authorizerها می‌توانند از سلکتورهای فیلدی یا برچسبی برای اعمال سیاست‌های دقیق‌تر بهره ببرند.

توکن سرویس اکانت برای Pull تصویر: اسرار کوتاه‌مدت به‌طور پیش‌فرض (Beta)

یک ضعف شناخته‌شده در امنیت Kubernetes استفاده از imagePullSecrets ثابت است که اگر فاش شود، می‌تواند به استفاده غیرمجاز منجر شود. در نسخه ۱.۳۴، به جای این روش قدیمی، توکن سرویس اکانت کوتاه‌مدت که به‌صورت خودکار نوسازی می‌شود، به kubelet ارائه می‌شود تا تصاویر را بکشند. این توکن‌ها محدود به محیط کاری هستند و دوره عمر کوتاهی دارند، در نتیجه دامنه اثر افشای آن‌ها کاهش می‌یابد.

برای فعال‌سازی، باید تنظیمات kubelet را به‌روز کرده و credential-provider را پیکربندی کنید.

محدودیت دسترسی ناشناس پیش‌فرض – سخت‌تر اما انعطاف‌پذیر (GA)

دسترسی ناشناس (Anonymous Auth) به API Kubernetes در گذشته امکان‌پذیر بود که برای برخی بررسی‌های سلامت (health probes) استفاده می‌شد؛ اما همزمان خطر پنهان شدن سطوح API را ایجاد می‌کرد. در نسخه ۱.۳۴، این دسترسی همچنان فعال است، اما به‌صورت پیش‌فرض محدود شده و تنها به endpointهایی خاص مانند /healthz و /readyz اجازه داده می‌شود. برای سایر نقاط، باید کنترل دسترسی دقیق‌تری اعمال شود.

با این رویکرد، تعادلی میان امنیت و کارایی برقرار می‌شود: سلامت‌سنجی بدون مانع و سطح دسترسی کاهش‌یافته به منابع حساس.

VolumeAttributesClass: تنظیم زنده کلاس عملکرد ذخیره‌سازی بدون نیاز به باز سوار (GA)

پیش از این، پس از پیوند دادن یک PVC، عملکرد آن قفل می‌شد و برای ارتقای عملکرد نیاز به باز سوار کردن (remount) یا تعویض ذخیره‌ساز بود. با ویژگی VolumeAttributesClass در نسخه ۱.۳۴، کاربران می‌توانند کلاسی از ویژگی‌ها مانند IOPS یا throughput را به PVC اعمال کنند و در زمان اجرا آن را تغییر دهند، بدون نیاز به قطع سرویس یا باز سوار نمودن. البته پشتیبانی این قابلیت وابسته به پشتیبانی ModifyVolume در درایور CSI است و اگر درایور این پشتیبانی را نداشته باشد، تغییر رد خواهد شد.

سیاست جایگزینی پاد در Job (PodReplacementPolicy) — پایان زمان‌بندی دوگانه (GA)

در نسخه‌های قبلی، هنگام خطا در اجرای یک پاد Job، کنترلر ممکن بود بلافاصله پاد جدیدی را ایجاد کند، حتی اگر پاد قبلی هنوز به طور کامل متوقف نشده باشد. این رفتار می‌تواند منجر به دو پاد همزمان در حال اجرا شود و مصرف منابع را افزایش دهد. در نسخه ۱.۳۴، پارامتر podReplacementPolicy معرفی شده است که می‌توان تعیین کرد قبل از ایجاد پاد جدید، پاد قبلی به طور کامل خاتمه یابد. این باعث مدیریت منابع بهتر و پیشگیری از اوج‌های ناگهانی مصرف می‌شود. این ویژگی به‌صورت پیش‌فرض فعال است و نیازی به فعال‌سازی خاص ندارد.

منابع:

ScalesOps

Kubernetese