🔵 عنوان مقاله
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
🔵 عنوان مقاله
Start Sidecar First: How To Avoid Snags
🟢 خلاصه مقاله:
این مطلب از kubernetes.io توضیح می‌دهد چرا شروع‌شدن Sidecar پیش از کانتینر اصلی مهم است و این‌که Kubernetes ترتیب شروع کانتینرها در یک Pod را تضمین نمی‌کند. برای جلوگیری از خطاهای شروع، پیشنهاد می‌شود از readiness برای مسدود کردن دریافت ترافیک تا وقتی Sidecar آماده است، از startupProbe برای دادن زمان کافی به فرایند راه‌اندازی و جلوگیری از ری‌استارت‌های زودهنگام، و از postStart برای علامت‌دادن آماده‌بودن (مثلاً از طریق فایل یا پورت محلی) استفاده شود. اگر اپلیکیشن باید قبل از آماده‌شدن Sidecar اصلاً جلو نرود، یک اسکریپت ساده در entrypoint کانتینر اصلی باید تا آماده‌شدن Sidecar صبر کند. ترکیب این روش‌ها عملاً ترتیب‌دهی مطمئن راه‌اندازی را فراهم می‌کند.
#Kubernetes #Sidecar #ReadinessProbe #StartupProbe #PostStart #Containers #DevOps #Reliability
🟣لینک مقاله:
https://ku.bz/QRqjJKQJt
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Start Sidecar First: How To Avoid Snags
🟢 خلاصه مقاله:
این مطلب از kubernetes.io توضیح می‌دهد چرا شروع‌شدن Sidecar پیش از کانتینر اصلی مهم است و این‌که Kubernetes ترتیب شروع کانتینرها در یک Pod را تضمین نمی‌کند. برای جلوگیری از خطاهای شروع، پیشنهاد می‌شود از readiness برای مسدود کردن دریافت ترافیک تا وقتی Sidecar آماده است، از startupProbe برای دادن زمان کافی به فرایند راه‌اندازی و جلوگیری از ری‌استارت‌های زودهنگام، و از postStart برای علامت‌دادن آماده‌بودن (مثلاً از طریق فایل یا پورت محلی) استفاده شود. اگر اپلیکیشن باید قبل از آماده‌شدن Sidecar اصلاً جلو نرود، یک اسکریپت ساده در entrypoint کانتینر اصلی باید تا آماده‌شدن Sidecar صبر کند. ترکیب این روش‌ها عملاً ترتیب‌دهی مطمئن راه‌اندازی را فراهم می‌کند.
#Kubernetes #Sidecar #ReadinessProbe #StartupProbe #PostStart #Containers #DevOps #Reliability
🟣لینک مقاله:
https://ku.bz/QRqjJKQJt
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Kubernetes
Start Sidecar First: How To Avoid Snags
From the Kubernetes Multicontainer Pods: An Overview blog post you know what their job is, what are the main architectural patterns, and how they are implemented in Kubernetes. The main thing I’ll cover in this article is how to ensure that your sidecar containers…
❤1
🔵 عنوان مقاله
Grafana k8s-monitoring-helm: Scalable Observability Stack for Kubernetes
🟢 خلاصه مقاله:
این مقاله یک راهکار یکپارچه و مقیاس‌پذیر برای مشاهده‌پذیری Kubernetes با استفاده از Helm معرفی می‌کند که به‌صورت یک چارت، استقرار نظارت جامع شامل metrics، logs و traces را ساده می‌سازد. اجزای کلیدی آن شامل جمع‌آوری metrics سازگار با Prometheus، تجمیع logs با Loki و agents سبک مثل Promtail یا Grafana Agent، پشتیبانی از traces با Tempo و OpenTelemetry، و نمایش و هشداردهی از طریق Grafana است. این چارت با کشف خودکار سرویس‌ها، داشبوردهای آماده، قوانین هشدار، و گزینه‌های مقیاس‌پذیری (sharding، remote_write، و تنظیمات retention/limits) امکان بهره‌برداری در خوشه‌های بزرگ را فراهم می‌کند. امنیت و پایداری با RBAC، TLS، مدیریت Secrets، NetworkPolicy و پشتیبانی از persistence و GitOps (مانند Argo CD و Flux) پوشش داده می‌شود. هدف، ارائه مسیر سریع و قابل اتکا برای استقرار مشاهده‌پذیری در Kubernetes است؛ چه در مدل خودمیزبان و چه با اتصال به Grafana Cloud، همراه با قابلیت شخصی‌سازی داشبوردها و سیاست‌های مقیاس‌پذیری.
#Kubernetes #Grafana #Helm #Observability #Prometheus #Loki #OpenTelemetry #DevOps
🟣لینک مقاله:
https://ku.bz/G5l3N6Pcw
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Grafana k8s-monitoring-helm: Scalable Observability Stack for Kubernetes
🟢 خلاصه مقاله:
این مقاله یک راهکار یکپارچه و مقیاس‌پذیر برای مشاهده‌پذیری Kubernetes با استفاده از Helm معرفی می‌کند که به‌صورت یک چارت، استقرار نظارت جامع شامل metrics، logs و traces را ساده می‌سازد. اجزای کلیدی آن شامل جمع‌آوری metrics سازگار با Prometheus، تجمیع logs با Loki و agents سبک مثل Promtail یا Grafana Agent، پشتیبانی از traces با Tempo و OpenTelemetry، و نمایش و هشداردهی از طریق Grafana است. این چارت با کشف خودکار سرویس‌ها، داشبوردهای آماده، قوانین هشدار، و گزینه‌های مقیاس‌پذیری (sharding، remote_write، و تنظیمات retention/limits) امکان بهره‌برداری در خوشه‌های بزرگ را فراهم می‌کند. امنیت و پایداری با RBAC، TLS، مدیریت Secrets، NetworkPolicy و پشتیبانی از persistence و GitOps (مانند Argo CD و Flux) پوشش داده می‌شود. هدف، ارائه مسیر سریع و قابل اتکا برای استقرار مشاهده‌پذیری در Kubernetes است؛ چه در مدل خودمیزبان و چه با اتصال به Grafana Cloud، همراه با قابلیت شخصی‌سازی داشبوردها و سیاست‌های مقیاس‌پذیری.
#Kubernetes #Grafana #Helm #Observability #Prometheus #Loki #OpenTelemetry #DevOps
🟣لینک مقاله:
https://ku.bz/G5l3N6Pcw
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - grafana/k8s-monitoring-helm
Contribute to grafana/k8s-monitoring-helm development by creating an account on GitHub.
❤1
🔵 عنوان مقاله
The Ingredients of the Cake: Recipes for Sustainable AI Delivery (5 minute read)
🟢 خلاصه مقاله:
** این مقاله توسعه پایدار هوش مصنوعی را با پختن کیک مقایسه می‌کند: داشتن دستور روشن، مواد اولیه باکیفیت، ابزار درست و فرایند تکرارشونده. داده و برچسب تمیز و تحت حاکمیت، تعریف دقیق مسئله و معیارهای موفقیت، معماری و تنظیمات آموزشی مناسب، و زیرساخت و MLOps قابل اتکا، چهار ستون نتیجه‌گیری قابل پیش‌بینی‌اند. پایداری با بهینه‌سازی اندازه و کارایی مدل آغاز می‌شود: سنجش مبادله‌ها و استفاده از روش‌هایی مانند pruning، quantization و distillation برای کاهش هزینه، تأخیر و ردپای کربن؛ همچنین بازاستفاده از مؤلفه‌ها، خودکارسازی منطقی، و گنجاندن حاکمیت (حریم خصوصی، امنیت، انطباق و ارزیابی سوگیری) از ابتدا. در تحویل، تنها استقرار مدل کافی نیست: محیط‌های مرحله‌ای، انتشار تدریجی یا A/B، قابلیت بازگشت، پایش و هشداردهی، تعریف SLA/SLO، انسان در حلقه برای تصمیم‌های حساس و دریافت بازخورد کاربر ضروری‌اند. در نهایت، یک «کارت دستور» شامل هم‌راستاسازی و معیارها، آماده‌سازی داده، آموزش و اعتبارسنجی، استقرار با CI/CD و نگهبان‌ها، پایش و تکرار، مستندسازی و مدیریت هزینه، و نگهداری playbookها، تحویل هوش مصنوعی را قابل اتکا و پایدار می‌کند.
#SustainableAI #MLOps #ResponsibleAI #AIEngineering #ModelOps #DataGovernance #AIOps
🟣لینک مقاله:
https://cd.foundation/blog/2025/10/03/sustainable-ai-delivery/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
The Ingredients of the Cake: Recipes for Sustainable AI Delivery (5 minute read)
🟢 خلاصه مقاله:
** این مقاله توسعه پایدار هوش مصنوعی را با پختن کیک مقایسه می‌کند: داشتن دستور روشن، مواد اولیه باکیفیت، ابزار درست و فرایند تکرارشونده. داده و برچسب تمیز و تحت حاکمیت، تعریف دقیق مسئله و معیارهای موفقیت، معماری و تنظیمات آموزشی مناسب، و زیرساخت و MLOps قابل اتکا، چهار ستون نتیجه‌گیری قابل پیش‌بینی‌اند. پایداری با بهینه‌سازی اندازه و کارایی مدل آغاز می‌شود: سنجش مبادله‌ها و استفاده از روش‌هایی مانند pruning، quantization و distillation برای کاهش هزینه، تأخیر و ردپای کربن؛ همچنین بازاستفاده از مؤلفه‌ها، خودکارسازی منطقی، و گنجاندن حاکمیت (حریم خصوصی، امنیت، انطباق و ارزیابی سوگیری) از ابتدا. در تحویل، تنها استقرار مدل کافی نیست: محیط‌های مرحله‌ای، انتشار تدریجی یا A/B، قابلیت بازگشت، پایش و هشداردهی، تعریف SLA/SLO، انسان در حلقه برای تصمیم‌های حساس و دریافت بازخورد کاربر ضروری‌اند. در نهایت، یک «کارت دستور» شامل هم‌راستاسازی و معیارها، آماده‌سازی داده، آموزش و اعتبارسنجی، استقرار با CI/CD و نگهبان‌ها، پایش و تکرار، مستندسازی و مدیریت هزینه، و نگهداری playbookها، تحویل هوش مصنوعی را قابل اتکا و پایدار می‌کند.
#SustainableAI #MLOps #ResponsibleAI #AIEngineering #ModelOps #DataGovernance #AIOps
🟣لینک مقاله:
https://cd.foundation/blog/2025/10/03/sustainable-ai-delivery/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
CD Foundation
The Ingredients of the Cake: Recipes for Sustainable AI Delivery - CD Foundation
This article uses cake analogies and real-world case studies of failures — not to shame, but to remind us that AI is not experimental. It require structure, precision, and respect.
🔵 عنوان مقاله
kcp: isolated workspaces
🟢 خلاصه مقاله:
kcp مفهوم Workspaceهای ایزوله را معرفی می‌کند؛ محیط‌های منطقی سبک که روی یک کنترل‌پلین مشترک اجرا می‌شوند اما APIها، منابع، دسترسی‌ها و خط‌مشی‌ها را در محدوده هر Workspace جدا نگه می‌دارند. این جداسازی باعث می‌شود CRDها و نام‌ها تداخلی نداشته باشند، RBAC و سهمیه‌ها مستقل باشند و تیم‌ها بدون سربار چندین کلاستر، امن و چابک کار کنند. با استفاده از APIExport و APIBinding می‌توان یک API را یک‌بار تعریف و در Workspaceهای مختلف مصرف کرد؛ ارتقا و انتشار مرحله‌ای (از staging به production) و حتی رول‌اوت تدریجی برای هر مشتری یا تیم امن‌تر و قابل‌کنترل‌تر می‌شود. نتیجه برای سناریوهای Multi-tenant SaaS، Platform Engineering، جداسازی‌های مقرراتی و اکوسیستم‌های شریک، امنیت، مقیاس‌پذیری و قابلیت عملیات بهتر است؛ هرچند هماهنگی بین Workspaceها باید شفاف و مبتنی بر خط‌مشی باشد.
#kcp #Kubernetes #Workspaces #MultiTenancy #PlatformEngineering #SaaS #APIs #Security
🟣لینک مقاله:
https://ku.bz/vxxKWBytr
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
kcp: isolated workspaces
🟢 خلاصه مقاله:
kcp مفهوم Workspaceهای ایزوله را معرفی می‌کند؛ محیط‌های منطقی سبک که روی یک کنترل‌پلین مشترک اجرا می‌شوند اما APIها، منابع، دسترسی‌ها و خط‌مشی‌ها را در محدوده هر Workspace جدا نگه می‌دارند. این جداسازی باعث می‌شود CRDها و نام‌ها تداخلی نداشته باشند، RBAC و سهمیه‌ها مستقل باشند و تیم‌ها بدون سربار چندین کلاستر، امن و چابک کار کنند. با استفاده از APIExport و APIBinding می‌توان یک API را یک‌بار تعریف و در Workspaceهای مختلف مصرف کرد؛ ارتقا و انتشار مرحله‌ای (از staging به production) و حتی رول‌اوت تدریجی برای هر مشتری یا تیم امن‌تر و قابل‌کنترل‌تر می‌شود. نتیجه برای سناریوهای Multi-tenant SaaS، Platform Engineering، جداسازی‌های مقرراتی و اکوسیستم‌های شریک، امنیت، مقیاس‌پذیری و قابلیت عملیات بهتر است؛ هرچند هماهنگی بین Workspaceها باید شفاف و مبتنی بر خط‌مشی باشد.
#kcp #Kubernetes #Workspaces #MultiTenancy #PlatformEngineering #SaaS #APIs #Security
🟣لینک مقاله:
https://ku.bz/vxxKWBytr
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
🔵 عنوان مقاله
Kubernetes v1.33: Updates to Container Lifecycle
🟢 خلاصه مقاله:
** این نسخه از Kubernetes v1.33 دو به‌روزرسانی مهم در چرخه عمر container ارائه می‌دهد: نخست، Sleep اکنون به‌طور پیش‌فرض از مدت‌زمان صفر ثانیه پشتیبانی می‌کند تا بتوان همان الگوها را بدون تأخیر واقعی استفاده کرد و فقط در صورت نیاز تأخیر را تنظیم کرد. دوم، می‌توان signal خاموش‌سازی را مستقیماً در Pod مشخص کرد (مثلاً SIGTERM یا SIGINT) و دیگر لازم نیست برای تغییر STOPSIGNAL، image را دوباره ساخت. نتیجه، ساده‌تر شدن تمپلیت‌ها و CI/CD، خاموش‌سازی gracefulتر، و کاهش نیاز به بازسازی image است.
#Kubernetes #K8s #Containers #DevOps #Pod #Lifecycle #SIGTERM #CloudNative
🟣لینک مقاله:
https://ku.bz/GkJ9S8P0Z
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Kubernetes v1.33: Updates to Container Lifecycle
🟢 خلاصه مقاله:
** این نسخه از Kubernetes v1.33 دو به‌روزرسانی مهم در چرخه عمر container ارائه می‌دهد: نخست، Sleep اکنون به‌طور پیش‌فرض از مدت‌زمان صفر ثانیه پشتیبانی می‌کند تا بتوان همان الگوها را بدون تأخیر واقعی استفاده کرد و فقط در صورت نیاز تأخیر را تنظیم کرد. دوم، می‌توان signal خاموش‌سازی را مستقیماً در Pod مشخص کرد (مثلاً SIGTERM یا SIGINT) و دیگر لازم نیست برای تغییر STOPSIGNAL، image را دوباره ساخت. نتیجه، ساده‌تر شدن تمپلیت‌ها و CI/CD، خاموش‌سازی gracefulتر، و کاهش نیاز به بازسازی image است.
#Kubernetes #K8s #Containers #DevOps #Pod #Lifecycle #SIGTERM #CloudNative
🟣لینک مقاله:
https://ku.bz/GkJ9S8P0Z
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Kubernetes
Kubernetes v1.33: Updates to Container Lifecycle
Kubernetes v1.33 introduces a few updates to the lifecycle of containers. The Sleep action for container lifecycle hooks now supports a zero sleep duration (feature enabled by default). There is also alpha support for customizing the stop signal sent to containers…
🔵 عنوان مقاله
Service Binding for Kubernetes in Spring Boot cloud-native applications
🟢 خلاصه مقاله:
این آموزش نشان می‌دهد چگونه با تکیه بر spec مربوط به Service Binding for Kubernetes و استفاده از Spring Cloud Bindings، اتصال برنامه‌های Spring Boot به سرویس‌های پشتیبان مانند PostgreSQL را به‌صورت خودکار انجام دهیم و نیاز به تنظیم دستی متغیرهای محیطی را حذف کنیم. برنامه با افزودن Spring Cloud Bindings می‌تواند Bindingهای استانداردشده را که از طریق Secrets و الگوی مشخص در Kubernetes تزریق می‌شوند، شناسایی کرده و به‌صورت خودکار در پیکربندی Spring Boot (مثلاً DataSource) به کار بگیرد. روند کار شامل استقرار PostgreSQL، دسترس‌پذیر کردن اطلاعات اتصال در قالب Secret، و تعریف یک ServiceBinding است که Deployment برنامه و Secret را به هم متصل می‌کند. این روش علاوه‌بر ساده‌سازی و کاهش وابستگی به ConfigMap و env varهای سفارشی، امنیت و پورتابل بودن را بهبود می‌دهد و برای سرویس‌های دیگر نیز قابل تعمیم است.
#Kubernetes #SpringBoot #ServiceBinding #SpringCloudBindings #PostgreSQL #CloudNative #DevOps #K8s
🟣لینک مقاله:
https://ku.bz/CZrT1x9Rq
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Service Binding for Kubernetes in Spring Boot cloud-native applications
🟢 خلاصه مقاله:
این آموزش نشان می‌دهد چگونه با تکیه بر spec مربوط به Service Binding for Kubernetes و استفاده از Spring Cloud Bindings، اتصال برنامه‌های Spring Boot به سرویس‌های پشتیبان مانند PostgreSQL را به‌صورت خودکار انجام دهیم و نیاز به تنظیم دستی متغیرهای محیطی را حذف کنیم. برنامه با افزودن Spring Cloud Bindings می‌تواند Bindingهای استانداردشده را که از طریق Secrets و الگوی مشخص در Kubernetes تزریق می‌شوند، شناسایی کرده و به‌صورت خودکار در پیکربندی Spring Boot (مثلاً DataSource) به کار بگیرد. روند کار شامل استقرار PostgreSQL، دسترس‌پذیر کردن اطلاعات اتصال در قالب Secret، و تعریف یک ServiceBinding است که Deployment برنامه و Secret را به هم متصل می‌کند. این روش علاوه‌بر ساده‌سازی و کاهش وابستگی به ConfigMap و env varهای سفارشی، امنیت و پورتابل بودن را بهبود می‌دهد و برای سرویس‌های دیگر نیز قابل تعمیم است.
#Kubernetes #SpringBoot #ServiceBinding #SpringCloudBindings #PostgreSQL #CloudNative #DevOps #K8s
🟣لینک مقاله:
https://ku.bz/CZrT1x9Rq
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
Service Binding for K8s in Spring Boot cloud-native applications
Part 9 — Using Spring Cloud Bindings to auto-configure CNB Bindings