🔵 عنوان مقاله
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

🔵 عنوان مقاله
Most Cloud-Native Roles are Software Engineers

🟢 خلاصه مقاله:
این مقاله بازار کار cloud-native در سال ۲۰۲۵ را بررسی می‌کند و نشان می‌دهد که حدود ۴۷٪ از موقعیت‌های مرتبط با Kubernetes به عنوان Software Engineer آگهی می‌شوند؛ در حالی‌که نقش‌های DevOps، Platform، DevSecOps و SRE سهم کمتری دارند. این روند بیانگر استخدامِ مهندس‌محور و حرکت به‌سمت shift-left است: از توسعه‌دهندگان انتظار می‌رود علاوه بر توسعه، با Kubernetes و بخشی از زیرساخت، امنیت و تحویل نیز درگیر باشند. برای متقاضیان، تسلط بر Kubernetes همراه با مهارت‌های CI/CD، IaC، observability و اصول امنیت ضروری‌تر شده است و در عین حال همکاری نزدیک با تیم‌های DevOps/Platform/SRE همچنان اهمیت دارد.

#CloudNative #Kubernetes #SoftwareEngineering #DevOps #SRE #DevSecOps #PlatformEngineering #TechJobs2025

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
SR-IOV Network Device Plugin

🟢 خلاصه مقاله:
این افزونه با بهره‌گیری از SR-IOV امکان تخصیص مستقیم VFهای یک NIC فیزیکی به Podها را در Kubernetes فراهم می‌کند تا به کارایی نزدیک به سخت‌افزار، تأخیر پایین و سربار CPU کم برسند. افزونه به‌صورت DaemonSet روی نودها اجرا می‌شود، دستگاه‌های SR-IOV را کشف کرده و از طریق Device Plugin API به‌عنوان منابع قابل‌درخواست در اختیار kubelet می‌گذارد؛ با درخواست Pod یک VF به‌طور انحصاری تخصیص می‌یابد و جداسازی و پیش‌بینی‌پذیری کارایی تضمین می‌شود. پیکربندی شبکه با SR-IOV CNI و معمولاً Multus انجام می‌شود و بسته به نیاز، VF می‌تواند به درایورهایی مانند vfio-pci برای DPDK یا درایورهای کرنلی متصل شود؛ همچنین در صورت پشتیبانی سخت‌افزار، RDMA قابل استفاده است. استقرار نیازمند فعال‌سازی SR-IOV و IOMMU، NIC سازگار، ایجاد VFها و Linux است و در بسیاری از سناریوها SR-IOV Network Operator مدیریت خودکار و سیاست‌گذاری را ساده می‌کند. این راهکار برای CNFها، NFV، تحلیل بلادرنگ و محیط‌های با حساسیت بالا به تأخیر کاربردی است و به‌صورت استاندارد با اکوسیستم CNI در Kubernetes ادغام می‌شود.

#SRIOV #Kubernetes #CNI #Multus #DPDK #NFV #Networking #CloudNative

🟣لینک مقاله:
https://ku.bz/jVg_1VS-k

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Debugging the One-in-a-Million Failure: Migrating Pinterest’s Search Infrastructure to Kubernetes

🟢 خلاصه مقاله:
** این مقاله روایت مهاجرت زیرساخت جست‌وجوی Pinterest به Kubernetes است و چگونگی برخورد تیم با یک خطای بسیار نادر را شرح می‌دهد؛ خطایی که در محیط‌های آزمایشی دیده نمی‌شد اما در بار واقعی تولید، به‌صورت افزایش‌های مقطعی در تاخیر و تایم‌اوت‌های پراکنده بروز می‌کرد. تیم با تقویت مشاهده‌پذیری، هم‌بند کردن لاگ‌ها، متریک‌ها و تریس‌ها، و اجرای آزمایش‌های کنترل‌شده و تدریجی روی پیکربندی‌ها، مسئله را مانند یک معمای سیستم‌های توزیع‌شده واکاوی کرد. نتیجه نشان داد مشکل ناشی از برهم‌کنش چند عامل بود: زمان‌بندی ارکستریشن، محدودیت‌های منابع، و سیاست‌های retry/timeout که در شرایط خاص همدیگر را تقویت می‌کردند. راه‌حل شامل مجموعه‌ای از بهبودهای کوچک اما مکمل بود—از تنظیم دقیق درخواست/سقف منابع و آماده‌سازی سرویس تا هموار کردن رفتار autoscaling، بهینه‌سازی زمان‌بندی readiness، و مقاوم‌سازی سیاست‌های backoff و فشار معکوس. درس‌های کلیدی نیز بر مهاجرت‌های مبتنی بر SLO، آینه‌سازی ترافیک تولید، آزمایش خرابی متمرکز بر رخدادهای Kubernetes، و اتوماسیون علائم هشداردهنده برای تشدیدهای نادر تاکید دارند. در نهایت، مهاجرت مزایای مقیاس‌پذیری و یکنواختی استقرار را به‌همراه داشت و نشان داد که در مقیاس بزرگ، رخدادهای «یک در میلیون» باید به‌طور نظام‌مند دیده، سنجیده و مهار شوند.

#Kubernetes #Pinterest #SearchInfrastructure #DistributedSystems #Debugging #ReliabilityEngineering #Migration #ProductionIncidents

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
How to Prevent Failures with Kubernetes Topology Spread Constraints

🟢 خلاصه مقاله:
این مقاله نشان می‌دهد چرا استفاده از Pod Topology Spread Constraints در زمان rolling updates می‌تواند باعث توزیع ناعادلانه پادها شود و در پایان استقرار، یک یا چند ناحیه بیش‌ازحد شلوغ بماند. علت این است که Scheduler در هنگام جای‌گذاری پادهای جدید، پادهای قدیمی و جدید را با هم در نظر می‌گیرد؛ بنابراین پادهای تازه را به نواحی «فعلاً» کم‌تراکم می‌فرستد، اما با حذف تدریجی پادهای قدیمی، همان نواحی از نسخه جدید اشباع می‌شوند.

راه‌حل پیشنهادی استفاده از matchLabelKeys (برای نمونه با کلید pod-template-hash) است تا Scheduler هر نسل از پادها را فقط نسبت به هم‌نسل‌های خودش پخش کند. بدین ترتیب هر ReplicaSet به‌طور مستقل متعادل می‌شود و چون نسل قبلی نیز از قبل متعادل بوده، مجموع پادها در طول و پس از rollout یکنواخت باقی می‌ماند.

برای اجرای درست، از پشتیبانی Kubernetes v1.25+ نسبت به matchLabelKeys مطمئن شوید، topologyKey مناسب (مثلاً topology.kubernetes.io/zone) و maxSkew معقول انتخاب کنید و سیاست whenUnsatisfiable را بسته به نیاز سخت‌گیرانه (DoNotSchedule) یا منعطف (ScheduleAnyway) تنظیم کنید.

#Kubernetes #PodTopologySpreadConstraints #TopologySpread #RollingUpdates #DevOps #SRE #HighAvailability #matchLabelKeys

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon