🔵 عنوان مقاله
Kubernetes v1.34: VolumeAttributesClass for Volume Modification GA (2 minute read)

🟢 خلاصه مقاله:
در Kubernetes v1.34 قابلیت VolumeAttributesClass به مرحله GA رسیده و امکان تغییر پویا و ایمن برخی ویژگی‌های Volume را بدون ساخت مجدد PVC فراهم می‌کند؛ به‌شرط پشتیبانی درایور CSI. این ویژگی برای مواردی مثل تغییر سطح کارایی (IOPS/Throughput)، جابه‌جایی بین Tierها یا تنظیمات رمزنگاری کاربرد دارد و با تکیه بر کلاس‌های از پیش تعریف‌شده، کنترل و سیاست‌گذاری را ساده می‌کند. همچنین پشتیبانی صریح از لغو درخواست‌های «غیرقابل انجام» اضافه شده تا در صورت ناممکن بودن تغییر، وضعیت سریعاً به حالت پایدار بازگردد. در کنار آن، اعمال Quota روی PVCهایی که به یک VolumeAttributesClass خاص ارجاع می‌دهند ممکن شده و به مدیران امکان کنترل دقیق هزینه و حاکمیت در محیط‌های چندمستاجری را می‌دهد.

#Kubernetes #VolumeAttributesClass #CSI #PersistentVolume #PVC #CloudNative #DevOps

🟣لینک مقاله:
https://kubernetes.io/blog/2025/09/08/kubernetes-v1-34-volume-attributes-class/?utm_source=tldrdevops

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
PVC-Autoresizer: Dynamic Volume Expansion

🟢 خلاصه مقاله:
PVC-Autoresizer یک کنترلر در Kubernetes است که با پایش مصرف دیسک، اندازه PVC را به‌صورت خودکار و مرحله‌ای افزایش می‌دهد تا از پر شدن ناگهانی حجم و توقف سرویس جلوگیری شود. این ابزار بر اساس آستانه‌های قابل‌پیکربندی عمل می‌کند، تنها وقتی StorageClass و درایور CSI از گسترش پشتیبانی کنند اقدام می‌کند، و برای هر PVC/Namespace امکان سیاست‌های جداگانه (حداکثر اندازه، گام رشد، و Backoff) را فراهم می‌سازد. با فایل‌سیستم‌ها و درایورهای سازگار، گسترش اغلب آنلاین و بدون downtime انجام می‌شود؛ در غیر این صورت می‌تواند نیاز به راه‌اندازی مجدد کنترل‌شده را اعلام کند. موارد استفاده رایج شامل دیتابیس‌ها و بارهای Stateful با رشد غیرقابل‌پیش‌بینی است. محدودیت مهم این است که کوچک‌سازی معمولاً ممکن نیست و نیاز به allowVolumeExpansion و پشتیبانی CSI وجود دارد. نتیجه: خودکارسازی، پیشگیری از رخدادهای کمبود فضا، و کاهش کار عملیاتی در مدیریت ذخیره‌سازی.

#Kubernetes #PVC #PersistentVolume #CSI #DevOps #CloudNative #StatefulWorkloads #StorageAutomation

🟣لینک مقاله:
https://ku.bz/xwnlC772q

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Kubernetes Headaches: Unsticking StatefulSets from EBS ReadWriteMany Drama

