مقدمه

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

منسوخ‌سازی‌ها و تغییرات امنیتی در نسخه ۱.۳۷

۱. حذف دسترسی پادهای استاتیک به Secrets و ConfigMaps

پادهای استاتیک (Static Pods) از طریق API Server ایجاد نمی‌شوند، بلکه مستقیماً توسط Kubelet روی نود اجرا می‌شوند. در نسخه‌های قبلی یک باگ اجازه می‌داد این پادها با استفاده از فیلدهایی مانند configMapRef یا secretRef به منابع API دسترسی داشته باشند. در نسخه ۱.۳۷ این باگ برطرف شده و این مراجع به‌طور کامل ممنوع شده‌اند. همچنین، Feature Gateی به نام PreventStaticPodAPIReferences که امکان دور زدن این محدودیت را می‌داد، حذف شده است.

نکته امنیتی برای سیستم‌های عاملی: در معماری‌های مبتنی بر AI Agent که نیاز به اجرای مستقیم و بدون وابستگی به API Server در سطح نود دارند، باید از روش‌های استاندارد تزریق پیکربندی (مانند فایل‌های پیکربندی محلی) استفاده کنید و وابستگی به API را در پادهای استاتیک حذف کنید.

۲. منسوخ‌سازی حالت ipvs در kube-proxy

حالت ipvs در kube-proxy از نسخه ۱.۸ برای حل گلوگاه‌های iptables معرفی شده بود، اما از آنجا که API هسته لینوکس ipvs به تنهایی قادر به پیاده‌سازی کامل سرویس‌های کوبرنیتیز نیست، این حالت همچنان در پس‌زمینه از iptables استفاده می‌کند. به همین دلیل، پشتیبانی از حالت ipvs در حال منسوخ‌سازی است.

  • نسخه ۱.۴۰: انتظار می‌رود حالت ipvs به‌طور پیش‌فرض غیرفعال شود (فقط از طریق feature gate قابل انتخاب باشد).
  • نسخه ۱.۴۳: پشتیبانی از حالت ipvs به‌طور کامل حذف خواهد شد.

برای بررسی حالت فعلی kube-proxy می‌توانید از دستور زیر استفاده کنید:

```bash

kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode:'

`

تغییرات اساسی و حذف پشتیبانی cgroup v1

با توجه به اینکه توزیع‌های مدرن لینوکس و محیط‌های اجرای کانتینری از cgroup v2 به‌عنوان استاندارد استفاده می‌کنند، پشتیبانی از cgroup v1 در حال حذف است. از نسخه ۱.۳۵ تنظیم failCgroupV1 به‌طور پیش‌فرض روی true قرار گرفته است که باعث می‌شود Kubelet در صورت استفاده از cgroup v1 اجرا نشود، مگر اینکه به‌طور صریح بازنویسی شود.

```yaml

apiVersion: kubelet.config.k8s.io/v1beta1

kind: KubeletConfiguration

failCgroupV1: false # بازنویسی موقت

`

اهمیت برای کاربردهای هوش مصنوعی: قابلیت‌های پیشرفته مدیریت منابع مانند تغییر اندازه پادها در حین اجرا (In-Place Pod Resizing) و حفاظت حافظه لایه‌بندی‌شده (Tiered Memory Protection) کاملاً به cgroup v2 وابسته هستند. این ویژگی‌ها برای مدیریت بهینه منابع GPU و حافظه در زمان آموزش مدل‌های هوش مصنوعی حیاتی هستند. استفاده از بازنویسی فوق تنها راه‌حلی کوتاه‌مدت است و مهاجرت به cgroup v2 الزامی است.

تغییرات Breaking: SELinuxMount

ویژگی SELinuxMount در نسخه ۱.۳۷ به Graduation (GA) می‌رسد و به‌طور پیش‌فرض فعال خواهد شد. در این حالت، Volume‌ها با گزینه -o context=<label> سوار (mount) می‌شوند تا از برچسب‌گذاری بازگشتی (recursive relabeling) جلوگیری شود. این تغییر تنها زمانی اعمال می‌شود که درایور CSI مربوطه از طریق .spec seLinuxMount: true آن را فعال کند.

محدودیت: از آنجا که هر mount تنها می‌تواند یک SELinux context داشته باشد، پادهایی که برچسب‌های SELinux متفاوتی دارند و یک Volume را روی یک نود به اشتراک می‌گذارند، ممکن است با فعال شدن این ویژگی با خطای عدم اجرا مواجه شوند.

جمع‌بندی و راهنمای اقدام

مدیران زیرساخت‌های هوش مصنوعی باید پیش از ارتقا به نسخه ۱.۳۷ موارد زیر را بررسی کنند:

1. بررسی وابستگی پادهای استاتیک به Secrets و ConfigMaps.

2. بررسی حالت kube-proxy و برنامه‌ریزی برای انتقال از ipvs به iptables.

3. اطمینان از پشتیبانی توزیع‌های لینوکس از cgroup v2 برای استفاده از قابلیت‌های مدیریت منابع پیشرفته.

4. بررسی سیاست‌های SELinux برای Volume‌های اشتراکی.