در مجموعههای SIG Spotlight، گروههایی را معرفی میکنیم که توسعه Kubernetes را به جلو میبرند. این شماره درباره SIG Storage است — تیمی که مسئول فراهمسازی ذخیرهسازی پایدار، مدیریت حجمها و رابطهایی است که بارهای کاری Kubernetes را به سیستمهای ذخیرهسازی زیرساختی متصل میکند. 😊
سوال: میتوانید خودتان را معرفی کنید و نقشهایتان در SIG Storage را بگویید؟
من Xing Yang هستم؛ مهندس نرمافزار در VMware by Broadcom و یکی از co-chairs تیم SIG Storage. هموقت با من، Saad Ali از Google هم co-chair است و دو technical lead اصلی تیم Michelle Au از Google و Jan Šafránek از Red Hat هستند. 🎯
سوال: چه چیزی باعث شد به فضای ذخیرهسازی در Kubernetes علاقهمند شوید و چطور وارد مشارکت شدید؟
پیشینه من در حوزه ذخیرهسازی بود، بنابراین وقتی شروع به یادگیری Kubernetes کردم، SIG Storage یک انتخاب طبیعی بود. با حضور در جلسات SIG کمکم فهمیدم کجا میتوانم کمک کنم — این زمانها قبل از معرفی رسمی Container Storage Interface (CSI) بود و خیلی چیزها در حال شکلگیری بودند؛ واقعاً دوران پرفراز و نشیبی بود. 🚀
سوال: امروز روی چه زیرپروژهها یا حوزههایی فعال هستید؟
من نگهدارنده (maintainer) در پروژه Kubernetes CSI هستم. همچنین تعدادی ابزار جانبی مرتبط با CSI مثل csi-provisioner، csi-attacher، csi-resizer و csi-snapshotter وجود دارند که پس از هر نسخه Kubernetes نیاز به انتشار دارند. علاوه بر این، من co-chair یک Data Protection WG هستم که با حمایت SIG Storage و SIG Apps کار میکند و روی gapهای حفاظت داده در Kubernetes کار میکند — ویژگیهایی مثل VolumeGroupSnapshot و Changed Block Tracking (CBT) از خروجیهای مهم این گروه هستند. 🔧
درباره SIG Storage: اگر تازهکارید، SIG Storage چیست و چه مسائلی را حل میکند؟
SIG Storage یک Special Interest Group است که تمرکزش روی چگونگی فراهم شدن ذخیرهسازی برای کانتینرها در خوشه Kubernetes است. ما استانداردها و APIهایی تعریف میکنیم تا فروشندههای ذخیرهسازی بتوانند درایور بنویسند و سیستمهای ذخیرهسازی زیربنایی توسط بارهای کاری Kubernetes مصرف شوند — همان نقش کلیدی که CSI برای بلوک و فایل دارد. 📦
چرا به یک SIG جدا برای ذخیرهسازی نیاز بود و چه چیزی ذخیرهسازی را در سیستم توزیعشده سخت میکند؟
ابتدا Kubernetes برای بارهای بدونحالت طراحی شده بود؛ اما خیلی سریع Stateful workloads وارد شدند و نیاز به ماندگاری داده پدید آمد. مدیریت persistence در یک سیستم طراحیشده برای ephemeral بودن، پیچیدگیهای خاص خودش را دارد: سازوکارهایی مثل PersistentVolume، PersistentVolumeClaim و StorageClass معرفی شدند تا این نیازها را رفع کنند، اما کنار اینها چالشهایی مثل data gravity، جابجایی داده و سازگاری در سطح برنامه همچنان بزرگ هستند. ⚖️
SIG Storage در ابتدا چگونه شکل گرفت و ماموریتش چگونه تغییر کرد؟
در ابتدا بسیاری از پلاگینهای ذخیرهسازی بهصورت in-tree (درون درخت) بودند و SIG روی آنها مدیریت داشت. با آمدن CSI، مسیر حرکت به سمت out-of-tree drivers باز شد که اجازه میداد توسعهدهندگان بدون تغییر کد اصلی Kubernetes درایور بسازند. سپس SIG دامنهاش را گسترش داد تا ویژگیهای سطح بالاتر ذخیرهسازی را هم مدیریت کند و بعداً پشتیبانی از object storage از طریق Container Object Storage Interface (COSI) را هم اضافه کرد. این تکامل باعث شد تا تمرکز از صرفاً افزونهها به مدیریت کامل تجربه ذخیرهسازی ارتقا یابد. 🔁
برترین ویژگیهای فعال فعلی SIG Storage چیستند؟
چند کار برجسته وجود دارد: VolumeGroupSnapshot که امکان گرفتن snapshot گروهی از چند PersistentVolume را بهصورت هماهنگ فراهم میکند — این ویژگی برای برنامههایی مثل دیتابیسهای توزیعشده حیاتی است و اخیراً به GA در Kubernetes v1.36 رسید. ویژگی دیگر Changed Block Tracking (CBT) در CSI است که امکان پشتیبانگیری افزایشی بسیار کارآمد را میدهد؛ CBT در v1.36 به بتا ارتقا یافته است. همچنین COSI برای استانداردسازی دسترسی به object buckets در Kubernetes فعال است و اکنون در مسیر v1alpha2 به سمت بتا حرکت میکند. 🛠️
کدام کار اخیر را بیشترین «برد» برای کاربران میدانید؟
فارغالتحصیلی VolumeAttributesClass به GA در v1.34 یک برد بزرگ بود. قبلاً تغییر ویژگیهایی مثل IOPS یا throughput نیازمند کار خارج از باند یا دستی بود؛ حالا کاربران میتوانند بهصورت پویا تنظیماتی مثل IOPS را از طریق Kubernetes API مدیریت کنند — مشابه اینکه چطور CPU و حافظه را تنظیم میکنند. این بهینهسازی هزینه و انعطافپذیری عملیاتی را بسیار آسانتر میکند. 🏆
با نگاه به چند نسخه آینده، چه چیزهایی در نقشه راه هستند که باید دنبال شوند؟
یکی از تمرکزها Volume Health است: هدف ارائه دید عملیاتی و یکپارچگی حجمهاست تا بتوان مشکلات را زودتر شناسایی کرد و در آینده خودکارسازی بازیابی را فراهم کرد. در حال حاضر گزارش سلامت از طریق رویدادها انجام میشود، اما ما دنبال بهبود مدل گزارش و حرکت به سمت قابلیتهای اصلاح خودکار (auto-remediation) هستیم. ⚕️
آیا حوزههایی وجود دارد که مایلید جامعه دربارهشان بحث یا کمک کند؟
ما همیشه به کمک جامعه برای رفع باگها، اضافه کردن تستها و کمک در PR reviewها نیاز داریم. موضوعاتی مثل Alpha Mutable PV Affinity (برای جابجایی حجم بین منطقهها یا از یک نوع دیسک به نوع دیگر) و بحث تکرار حجم (replication) در Data Protection WG مطرح هستند — مشارکتکنندگان علاقهمند را به پیوستن به جلسات WG دعوت میکنیم. 🤝
کاربران امروز در اجرای بارهای حالتدار در Kubernetes با چه چالشهایی مواجهاند؟
چند چالش کلیدی وجود دارد: اول data gravity — دادههای پایدار تمایل دارند در محل خاصی متمرکز شوند و اگر یک گره خراب شود، volumeهای محلی ممکن است گیر کنند. تشخیص اینکه قطع سرویس موقتی است یا دائمی کار حساسی است. دوم «روز دوم» عملیات: راهاندازی ساده است، ولی نگهداری، ارتقاء schema، وصلهها و ارتقای کل خوشه دردسرساز است. سوم تحرک دادهها: جابجایی ظرفیت و انتقال بین لایهها یا مناطق، همگامسازی و تکرار برای HA/DR، همه چالشهای فنی و عملیاتی بزرگی هستند. ⚠️
ذخیرهسازی و AI/ML — در چند سال آینده چه تغییراتی میبینید؟
چند روند مشهود است: درایورهای CSI و ابزارهای مدیریت داده هوشمندتر خواهند شد، با قابلیتهایی مثل automated tiering، snapshot، migration و replication بهینهشده برای جریانهای کاری AI/ML و پلتفرمهای داده در مقیاس بزرگ. ذخیرهسازی اشیاء (با COSI) بهعنوان یک شهروند درجهیک شناخته میشود تا مجموعهدادههای بزرگ ML را بهتر مدیریت کند. همچنین شاهد پذیرش NVMe-over-Fabrics و فایلسیستمهای موازی تحت مدیریت بومی Kubernetes خواهیم بود. نهایتاً scheduling آگاه از داده (data-aware scheduling) بیشتر میشود تا هزینه جابجایی داده در مقابل حرکت compute سنجیده شود. 🔮
اگر شما SRE یا DevOps هستید که با دیتابیسهای Production کار میکنید یا توسعهدهندهای که به داخله ذخیرهسازی علاقهمند است، مکان برای مشارکت در SIG Storage وجود دارد. پیشنهاد میکنم در جلسات شرکت کنید، در بررسی درایورها کمک کنید، تستهای بیشتر بنویسید و بازخورد برای ویژگیهای آلفا ارسال کنید — حضور شما واقعاً تفاوت ایجاد میکند. ✨
