🔵 عنوان مقاله
Introducing Gateway API Inference Extension
🟢 خلاصه مقاله:
این مقاله یک افزونه برای Kubernetes Gateway API معرفی میکند که مخصوص بارهای کاری LLM و inference طراحی شده است. هدف آن «مدلآگاه» کردن لایه شبکه است تا مسیریابی و سیاستهای ترافیکی بر اساس مدل، نسخه، ارائهدهنده و فراداده درخواست انجام شود. این کار امکانهایی مانند A/B تست، shadowing، و fallback بین مدلها و ارائهدهندگان مختلف را بدون تغییر کد برنامه فراهم میکند.
همچنین قابلیت تعیین criticality برای هر درخواست را فراهم میکند تا مسیرهای حساس به تأخیر نسبت به کارهای پسزمینه در صفها، بودجه زمانی و ظرفیت، اولویت بگیرند و SLOها بهتر رعایت شوند. از طرفی، load balancing بهینهشده برای inference با درنظرگرفتن عمق صف، وضعیت GPU، اندازه batch، گذردهی توکن و زمان تکمیل تخمینی، به کاهش tail latency و افزایش بهرهوری کمک میکند.
این طراحی بر پایه الگوی آشنای Gateway API بنا شده و با گسترش منابع موجود (Gateway و Route) بهصورت ارائهدهنده-محور خنثی عمل میکند و هم backendهای درون کلاستر و هم خارجی را پوشش میدهد. نتیجه، لایه شبکهای است که محدودیتهای inference را میشناسد و استقرارهای امنتر، سیاستهای هزینهمحور و رصدپذیری دقیقتر در سطح مدل را برای تیمهای پلتفرمی در Kubernetes ممکن میسازد.
#Kubernetes #GatewayAPI #LLM #Inference #MLOps #AIInfrastructure #LoadBalancing #ModelRouting
🟣لینک مقاله:
https://ku.bz/QhNP_lkb3
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Introducing Gateway API Inference Extension
🟢 خلاصه مقاله:
این مقاله یک افزونه برای Kubernetes Gateway API معرفی میکند که مخصوص بارهای کاری LLM و inference طراحی شده است. هدف آن «مدلآگاه» کردن لایه شبکه است تا مسیریابی و سیاستهای ترافیکی بر اساس مدل، نسخه، ارائهدهنده و فراداده درخواست انجام شود. این کار امکانهایی مانند A/B تست، shadowing، و fallback بین مدلها و ارائهدهندگان مختلف را بدون تغییر کد برنامه فراهم میکند.
همچنین قابلیت تعیین criticality برای هر درخواست را فراهم میکند تا مسیرهای حساس به تأخیر نسبت به کارهای پسزمینه در صفها، بودجه زمانی و ظرفیت، اولویت بگیرند و SLOها بهتر رعایت شوند. از طرفی، load balancing بهینهشده برای inference با درنظرگرفتن عمق صف، وضعیت GPU، اندازه batch، گذردهی توکن و زمان تکمیل تخمینی، به کاهش tail latency و افزایش بهرهوری کمک میکند.
این طراحی بر پایه الگوی آشنای Gateway API بنا شده و با گسترش منابع موجود (Gateway و Route) بهصورت ارائهدهنده-محور خنثی عمل میکند و هم backendهای درون کلاستر و هم خارجی را پوشش میدهد. نتیجه، لایه شبکهای است که محدودیتهای inference را میشناسد و استقرارهای امنتر، سیاستهای هزینهمحور و رصدپذیری دقیقتر در سطح مدل را برای تیمهای پلتفرمی در Kubernetes ممکن میسازد.
#Kubernetes #GatewayAPI #LLM #Inference #MLOps #AIInfrastructure #LoadBalancing #ModelRouting
🟣لینک مقاله:
https://ku.bz/QhNP_lkb3
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Kubernetes
Introducing Gateway API Inference Extension
Modern generative AI and large language model (LLM) services create unique traffic-routing challenges on Kubernetes. Unlike typical short-lived, stateless web requests, LLM inference sessions are often long-running, resource-intensive, and partially stateful.…
🔵 عنوان مقاله
Is It Time to Migrate? A Practical Look at Kubernetes Ingress vs. Gateway API
🟢 خلاصه مقاله:
** این مقاله توضیح میدهد چرا Ingress سنتی در Kubernetes با اتکا به annotations اختصاصی و رفتار وابسته به فروشنده شکننده میشود و چگونه Gateway API با مدل استاندارد و نقشمحور (مانند Gateway، GatewayClass و HTTPRoute) این مشکلات را حل میکند. Calico Ingress Gateway (v3.30) مبتنی بر Envoy پیادهسازیای ارائه میدهد که ورود ترافیک را استاندارد و امن میکند، مدیریت TLS را خودکار میسازد و نیاز به annotations ویژه را حذف میکند. اگر با قوانین مسیریابی پیچیده، چرخش گواهیهای TLS، چند محیط ناهمگون یا تکیه به تنظیمات شکننده دستوپنجه نرم میکنید، زمان مهاجرت است: Ingressهای موجود را به HTTPRoute نگاشت کنید، GatewayClass و Gateway بسازید، TLS را خودکار کنید و بهصورت تدریجی و موازی مهاجرت را انجام دهید تا در نهایت به پیکربندی پایدارتر و قابلحمل برسید.
#Kubernetes #GatewayAPI #Ingress #Calico #Envoy #TLS #CloudNative
🟣لینک مقاله:
https://ku.bz/kVLk03Ykw
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Is It Time to Migrate? A Practical Look at Kubernetes Ingress vs. Gateway API
🟢 خلاصه مقاله:
** این مقاله توضیح میدهد چرا Ingress سنتی در Kubernetes با اتکا به annotations اختصاصی و رفتار وابسته به فروشنده شکننده میشود و چگونه Gateway API با مدل استاندارد و نقشمحور (مانند Gateway، GatewayClass و HTTPRoute) این مشکلات را حل میکند. Calico Ingress Gateway (v3.30) مبتنی بر Envoy پیادهسازیای ارائه میدهد که ورود ترافیک را استاندارد و امن میکند، مدیریت TLS را خودکار میسازد و نیاز به annotations ویژه را حذف میکند. اگر با قوانین مسیریابی پیچیده، چرخش گواهیهای TLS، چند محیط ناهمگون یا تکیه به تنظیمات شکننده دستوپنجه نرم میکنید، زمان مهاجرت است: Ingressهای موجود را به HTTPRoute نگاشت کنید، GatewayClass و Gateway بسازید، TLS را خودکار کنید و بهصورت تدریجی و موازی مهاجرت را انجام دهید تا در نهایت به پیکربندی پایدارتر و قابلحمل برسید.
#Kubernetes #GatewayAPI #Ingress #Calico #Envoy #TLS #CloudNative
🟣لینک مقاله:
https://ku.bz/kVLk03Ykw
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Tigera - Creator of Calico
Is It Time to Migrate? A Practical Look at Kubernetes Ingress vs. Gateway API | Tigera - Creator of Calico
If you’ve managed traffic in Kubernetes, you’ve likely navigated the world of Ingress controllers. For years, Ingress has been the standard way of getting HTTP/S services exposed. But let’s be honest, it often felt like...
🔵 عنوان مقاله
Kubernetes Copilot
🟢 خلاصه مقاله:
** Kubernetes Copilot یا همان kube-copilot یک دستیار هوشمند برای سادهسازی کارهای روزمره روی Kubernetes است. این ابزار با تمرکز بر عیبیابی سریع مشکلات pod و ممیزی امنیتی با Trivy، هم سلامت منابع را تحلیل میکند و هم آسیبپذیریها و پیکربندیهای پرریسک را آشکار میسازد. از سوی دیگر، با دریافت درخواستهای طبیعی، مانيفستهای Kubernetes تولید میکند و امکان اصلاح مرحلهبهمرحله جزئیات مانند محدودیت منابع و probeها را میدهد. همچنین با تکیه بر LLMs، دستورات kubectl را از زبان طبیعی ساخته و با سازوکارهای تأیید، ایمن اجرا میکند. حاصل کار، چرخهی کوتاهتر عیبیابی و امنسازی برای تیمهای پلتفرم و SRE است.
#Kubernetes #DevOps #CloudNative #AI #LLM #Security #Trivy #kubectl
🟣لینک مقاله:
https://ku.bz/YXW9h0WXT
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Kubernetes Copilot
🟢 خلاصه مقاله:
** Kubernetes Copilot یا همان kube-copilot یک دستیار هوشمند برای سادهسازی کارهای روزمره روی Kubernetes است. این ابزار با تمرکز بر عیبیابی سریع مشکلات pod و ممیزی امنیتی با Trivy، هم سلامت منابع را تحلیل میکند و هم آسیبپذیریها و پیکربندیهای پرریسک را آشکار میسازد. از سوی دیگر، با دریافت درخواستهای طبیعی، مانيفستهای Kubernetes تولید میکند و امکان اصلاح مرحلهبهمرحله جزئیات مانند محدودیت منابع و probeها را میدهد. همچنین با تکیه بر LLMs، دستورات kubectl را از زبان طبیعی ساخته و با سازوکارهای تأیید، ایمن اجرا میکند. حاصل کار، چرخهی کوتاهتر عیبیابی و امنسازی برای تیمهای پلتفرم و SRE است.
#Kubernetes #DevOps #CloudNative #AI #LLM #Security #Trivy #kubectl
🟣لینک مقاله:
https://ku.bz/YXW9h0WXT
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - feiskyer/kube-copilot: Kubernetes Copilot powered by AI (OpenAI/Claude/Gemini/etc)
Kubernetes Copilot powered by AI (OpenAI/Claude/Gemini/etc) - feiskyer/kube-copilot
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
YouTube
Anton Putra
AWS - GCP - Azure - Kubernetes - Terraform
🔵 عنوان مقاله
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
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
Amazon
How to run AI model inference with GPUs on Amazon EKS Auto Mode | Amazon Web Services
In this post, we show you how to swiftly deploy inference workloads on EKS Auto Mode and demonstrate key features that streamline GPU management. We walk through a practical example by deploying open weight models from OpenAI using vLLM, while showing best…
🔵 عنوان مقاله
The story behind the great sidecar debate
🟢 خلاصه مقاله:
این مقاله با محور «جدال بزرگ sidecar» نشان میدهد چگونه میتوان مصرف منابع data plane را میان Linkerd، Istio Legacy و Istio Ambient روی GKE به شکلی عادلانه و قابلتکرار مقایسه کرد. روش کار با ساخت یک تستبد استاندارد روی GKE آغاز میشود: خوشهای با اندازه و نوع نود یکسان، غیرفعالکردن autoscaling، یک بارکاری پایه برای سنجش، و اندازهگیری CPU، حافظه و تاخیرهای p95/p99 بدون mesh بهعنوان خط مبنا.
سپس هر mesh با سطح امکانات برابر تنظیم میشود: فعالسازی mTLS، حداقل telemetry یکسان، و کنترل دقیق منابع. در Linkerd و Istio Legacy از sidecar برای هر پاد استفاده میشود و در Istio Ambient اجزای مشترک مانند ztunnel/waypoint پیکربندی میگردد. آزمایش در فازهای افزایشی انجام میشود: ابتدا فقط mTLS، سپس سیاستهای L7 و مسیریابی، و در نهایت telemetry؛ در هر فاز، بار گرمکردن، افزایش و پایداری اعمال و دادهها با Prometheus و ابزارهای observability جمعآوری میشود. برای اطمینان از بیطرفی، اجراها تکرار و ترتیب آزمونها تصادفی میشود.
تحلیل نتایج دو سطح را پوشش میدهد: سربار هر پاد و اثر کلان در مقیاس خوشه. طراحیهای مبتنی بر sidecar با افزایش تعداد پادها سربار را خطی بالا میبرند، درحالیکه Ambient هزینهها را به اجزای مشترک منتقل میکند و منحنی هزینه را در مقیاس تغییر میدهد. مقاله همچنین ملاحظات عملی مانند جداسازی خرابی، امنیت، سادگی عملیات، و نیازهای واقعی قابلیتها را مطرح میکند و یک الگوی مرجع برای تکرار آزمایش با Terraform/Helm و داشبوردهای استاندارد ارائه میدهد تا تیمها بتوانند بر اساس دادههای واقعی تصمیم بگیرند.
#ServiceMesh #Istio #Linkerd #Kubernetes #GKE #Sidecar #AmbientMesh #Benchmark
🟣لینک مقاله:
https://ku.bz/vJWcQchQn
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
The story behind the great sidecar debate
🟢 خلاصه مقاله:
این مقاله با محور «جدال بزرگ sidecar» نشان میدهد چگونه میتوان مصرف منابع data plane را میان Linkerd، Istio Legacy و Istio Ambient روی GKE به شکلی عادلانه و قابلتکرار مقایسه کرد. روش کار با ساخت یک تستبد استاندارد روی GKE آغاز میشود: خوشهای با اندازه و نوع نود یکسان، غیرفعالکردن autoscaling، یک بارکاری پایه برای سنجش، و اندازهگیری CPU، حافظه و تاخیرهای p95/p99 بدون mesh بهعنوان خط مبنا.
سپس هر mesh با سطح امکانات برابر تنظیم میشود: فعالسازی mTLS، حداقل telemetry یکسان، و کنترل دقیق منابع. در Linkerd و Istio Legacy از sidecar برای هر پاد استفاده میشود و در Istio Ambient اجزای مشترک مانند ztunnel/waypoint پیکربندی میگردد. آزمایش در فازهای افزایشی انجام میشود: ابتدا فقط mTLS، سپس سیاستهای L7 و مسیریابی، و در نهایت telemetry؛ در هر فاز، بار گرمکردن، افزایش و پایداری اعمال و دادهها با Prometheus و ابزارهای observability جمعآوری میشود. برای اطمینان از بیطرفی، اجراها تکرار و ترتیب آزمونها تصادفی میشود.
تحلیل نتایج دو سطح را پوشش میدهد: سربار هر پاد و اثر کلان در مقیاس خوشه. طراحیهای مبتنی بر sidecar با افزایش تعداد پادها سربار را خطی بالا میبرند، درحالیکه Ambient هزینهها را به اجزای مشترک منتقل میکند و منحنی هزینه را در مقیاس تغییر میدهد. مقاله همچنین ملاحظات عملی مانند جداسازی خرابی، امنیت، سادگی عملیات، و نیازهای واقعی قابلیتها را مطرح میکند و یک الگوی مرجع برای تکرار آزمایش با Terraform/Helm و داشبوردهای استاندارد ارائه میدهد تا تیمها بتوانند بر اساس دادههای واقعی تصمیم بگیرند.
#ServiceMesh #Istio #Linkerd #Kubernetes #GKE #Sidecar #AmbientMesh #Benchmark
🟣لینک مقاله:
https://ku.bz/vJWcQchQn
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Linkerd
The Story Behind the Great Sidecar Debate
Pulling back the curtain on architectural choices in Linkerd, Istio Legacy, and Istio Ambient.
🔵 عنوان مقاله
YamlQL – Query YAML Files with SQL & Natural Language
🟢 خلاصه مقاله:
YamlQL ابزاری است برای جستوجو و تحلیل فایلهای YAML با دو شیوه: SQL و زبان طبیعی. این ابزار اجازه میدهد بدون نوشتن اسکریپتهای یکبارمصرف، روی چندین فایل همزمان فیلتر بزنید، فیلدها را استخراج کنید و خلاصهها یا آمارهای لازم را بسازید. برای کسانی که SQL نمیدانند، میتوان پرسشها را به زبان طبیعی مطرح کرد تا به پرسوجوهای مناسب روی ساختار YAML تبدیل شوند. YamlQL بهویژه برای توسعهدهندگان و تیمهای DevOps در سناریوهایی مثل تنظیمات برنامه، خطوط CI/CD و مانیفستهای Kubernetes مفید است؛ از بررسی انطباق و یافتن فیلدهای ناقص تا تهیه موجودی و گزارشگیری سریع.
#YamlQL #YAML #SQL #NaturalLanguage #DevOps #ConfigManagement #DataQuery #Kubernetes
🟣لینک مقاله:
https://ku.bz/dGSTnVnN4
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
YamlQL – Query YAML Files with SQL & Natural Language
🟢 خلاصه مقاله:
YamlQL ابزاری است برای جستوجو و تحلیل فایلهای YAML با دو شیوه: SQL و زبان طبیعی. این ابزار اجازه میدهد بدون نوشتن اسکریپتهای یکبارمصرف، روی چندین فایل همزمان فیلتر بزنید، فیلدها را استخراج کنید و خلاصهها یا آمارهای لازم را بسازید. برای کسانی که SQL نمیدانند، میتوان پرسشها را به زبان طبیعی مطرح کرد تا به پرسوجوهای مناسب روی ساختار YAML تبدیل شوند. YamlQL بهویژه برای توسعهدهندگان و تیمهای DevOps در سناریوهایی مثل تنظیمات برنامه، خطوط CI/CD و مانیفستهای Kubernetes مفید است؛ از بررسی انطباق و یافتن فیلدهای ناقص تا تهیه موجودی و گزارشگیری سریع.
#YamlQL #YAML #SQL #NaturalLanguage #DevOps #ConfigManagement #DataQuery #Kubernetes
🟣لینک مقاله:
https://ku.bz/dGSTnVnN4
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - AKSarav/YamlQL: YamlQL - Query your YAML files with SQL and Natural Language
YamlQL - Query your YAML files with SQL and Natural Language - AKSarav/YamlQL
Forwarded from Bardia & Erfan
♨️ پیام جنجالی پاول دروف به کاربران فرانسوی ؛ هشدار درباره قانون «کنترل چت» اتحادیه اروپا
▪️طبق پیغام جدید پاول دروف ، ظاهراً اتحادیه اروپا قرار بوده قانونی تصویب کنه که تمام اپلیکیشنها رو مجبور به اسکن همه پیامهای خصوصی کاربران میکرد! چیزی شبیه یک سیستم جاسوسی سراسری روی گوشی همه مردم.
▪️فرانسه، با حمایت وزیران کشور سابق و فعلی در رأس این طرح قرار داشت. به عقدیده دروف چنین طرحی به بهانه «مبارزه با جرم» معرفی شده، اما در واقع هدفش مردم عادی و جاسوسی از مردمه.
+ چرا که مجرمان واقعی بهراحتی از VPN یا ابزارهای مخفی استفاده میکنن، در حالیکه پیامهای مقامات و پلیس از این نظارت معاف هستند!
♨️ پیام جنجالی پاول دروف به کاربران فرانسوی ؛ هشدار درباره قانون «کنترل چت» اتحادیه اروپا
▪️طبق پیغام جدید پاول دروف ، ظاهراً اتحادیه اروپا قرار بوده قانونی تصویب کنه که تمام اپلیکیشنها رو مجبور به اسکن همه پیامهای خصوصی کاربران میکرد! چیزی شبیه یک سیستم جاسوسی سراسری روی گوشی همه مردم.
▪️فرانسه، با حمایت وزیران کشور سابق و فعلی در رأس این طرح قرار داشت. به عقدیده دروف چنین طرحی به بهانه «مبارزه با جرم» معرفی شده، اما در واقع هدفش مردم عادی و جاسوسی از مردمه.
+ چرا که مجرمان واقعی بهراحتی از VPN یا ابزارهای مخفی استفاده میکنن، در حالیکه پیامهای مقامات و پلیس از این نظارت معاف هستند!
🔵 عنوان مقاله
A Journey Through Kafkian SplitDNS in a Multitenant Kubernetes Offering
🟢 خلاصه مقاله:
** در یک محیط چندمستاجری Kubernetes، اتصال به Kafka میتواند پیچیده شود؛ هر مستاجر نیازها و مقصدهای متفاوتی دارد و تیم PaaS باید مدیریت ساده و پایدار باقی بماند. این مقاله توضیح میدهد چگونه تیم پلتفرم با تکیه بر DNS بهجای کد سفارشی، الگوی split-DNS را برای Kafka پیادهسازی کرده است.
ایده اصلی این است: با استفاده از قالبهای CoreDNS، نامهای میزبان خاصِ broker درون کلاستر بازنویسی میشوند تا کلاینتها همانجا به سرویسهای درست برسند، بدون وابستگی به resolve شدن این نامها در خارج از کلاستر. بدینترتیب کنترل نامهای قابلOverride دست پلتفرم میماند و تنظیمات کلاینتها شکننده نمیشود.
برای واگذاری کنترل مقصد نهایی به مستاجران، از ExternalName استفاده شده است؛ هر مستاجر میتواند با تغییر مقدار ExternalName، نامهای ثابت و درونکلاستری Kafka را به broker دلخواه—چه داخلی و چه بیرونی—اشاره دهد، بدون نیاز به بازسازی تصویر یا راهاندازی مجدد.
جمعبندی: این الگو با تکیه بر قابلیتهای بومی Kubernetes، جداسازی مسئولیتها، سادگی عملیاتی و مقیاسپذیری را فراهم میکند؛ البته با توجه به نکاتی مانند TTL و کش DNS، محدودسازی دامنه Override، مانیتورینگ خطاهای resolve و مستندسازی مسیر مهاجرت.
#Kubernetes #Kafka #DNS #CoreDNS #Multitenancy #ExternalName #PaaS #PlatformEngineering
🟣لینک مقاله:
https://ku.bz/2lTrzwpkM
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
A Journey Through Kafkian SplitDNS in a Multitenant Kubernetes Offering
🟢 خلاصه مقاله:
** در یک محیط چندمستاجری Kubernetes، اتصال به Kafka میتواند پیچیده شود؛ هر مستاجر نیازها و مقصدهای متفاوتی دارد و تیم PaaS باید مدیریت ساده و پایدار باقی بماند. این مقاله توضیح میدهد چگونه تیم پلتفرم با تکیه بر DNS بهجای کد سفارشی، الگوی split-DNS را برای Kafka پیادهسازی کرده است.
ایده اصلی این است: با استفاده از قالبهای CoreDNS، نامهای میزبان خاصِ broker درون کلاستر بازنویسی میشوند تا کلاینتها همانجا به سرویسهای درست برسند، بدون وابستگی به resolve شدن این نامها در خارج از کلاستر. بدینترتیب کنترل نامهای قابلOverride دست پلتفرم میماند و تنظیمات کلاینتها شکننده نمیشود.
برای واگذاری کنترل مقصد نهایی به مستاجران، از ExternalName استفاده شده است؛ هر مستاجر میتواند با تغییر مقدار ExternalName، نامهای ثابت و درونکلاستری Kafka را به broker دلخواه—چه داخلی و چه بیرونی—اشاره دهد، بدون نیاز به بازسازی تصویر یا راهاندازی مجدد.
جمعبندی: این الگو با تکیه بر قابلیتهای بومی Kubernetes، جداسازی مسئولیتها، سادگی عملیاتی و مقیاسپذیری را فراهم میکند؛ البته با توجه به نکاتی مانند TTL و کش DNS، محدودسازی دامنه Override، مانیتورینگ خطاهای resolve و مستندسازی مسیر مهاجرت.
#Kubernetes #Kafka #DNS #CoreDNS #Multitenancy #ExternalName #PaaS #PlatformEngineering
🟣لینک مقاله:
https://ku.bz/2lTrzwpkM
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
A Journey Through Kafkian SplitDNS in a Multitenant Kubernetes Offering
In previous posts, we’ve explored various aspects of SCHIP, our Kubernetes-based PaaS at Adevinta, like How we avoided an outage caused by…
🔵 عنوان مقاله
Load Testing with Impulse at Airbnb (8 minute read)
🟢 خلاصه مقاله:
**Impulse یک چارچوب غیرمتمرکز load-testing-as-a-service در Airbnb است که تیمها را قادر میسازد بهصورت سلفسرویس بار مصنوعی بسازند، وابستگیها را mock کنند، الگوهای ترافیک تولید را برای آزمونهای واقعگرایانه به کار بگیرند و برای گردشکارهای غیرهمزمان APIهای تست ایجاد کنند. این رویکرد کمک میکند عملکرد و پایداری سرویسهای توزیعشده در مقیاس سنجیده شود، ریسک انتشار کاهش یابد و تصمیمهای بهینهتری درباره ظرفیت و انعطافپذیری در برابر خطا گرفته شود.
#LoadTesting #Airbnb #Impulse #PerformanceTesting #Scalability #DevOps #SRE #AsynchronousWorkflows
🟣لینک مقاله:
https://medium.com/airbnb-engineering/load-testing-with-impulse-at-airbnb-f466874d03d2?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Load Testing with Impulse at Airbnb (8 minute read)
🟢 خلاصه مقاله:
**Impulse یک چارچوب غیرمتمرکز load-testing-as-a-service در Airbnb است که تیمها را قادر میسازد بهصورت سلفسرویس بار مصنوعی بسازند، وابستگیها را mock کنند، الگوهای ترافیک تولید را برای آزمونهای واقعگرایانه به کار بگیرند و برای گردشکارهای غیرهمزمان APIهای تست ایجاد کنند. این رویکرد کمک میکند عملکرد و پایداری سرویسهای توزیعشده در مقیاس سنجیده شود، ریسک انتشار کاهش یابد و تصمیمهای بهینهتری درباره ظرفیت و انعطافپذیری در برابر خطا گرفته شود.
#LoadTesting #Airbnb #Impulse #PerformanceTesting #Scalability #DevOps #SRE #AsynchronousWorkflows
🟣لینک مقاله:
https://medium.com/airbnb-engineering/load-testing-with-impulse-at-airbnb-f466874d03d2?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
Load Testing with Impulse at Airbnb
Comprehensive Load Testing with Load Generator, Dependency Mocker, Traffic Collector, and More
🔵 عنوان مقاله
Advanced analytics using Amazon CloudWatch Logs Insights (9 minute read)
🟢 خلاصه مقاله:
** خلاصه فارسی: Amazon CloudWatch Logs Insights با پشتیبانی از OpenSearch Piped Processing Language و SQL، تحلیل لاگها را منعطفتر و قدرتمندتر کرده است. این قابلیتها امکان همبستگی سریعتر رویدادها، دستکاری غنیتر دادهها (فیلتر، تجمع و تبدیل)، و پیادهسازی سناریوهای پیشرفته تشخیص ناهنجاری را فراهم میکنند. علاوه بر این، Generative AI با تبدیل درخواستهای زبان طبیعی به کوئریهای قابل اجرا، خلاصهسازی نتایج و اتصال بین چند منبع لاگ، زمان دستیابی به بینش را بهطور چشمگیری کاهش میدهد.
#AmazonCloudWatch #LogsInsights #OpenSearch #PPL #SQL #GenerativeAI #Observability #AnomalyDetection
🟣لینک مقاله:
https://aws.amazon.com/blogs/mt/advanced-analytics-using-amazon-cloudwatch-logs-insights/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Advanced analytics using Amazon CloudWatch Logs Insights (9 minute read)
🟢 خلاصه مقاله:
** خلاصه فارسی: Amazon CloudWatch Logs Insights با پشتیبانی از OpenSearch Piped Processing Language و SQL، تحلیل لاگها را منعطفتر و قدرتمندتر کرده است. این قابلیتها امکان همبستگی سریعتر رویدادها، دستکاری غنیتر دادهها (فیلتر، تجمع و تبدیل)، و پیادهسازی سناریوهای پیشرفته تشخیص ناهنجاری را فراهم میکنند. علاوه بر این، Generative AI با تبدیل درخواستهای زبان طبیعی به کوئریهای قابل اجرا، خلاصهسازی نتایج و اتصال بین چند منبع لاگ، زمان دستیابی به بینش را بهطور چشمگیری کاهش میدهد.
#AmazonCloudWatch #LogsInsights #OpenSearch #PPL #SQL #GenerativeAI #Observability #AnomalyDetection
🟣لینک مقاله:
https://aws.amazon.com/blogs/mt/advanced-analytics-using-amazon-cloudwatch-logs-insights/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Amazon
Advanced analytics using Amazon CloudWatch Logs Insights | Amazon Web Services
Effective log management and analysis are critical for maintaining robust, secure, and high-performing systems. Amazon CloudWatch Logs Insights has long been a powerful tool for searching, filtering, and analyzing log data across multiple log groups. The…
🔵 عنوان مقاله
Examples are the best documentation (2 minute read)
🟢 خلاصه مقاله:
**این مقاله میگوید آنچه بیشترِ توسعهدهندگان از مستندات میخواهند، مثالهای روشن و اجراشدنی است، اما منابع رسمی اغلب با فرض آشنایی عمیق نوشته میشوند و مثال کم دارند؛ همین موضوع برای کسانی که بین اکوسیستمها جابهجا میشوند، مانع یادگیری سریع است. نمونههای عینی با نشاندادن ورودی/خروجی، الگوهای رایج و خطاهای محتمل، بار ذهنی را کم میکنند و از متن خشک مؤثرترند. سایتهای جامعهمحور مثل clojuredocs.org ارزش مستندسازی مبتنی بر مثال را نشان میدهند: قطعهکدهای کوتاه، واقعی و همراه با نکتهها یادگیری را سریع و عملی میکنند. توصیه نهایی: مثال را رکن اول مستندات بدانید؛ کنار هر مفهوم و API، مثالهای حداقلی و قابل اجرا بگذارید، مشارکت جامعه را بپذیرید و به محیطهای تعاملی لینک دهید تا ورود سریعتر و خطا کمتر شود.
#Documentation #DeveloperExperience #CodeExamples #TechnicalWriting #OpenSource #ClojureDocs #APIDocs
🟣لینک مقاله:
https://rakhim.exotext.com/examples-are-the-best-documentation?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Examples are the best documentation (2 minute read)
🟢 خلاصه مقاله:
**این مقاله میگوید آنچه بیشترِ توسعهدهندگان از مستندات میخواهند، مثالهای روشن و اجراشدنی است، اما منابع رسمی اغلب با فرض آشنایی عمیق نوشته میشوند و مثال کم دارند؛ همین موضوع برای کسانی که بین اکوسیستمها جابهجا میشوند، مانع یادگیری سریع است. نمونههای عینی با نشاندادن ورودی/خروجی، الگوهای رایج و خطاهای محتمل، بار ذهنی را کم میکنند و از متن خشک مؤثرترند. سایتهای جامعهمحور مثل clojuredocs.org ارزش مستندسازی مبتنی بر مثال را نشان میدهند: قطعهکدهای کوتاه، واقعی و همراه با نکتهها یادگیری را سریع و عملی میکنند. توصیه نهایی: مثال را رکن اول مستندات بدانید؛ کنار هر مفهوم و API، مثالهای حداقلی و قابل اجرا بگذارید، مشارکت جامعه را بپذیرید و به محیطهای تعاملی لینک دهید تا ورود سریعتر و خطا کمتر شود.
#Documentation #DeveloperExperience #CodeExamples #TechnicalWriting #OpenSource #ClojureDocs #APIDocs
🟣لینک مقاله:
https://rakhim.exotext.com/examples-are-the-best-documentation?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
❤1
🔵 عنوان مقاله
Inlets-operator: LoadBalancer tool
🟢 خلاصه مقاله:
** Inlets-operator یک ابزار ایجاد LoadBalancer برای Kubernetes است که به کلاسترهای پشت NAT یا بدون ارائهدهنده ابری، یک نقطه دسترسی عمومی میدهد. با رصد Serviceهای نوع LoadBalancer، یک سرور خروجی در فضای عمومی فراهم میکند و از طریق تونل امن inlets ترافیک را از آن سرور به NodePort یا Podهای داخل کلاستر هدایت میکند. این روش برای محیطهای on‑prem، لبه، k3s/microk8s و سناریوهای توسعه و آزمایشی مقرونبهصرفه است و بدون وابستگی به LoadBalancerهای مدیریتشده ابری، انتشار سرویسها را ساده و قابلحمل میسازد.
#Kubernetes #LoadBalancer #Inlets #DevOps #CloudNative #Networking #EdgeComputing
🟣لینک مقاله:
https://ku.bz/Cn8HJr43C
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Inlets-operator: LoadBalancer tool
🟢 خلاصه مقاله:
** Inlets-operator یک ابزار ایجاد LoadBalancer برای Kubernetes است که به کلاسترهای پشت NAT یا بدون ارائهدهنده ابری، یک نقطه دسترسی عمومی میدهد. با رصد Serviceهای نوع LoadBalancer، یک سرور خروجی در فضای عمومی فراهم میکند و از طریق تونل امن inlets ترافیک را از آن سرور به NodePort یا Podهای داخل کلاستر هدایت میکند. این روش برای محیطهای on‑prem، لبه، k3s/microk8s و سناریوهای توسعه و آزمایشی مقرونبهصرفه است و بدون وابستگی به LoadBalancerهای مدیریتشده ابری، انتشار سرویسها را ساده و قابلحمل میسازد.
#Kubernetes #LoadBalancer #Inlets #DevOps #CloudNative #Networking #EdgeComputing
🟣لینک مقاله:
https://ku.bz/Cn8HJr43C
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - inlets/inlets-operator: Get public TCP LoadBalancers for local Kubernetes clusters
Get public TCP LoadBalancers for local Kubernetes clusters - inlets/inlets-operator
🔵 عنوان مقاله
kubectl-klock – Readable kubectl watch output
🟢 خلاصه مقاله:
ابزار kubectl-klock جریان رویدادهای kubectl get --watch را به یک نمایش زنده، خوانا و کمنویز تبدیل میکند تا بهجای تکیه بر polling، تغییرات منابع Kubernetes را بهصورت پیوسته و قابل دنبالکردن ببینید. این رویکرد در زمان rollout، رفع اشکال و پایش Pod/Deployment/Job باعث میشود گذارها و نتیجهها آشکارتر شوند و واکنش سریعتر باشد. kubectl-klock مانند یک لایه سبک روی kubectl عمل میکند و با همان الگوهای دستور کار میکند؛ بنابراین با کمترین یادگیری، خوانایی و آگاهی لحظهای شما را بهبود میدهد.
#Kubernetes #kubectl #DevOps #SRE #Observability #CLI #Streaming #Productivity
🟣لینک مقاله:
https://ku.bz/FHRmb31F0
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
kubectl-klock – Readable kubectl watch output
🟢 خلاصه مقاله:
ابزار kubectl-klock جریان رویدادهای kubectl get --watch را به یک نمایش زنده، خوانا و کمنویز تبدیل میکند تا بهجای تکیه بر polling، تغییرات منابع Kubernetes را بهصورت پیوسته و قابل دنبالکردن ببینید. این رویکرد در زمان rollout، رفع اشکال و پایش Pod/Deployment/Job باعث میشود گذارها و نتیجهها آشکارتر شوند و واکنش سریعتر باشد. kubectl-klock مانند یک لایه سبک روی kubectl عمل میکند و با همان الگوهای دستور کار میکند؛ بنابراین با کمترین یادگیری، خوانایی و آگاهی لحظهای شما را بهبود میدهد.
#Kubernetes #kubectl #DevOps #SRE #Observability #CLI #Streaming #Productivity
🟣لینک مقاله:
https://ku.bz/FHRmb31F0
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - applejag/kubectl-klock: A kubectl plugin to render watch output in a more readable fashion
A kubectl plugin to render watch output in a more readable fashion - applejag/kubectl-klock
Forwarded from AI Labdon
اگه برنامه نویس هستید و از هوش مصنوعی برای کدنویسی استفاده میکنید، واقعاً به خودتون لطف میکنید که OpenSpec رو چک کنید. این ابزار به شما کمک میکنه کنترل کامل پروژه رو دست بگیرید و از AI به عنوان یک همکار قابل اعتماد استفاده کنید!
تا حالا با دستیارهای کدنویسی هوش مصنوعی (مثل Cursor یا Copilot) کار کردید و به جای چیزی که دقیقاً در ذهن داشتید، یک چیز کاملاً دیگه تحویل گرفتید؟ یا یک بخش رو نوشته و یک بخش دیگه رو براتون خراب کرده
من جدیدا ابزاری رو پیدا کردم به اسم OpenSpec که داره این بازی رو برای همیشه عوض میکنه.
ایدهاش ساده و ناب هست: شما و هوش مصنوعی، قبل از نوشتن حتی یک خط کد، روی «چیزی که باید ساخته بشه» به توافق کامل میرسید.
دیگه خبری از پرامپتهای مبهم در چت و خروجیهای غیرقابل پیشبینی نیست. OpenSpec یک فرآیند کاری سبک و قدرتمند اضافه میکنه که پروژهها رو اینطوری پیش میبره:
۱. پیشنهاد تغییر (Change Proposal): شما به AI میگید چه قابلیتی رو میخواید اضافه کنید. AI یک ساختار کامل از مشخصات، وظایف و پیشنهادها رو براتون میسازه.
۲. بازبینی و هماهنگی: شما و AI با هم مشخصات رو دقیق میکنید تا همه چیز شفاف و بدون ابهام باشه.
۳. پیادهسازی: AI بر اساس مشخصات نهایی و توافق شده، کدنویسی رو انجام میده.
۴. آرشیو: بعد از اتمام کار، تغییرات به آرشیو منتقل میشن و مشخصات اصلی پروژه رو بهروز میکنن.
چرا این ابزار به خوبی جواب میده
- بدون نیاز به کلید API: نصب کن و استفاده کن. ساده و سریع.
- با ابزارهای فعلی شما کار میکنه: با Claude Code, Cursor, GitHub Copilot, Windsurf و دهها ابزار دیگه یکپارچه میشه.
- قابل پیشبینی و شفاف: دیگه نمیخواد حدس بزنید AI چی میسازه. همه چیز از قبل مشخصه.
- عالی برای پروژههای موجود: نه فقط برای پروژههای جدید، بلکه برای تغییر و توسعه کدهای قدیمی هم عالیه.
- مستندسازی خودکار: هر تغییری با مشخصات و وظایفش ثبت میشه و یک سند زنده از پروژه میسازه.
اینم آدرس گیتهابش که همه چیز اماده یک جا هست!
https://github.com/Fission-AI/OpenSpec
اگر نتونستنید دستی نصبش کنید ، میتونید فایل README[.]md رو کپی کنید ، بدید به همون ابزار Ai که براتون کد میزنه مثل Claude Code, Cursor, GitHub Copilot ، بگید نصبش کن!
<POURYA/>
تا حالا با دستیارهای کدنویسی هوش مصنوعی (مثل Cursor یا Copilot) کار کردید و به جای چیزی که دقیقاً در ذهن داشتید، یک چیز کاملاً دیگه تحویل گرفتید؟ یا یک بخش رو نوشته و یک بخش دیگه رو براتون خراب کرده
من جدیدا ابزاری رو پیدا کردم به اسم OpenSpec که داره این بازی رو برای همیشه عوض میکنه.
ایدهاش ساده و ناب هست: شما و هوش مصنوعی، قبل از نوشتن حتی یک خط کد، روی «چیزی که باید ساخته بشه» به توافق کامل میرسید.
دیگه خبری از پرامپتهای مبهم در چت و خروجیهای غیرقابل پیشبینی نیست. OpenSpec یک فرآیند کاری سبک و قدرتمند اضافه میکنه که پروژهها رو اینطوری پیش میبره:
۱. پیشنهاد تغییر (Change Proposal): شما به AI میگید چه قابلیتی رو میخواید اضافه کنید. AI یک ساختار کامل از مشخصات، وظایف و پیشنهادها رو براتون میسازه.
۲. بازبینی و هماهنگی: شما و AI با هم مشخصات رو دقیق میکنید تا همه چیز شفاف و بدون ابهام باشه.
۳. پیادهسازی: AI بر اساس مشخصات نهایی و توافق شده، کدنویسی رو انجام میده.
۴. آرشیو: بعد از اتمام کار، تغییرات به آرشیو منتقل میشن و مشخصات اصلی پروژه رو بهروز میکنن.
چرا این ابزار به خوبی جواب میده
- بدون نیاز به کلید API: نصب کن و استفاده کن. ساده و سریع.
- با ابزارهای فعلی شما کار میکنه: با Claude Code, Cursor, GitHub Copilot, Windsurf و دهها ابزار دیگه یکپارچه میشه.
- قابل پیشبینی و شفاف: دیگه نمیخواد حدس بزنید AI چی میسازه. همه چیز از قبل مشخصه.
- عالی برای پروژههای موجود: نه فقط برای پروژههای جدید، بلکه برای تغییر و توسعه کدهای قدیمی هم عالیه.
- مستندسازی خودکار: هر تغییری با مشخصات و وظایفش ثبت میشه و یک سند زنده از پروژه میسازه.
اینم آدرس گیتهابش که همه چیز اماده یک جا هست!
https://github.com/Fission-AI/OpenSpec
اگر نتونستنید دستی نصبش کنید ، میتونید فایل README[.]md رو کپی کنید ، بدید به همون ابزار Ai که براتون کد میزنه مثل Claude Code, Cursor, GitHub Copilot ، بگید نصبش کن!
<POURYA/>
GitHub
GitHub - Fission-AI/OpenSpec: Spec-driven development for AI coding assistants.
Spec-driven development for AI coding assistants. Contribute to Fission-AI/OpenSpec development by creating an account on GitHub.
🔵 عنوان مقاله
Kagent: Agenetic AI for Kubernetes
🟢 خلاصه مقاله:
Kagent یک چارچوب agentic AI برای Kubernetes است که به تیمهای پلتفرم، DevOps و SRE امکان میدهد agentهای خودگردان را برای خودکارسازی عملیات و تسریع رفع اشکال اجرا کنند. نصب آن از طریق shell یا Helm انجام میشود و از طریق Model Context Protocol (MCP) به LLMs متصل میشود تا دسترسی استاندارد به بافت زنده خوشه و ابزارها فراهم شود. نتیجه، کاهش کار تکراری، تریاژ سریعتر رخدادها و اجرای مطمئنتر عملیات Kubernetes است؛ با اختیار انتخاب بین اجرای خودکار کارهای کمریسک یا تأیید انسانی برای اقدامات حساس.
#Kagent #Kubernetes #AIOps #LLMs #MCP #Helm #DevOps #SRE
🟣لینک مقاله:
https://ku.bz/R52yDGdFL
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Kagent: Agenetic AI for Kubernetes
🟢 خلاصه مقاله:
Kagent یک چارچوب agentic AI برای Kubernetes است که به تیمهای پلتفرم، DevOps و SRE امکان میدهد agentهای خودگردان را برای خودکارسازی عملیات و تسریع رفع اشکال اجرا کنند. نصب آن از طریق shell یا Helm انجام میشود و از طریق Model Context Protocol (MCP) به LLMs متصل میشود تا دسترسی استاندارد به بافت زنده خوشه و ابزارها فراهم شود. نتیجه، کاهش کار تکراری، تریاژ سریعتر رخدادها و اجرای مطمئنتر عملیات Kubernetes است؛ با اختیار انتخاب بین اجرای خودکار کارهای کمریسک یا تأیید انسانی برای اقدامات حساس.
#Kagent #Kubernetes #AIOps #LLMs #MCP #Helm #DevOps #SRE
🟣لینک مقاله:
https://ku.bz/R52yDGdFL
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
Kagent: Agentic AI for Kubernetes (AI meets cloudnative)
In the era of Artificial Intelligence, Generative AI, Large Language models and yes new buzz word Agentic AI and to support it new…
🔵 عنوان مقاله
AI-Assisted GitOps with Flux MCP Server
🟢 خلاصه مقاله:
**
این آموزش نشان میدهد چگونه با استفاده از Flux MCP Server، یک دستیار هوش مصنوعی را به Kubernetes وصل کنید تا مدیریت و عیبیابی جریانهای GitOps با زبان طبیعی انجام شود. با تکیه بر MCP، دستیار میتواند وضعیت Flux را بخواند، Kustomization و HelmReleaseها را فهرست کند، اختلافها را توضیح دهد، لاگ کنترلرها را بررسی کند و در صورت نیاز اقدامات امنی مثل آغاز reconcile یا پیشنهاد تغییر از طریق PR را انجام دهد.
راهنما شامل پیشنیازها (خوشه Kubernetes، نصب Flux و یک مخزن Git پیکربندیشده)، نصب و تنظیم Flux MCP Server و اتصال آن به یک دستیار سازگار با MCP است. مثالهای عملی نشان میدهد چگونه درخواستهای طبیعی به عملیات دقیق تبدیل میشوند: بررسی سلامت، دلیل شکست انتشار، ایجاد PR برای بهروزرسانی، بازگردانی به نسخه قبلی یا توقف/ادامه reconcile.
همچنین نکات امنیتی و رفع اشکال را پوشش میدهد؛ از جمله محدودسازی دسترسی با RBAC و اصل حداقل دسترسی، ثبت و ممیزی اقدامات دستیار، و اعتبارسنجی تغییرات از طریق Git پیش از اعمال در کلاستر. خروجی، چرخه GitOps سریعتر و شفافتری است که در آن توسعهدهندگان و SREها با کمک دستیار هوشمند، کارهای تکراری را خودکار و مسائل را دقیقتر مدیریت میکنند.
#GitOps #Kubernetes #Flux #MCP #AIOps #DevOps #PlatformEngineering
🟣لینک مقاله:
https://ku.bz/Dc6z5yxvs
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
AI-Assisted GitOps with Flux MCP Server
🟢 خلاصه مقاله:
**
این آموزش نشان میدهد چگونه با استفاده از Flux MCP Server، یک دستیار هوش مصنوعی را به Kubernetes وصل کنید تا مدیریت و عیبیابی جریانهای GitOps با زبان طبیعی انجام شود. با تکیه بر MCP، دستیار میتواند وضعیت Flux را بخواند، Kustomization و HelmReleaseها را فهرست کند، اختلافها را توضیح دهد، لاگ کنترلرها را بررسی کند و در صورت نیاز اقدامات امنی مثل آغاز reconcile یا پیشنهاد تغییر از طریق PR را انجام دهد.
راهنما شامل پیشنیازها (خوشه Kubernetes، نصب Flux و یک مخزن Git پیکربندیشده)، نصب و تنظیم Flux MCP Server و اتصال آن به یک دستیار سازگار با MCP است. مثالهای عملی نشان میدهد چگونه درخواستهای طبیعی به عملیات دقیق تبدیل میشوند: بررسی سلامت، دلیل شکست انتشار، ایجاد PR برای بهروزرسانی، بازگردانی به نسخه قبلی یا توقف/ادامه reconcile.
همچنین نکات امنیتی و رفع اشکال را پوشش میدهد؛ از جمله محدودسازی دسترسی با RBAC و اصل حداقل دسترسی، ثبت و ممیزی اقدامات دستیار، و اعتبارسنجی تغییرات از طریق Git پیش از اعمال در کلاستر. خروجی، چرخه GitOps سریعتر و شفافتری است که در آن توسعهدهندگان و SREها با کمک دستیار هوشمند، کارهای تکراری را خودکار و مسائل را دقیقتر مدیریت میکنند.
#GitOps #Kubernetes #Flux #MCP #AIOps #DevOps #PlatformEngineering
🟣لینک مقاله:
https://ku.bz/Dc6z5yxvs
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
AI-Assisted GitOps with Flux MCP Server
Bridging the gap between AI assistants and GitOps pipelines
❤1
🔵 عنوان مقاله
GPU sharing with MPS and OKE
🟢 خلاصه مقاله:
این آموزش نشان میدهد چگونه با استفاده از NVIDIA MPS در Oracle Kubernetes Engine (OKE) اشتراکگذاری GPU را فعال کنیم تا چندین پردازه CUDA بهطور همزمان از یک GPU بهره ببرند. مراحل اصلی شامل ایجاد یک GPU node pool اختصاصی، سفارشیسازی cloud-init برای فعالسازی و پایدارسازی MPS روی نودها، استقرار NVIDIA device-plugin با Helm و سپس آزمایش دسترسی اشتراکی با اجرای یک بارکاری نمونه در قالب ۱۰ replica است. در پایان با ابزارهایی مانند nvidia-smi میزان همزمانی و بهرهوری بررسی میشود. نکات مهم: نیاز به سازگاری نسخههای CUDA و درایور، نبود ایزولیشن سخت حافظه در MPS، و مقایسه با گزینههایی مثل MIG برای سناریوهای نیازمند ایزولیشن قویتر.
#NVIDIA #MPS #GPUSharing #Kubernetes #OKE #OracleCloud #CUDA #Helm
🟣لینک مقاله:
https://ku.bz/Hd9QMtTXf
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GPU sharing with MPS and OKE
🟢 خلاصه مقاله:
این آموزش نشان میدهد چگونه با استفاده از NVIDIA MPS در Oracle Kubernetes Engine (OKE) اشتراکگذاری GPU را فعال کنیم تا چندین پردازه CUDA بهطور همزمان از یک GPU بهره ببرند. مراحل اصلی شامل ایجاد یک GPU node pool اختصاصی، سفارشیسازی cloud-init برای فعالسازی و پایدارسازی MPS روی نودها، استقرار NVIDIA device-plugin با Helm و سپس آزمایش دسترسی اشتراکی با اجرای یک بارکاری نمونه در قالب ۱۰ replica است. در پایان با ابزارهایی مانند nvidia-smi میزان همزمانی و بهرهوری بررسی میشود. نکات مهم: نیاز به سازگاری نسخههای CUDA و درایور، نبود ایزولیشن سخت حافظه در MPS، و مقایسه با گزینههایی مثل MIG برای سناریوهای نیازمند ایزولیشن قویتر.
#NVIDIA #MPS #GPUSharing #Kubernetes #OKE #OracleCloud #CUDA #Helm
🟣لینک مقاله:
https://ku.bz/Hd9QMtTXf
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
GPU sharing with MPS and OKE
Though I’ve been working with Kubernetes since 2018, only very recently I had the opportunity to learn a bit more about GPU-based worker…
❤1
Forwarded from Bardia & Erfan
دارم پادکست پاول دوروف مال تلگرام رو میبینم
نکته جالبش اینجا اگر برادر نابغش نبود هیچ وقت تلگرامی وجود نداشت
نکته دیگه اینه اگر دقت کرده باشید پاول برعکس مارک زاکربرگ ، ایلان ماسک و . . .
زندگی خیلی لاکچری داره ولی ایلان و زاکربرگ همیشه ساده پوشن و خیلی زنی بی آلایشی از خودشون نشون میدن
حتی مارک و ایلان نهایتا ۶ تا ۸ ساعت میخوابن و پاول ۱۲ ساعت
دلیلش از نظر من خیلی جالبه
ایلان و زاکربرگ تمام سهام شرکتشون برای خودشون نیست! سرمایه گذار های بزرگی پشتشونه و هروقت بیان خودشون رو اینطور نشون بدن قطعابا فشار زیادی مواجه میشن
ولی پاول مالک خودش هست و برادرش و کلا ۴۰ برنامه نویس
هیچ وقت هم جواب به کسی نمیده
نکات خیلی زیادی داره این شخص پیشنهاد میکنم حتما درموردش مطالعه کنید
https://www.youtube.com/watch?v=qjPH9njnaVU
نکته جالبش اینجا اگر برادر نابغش نبود هیچ وقت تلگرامی وجود نداشت
نکته دیگه اینه اگر دقت کرده باشید پاول برعکس مارک زاکربرگ ، ایلان ماسک و . . .
زندگی خیلی لاکچری داره ولی ایلان و زاکربرگ همیشه ساده پوشن و خیلی زنی بی آلایشی از خودشون نشون میدن
حتی مارک و ایلان نهایتا ۶ تا ۸ ساعت میخوابن و پاول ۱۲ ساعت
دلیلش از نظر من خیلی جالبه
ایلان و زاکربرگ تمام سهام شرکتشون برای خودشون نیست! سرمایه گذار های بزرگی پشتشونه و هروقت بیان خودشون رو اینطور نشون بدن قطعابا فشار زیادی مواجه میشن
ولی پاول مالک خودش هست و برادرش و کلا ۴۰ برنامه نویس
هیچ وقت هم جواب به کسی نمیده
نکات خیلی زیادی داره این شخص پیشنهاد میکنم حتما درموردش مطالعه کنید
https://www.youtube.com/watch?v=qjPH9njnaVU
❤1
🔵 عنوان مقاله
Enhancing Kubernetes Event Management with Custom Aggregation
🟢 خلاصه مقاله:
این مطلب در kubernetes.io نشان میدهد چگونه میتوان یک سامانهی تجمیع سفارشی برای Eventهای Kubernetes ساخت تا محدودیتهای پیشفرض را دور بزند و سیگنالها را قابل استفادهتر کند. ایده این است که رویدادهای خام و پرتکرار از طریق API خوانده شوند، بر اساس کلیدهایی مانند involved object، reason، namespace و الگوی پیام گروهبندی و نرمالسازی شوند، رویدادهای تکراری در پنجرههای زمانی حذف و شمارش شوند، و در نهایت رکوردهای خلاصه و ماندگار تولید شود.
با ذخیرهسازی این خلاصهها در یک backend پایدار و تعریف سیاستهای نگهداشت، تاریخچهی معنادار برای تحلیل و عیبیابی حفظ میشود. سامانه میتواند API و داشبورد برای جستوجو و روندیابی ارائه دهد، به هشداردهی متصل شود تا بهجای جهشهای لحظهای روی الگوهای پایدار یا غیرعادی هشدار دهد، و متریکها را برای ابزارهای observability صادر کند. ملاحظات عملی شامل RBAC مناسب، کنترل فشار روی API server، کش کارآمد، HA و پشتیبانی چندکلاستری است. یک controller مبتنی بر CRD نیز میتواند AggregatedEventها را نگه دارد و با Jobهای پسزمینه سیاستهای retention را اعمال کند. نتیجه، کاهش نویز، حفظ تاریخچه فراتر از ظرفیت پیشفرض و بهبود قابلیت مشاهده و عملیات SRE/DevOps است.
#Kubernetes #EventManagement #Aggregation #Observability #DevOps #SRE #CloudNative #Monitoring
🟣لینک مقاله:
https://ku.bz/HCfkK0GTC
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Enhancing Kubernetes Event Management with Custom Aggregation
🟢 خلاصه مقاله:
این مطلب در kubernetes.io نشان میدهد چگونه میتوان یک سامانهی تجمیع سفارشی برای Eventهای Kubernetes ساخت تا محدودیتهای پیشفرض را دور بزند و سیگنالها را قابل استفادهتر کند. ایده این است که رویدادهای خام و پرتکرار از طریق API خوانده شوند، بر اساس کلیدهایی مانند involved object، reason، namespace و الگوی پیام گروهبندی و نرمالسازی شوند، رویدادهای تکراری در پنجرههای زمانی حذف و شمارش شوند، و در نهایت رکوردهای خلاصه و ماندگار تولید شود.
با ذخیرهسازی این خلاصهها در یک backend پایدار و تعریف سیاستهای نگهداشت، تاریخچهی معنادار برای تحلیل و عیبیابی حفظ میشود. سامانه میتواند API و داشبورد برای جستوجو و روندیابی ارائه دهد، به هشداردهی متصل شود تا بهجای جهشهای لحظهای روی الگوهای پایدار یا غیرعادی هشدار دهد، و متریکها را برای ابزارهای observability صادر کند. ملاحظات عملی شامل RBAC مناسب، کنترل فشار روی API server، کش کارآمد، HA و پشتیبانی چندکلاستری است. یک controller مبتنی بر CRD نیز میتواند AggregatedEventها را نگه دارد و با Jobهای پسزمینه سیاستهای retention را اعمال کند. نتیجه، کاهش نویز، حفظ تاریخچه فراتر از ظرفیت پیشفرض و بهبود قابلیت مشاهده و عملیات SRE/DevOps است.
#Kubernetes #EventManagement #Aggregation #Observability #DevOps #SRE #CloudNative #Monitoring
🟣لینک مقاله:
https://ku.bz/HCfkK0GTC
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Kubernetes
Enhancing Kubernetes Event Management with Custom Aggregation
Kubernetes Events provide crucial insights into cluster operations, but as clusters grow, managing and analyzing these events becomes increasingly challenging. This blog post explores how to build custom event aggregation systems that help engineering teams…
❤3