DevOps Labdon
470 subscribers
24 photos
3 videos
2 files
733 links
👑 DevOps Labdon

حمایت مالی:
https://www.coffeete.ir/mrbardia72

ادمین:
@mrbardia72
Download Telegram
🔵 عنوان مقاله
Kubernetes 1.33: Resizing Pods Without the Drama (Finally!)

🟢 خلاصه مقاله:
کوبرنیتس 1.33 روی حل یک درد قدیمی تمرکز دارد: تغییر CPU و Memory یک Pod بدون ری‌استارت و رول‌اوت‌های پرهزینه. در نسخه‌های قبلی، تنظیم request/limit معمولاً به بازسازی Pod یا تغییرات پیچیده در Deployment/StatefulSet ختم می‌شد که برای سرویس‌های حساس یا اپ‌های stateful دردسرساز بود. در این نسخه، امکان تغییر منابع به‌صورت in-place در سطح Pod بسیار روان‌تر شده است؛ kubelet تغییرات cgroup را روی نود اعمال می‌کند، حسابداری منابع و زمان‌بند با درخواست‌های جدید هماهنگ می‌شوند و محدودیت‌هایی مثل ResourceQuota و LimitRange همچنان رعایت می‌گردند. نتیجه این است که برای رایت‌سایزینگ واقعی، کمتر نیاز به رول‌اوت دارید، ریسک وقفه کاهش می‌یابد و هزینه‌ها بهتر کنترل می‌شود. با این حال، همه منابع یکسان قابل تغییر لحظه‌ای نیستند و کاهش تهاجمی Memory می‌تواند خطر OOM داشته باشد؛ بنابراین توصیه می‌شود تغییرات مرحله‌ای انجام شود و با مانیتورینگ دقیق همراه باشد. خلاصه اینکه 1.33 رایت‌سایزینگ را به یک عملیات کم‌دردسر و کاربردی تبدیل می‌کند و زمان تیم‌ها را از مدیریت رول‌اوت‌های غیرضروری به بهینه‌سازی عملکرد و هزینه روی بارهای واقعی منتقل می‌سازد.

#Kubernetes #Pods #DevOps #SRE #CloudNative #Autoscaling #ResourceManagement #Containers

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


👑 @DevOps_Labdon
🎉2
🔵 عنوان مقاله
How to run AI model inference with GPUs on Amazon EKS Auto Mode

🟢 خلاصه مقاله:
اجرای استنتاج مدل‌های هوش مصنوعی روی GPU در Amazon EKS Auto Mode با اعلام نیازمندی‌ها در سطح Pod ساده می‌شود و خودکار ظرفیت GPU را فراهم و مقیاس می‌دهد. کافی است سرور استنتاج (مثل TensorFlow Serving، TorchServe یا NVIDIA Triton Inference Server) را با CUDA/cuDNN و NVIDIA Container Toolkit در یک ایمیج آماده کنید، در Deployment منابع nvidia.com/gpu و CPU/Memory را درخواست دهید، و با نصب NVIDIA device plugin امکان شناسایی GPU را فراهم کنید. Auto Mode براساس این درخواست‌ها نودهای GPU مناسب را در EC2 تأمین و زمان‌بندی را تسریع می‌کند. برای مقیاس‌پذیری از HPA و اتوسکیلینگ کلاستر استفاده کنید و با تکنیک‌هایی مثل dynamic batching و multi-model throughput را بالا ببرید؛ برای مدیریت هزینه، right-sizing، استفاده هدفمند از Spot و scale-to-zero را در نظر بگیرید. امنیت و شبکه با VPC CNI، Security Group و IAM Roles for Service Accounts و مشاهده‌پذیری با Prometheus/Grafana، DCGM و CloudWatch تکمیل می‌شوند. در نهایت، با CI/CD و Amazon ECR و الگوهای انتشار امن (blue/green یا canary) استقرار به‌صورت قابل تکرار و پایدار از توسعه تا تولید انجام می‌شود.

