نسخه Kubernetes v1.37 در راه است و همانطور که پروژه بالغتر میشود، برخی قابلیتها ممکن است منسوخ یا حذف شوند یا با راهحلهای بهتر جایگزین گردند. این مطلب یک نگاه کلی و فنی برای تیمهای DevOps/SRE فراهم میکند تا از تغییرات برنامهریزیشده آگاه باشند و بتوانند خوشههای خود را برای انتشار آماده کنند 🚀.
اطلاعات زیر وضعیت فعلی برنامهها برای v1.37 را نشان میدهد و ممکن است تا زمان انتشار نهایی تغییر کند؛ پس بهتر است تغییرات نهایی را در زمان نزدیکتر به انتشار دوباره بررسی کنید.
منسوخ شدنها و حذفها 🔧
kubectl: flag –filename (یا -f) در kubectl run در حال منسوخ شدن است، چون ساختار آرگومانها برای این فرمان به سمت ناممحوری حرکت کرده و استفاده از این پرچم برای اجرای run دیگر مناسب نیست. برای بحث فنی بیشتر میتوانید به issue مرتبط مراجعه کنید.
Kubelet / Static Pods: Static Pods دیگر نباید به Secrets یا ConfigMaps که منابع API هستند، اشاره کنند. این pods هرگز قرار نبود مستقیماً منابع API را بخوانند چون از طریق API server ایجاد نمیشوند؛ یک باگ قبلاً به آنها اجازه ارجاع به مواردی مثل configMap را میداد که اکنون برطرف شده است. از v1.37 این مراجع ممنوع هستند و feature gate قبلی که امکان چشمپوشی را میداد (PreventStaticPodAPIReferences) حذف شده است — اگر روی خوشه یا فرآیند ساخت خود به این رفتار اشتباه تکیه کردهاید، باید آن را اصلاح کنید.
kube-proxy mode = ipvs: حالت ipvs که در گذشته برای بهبود کارایی معرفی شد، در حال بازنگری است زیرا هسته ipvs API به تنهایی توان تعویض کامل سرویسهای Kubernetes را ندارد و هنوز از برخی iptables زیرساختی استفاده میکند. برنامهریزی زمانی حذف/تغییر به این شکل است: در نسخه 1.40 حالت ipvs به طور پیشفرض غیرفعال میشود (هنوز قابل انتخاب از طریق feature gate است) و در نسخه 1.43 پشتیبانی کامل حذف خواهد شد. برای چک کردن حالتی که فعلاً فعال است، میتوانید کانفیگ kube-proxy را بخوانید و فیلد mode را بررسی کنید:
kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config.conf}' | grep 'mode:'
تغییرات بزرگ در حال انجام ⚙️
حذف پشتیبانی cgroup v1: از آنجا که توزیعهای مدرن لینوکس و runtimeها به سمت cgroup v2 میروند، حذف رسمی پشتیبانی از cgroup v1 در دستور کار است. از v1.35 مقدار پیشفرض failCgroupV1 روی true تنظیم شده و در نتیجه kubelet روی نودهایی که هنوز به cgroup v1 وابستهاند، بدون یک override صریح مقداردهی اولیه نمیشود. اگر نیاز دارید موقتاً این رفتار را نادیده بگیرید، میتوانید یک بازنویسی پیکربندی مثل زیر اعمال کنید:
apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration failCgroupV1: false # نادیده گرفتن موقت — فقط در صورت ضروری استفاده شود
توصیه عملی: مهاجرت به cgroup v2 را جدی بگیرید. قابلیتهای مدیریت منابع پیشرفته (مثل resize on the fly برای Pods و memory protection لایهای) روی cgroup v2 تکیه دارند و پشتیبانی از v1 برنامهریزی شده که در نسخههای بعدی حذف شود.
SELinux mount behavior (GA): قابلیت مربوط به seLinuxMount به وضعیت GA میرسد و به طور پیشفرض در v1.37 فعال خواهد شد. پس از این، volumeها به جای relabel بازگشتی، با گزینهٔ -o context= سوار میشوند ولی این رفتار فقط وقتی اتفاق میافتد که درایور CSI از طریق یک CSIDriver، .spec.seLinuxMount را true تنظیم کرده باشد. چون یک mount فقط یک SELinux context میتواند داشته باشد، پادهایی که حجمهای مختلفی با زمینههای متفاوت SELinux دارند ممکن است به relabel بازگشتی قبلی دسترسی نداشته باشند — اگر نیاز به حفظ رفتار بازگشتی دارید، از seLinuxChangePolicy: Recursive در spec Pod استفاده کنید. خوشههایی که SELinux ندارند تحت تأثیر نخواهند بود.
Metrics API به GA میرود: انتظار میرود API metrics.k8s.io پس از تقریباً نه سال به Stable (GA) در v1.37 ارتقا یابد. این API استاندارد مصرف CPU و حافظه برای Pods و Nodes را فراهم میکند و ابزارهایی مثل HPA و دستور kubectl top روی آن تکیه دارند. هر دو نسخه v1 و v1beta1 در دورهٔ انتقال قابل استفاده خواهند بود تا توسعهدهندگان بتوانند بدون شکست در گردشکار، به API پایدار مهاجرت کنند.
Kubelet در UserNS (Rootless / Beta): اجرای kubelet در user namespaces (معروف به حالت rootless) به بتا میرود. این مدل به کامپوننتهای نود اجازه میدهد که در فضای نام کاربری لینوکس بهعنوان کاربر غیر-root روی هاست اجرا شوند اما در فضای نام ریشه همچنان رفتار ریشهای داشته باشند. اثر عملی این تغییر: کاهش نیاز به امتیازات سطح میزبان و افزودن یک لایهٔ حفاظت بیشتر در برابر تاثیرات احتمالی آسیبپذیریها در اجزای نود — مخصوصاً برای محیطهایی که امنیت سطح میزبان اهمیت بالاتری دارد.
Volume Health Monitor (بازنشانی به آلفا + RPCهای CSI جدید): سابقهٔ مشکلات volume health (مثل اتصال ناموفق یا I/O آویزان) نشان داده که بدون یک گزارش خوانای ماشینی، تشخیص ریشهٔ مشکل دشوار است. در v1.37 این KEP پس از اجرای اولیه از v1.21، فارغالتحصیلی را به آلفا بازگردانده و چهار RPC جدید CSI معرفی میکند تا کنترلکنندهها و kubelet بتوانند وضعیت سلامت volumeها را گزارش کنند. اجزای کلیدی این طراحی عبارتاند از:
– ControllerListVolumeHealth و ControllerGetVolumeHealth برای گزارش سلامت از سمت کنترلکننده (فهرست مجموعههای ناسالم و بررسی یک volume مشخص).
– NodeGetVolumeHealth که kubelet آن را فراخوانی میکند تا سلامت volumeهای روی آن گره را بیابد و در Pod.status.volume.volumeHealths ثبت کند.
– ذخیرهٔ نتایج کنترلکننده در PersistentVolumeClaim.status.healthStatus و ثبت وضعیت گره در CSINode.status.storageHealth.
– واژگان خطا که ساده، قابل توسعه و قابل پارس ماشینی (مثل Unavailable، Degraded و غیره) هستند، با فیلدهای reason و message برای توضیح بیشتر توسط راننده.
این جداسازی گزارشهای سمت کنترلکننده و سمت گره نمایی کاملتر از وضعیت ذخیرهسازی فراهم میکند و برای عیبیابی و اتوماسیون خیلی مفید خواهد بود.
زمانبندی انتشار و ادامه کار 📅
تاریخ هدف برای انتشار Kubernetes v1.37 حالا چهارشنبه، 26 آگوست 2026 برنامهریزی شده است. تا آن زمان، یادداشتهای انتشار و CHANGELOG رسمی ممکن است بهروزرسانی شوند — حتماً قبل از ارتقاء، یادداشتهای انتشار نهایی را بررسی کنید و تستهای سازگاری و پشتیبانی runtime/os را برای خوشهها انجام دهید.
چگونه مشارکت کنید یا بیشتر یاد بگیرید 🤝
سادهترین راه برای درگیر شدن با Kubernetes پیوستن به SIGهای مرتبط با علاقهٔ شما است (SIGs مثل SIG Node، SIG Storage، SIG Auth و غیره). اگر نگران این هستید که از کجا شروع کنید، جلسات «new contributor orientation» ماهانه میتواند کمک کند تا قدمهای اول مشارکت را بردارید. مشارکت در حوزههایی مثل بررسی KEPها، تستهای e2e، و تهیه پیشنهادات مهاجرت برای کاربران واقعی بسیار ارزشمند است.
اگر رشتهای از تغییرات یا بخش خاصی مد نظر شماست و میخواهید نقطهنظرات عملیتری برای تیمهای SRE/DevOps دریافت کنید، بگویید کدام بخش را میخواهید اولویتبندی کنیم تا دقیقتر راهنمایی و چکلیست ارتقا برای آن تهیه کنم 🙂.
