🔵 عنوان مقاله
Kubernetes CPU Limits and Go
🟢 خلاصه مقاله:
بهروزرسانی این مقاله توضیح میدهد که چرا runtime زبان Go بهطور پیشفرض از محدودیتهای CPU در Kubernetes خبر ندارد و چگونه همین موضوع میتواند به oversubscription و در نتیجه throttling و جهشهای تاخیری منجر شود. راهحل عملی، همراستاکردن GOMAXPROCS با سهم واقعی CPU کانتینر (براساس cgroups) است؛ یا با تنظیم متغیر محیطی GOMAXPROCS یا با استفاده از کتابخانه go.uber.org/automaxprocs تا runtime با ظرفیت واقعی زمانبندی کند. از نظر عملیاتی، برای سرویسهای حساس به تاخیر بهتر است از limit سخت CPU پرهیز کرده و به request بههمراه HPA اتکا کنید؛ در صورت اجبار به limit، سقف را طوری بگذارید که throttling حداقلی باشد و در صورت نیاز از CPU pinning و QoS مناسب بهره بگیرید. ارزیابی این تنظیمات با سنجههایی مانند container_cpu_cfs_throttled_seconds_total و توزیع تاخیر و نیز متریکهای runtime در Go، تصویر دقیقی از تاثیر بهینهسازیها ارائه میکند.
#Kubernetes #Go #GOMAXPROCS #cgroups #CPUThrottling #ContainerPerformance #DevOps #SRE
🟣لینک مقاله:
https://golangweekly.com/link/174644/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Kubernetes CPU Limits and Go
🟢 خلاصه مقاله:
بهروزرسانی این مقاله توضیح میدهد که چرا runtime زبان Go بهطور پیشفرض از محدودیتهای CPU در Kubernetes خبر ندارد و چگونه همین موضوع میتواند به oversubscription و در نتیجه throttling و جهشهای تاخیری منجر شود. راهحل عملی، همراستاکردن GOMAXPROCS با سهم واقعی CPU کانتینر (براساس cgroups) است؛ یا با تنظیم متغیر محیطی GOMAXPROCS یا با استفاده از کتابخانه go.uber.org/automaxprocs تا runtime با ظرفیت واقعی زمانبندی کند. از نظر عملیاتی، برای سرویسهای حساس به تاخیر بهتر است از limit سخت CPU پرهیز کرده و به request بههمراه HPA اتکا کنید؛ در صورت اجبار به limit، سقف را طوری بگذارید که throttling حداقلی باشد و در صورت نیاز از CPU pinning و QoS مناسب بهره بگیرید. ارزیابی این تنظیمات با سنجههایی مانند container_cpu_cfs_throttled_seconds_total و توزیع تاخیر و نیز متریکهای runtime در Go، تصویر دقیقی از تاثیر بهینهسازیها ارائه میکند.
#Kubernetes #Go #GOMAXPROCS #cgroups #CPUThrottling #ContainerPerformance #DevOps #SRE
🟣لینک مقاله:
https://golangweekly.com/link/174644/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
pkg.go.dev
automaxprocs package - go.uber.org/automaxprocs - Go Packages
Package automaxprocs automatically sets GOMAXPROCS to match the Linux container CPU quota, if any.
❤1
🔵 عنوان مقاله
Terminating Elegantly: A Guide to Graceful Shutdowns
🟢 خلاصه مقاله:
ترک شایسته در سرویسها یعنی برنامه بتواند با دریافت SIGTERM، بدون از دست دادن داده یا خراب کردن وضعیت، درخواستهای جاری را تمام کند و منابع را درست آزاد کند. در این ارائه، Alex Pliutau با تمرکز بر Go در Kubernetes، چرخه کامل خاتمه را توضیح میدهد: از دریافت سیگنال و قطعکردن ترافیک تا ضربالاجل SIGKILL.
نکتههای کلیدی شامل اینهاست: استفاده از signal.NotifyContext و context برای لغو هماهنگ، مدیریت goroutineها با sync.WaitGroup، فراخوانی http.Server.Shutdown یا معادل gRPC برای تخلیه امن اتصالها، و توقف گرفتن کار جدید در Workerها درحالیکه کارهای درحال اجرا بهصورت زماندار تمام میشوند. در Kubernetes باید readiness زودتر غیرفعال شود تا Pod از مسیر ترافیک خارج شود، از preStop برای تأخیر یا Drain سفارشی کمک بگیرید، و terminationGracePeriodSeconds را درست تنظیم کنید. پایش و آزمون نیز ضروری است: لاگ شروع/پایان Shutdown، سنجههایی مثل تعداد درخواستهای درحال پردازش و زمان خاتمه، و تست SIGTERM تحت بار. رعایت این الگوهای ساده، خاتمهای قابل اعتماد و بدون اختلال در Go روی Kubernetes فراهم میکند.
#Go #Kubernetes #GracefulShutdown #CloudNative #Microservices #DevOps #Reliability #ProductionOps
🟣لینک مقاله:
https://golangweekly.com/link/175363/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Terminating Elegantly: A Guide to Graceful Shutdowns
🟢 خلاصه مقاله:
ترک شایسته در سرویسها یعنی برنامه بتواند با دریافت SIGTERM، بدون از دست دادن داده یا خراب کردن وضعیت، درخواستهای جاری را تمام کند و منابع را درست آزاد کند. در این ارائه، Alex Pliutau با تمرکز بر Go در Kubernetes، چرخه کامل خاتمه را توضیح میدهد: از دریافت سیگنال و قطعکردن ترافیک تا ضربالاجل SIGKILL.
نکتههای کلیدی شامل اینهاست: استفاده از signal.NotifyContext و context برای لغو هماهنگ، مدیریت goroutineها با sync.WaitGroup، فراخوانی http.Server.Shutdown یا معادل gRPC برای تخلیه امن اتصالها، و توقف گرفتن کار جدید در Workerها درحالیکه کارهای درحال اجرا بهصورت زماندار تمام میشوند. در Kubernetes باید readiness زودتر غیرفعال شود تا Pod از مسیر ترافیک خارج شود، از preStop برای تأخیر یا Drain سفارشی کمک بگیرید، و terminationGracePeriodSeconds را درست تنظیم کنید. پایش و آزمون نیز ضروری است: لاگ شروع/پایان Shutdown، سنجههایی مثل تعداد درخواستهای درحال پردازش و زمان خاتمه، و تست SIGTERM تحت بار. رعایت این الگوهای ساده، خاتمهای قابل اعتماد و بدون اختلال در Go روی Kubernetes فراهم میکند.
#Go #Kubernetes #GracefulShutdown #CloudNative #Microservices #DevOps #Reliability #ProductionOps
🟣لینک مقاله:
https://golangweekly.com/link/175363/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
YouTube
Terminating elegantly: a guide to graceful shutdowns - Alex Pliutau
Did you ever unplug your computer because you were frustrated? In the world of software, a similar concept exists: the hard shutdown.
This abrupt termination can cause problems like data loss or system instability.
Thankfully, there's a better way: the…
This abrupt termination can cause problems like data loss or system instability.
Thankfully, there's a better way: the…
Forwarded from DevOps Labdon
One of the best practical YouTube Channels to learn DevOps Tools and Skills.
یکی از بهترین کانالهایی که بصورت عملی ابزارهای DevOps رو بصورت ملموس و خیلی کوتاه و مختصر و مفید توضیح و آموزش میده
#DevOps #Terraform #Helm #Kubernetes #AWS #GCP #Azure
https://www.youtube.com/@AntonPutra
یکی از بهترین کانالهایی که بصورت عملی ابزارهای DevOps رو بصورت ملموس و خیلی کوتاه و مختصر و مفید توضیح و آموزش میده
#DevOps #Terraform #Helm #Kubernetes #AWS #GCP #Azure
https://www.youtube.com/@AntonPutra
Forwarded from DevOps Labdon
🔵 عنوان مقاله
Exposing Kubernetes Services Without Cloud LoadBalancers: A Practical Guide
🟢 خلاصه مقاله:
این راهنما برای محیطهای bare‑metal و air‑gapped که به LoadBalancerهای ابری دسترسی ندارند، روشی عملی برای اکسپوز کردن سرویسهای Kubernetes ارائه میدهد. با ترکیب MetalLB و NGINX Ingress، ابتدا MetalLB یک IP پایدار به Serviceهای نوع LoadBalancer اختصاص میدهد، سپس NGINX Ingress ترافیک را بر اساس host و path به سرویسهای داخلی مسیردهی میکند. نتیجه، یک نقطه ورودی واحد با IP ثابت، مدیریت سادهتر DNS و عدم نیاز به باز کردن پورتهای متعدد است. آموزش شامل نصب و پیکربندی MetalLB (L2 یا BGP)، استقرار NGINX Ingress، تعریف Ingressها، و نکاتی درباره TLS، پایداری، و عیبیابی است؛ و نشان میدهد چرا این الگو نسبت به NodePort یا hostNetwork تمیزتر و مقیاسپذیرتر بوده و تجربهای مشابه فضای ابری را بدون وابستگی به آن فراهم میکند.
#Kubernetes #MetalLB #NGINXIngress #BareMetal #AirGapped #DevOps #Ingress #LoadBalancer
🟣لینک مقاله:
https://ku.bz/CDWB9HJg7
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Exposing Kubernetes Services Without Cloud LoadBalancers: A Practical Guide
🟢 خلاصه مقاله:
این راهنما برای محیطهای bare‑metal و air‑gapped که به LoadBalancerهای ابری دسترسی ندارند، روشی عملی برای اکسپوز کردن سرویسهای Kubernetes ارائه میدهد. با ترکیب MetalLB و NGINX Ingress، ابتدا MetalLB یک IP پایدار به Serviceهای نوع LoadBalancer اختصاص میدهد، سپس NGINX Ingress ترافیک را بر اساس host و path به سرویسهای داخلی مسیردهی میکند. نتیجه، یک نقطه ورودی واحد با IP ثابت، مدیریت سادهتر DNS و عدم نیاز به باز کردن پورتهای متعدد است. آموزش شامل نصب و پیکربندی MetalLB (L2 یا BGP)، استقرار NGINX Ingress، تعریف Ingressها، و نکاتی درباره TLS، پایداری، و عیبیابی است؛ و نشان میدهد چرا این الگو نسبت به NodePort یا hostNetwork تمیزتر و مقیاسپذیرتر بوده و تجربهای مشابه فضای ابری را بدون وابستگی به آن فراهم میکند.
#Kubernetes #MetalLB #NGINXIngress #BareMetal #AirGapped #DevOps #Ingress #LoadBalancer
🟣لینک مقاله:
https://ku.bz/CDWB9HJg7
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
Exposing Kubernetes Services Without Cloud LoadBalancers: A Practical Guide
“How do I expose my apps in an air‑gapped Kubernetes cluster without any cloud load balancer?”
Forwarded from 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
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
❤2