#AmazonEKS #Kubernetes #GPU #MLOps #AWS #Inference #AutoScaling #NVIDIA

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


👑 @DevOps_Labdon
🔵 عنوان مقاله
Kubernetes Event Driven Autoscaling: Spring Boot & RabbitMQ

🟢 خلاصه مقاله:
این مقاله KEDA را به‌عنوان راهکاری سبک برای مقیاس‌پذیری رویدادمحور در Kubernetes معرفی می‌کند؛ رویکردی که به‌جای تکیه صرف بر CPU یا memory، بر اساس منابع رویدادی خارجی مانند طول صف در RabbitMQ مقیاس را تنظیم می‌کند. با پشتیبانی از Deployments، StatefulSets و Jobs، KEDA می‌تواند هنگام نبود کار تا سطح صفر مقیاس دهد و با افزایش پیام‌ها در صف، تعداد پادهای پردازشگر Spring Boot را بالا ببرد.

در این روش، با نصب KEDA و تعریف یک ScaledObject (یا ScaledJob) که به بارکار هدف اشاره دارد، تریگر RabbitMQ با تنظیماتی مانند نام صف، اطلاعات اتصال، هدف طول صف، pollingInterval، cooldownPeriod و حدود حداقل/حداکثر replica پیکربندی می‌شود. KEDA به‌عنوان metrics adapter عمل می‌کند و معیارهای رویدادمحور را به مسیر autoscaling وارد می‌کند تا خوشه بر اساس فشار واقعی کار نه صرفاً آستانه‌های منابع، واکنش نشان دهد.

نتیجه این است که در معماری‌های مبتنی بر صف و پردازش ناهمزمان، مقیاس‌پذیری دقیق‌تر و مقرون‌به‌صرفه‌تری نسبت به روش صرفاً مبتنی بر CPU/memory حاصل می‌شود؛ در زمان اوج، توان پردازش سریع‌تر و در زمان بیکاری، مصرف منابع حداقلی خواهد بود.

#Kubernetes #KEDA #RabbitMQ #SpringBoot #Autoscaling #EventDriven #DevOps #CloudNative

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


👑 @DevOps_Labdon
🔵 عنوان مقاله
Metrics Server and HPA in Kubernetes

🟢 خلاصه مقاله:
** این آموزش نشان می‌دهد چگونه با استفاده از Metrics Server برای جمع‌آوری معیارهای CPU و حافظه و ابزار Horizontal Pod Autoscaler (HPA) در Kubernetes، مقیاس‌گذاری خودکار Deploymentها را پیاده‌سازی کنید. ابتدا Metrics Server را نصب و با kubectl top صحت جریان معیارها را بررسی می‌کنید، سپس برای Deployment هدف، یک HPA با حداقل/حداکثر Replica و اهدافی مثل متوسط استفاده CPU تعریف می‌شود. با اعمال بار، HPA تعداد Podها را برای رسیدن به هدف افزایش و در زمان کاهش بار آن را کاهش می‌دهد. آموزش بر تنظیم requests/limits، انتخاب بازه مناسب Replica و آگاهی از محدودیت‌های Metrics Server تأکید دارد؛ و برای نیازهای پیشرفته به معیارهای سفارشی، استفاده از Custom Metrics API و ابزارهایی مانند Prometheus Adapter را پیشنهاد می‌کند.

#Kubernetes #HPA #MetricsServer #Autoscaling #CloudNative #DevOps #Containers

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


👑 @DevOps_Labdon
🔵 عنوان مقاله
Best Practices Cluster Setup Guide for Real-Time Inference on Amazon EKS

🟢 خلاصه مقاله:
**این راهنما نشان می‌دهد چگونه مدل‌های ML را به سرویس‌های آمادهٔ تولید روی Amazon EKS تبدیل کنید، به‌ویژه برای بارهای GenAI با نیاز به تأخیر کم و ظرفیت الاستیک. محتوای آن اصول طراحی کلاستر (انتخاب CPU/GPU، تفکیک بارها با Node Group، چند-AZ، امنیت با Namespace و NetworkPolicy و IRSA)، استقرار استاندارد (کانتینرسازی، مدیریت کانفیگ و آرتیفکت‌ها)، و مقیاس‌پذیری چندلایه را پوشش می‌دهد: HPA در سطح Pod بر اساس متریک‌ها و Cluster Autoscaler برای افزودن/کاهش ظرفیت. همچنین به پیش‌گرم‌سازی برای کاهش Cold Start، مدیریت ترافیک با Ingress/Load Balancer، و بهینه‌سازی هزینه با Right-Sizing و ترکیب On-Demand و Spot اشاره می‌کند. برای پایداری، الگوهای Canary/Blue‑Green، PDB و پراکندگی توپولوژیک پیشنهاد می‌شود؛ و برای عملیات، مشاهده‌پذیری و هشداردهی مبتنی بر SLO به‌همراه آزمون کارایی توصیه شده است. نتیجه: ساده‌سازی دیپلوی، مقیاس‌گذاری کارآمد، و کاهش هزینهٔ عملیاتی برای ارائهٔ بی‌وقفهٔ استنتاج بلادرنگ روی EKS.

#AmazonEKS #Kubernetes #MLOps #RealTimeInference #GenAI #Autoscaling #CostOptimization #CloudArchitecture

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


👑 @DevOps_Labdon
🔵 عنوان مقاله
KEDA HTTP Add-on: scale on requests

🟢 خلاصه مقاله:
مقیاس‌گذاری خودکار برای سرویس‌های HTTP در Kubernetes با تکیه بر سیگنال‌های CPU/Memory دقیق نیست. KEDA HTTP Add-on این مشکل را با مقیاس‌گذاری بر اساس ترافیک واقعی HTTP (درخواست‌های در حال پردازش و در صف) حل می‌کند. این افزونه با KEDA یکپارچه است، از scale-to-zero پشتیبانی می‌کند، با یک پروکسی سبک جلوی سرویس صف‌سازی و مسیربندی امن انجام می‌دهد تا هنگام جهش ترافیک، بارگذاری سرد و ازدحام کنترل شود. پیکربندی آن از طریق HTTPScaledObject انجام می‌شود و با Ingress و Service Mesh سازگار است، معمولاً بدون نیاز به تغییر کد برنامه. برای رصدپذیری، متریک‌ها به Prometheus صادر می‌شوند و با Grafana قابل مانیتور هستند. نتیجه، هم‌راست‌سازی تعداد Replicaها با تقاضای واقعی HTTP برای بهبود کارایی، کاهش هزینه و پوشش بهتر ترافیک‌های انفجاری است؛ همچنین می‌تواند در کنار HPA و سایر Scalerهای KEDA استفاده شود.

#KEDA #Kubernetes #Autoscaling #HTTP #Serverless #CloudNative #DevOps #Observability

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


👑 @DevOps_Labdon
🔵 عنوان مقاله
Autoscaling .NET APIs with KEDA and Kubernetes Metrics

🟢 خلاصه مقاله:
** مقیاس‌پذیری خودکار برای APIهای .NET در Kubernetes با ترکیب HPA، Kubernetes Metrics و KEDA ممکن می‌شود. KEDA با تعریف ScaledObject و تریگرهایی مثل درخواست‌درثانیه یا تأخیر از Prometheus، عمق صف در RabbitMQ/Kafka، و زمان‌بندی cron، متریک‌های خارجی را به HPA می‌دهد و حتی قابلیت scale‑to‑zero را فراهم می‌کند. برای APIهای .NET می‌توان روی نرخ درخواست، تعداد درخواست‌های درحال پردازش، یا صف کارهای پس‌زمینه مقیاس داد و هم‌زمان یک تکیه‌گاه CPU برای جهش‌های محاسباتی داشت. بهترین‌عمل‌ها شامل تنظیم درست requests/limits، همکاری با Cluster Autoscaler، تعریف readiness/liveness/startup probes، کنترل همزمانی، و بهینه‌سازی‌های .NET مانند async I/O، HttpClientFactory و connection pooling است. با پایش Prometheus/Grafana، آزمون بار مثل k6، و پنجره‌های تثبیت و cooldown مناسب، API به‌صورت رویدادمحور، دقیق و به‌صرفه مقیاس می‌گیرد و در اوج‌ها پایدار می‌ماند.

#Kubernetes #KEDA #DotNet #Autoscaling #HPA #Prometheus #CloudNative #APIs

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


👑 @DevOps_Labdon
🔵 عنوان مقاله
Cost-optimized ml on production: autoscaling GPU nodes on Kubernetes to zero using keda

🟢 خلاصه مقاله:
این آموزش نشان می‌دهد چگونه با استفاده از Kubernetes و KEDA ظرفیت GPU را بر اساس طول صف پیام‌ها به‌صورت خودکار تا صفر کاهش دهیم و هزینه اجرای ML در محیط تولید را کم کنیم. معماری مبتنی بر یک message queue (مثل Kafka، RabbitMQ یا AWS SQS) است و KEDA با ScaledObject تعداد پادهای مصرف‌کننده GPU را نسبت به backlog تنظیم می‌کند (minReplicaCount=0). با فعال‌بودن Cluster Autoscaler و یک GPU node pool با حداقل اندازه صفر، نودهای GPU فقط هنگام نیاز ایجاد و سپس آزاد می‌شوند. نکات کلیدی شامل تنظیم nodeSelector/tolerations، درخواست nvidia.com/gpu، کنترل pollingInterval/cooldownPeriod، کاهش cold start با pre-pull و پایش با Prometheus/Grafana است. نتیجه: پرداخت هزینه GPU فقط هنگام وجود کار، همراه با حفظ قابلیت اطمینان و کنترل تأخیر.

#Kubernetes #KEDA #GPU #MLOps #Autoscaling #CostOptimization #MessageQueue #ProductionML

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


👑 @DevOps_Labdon
1
🔵 عنوان مقاله
Under the hood: Amazon EKS Auto Mode

🟢 خلاصه مقاله:
Amazon EKS Auto Mode با خودکارسازی راه‌اندازی، مقیاس‌دهی و نگه‌داری کنترل پلین و worker nodeها، بار مدیریت زیرساخت Kubernetes را برمی‌دارد تا تیم‌ها بر توسعه محصول تمرکز کنند. در این مطلب، AWS توضیح می‌دهد این رویکرد برای بارهای کاری Kubernetes چه مزایایی دارد؛ از تأمین خودکار ظرفیت و مقیاس‌پذیری متناسب با ترافیک تا کاهش اضافه‌ظرفیت و ساده‌سازی عملیات برای سناریوهای مختلف مانند microservices و پردازش دسته‌ای. همچنین نگاهی به سازوکار درونی EKS Auto Mode ارائه می‌شود—نحوه ایجاد و نگه‌داری منابع کلاستر، تصمیم‌های مقیاس‌دهی، اعمال به‌روزرسانی‌ها و وصله‌های امنیتی با حداقل اختلال، و ادغام با قابلیت‌های شبکه، ذخیره‌سازی و observability در AWS. در پایان، به ملاحظات هزینه، بهترین‌روش‌ها و نحوه هم‌راست‌سازی با CI/CD اشاره می‌شود تا تیم‌ها با اعتماد بیشتری از این اتوماسیون استفاده کنند.

#AmazonEKS #Kubernetes #AWS #Cloud #DevOps #Containers #Autoscaling #PlatformEngineering

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


👑 @DevOps_Labdon