🟢 خلاصه مقاله:
با اجرای سرویس‌های دارای حالت روی Kubernetes، خیلی زود محدودیت اصلی نمایان می‌شود: EBS در AWS برای ReadWriteMany طراحی نشده و همین باعث گیرکردن StatefulSetها، Pending شدن پادها و مشکل در اتصال ولوم‌ها بین نودها می‌شود. راه‌حل‌ها سه مسیر اصلی دارند: یا ماهیت ReadWriteOnce را بپذیرید و هر replica را در همان AZ و کنار EBS خودش نگه دارید (با تنظیمات topology و ReadWriteOncePod)، یا به یک RWX واقعی مهاجرت کنید (EFS با EFS CSI و Access Pointها، یا سیستم‌های توزیع‌شده مانند Rook Ceph/Longhorn/OpenEBS)، یا معماری برنامه را طوری بازطراحی کنید که نیاز به RWX از بین برود (sharding، استفاده از S3 برای blobها، و stream کردن WAL/backup).
برای مهاجرت امن: از VolumeSnapshot یا Jobهای کپی داده (rsync) بین PVCهای قدیم (EBS) و جدید (EFS/RWX) استفاده کنید، StatefulSet را به‌صورت ترتیبی scale down کنید، persistentVolumeClaimRetentionPolicy را برای حفظ PVCها تنظیم کنید، StorageClass را در volumeClaimTemplates عوض کنید و سپس به‌تدریج scale up کنید. رعایت PDB، readiness، fsGroup، و IRSA برای درایورهای CSI حیاتی است و باید قبل از سوییچ نهایی، کارایی و برگشت‌پذیری را با fio و پشتیبان‌گیری (Velero/اسنپ‌شات‌ها) تست کرد. به‌طور خلاصه: یا با EBS و تک‌نویسنده کنار بیایید، یا به EFS/ذخیره‌سازی توزیع‌شده بروید؛ تلاش برای RWX با EBS معمولاً فقط مشکل را عقب می‌اندازد.

#Kubernetes #StatefulSet #EBS #EFS #RWX #CSI #AWS #CloudStorage

🟣لینک مقاله:
https://ku.bz/Zg29dRHx4

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
topolvm: capacity-aware CSI

🟢 خلاصه مقاله:
TopoLVM یک درایور CSI برای Kubernetes است که با استفاده از LVM روی Linux، دیسک‌های محلی هر نود را به PersistentVolumeهای پویا و قابل اطمینان تبدیل می‌کند. ویژگی اصلی آن «آگاه از ظرفیت» بودن است؛ یعنی ظرفیت آزاد واقعی هر نود را می‌شناسد و آن را به Scheduler اعلام می‌کند تا Podهایی که PVC دارند فقط روی نودهایی زمان‌بندی شوند که واقعا توان تامین آن حجم را دارند. این رویکرد از حلقه‌های شکست در زمان‌بندی و خطاهای دیرهنگام Provisioning جلوگیری می‌کند.

TopoLVM معمولا شامل یک Controller، یک Node Plugin و مولفه سبک lvmd روی هر نود است. StorageClassها می‌توانند به Volume Groupها یا Device Classهای متفاوت نگاشت شوند تا لایه‌های کارایی مختلف ارائه شود. پشتیبانی از حجم‌های فایل‌سیستمی و Block، توسعه حجم (در صورت پشتیبانی Kubernetes)، و تنظیمات Thin/Thick provisioning در LVM فراهم است. در کلاسترهایی که Storage Capacity Tracking را پشتیبانی می‌کنند، اطلاعات ظرفیت از طریق اشیای StorageCapacity در دسترس Scheduler قرار می‌گیرد.

این راه‌حل برای سناریوهای ذخیره‌سازی محلی با کارایی بالا و نیاز به Locality مناسب است؛ مانند محیط‌های Bare Metal و Edge. از آن‌جا که Volumeها محلی‌اند، تاب‌آوری معمولا از طریق تکرار در سطح اپلیکیشن تامین می‌شود. در مقایسه با درایورهای ذخیره‌سازی شبکه‌ای، TopoLVM بر ظرفیت قابل پیش‌بینی روی نود، Provisioning سریع و کنترل مستقیم عملیاتی با LVM تمرکز دارد.

#Kubernetes #CSI #TopoLVM #LVM #Storage #PersistentVolume #CapacityAware #DevOps

🟣لینک مقاله:
https://ku.bz/nW4zYDCHT

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon