🔵 عنوان مقاله
Kubernetes v1.37: Native Histograms Graduates to Beta (3 minute read)
🟢 خلاصه مقاله:
در نسخه ۱.۳۷ کیوب‌نتیس، قابلیت پشتیبانی بومی هیستوگرام‌ها به مرحله بتا رسید و به طور پیش‌فرض فعال شده است. این ویژگی، امکان اندازه‌گیری دقیق‌تر معیارهای مرتبط با تأخیر و مدت زمان را فراهم می‌کند و در عین حال، میزان نیاز به حافظه و بارگیری داده‌های Telemetry را کاهش می‌دهد. در گذشته، کاربران باید برای جمع‌آوری این داده‌ها از جعبه‌ابزارهای مختلف، مانند Prometheus، استفاده می‌کردند؛ اما اکنون هیستوگرام‌های بومی جایگزین جعبه‌ابزارهای ثابت و تعریف‌شده به صورت دستی، با buckets دینامیک و نمایی شده‌اند که در قالب یک سری زمانی واحد ذخیره می‌شود. این تغییر، به بهبود دقت و کارایی مانیتورینگ در اکوسیستم Kubernetes کمک می‌کند و توسعه‌دهندگان و اپراتورها را قادر می‌سازد تا نظارت بهتری بر عملکرد سرویس‌های خود داشته باشند.
#Kubernetes #هیستوگرام #Prometheus #نصب81
🟣لینک مقاله:
https://kubernetes.io/blog/2026/09/11/kubernetes-v1-37-native-histograms-beta/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Kubernetes v1.37: Native Histograms Graduates to Beta (3 minute read)
🟢 خلاصه مقاله:
در نسخه ۱.۳۷ کیوب‌نتیس، قابلیت پشتیبانی بومی هیستوگرام‌ها به مرحله بتا رسید و به طور پیش‌فرض فعال شده است. این ویژگی، امکان اندازه‌گیری دقیق‌تر معیارهای مرتبط با تأخیر و مدت زمان را فراهم می‌کند و در عین حال، میزان نیاز به حافظه و بارگیری داده‌های Telemetry را کاهش می‌دهد. در گذشته، کاربران باید برای جمع‌آوری این داده‌ها از جعبه‌ابزارهای مختلف، مانند Prometheus، استفاده می‌کردند؛ اما اکنون هیستوگرام‌های بومی جایگزین جعبه‌ابزارهای ثابت و تعریف‌شده به صورت دستی، با buckets دینامیک و نمایی شده‌اند که در قالب یک سری زمانی واحد ذخیره می‌شود. این تغییر، به بهبود دقت و کارایی مانیتورینگ در اکوسیستم Kubernetes کمک می‌کند و توسعه‌دهندگان و اپراتورها را قادر می‌سازد تا نظارت بهتری بر عملکرد سرویس‌های خود داشته باشند.
#Kubernetes #هیستوگرام #Prometheus #نصب81
🟣لینک مقاله:
https://kubernetes.io/blog/2026/09/11/kubernetes-v1-37-native-histograms-beta/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Kubernetes
Kubernetes v1.37: Native Histograms Graduates to Beta
I'm excited to announce that native histogram support for Kubernetes metrics is graduating to Beta and is enabled by default in Kubernetes v1.37!
Native histograms (previously introduced as Alpha in Kubernetes v1.36 under KEP-5808) bring high-resolution,…
Native histograms (previously introduced as Alpha in Kubernetes v1.36 under KEP-5808) bring high-resolution,…
🔵 عنوان مقاله
Migrating from AWS VPC CNI & Kube-Proxy to Cilium on EKS
🟢 خلاصه مقاله:
در این مقاله، فرآیند انتقال محیط EKS از استفاده از شبکه‌ساز VPC CNI و پروکسی کابی‌پروکسی به راه‌حل پیشرفته‌تر Cilium مورد بررسی قرار می‌گیرد. این تغییرات به منظور بهبود امنیت، کارایی و قابلیت‌های نظارتی انجام می‌شود و شامل استراتژی‌های پیشرفته‌ای مانند بهره‌گیری از نودهای blue/green، رمزگذاری با WireGuard و استفاده از ابزار Hubble برای مشاهده‌پذیری شبکه است.
در ابتدای فرآیند، نیاز است تا زیرساخت‌های موجود با دقت بررسی شده و برنامه‌ریزی مناسبی برای مهاجرت صورت گیرد. استفاده از نودهای نوع blue/green به مدیران این امکان را می‌دهد که به صورت مرحله‌ای و بدون اختلال، سیستم‌ها را به نسخه جدید منتقل کنند. همچنین، بهره‌گیری از فناوری رمزگذاری WireGuard تضمین می‌کند که ترافیک شبکه به صورت ایمن و پراکنده انجام می‌شود، که این امر سبب افزایش امنیت داده‌ها و کاهش ریسک‌های احتمالی می‌گردد.
در نهایت، با استفاده از Hubble برای نظارت بر ترافیک و عملکرد شبکه، قابلیت‌های دیداری و عملیات‌پذیری بیشتر و بهتر می‌شود، که این امر در مدیریت و رفع اشکالات شبکه نقش حیاتی دارد. این مقاله گام به گام به توسعه‌دهندگان و مدیران سیستم کمک می‌کند تا این مهاجرت را به صورت کارآمد، امن و بی‌وقفه انجام دهند و از مزایای فناوری نوین Cilium بهره‌مند شوند.
#کلود #امنیت_شبکه #Kubernetes #Cilium
🟣لینک مقاله:
https://ku.bz/sYGLb0l37
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Migrating from AWS VPC CNI & Kube-Proxy to Cilium on EKS
🟢 خلاصه مقاله:
در این مقاله، فرآیند انتقال محیط EKS از استفاده از شبکه‌ساز VPC CNI و پروکسی کابی‌پروکسی به راه‌حل پیشرفته‌تر Cilium مورد بررسی قرار می‌گیرد. این تغییرات به منظور بهبود امنیت، کارایی و قابلیت‌های نظارتی انجام می‌شود و شامل استراتژی‌های پیشرفته‌ای مانند بهره‌گیری از نودهای blue/green، رمزگذاری با WireGuard و استفاده از ابزار Hubble برای مشاهده‌پذیری شبکه است.
در ابتدای فرآیند، نیاز است تا زیرساخت‌های موجود با دقت بررسی شده و برنامه‌ریزی مناسبی برای مهاجرت صورت گیرد. استفاده از نودهای نوع blue/green به مدیران این امکان را می‌دهد که به صورت مرحله‌ای و بدون اختلال، سیستم‌ها را به نسخه جدید منتقل کنند. همچنین، بهره‌گیری از فناوری رمزگذاری WireGuard تضمین می‌کند که ترافیک شبکه به صورت ایمن و پراکنده انجام می‌شود، که این امر سبب افزایش امنیت داده‌ها و کاهش ریسک‌های احتمالی می‌گردد.
در نهایت، با استفاده از Hubble برای نظارت بر ترافیک و عملکرد شبکه، قابلیت‌های دیداری و عملیات‌پذیری بیشتر و بهتر می‌شود، که این امر در مدیریت و رفع اشکالات شبکه نقش حیاتی دارد. این مقاله گام به گام به توسعه‌دهندگان و مدیران سیستم کمک می‌کند تا این مهاجرت را به صورت کارآمد، امن و بی‌وقفه انجام دهند و از مزایای فناوری نوین Cilium بهره‌مند شوند.
#کلود #امنیت_شبکه #Kubernetes #Cilium
🟣لینک مقاله:
https://ku.bz/sYGLb0l37
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
Migrating from AWS VPC CNI & Kube-Proxy to Cilium on EKS
Migrating from AWS VPC CNI & Kube-Proxy to Cilium on EKS If you are running Kubernetes in production, network security and visibility eventually become top priorities. Recently, I decided to migrate …
🔵 عنوان مقاله
Kubernetes Through Control Theory Glasses: HPA
🟢 خلاصه مقاله:
در این مقاله، نگارنده به بررسی سیستم مقیاس‌گذاری خودکار در کابرنتیس، از منظر تئوری کنترل می‌پردازد و آن را به عنوان یک کنترلر تناسبی تحلیل می‌کند. این رویکرد به ما کمک می‌کند تا بهتر درک کنیم چرا در طراحی هستانده‌های خودکار، لازم است برخی محدودیت‌ها و ترازهای مختلف را در نظر بگیریم. به عنوان مثال، مفهوم دست‌کم‌گیری یا Deadband، حساسیت یا Gain بالا و پاسخ کند، همه از فاکتورهای حیاتی در توازن بین کارایی و پایداری این سیستم‌ها هستند که در طول زمان ناگزیر به ترويج آنها خواهیم بود.
در ادامه، نویسنده به تأثیرات منفی زمان تاخیر و میزان کوانتیزاسیون پادها بر عملکرد کنترلر PID می‌پردازد. این موارد، باعث می‌شوند نحوه پاسخ‌دهی و دقت سیستم کنترل به صورت قابل توجهی تغییر کند. درک اینکه چگونه این عوامل باعث کاهش کارایی و یا ناپایداری می‌شوند، ما را قادر می‌سازد تا طراحی‌های بهتری در حوزه کنترل و مقیاس‌گذاری خودکار پیاده کنیم.
در مجموع، این مقاله با نگاه کردن به HPA (مقیاس‌گذار خودکار در کابرنتیس) از دید کنترل نظری، نشان می‌دهد که محدودیت‌ها و توازن‌های اساسی در طراحی این سیستم‌ها وجود دارد و مهم است که به آنها آگاهانه توجه کنیم. این تحلیل، به مدیران و توسعه‌دهندگان کمک می‌کند تا درک عمیق‌تری از نحوه رفتار و بهبود عملکرد سیستم‌های مقیاس‌گذاری خودکار داشته باشند و در نتیجه، فرآیندهای مدیریت منابع را به صورت موثرتری هدایت کنند.
#کابرنتیس #کنترل_خودکار #پایش_سیستم #مدیریت_منابع
🟣لینک مقاله:
https://ku.bz/FdGgBK2q8
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Kubernetes Through Control Theory Glasses: HPA
🟢 خلاصه مقاله:
در این مقاله، نگارنده به بررسی سیستم مقیاس‌گذاری خودکار در کابرنتیس، از منظر تئوری کنترل می‌پردازد و آن را به عنوان یک کنترلر تناسبی تحلیل می‌کند. این رویکرد به ما کمک می‌کند تا بهتر درک کنیم چرا در طراحی هستانده‌های خودکار، لازم است برخی محدودیت‌ها و ترازهای مختلف را در نظر بگیریم. به عنوان مثال، مفهوم دست‌کم‌گیری یا Deadband، حساسیت یا Gain بالا و پاسخ کند، همه از فاکتورهای حیاتی در توازن بین کارایی و پایداری این سیستم‌ها هستند که در طول زمان ناگزیر به ترويج آنها خواهیم بود.
در ادامه، نویسنده به تأثیرات منفی زمان تاخیر و میزان کوانتیزاسیون پادها بر عملکرد کنترلر PID می‌پردازد. این موارد، باعث می‌شوند نحوه پاسخ‌دهی و دقت سیستم کنترل به صورت قابل توجهی تغییر کند. درک اینکه چگونه این عوامل باعث کاهش کارایی و یا ناپایداری می‌شوند، ما را قادر می‌سازد تا طراحی‌های بهتری در حوزه کنترل و مقیاس‌گذاری خودکار پیاده کنیم.
در مجموع، این مقاله با نگاه کردن به HPA (مقیاس‌گذار خودکار در کابرنتیس) از دید کنترل نظری، نشان می‌دهد که محدودیت‌ها و توازن‌های اساسی در طراحی این سیستم‌ها وجود دارد و مهم است که به آنها آگاهانه توجه کنیم. این تحلیل، به مدیران و توسعه‌دهندگان کمک می‌کند تا درک عمیق‌تری از نحوه رفتار و بهبود عملکرد سیستم‌های مقیاس‌گذاری خودکار داشته باشند و در نتیجه، فرآیندهای مدیریت منابع را به صورت موثرتری هدایت کنند.
#کابرنتیس #کنترل_خودکار #پایش_سیستم #مدیریت_منابع
🟣لینک مقاله:
https://ku.bz/FdGgBK2q8
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
DEV Community
Kubernetes Through Control Theory Glasses — Part 1: HPA
One Saturday morning I was fixing my coffee grinder while watching James Hoffmann explain how a PID...
🔵 عنوان مقاله
What we learned about AI agent security by monitoring our agents (1 minute read)
🟢 خلاصه مقاله:
در دنیای فناوری امروز، امنیت هوش مصنوعی یکی از موضوعات حیاتی و پرتکرار است که توجه بسیاری از کارشناسان و شرکت‌ها را به خود جلب کرده است. شرکت دیتادُگ، برای درک بهتر و تقویت امنیت عوامل هوش مصنوعی خود، تصمیم گرفت تا نظارتی دقیق بر عوامل هوشمند خود داشته باشد. این اقدام با هدف شناسایی نقاط ضعف، کشف داده‌های حساس و ارزیابی ریسک‌های موجود در فرآیندهای مختلف صورت گرفت.
در این فرآیند، اولین قدم ساخت فهرستی جامع از اجزای مختلف عامل‌های هوشمند بود. این فهرست شامل تمامی مؤلفه‌ها و ابزارهای مورد استفاده در سیستم‌ها می‌شد که کمک می‌کرد تا تصویری واضح از ساختار و عملیات هر عامل به دست آید. سپس، تیم بررسی به رصد جریان‌های داده‌های حساس و تماس‌های ابزارهای مختلف پرداخت، تا بتواند مسیرهای انتقال اطلاعات مهم را پیگیری کند و خطرات احتمالی را شناسایی کند. این اقدامات، بنیان‌های لازم برای اصلاح و تقویت امنیت عوامل هوشمند را فراهم ساختند و نشان دادند که نظارت دقیق، کلید مقابله با تهدیدهای سایبری است.
این تجربه نشان می‌دهد که نظارت متمرکز و مستمر بر سیستم‌های هوشمند نه تنها فرصت‌های بهبود امنیت را فراهم می‌آورد بلکه می‌تواند به شکل قابل توجهی احتمال وقوع حوادث غیرمترقبه را کاهش دهد. در نتیجه، شرکت‌ها باید فرآیندهای رصد و ارزیابی امنیت سیستم‌های هوشمند خود را جدی گرفته و از این تحقیقات بهره‌مند شوند تا بتوانند در دنیای رقابتی امروز، امنیت داده‌ها و سیستم‌های خود را تضمین کنند.
#امنیت_هوش_مصنوعی #مراقبت_هوشمند #ایمنی_سیستم #تحقیقات_سایبری
🟣لینک مقاله:
https://www.datadoghq.com/blog/ai-agent-security-lessons/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
What we learned about AI agent security by monitoring our agents (1 minute read)
🟢 خلاصه مقاله:
در دنیای فناوری امروز، امنیت هوش مصنوعی یکی از موضوعات حیاتی و پرتکرار است که توجه بسیاری از کارشناسان و شرکت‌ها را به خود جلب کرده است. شرکت دیتادُگ، برای درک بهتر و تقویت امنیت عوامل هوش مصنوعی خود، تصمیم گرفت تا نظارتی دقیق بر عوامل هوشمند خود داشته باشد. این اقدام با هدف شناسایی نقاط ضعف، کشف داده‌های حساس و ارزیابی ریسک‌های موجود در فرآیندهای مختلف صورت گرفت.
در این فرآیند، اولین قدم ساخت فهرستی جامع از اجزای مختلف عامل‌های هوشمند بود. این فهرست شامل تمامی مؤلفه‌ها و ابزارهای مورد استفاده در سیستم‌ها می‌شد که کمک می‌کرد تا تصویری واضح از ساختار و عملیات هر عامل به دست آید. سپس، تیم بررسی به رصد جریان‌های داده‌های حساس و تماس‌های ابزارهای مختلف پرداخت، تا بتواند مسیرهای انتقال اطلاعات مهم را پیگیری کند و خطرات احتمالی را شناسایی کند. این اقدامات، بنیان‌های لازم برای اصلاح و تقویت امنیت عوامل هوشمند را فراهم ساختند و نشان دادند که نظارت دقیق، کلید مقابله با تهدیدهای سایبری است.
این تجربه نشان می‌دهد که نظارت متمرکز و مستمر بر سیستم‌های هوشمند نه تنها فرصت‌های بهبود امنیت را فراهم می‌آورد بلکه می‌تواند به شکل قابل توجهی احتمال وقوع حوادث غیرمترقبه را کاهش دهد. در نتیجه، شرکت‌ها باید فرآیندهای رصد و ارزیابی امنیت سیستم‌های هوشمند خود را جدی گرفته و از این تحقیقات بهره‌مند شوند تا بتوانند در دنیای رقابتی امروز، امنیت داده‌ها و سیستم‌های خود را تضمین کنند.
#امنیت_هوش_مصنوعی #مراقبت_هوشمند #ایمنی_سیستم #تحقیقات_سایبری
🟣لینک مقاله:
https://www.datadoghq.com/blog/ai-agent-security-lessons/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Datadog
What we learned about AI agent security by monitoring our agents | Datadog
Learn what we discovered about AI agent security by monitoring our agents, from creating an inventory of agent components to tracing sensitive data and tool calls.
🔵 عنوان مقاله
Quick thoughts on Azure Regional Outage from July 23, '26 (3 minute read)
🟢 خلاصه مقاله:
در تاریخ ۲۳ ژوئیه، سرویس آژور در منطقه غرب ایالات متحده دچار خرابی شد که حدود پنج ساعت ادامه داشت. این مشکل پس از انجام یک تعمیر در شبکه رخ داد و منجر به جدا شدن گسترده‌ی دستگاه‌ها و سرویس‌های مختلف شد. این حادثه نشان‌دهنده ضعف‌هایی در تحلیل محدوده خسارت، ارزیابی ایمنی کلی شبکه، سیگنال‌های نادرست سلامت سیستم، ثبت ناقص رویدادها و اتوماسیون بازگردانی سیستم بود که همگی تحت تاثیر اتصال اینترنتی مختل شده قرار گرفتند.
این رویداد بر اهمیت طرح‌های پشتیبان‌گیری قوی و استراتژی‌های بازیابی سریع برای کاهش تاثیر چنین خرابی‌هایی تأکید می‌کند. همچنین، ضرورت بررسی و اصلاح فرآیندهای خطایابی و ارزیابی خطر در زمان‌های بحرانی را نمایان می‌سازد. شرکت‌ها و توسعه‌دهندگان باید با تمرکز بر امنیت و قابلیت اطمینان زیرساخت‌های ابری، از وقوع مجدد چنین مشکلاتی جلوگیری کنند و خدمات پایدار و قابل اعتماد برای کاربران فراهم آورند.
#آژور #خرابی_سرویس #امنیت_ابری #بازیابی_خدمات
🟣لینک مقاله:
https://surfingcomplexity.blog/2026/08/16/quick-thoughts-on-azure-regional-outage-from-july-23-26/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Quick thoughts on Azure Regional Outage from July 23, '26 (3 minute read)
🟢 خلاصه مقاله:
در تاریخ ۲۳ ژوئیه، سرویس آژور در منطقه غرب ایالات متحده دچار خرابی شد که حدود پنج ساعت ادامه داشت. این مشکل پس از انجام یک تعمیر در شبکه رخ داد و منجر به جدا شدن گسترده‌ی دستگاه‌ها و سرویس‌های مختلف شد. این حادثه نشان‌دهنده ضعف‌هایی در تحلیل محدوده خسارت، ارزیابی ایمنی کلی شبکه، سیگنال‌های نادرست سلامت سیستم، ثبت ناقص رویدادها و اتوماسیون بازگردانی سیستم بود که همگی تحت تاثیر اتصال اینترنتی مختل شده قرار گرفتند.
این رویداد بر اهمیت طرح‌های پشتیبان‌گیری قوی و استراتژی‌های بازیابی سریع برای کاهش تاثیر چنین خرابی‌هایی تأکید می‌کند. همچنین، ضرورت بررسی و اصلاح فرآیندهای خطایابی و ارزیابی خطر در زمان‌های بحرانی را نمایان می‌سازد. شرکت‌ها و توسعه‌دهندگان باید با تمرکز بر امنیت و قابلیت اطمینان زیرساخت‌های ابری، از وقوع مجدد چنین مشکلاتی جلوگیری کنند و خدمات پایدار و قابل اعتماد برای کاربران فراهم آورند.
#آژور #خرابی_سرویس #امنیت_ابری #بازیابی_خدمات
🟣لینک مقاله:
https://surfingcomplexity.blog/2026/08/16/quick-thoughts-on-azure-regional-outage-from-july-23-26/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Surfing Complexity
Quick thoughts on Azure Regional Outage from July 23, ’26
The folks at Microsoft Azure recently wrote up a post incident review for a networking issue in their West U.S region. From the included timeline, it looks like the impact was on the order of five …
🔵 عنوان مقاله
Rapidly scaling online storage to serve over 1 billion ChatGPT users (13 minute read)
🟢 خلاصه مقاله:
در دنیای امروز، نیاز به ذخیره‌سازی ابری قوی و مقیاس‌پذیر برای پاسخگویی به حجم عظیم کاربران و درخواست‌هایشان اهمیت فزاینده‌ای پیدا کرده است. شرکت OpenAI، با توسعه پلتفرم ذخیره‌سازی Habitat، موفق شده است در کوتاه‌ترین زمان ممکن، زیرساختی قدرتمند و مقیاس‌پذیر برای بیش از یک میلیارد کاربر ChatGPT فراهم آورد. این پلتفرم، در حال حاضر بیش از ۷۰ میلیون درخواست در ثانیه را پردازش می‌کند و بیش از ۵۰۰ پتابایت داده را سرو می‌کند.
یکی از اقدامات مهم تیم این بود که سرویس را مجدداً بازنویسی کند، این بار با استفاده از زبان برنامه‌نویسی Rust. این تغییر، باعث شد سرویس در مصرف منابع بسیار بهینه‌تر عمل کند و کارایی آن به طور چشمگیری افزایش یابد؛ به طوری که Rust نسبت به نسخه قبلی پایتون، ۶ برابر در بهره‌وری CPU و ۱۵ برابر در مصرف حافظه بهتر عمل می‌کند. این بهبودها نه تنها سرعت و کارایی سیستم را بهبود بخشید، بلکه امکان توسعه و استقرار آن در مقیاس‌های بزرگ‌تر را نیز فراهم ساخت.
Habitat در ابتدا تنها به عنوان یک کتابخانه پایتون در رویداد DevDay 2023 معرفی شد و هدف آن پشتیبانی از مدل‌های GPT بود. اما با گذشت زمان و ادامه توسعه‌ها، این سیستم به یک ساختار توزیع شده پیچیده تبدیل شد که توانسته است در هزاران منطقه جغرافیایی، کاربران هفتگی بیش از یک میلیارد نفر را پشتیبانی کند. این روند نشان‌دهنده توانایی تیم توسعه در ایجاد یک زیرساخت مقیاس‌پذیر، مقاوم و کارآمد است که می‌تواند نیازهای روزافزون هوش مصنوعی و کاربردهای آن را برآورده سازد.
در نهایت، بیشترین تمرکز این پروژه بر ایجاد سیستمی است که نه تنها توان پاسخگویی به تعداد بی‌سابقه‌ای از کاربران را داشته باشد، بلکه این کار را با بهره‌گیری از بهترین فناوری‌های ممکن انجام دهد. این دستاورد نشان می‌دهد که چگونه نوآوری و بهره‌گیری از فناوری‌های پیشرفته می‌تواند زیرساخت‌های حیاتی را به سطح جدیدی برساند و آینده‌ی فناوری اطلاعات را شکل دهد.
#هوش_مصنوعی #ذخیره‌سازی_ابری #توسعه_مقیاس‌پذیر #پیشرو
🟣لینک مقاله:
https://openai.com/index/scaling-storage-one-billion-users-part-one?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Rapidly scaling online storage to serve over 1 billion ChatGPT users (13 minute read)
🟢 خلاصه مقاله:
در دنیای امروز، نیاز به ذخیره‌سازی ابری قوی و مقیاس‌پذیر برای پاسخگویی به حجم عظیم کاربران و درخواست‌هایشان اهمیت فزاینده‌ای پیدا کرده است. شرکت OpenAI، با توسعه پلتفرم ذخیره‌سازی Habitat، موفق شده است در کوتاه‌ترین زمان ممکن، زیرساختی قدرتمند و مقیاس‌پذیر برای بیش از یک میلیارد کاربر ChatGPT فراهم آورد. این پلتفرم، در حال حاضر بیش از ۷۰ میلیون درخواست در ثانیه را پردازش می‌کند و بیش از ۵۰۰ پتابایت داده را سرو می‌کند.
یکی از اقدامات مهم تیم این بود که سرویس را مجدداً بازنویسی کند، این بار با استفاده از زبان برنامه‌نویسی Rust. این تغییر، باعث شد سرویس در مصرف منابع بسیار بهینه‌تر عمل کند و کارایی آن به طور چشمگیری افزایش یابد؛ به طوری که Rust نسبت به نسخه قبلی پایتون، ۶ برابر در بهره‌وری CPU و ۱۵ برابر در مصرف حافظه بهتر عمل می‌کند. این بهبودها نه تنها سرعت و کارایی سیستم را بهبود بخشید، بلکه امکان توسعه و استقرار آن در مقیاس‌های بزرگ‌تر را نیز فراهم ساخت.
Habitat در ابتدا تنها به عنوان یک کتابخانه پایتون در رویداد DevDay 2023 معرفی شد و هدف آن پشتیبانی از مدل‌های GPT بود. اما با گذشت زمان و ادامه توسعه‌ها، این سیستم به یک ساختار توزیع شده پیچیده تبدیل شد که توانسته است در هزاران منطقه جغرافیایی، کاربران هفتگی بیش از یک میلیارد نفر را پشتیبانی کند. این روند نشان‌دهنده توانایی تیم توسعه در ایجاد یک زیرساخت مقیاس‌پذیر، مقاوم و کارآمد است که می‌تواند نیازهای روزافزون هوش مصنوعی و کاربردهای آن را برآورده سازد.
در نهایت، بیشترین تمرکز این پروژه بر ایجاد سیستمی است که نه تنها توان پاسخگویی به تعداد بی‌سابقه‌ای از کاربران را داشته باشد، بلکه این کار را با بهره‌گیری از بهترین فناوری‌های ممکن انجام دهد. این دستاورد نشان می‌دهد که چگونه نوآوری و بهره‌گیری از فناوری‌های پیشرفته می‌تواند زیرساخت‌های حیاتی را به سطح جدیدی برساند و آینده‌ی فناوری اطلاعات را شکل دهد.
#هوش_مصنوعی #ذخیره‌سازی_ابری #توسعه_مقیاس‌پذیر #پیشرو
🟣لینک مقاله:
https://openai.com/index/scaling-storage-one-billion-users-part-one?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
OpenAI
Rapidly scaling online storage to serve over 1 billion ChatGPT users
Learn how OpenAI evolved Habitat from a Python library into a globally distributed storage platform serving 1 billion ChatGPT users and 22M requests per second.
🔵 عنوان مقاله
Kubernetes v1.37: Scale Workloads to Zero with HorizontalPodAutoscaler (4 minute read)
🟢 خلاصه مقاله:
در نسخه ۱.۳۷ کبرنتیس، قابلیت خودکارسازی میزان نمونه‌های کاری (پادها) به صفر به عنوان یک ویژگی در حالت بتا قرار گرفته است که به طور پیش‌فرض فعال است. این امکان به کاربر اجازه می‌دهد که با استفاده از HorizontalPodAutoscaler، میزان نمونه‌های کاری را تا صفر کاهش دهد و در صورت نیاز، مجدداً آنها را بر اساس معیارهای داخلی یا خارجی، از نو راه‌اندازی کند. پیش از این، چنین قابلیتی فقط با افزودن افزونه‌ها یا فعال‌سازی حالت‌های آزمایشی امکان‌پذیر بود، اما حالا به صورت آماده و بدون نیاز به موارد اضافی در دسترس است.
این ویژگی برای مصرف‌کنندگان صف‌ها و پردازش‌های دسته‌ای کاربردی است، اما نیازمند حداقل یک معیار داخلی مانند معیارهای خارجی است، چرا که پس از عدم وجود نمونه پادها، معیارهای مربوط به CPU و حافظه دیگر قابل اندازه‌گیری نیستند. به طور کلی، این قابلیت امکان بهینه‌سازی منابع و صرفه‌جویی در مصرف منابع سروری را فراهم می‌کند و انعطاف بیشتری در مدیریت بارهای کاری فراهم می‌سازد.
با ارائه این امکان، مدیران سیستم می‌توانند بهره‌وری را افزایش دهند و هزینه‌های عملیاتی را کاهش دهند، زیرا زمانی که هیچ بار کاری وجود ندارد، سیستم به طور کامل خاموش می‌شود و مجدد در صورت نیاز، به صورت هوشمند فعال می‌شود. این تحول در نسخه ۱.۳۷، نشان‌دهنده تمرکز بر توسعه قابلیت‌های خودکار و بهبود مدیریت منابع در کبرنتیس است.
#کبرنتیس #خودکارسازی_پاد #مدیریت_منابع #سازماندهی_کارهای
🟣لینک مقاله:
https://kubernetes.io/blog/2026/09/02/kubernetes-v1-37-hpa-scale-to-zero-beta/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Kubernetes v1.37: Scale Workloads to Zero with HorizontalPodAutoscaler (4 minute read)
🟢 خلاصه مقاله:
در نسخه ۱.۳۷ کبرنتیس، قابلیت خودکارسازی میزان نمونه‌های کاری (پادها) به صفر به عنوان یک ویژگی در حالت بتا قرار گرفته است که به طور پیش‌فرض فعال است. این امکان به کاربر اجازه می‌دهد که با استفاده از HorizontalPodAutoscaler، میزان نمونه‌های کاری را تا صفر کاهش دهد و در صورت نیاز، مجدداً آنها را بر اساس معیارهای داخلی یا خارجی، از نو راه‌اندازی کند. پیش از این، چنین قابلیتی فقط با افزودن افزونه‌ها یا فعال‌سازی حالت‌های آزمایشی امکان‌پذیر بود، اما حالا به صورت آماده و بدون نیاز به موارد اضافی در دسترس است.
این ویژگی برای مصرف‌کنندگان صف‌ها و پردازش‌های دسته‌ای کاربردی است، اما نیازمند حداقل یک معیار داخلی مانند معیارهای خارجی است، چرا که پس از عدم وجود نمونه پادها، معیارهای مربوط به CPU و حافظه دیگر قابل اندازه‌گیری نیستند. به طور کلی، این قابلیت امکان بهینه‌سازی منابع و صرفه‌جویی در مصرف منابع سروری را فراهم می‌کند و انعطاف بیشتری در مدیریت بارهای کاری فراهم می‌سازد.
با ارائه این امکان، مدیران سیستم می‌توانند بهره‌وری را افزایش دهند و هزینه‌های عملیاتی را کاهش دهند، زیرا زمانی که هیچ بار کاری وجود ندارد، سیستم به طور کامل خاموش می‌شود و مجدد در صورت نیاز، به صورت هوشمند فعال می‌شود. این تحول در نسخه ۱.۳۷، نشان‌دهنده تمرکز بر توسعه قابلیت‌های خودکار و بهبود مدیریت منابع در کبرنتیس است.
#کبرنتیس #خودکارسازی_پاد #مدیریت_منابع #سازماندهی_کارهای
🟣لینک مقاله:
https://kubernetes.io/blog/2026/09/02/kubernetes-v1-37-hpa-scale-to-zero-beta/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Kubernetes
Kubernetes v1.37: Scale Workloads to Zero with HorizontalPodAutoscaler
Kubernetes v1.37 includes API support for horizontal autoscaling of workloads down to zero replicas. This feature is now Beta and enabled by default. A HorizontalPodAutoscaler (HPA) that uses a suitable object metric or external metric can now scale a workload…
🔵 عنوان مقاله
Stale data makes agents fail confidently (Sponsor)
🟢 خلاصه مقاله:
در دنیای فناوری‌های هوشمند، یکی از مشکلات رایج که بسیاری از عوامل هوشمند با آن مواجه هستند، اعتماد به داده‌های قدیمی است. وقتی داده‌ها کهنه می‌شوند، عوامل هوشمند می‌توانند تا حدی مطمئن به نظر برسند، اما در واقع تصمیمات نادرستی خواهند گرفت. این مسئله باعث می‌شود که سیستم‌ها به جای ارائه نتایج دقیق و قابل اعتماد، در انجام وظایف خود اشتباه کنند و در نتیجه، خطاهای مالی، اطلاعیه‌های ناپایدار و تصمیمات متناقض به وجود آیند.
برای جلوگیری از این مشکل، سیستم‌های هوشمند از یک موتور زمینه‌یابی (Context Engine) بهره می‌برند. این موتور، در لحظه تصمیم‌گیری، ارزش‌ها و اطلاعات بروز را محاسبه می‌کند و به عوامل هوشمند کمک می‌کند تا بر اساس داده‌های جدید و دقیق عمل کنند. در نتیجه، عوامل همواره در حالت به‌روز و قابل اعتماد کار می‌کنند و خطای ناشی از استفاده از اطلاعات کهنه کاهش می‌یابد.
در این مقاله، به‌طور کامل نشان می‌دهیم که چگونه چنین سامانه‌ای عمل می‌کند و نقش حیاتی آن در بهبود عملکرد عوامل هوشمند چیست. با پیروی از این روش، می‌توان اطمینان بیشتری در تصمیم‌گیری‌های مجازی داشت و از اعتماد به داده‌های ناکامل یا قدیمی جلوگیری کرد.
#هوشمندسازی #اطلاعات_درلحظه #عوامل_هوشمند #دقت_تصمیم‌گیری
🟣لینک مقاله:
https://chalk.ai/blog/what-is-a-context-engine?utm_source=tldr&utm_medium=referral&utm_campaign=2026-09-14_contextengineblog&utm_term=tldrdev
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Stale data makes agents fail confidently (Sponsor)
🟢 خلاصه مقاله:
در دنیای فناوری‌های هوشمند، یکی از مشکلات رایج که بسیاری از عوامل هوشمند با آن مواجه هستند، اعتماد به داده‌های قدیمی است. وقتی داده‌ها کهنه می‌شوند، عوامل هوشمند می‌توانند تا حدی مطمئن به نظر برسند، اما در واقع تصمیمات نادرستی خواهند گرفت. این مسئله باعث می‌شود که سیستم‌ها به جای ارائه نتایج دقیق و قابل اعتماد، در انجام وظایف خود اشتباه کنند و در نتیجه، خطاهای مالی، اطلاعیه‌های ناپایدار و تصمیمات متناقض به وجود آیند.
برای جلوگیری از این مشکل، سیستم‌های هوشمند از یک موتور زمینه‌یابی (Context Engine) بهره می‌برند. این موتور، در لحظه تصمیم‌گیری، ارزش‌ها و اطلاعات بروز را محاسبه می‌کند و به عوامل هوشمند کمک می‌کند تا بر اساس داده‌های جدید و دقیق عمل کنند. در نتیجه، عوامل همواره در حالت به‌روز و قابل اعتماد کار می‌کنند و خطای ناشی از استفاده از اطلاعات کهنه کاهش می‌یابد.
در این مقاله، به‌طور کامل نشان می‌دهیم که چگونه چنین سامانه‌ای عمل می‌کند و نقش حیاتی آن در بهبود عملکرد عوامل هوشمند چیست. با پیروی از این روش، می‌توان اطمینان بیشتری در تصمیم‌گیری‌های مجازی داشت و از اعتماد به داده‌های ناکامل یا قدیمی جلوگیری کرد.
#هوشمندسازی #اطلاعات_درلحظه #عوامل_هوشمند #دقت_تصمیم‌گیری
🟣لینک مقاله:
https://chalk.ai/blog/what-is-a-context-engine?utm_source=tldr&utm_medium=referral&utm_campaign=2026-09-14_contextengineblog&utm_term=tldrdev
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Chalk
What is a Context Engine? | Chalk
Looking for a feature store? A context engine is what the category becomes when the consumer is an agent: values computed at the request, not read from a table.
🔵 عنوان مقاله
How we could save petabytes of cache storage with Zstandard and Pingora (7 minute read)
🟢 خلاصه مقاله:
در دنیای فناوری اطلاعات، مدیریت حجم عظیم داده‌ها و صرفه‌جویی در فضای ذخیره‌سازی اهمیت زیادی دارد. یکی از چالش‌های عمده شرکت‌ها، نگهداری مجموعه‌های بزرگ کش است که تنها با صرف هزینه و منابع قابل توجهی صورت می‌گیرد. شرکت کلودفلئر به تازگی پلتفرمی مبتکرانه ارائه داده است که می‌تواند به طور قابل ملاحظه‌ای در کاهش حجم این داده‌ها کمک کند.
این سیستم، با نام «کَش ترنسکدینگ» (Cache Transcoding)، از الگوریتم Zstandard برای فشرده‌سازی عناصر کش استفاده می‌کند. به این صورت که قبل از نوشتن داده‌ها روی دیسک، آنها را به شکلی فشرده می‌کند که به طور متوسط حجم این داده‌ها را به یک سوم حد اولیه کاهش می‌دهد. این رویکرد ویژه برای محتوای متنی که قابلیت فشرده‌سازی دارد، مانند HTML، JSON، CSS و JavaScript طراحی شده است. در نمونه‌های ترافیکی شرکت، این نوع محتوا حدود 67.3 درصد از درخواست‌ها را تشکیل می‌داد، اما بیش از 71 درصد این درخواست‌ها بدون فشرده‌سازی ورود پیدا می‌کردند، که نشان‌دهنده وجود فرصت‌های عظیم برای کاهش حجم فایل‌ها است.
فرایند فشرده‌سازی در این سیستم در لحظه ورود هر دارایی به کش انجام می‌شود؛ یعنی هر داده‌ای که وارد کش می‌شود، در همان مرحله فشرده‌سازی شده و پس از آن در قالبی کم‌تر حجم، ذخیره می‌گردد. این روش باعث می‌شود نه تنها فضای ذخیره‌سازی به شدت کاهش یابد، بلکه فرآیند بازیابی و سرویس‌دهی به کاربران نیز سریع‌تر انجام شود، چون حجم داده‌ها کم‌تر است و در نتیجه انتقال آنها سریع‌تر صورت می‌پذیرد. این نوآوری می‌تواند در سطح جهانی منجر به صرفه‌جویی قابل توجه در زیرساخت‌های ابری و سرورهای محتوایی شود، و هزینه‌های عملیاتی را به شکل قابل توجهی کاهش دهد.
در کل، این فناوری جدید نشان دهنده توانایی بزرگی در بهینه‌سازی مدیریت داده‌ها است، و پتانسیل بالایی برای انقلابی کردن روش‌های ذخیره‌سازی و ارائه محتوا در فضای اینترنت دارد.
#فشرده‌سازی #ذخیره‌سازی_کَش #پیشرفت_فنّاوری #کلودفیلر
🟣لینک مقاله:
https://blog.cloudflare.com/cache-transcoding/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
How we could save petabytes of cache storage with Zstandard and Pingora (7 minute read)
🟢 خلاصه مقاله:
در دنیای فناوری اطلاعات، مدیریت حجم عظیم داده‌ها و صرفه‌جویی در فضای ذخیره‌سازی اهمیت زیادی دارد. یکی از چالش‌های عمده شرکت‌ها، نگهداری مجموعه‌های بزرگ کش است که تنها با صرف هزینه و منابع قابل توجهی صورت می‌گیرد. شرکت کلودفلئر به تازگی پلتفرمی مبتکرانه ارائه داده است که می‌تواند به طور قابل ملاحظه‌ای در کاهش حجم این داده‌ها کمک کند.
این سیستم، با نام «کَش ترنسکدینگ» (Cache Transcoding)، از الگوریتم Zstandard برای فشرده‌سازی عناصر کش استفاده می‌کند. به این صورت که قبل از نوشتن داده‌ها روی دیسک، آنها را به شکلی فشرده می‌کند که به طور متوسط حجم این داده‌ها را به یک سوم حد اولیه کاهش می‌دهد. این رویکرد ویژه برای محتوای متنی که قابلیت فشرده‌سازی دارد، مانند HTML، JSON، CSS و JavaScript طراحی شده است. در نمونه‌های ترافیکی شرکت، این نوع محتوا حدود 67.3 درصد از درخواست‌ها را تشکیل می‌داد، اما بیش از 71 درصد این درخواست‌ها بدون فشرده‌سازی ورود پیدا می‌کردند، که نشان‌دهنده وجود فرصت‌های عظیم برای کاهش حجم فایل‌ها است.
فرایند فشرده‌سازی در این سیستم در لحظه ورود هر دارایی به کش انجام می‌شود؛ یعنی هر داده‌ای که وارد کش می‌شود، در همان مرحله فشرده‌سازی شده و پس از آن در قالبی کم‌تر حجم، ذخیره می‌گردد. این روش باعث می‌شود نه تنها فضای ذخیره‌سازی به شدت کاهش یابد، بلکه فرآیند بازیابی و سرویس‌دهی به کاربران نیز سریع‌تر انجام شود، چون حجم داده‌ها کم‌تر است و در نتیجه انتقال آنها سریع‌تر صورت می‌پذیرد. این نوآوری می‌تواند در سطح جهانی منجر به صرفه‌جویی قابل توجه در زیرساخت‌های ابری و سرورهای محتوایی شود، و هزینه‌های عملیاتی را به شکل قابل توجهی کاهش دهد.
در کل، این فناوری جدید نشان دهنده توانایی بزرگی در بهینه‌سازی مدیریت داده‌ها است، و پتانسیل بالایی برای انقلابی کردن روش‌های ذخیره‌سازی و ارائه محتوا در فضای اینترنت دارد.
#فشرده‌سازی #ذخیره‌سازی_کَش #پیشرفت_فنّاوری #کلودفیلر
🟣لینک مقاله:
https://blog.cloudflare.com/cache-transcoding/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Cloudflare Blog
How we could save petabytes of cache storage with Zstandard and Pingora
Could we get more cache space with the same hardware? We prototyped compression inside Cloudflare's cache to find out.
🔵 عنوان مقاله
When code is abundant (31 minute read)
🟢 خلاصه مقاله:
در دنیای فناوری، تولید و توسعه کدهای برنامه‌نویسی روزبه‌روز افزایش می‌یابد و این روند تاثیر قابل توجهی بر اهمیت و نقش اجرای کد در فرآیندهای توسعه نرم‌افزار دارد. در این وضعیت، هوش مصنوعی نقش مهمی در تسهیل نوآوری و تسریع روند تولید کد ایفا می‌کند. اما علاوه بر جنبه‌های فنی، تحول مهمی در رویکردهای مدیریتی و ساختار سازمانی نیز در حال وقوع است؛ جایی که تمرکز از صرفاً اجرا و پیاده‌سازی کد، به سمت اعتماد و اطمینان‌بخشی نسبت به سیستم‌ها متمایل شده است.
با گسترش گسترده سیستم‌های هوشمند و عامل‌های هوشمند، مسئولیت مدیریت کامل چرخه عمر نرم‌افزار به عهده این عامل‌ها سپرده می‌شود و نقش انسان‌ها در این فرآیند‌ها تغییر یافته است. در این مسیر، سازمان‌ها نیازمند ساختارهای محکم و مستحکم هستند که بتوانند زمینه‌های لازم برای ایجاد اعتماد، صحت‌سنجی، نظارت، شواهد مستند و همچنین مالکیت سازمانی را در تمام سطوح و موارد مختلف فراهم کنند. این ساختارها باید بتوانند ارتباط و هماهنگی میان افراد، عامل‌ها و مدل‌های هوشمند را تضمین کنند و نقش‌های هر یک را به شیوه‌ای شفاف و قابل اعتماد تعریف کنند.
در نهایت، این تغییرات نشان می‌دهد که موفقیت در توسعه نرم‌افزارهای مبتنی بر هوش مصنوعی، نیازمند معماری‌های مقاوم و انعطاف‌پذیر است که بتوانند در کنار نوآوری‌های فنی، اعتماد و اطمینان سازمانی را نیز تقویت کنند. اهمیت این موضوع در آینده‌ای نه چندان دور، بیشتر خواهد شد و سازمان‌ها باید برای ایجاد چنین زیرساخت‌هایی برنامه‌ریزی و استراتژی‌های مناسبی طراحی کنند.
#هوش_مصنوعی #توسعه_نرم‌افزار #اعتماد #معماری_سازمانی
🟣لینک مقاله:
https://about.gitlab.com/blog/when-code-is-abundant/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
When code is abundant (31 minute read)
🟢 خلاصه مقاله:
در دنیای فناوری، تولید و توسعه کدهای برنامه‌نویسی روزبه‌روز افزایش می‌یابد و این روند تاثیر قابل توجهی بر اهمیت و نقش اجرای کد در فرآیندهای توسعه نرم‌افزار دارد. در این وضعیت، هوش مصنوعی نقش مهمی در تسهیل نوآوری و تسریع روند تولید کد ایفا می‌کند. اما علاوه بر جنبه‌های فنی، تحول مهمی در رویکردهای مدیریتی و ساختار سازمانی نیز در حال وقوع است؛ جایی که تمرکز از صرفاً اجرا و پیاده‌سازی کد، به سمت اعتماد و اطمینان‌بخشی نسبت به سیستم‌ها متمایل شده است.
با گسترش گسترده سیستم‌های هوشمند و عامل‌های هوشمند، مسئولیت مدیریت کامل چرخه عمر نرم‌افزار به عهده این عامل‌ها سپرده می‌شود و نقش انسان‌ها در این فرآیند‌ها تغییر یافته است. در این مسیر، سازمان‌ها نیازمند ساختارهای محکم و مستحکم هستند که بتوانند زمینه‌های لازم برای ایجاد اعتماد، صحت‌سنجی، نظارت، شواهد مستند و همچنین مالکیت سازمانی را در تمام سطوح و موارد مختلف فراهم کنند. این ساختارها باید بتوانند ارتباط و هماهنگی میان افراد، عامل‌ها و مدل‌های هوشمند را تضمین کنند و نقش‌های هر یک را به شیوه‌ای شفاف و قابل اعتماد تعریف کنند.
در نهایت، این تغییرات نشان می‌دهد که موفقیت در توسعه نرم‌افزارهای مبتنی بر هوش مصنوعی، نیازمند معماری‌های مقاوم و انعطاف‌پذیر است که بتوانند در کنار نوآوری‌های فنی، اعتماد و اطمینان سازمانی را نیز تقویت کنند. اهمیت این موضوع در آینده‌ای نه چندان دور، بیشتر خواهد شد و سازمان‌ها باید برای ایجاد چنین زیرساخت‌هایی برنامه‌ریزی و استراتژی‌های مناسبی طراحی کنند.
#هوش_مصنوعی #توسعه_نرم‌افزار #اعتماد #معماری_سازمانی
🟣لینک مقاله:
https://about.gitlab.com/blog/when-code-is-abundant/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitLab
When code is abundant
Producing code is getting cheap. Trusting it is not. Why enterprises need a durable layer of context, verification, and governance around AI agents.
Forwarded from Persian Post
امروز، ۲۶ شهریور، زادروز پسر کوروش بزرگه؛ روزی که به‌عنوان «روز پسر» نام‌گذاری شده.
🔵 عنوان مقاله
When is a cluster really full? Unlocking hidden capacity with the k8s-overcommit Operator
🟢 خلاصه مقاله:
در دنیای مدیریت منابع فناوری اطلاعات، یکی از چالش‌های همیشگی میزان به‌کارگیری و بهره‌برداری صحیح از سرورها و گره‌ها است. سوال همیشه این بوده است که چه زمانی یک خوشه یا کلاستر واقعاً پر شده است و دیگر ظرفیت قابل استفاده ندارد؟ بهره‌برداری بهینه از منابع، مخصوصاً در شرایطی که نیاز به انعطاف‌پذیری و افزایش کارایی است، اهمیت فراوانی دارد. راهکارهای نوینی مانند بهره‌برداری بیش‌ازحد (overcommit) برای پاسخ به این نیاز طراحی شده‌اند، که کمک می‌کنند تا ظرفیت‌های پنهان و زیرزمینی خوشه‌های Kubernetes کشف و بهره‌برداری شوند.
در این مقاله موردی، به نمونه‌ای واقعی از شرکت Inditex پرداخته شده است، شرکتی که با استفاده از یک اپراتور منبع‌باز برای overcommit، توانسته است ظرفیت‌های بی‌استفاده سرورهای خود را دوباره فعال کند. این اپراتور به وسیله یک وب‌هوک تغییر دهنده قالب‌هتل، درخواست‌های پادها را بر اساس کلاس اولویت بازنویسی می‌کند، بدین ترتیب می‌تواند میان منابع در حال استراحت و نیازهای فوری، تعادل برقرار کند و میزان بهره‌برداری از سرورها را بهینه سازد.
با پیاده‌سازی چنین رویکردی، شرکت‌هایی مانند Inditex توانسته‌اند بدون نیاز به خرید سرورهای جدید، بهره‌وری منابع زیرساخت‌های خود را افزایش دهند و هزینه‌های عملیاتی را کاهش دهند. این مطالعه نشان می‌دهد که چگونه فناوری‌های نوین در مدیریت منابع، به شرکت‌ها امکان می‌دهند تا به صورت هوشمندانه‌تری از منابع خود بهره‌مند شوند و در عین حال، پایداری و انعطاف‌پذیری سیستم‌های خود را حفظ کنند.
#کلاستر #مدیریتمنابع #کوبنیتیز #بازدهیاستفاده
🟣لینک مقاله:
https://ku.bz/XV3rLBhJr
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
When is a cluster really full? Unlocking hidden capacity with the k8s-overcommit Operator
🟢 خلاصه مقاله:
در دنیای مدیریت منابع فناوری اطلاعات، یکی از چالش‌های همیشگی میزان به‌کارگیری و بهره‌برداری صحیح از سرورها و گره‌ها است. سوال همیشه این بوده است که چه زمانی یک خوشه یا کلاستر واقعاً پر شده است و دیگر ظرفیت قابل استفاده ندارد؟ بهره‌برداری بهینه از منابع، مخصوصاً در شرایطی که نیاز به انعطاف‌پذیری و افزایش کارایی است، اهمیت فراوانی دارد. راهکارهای نوینی مانند بهره‌برداری بیش‌ازحد (overcommit) برای پاسخ به این نیاز طراحی شده‌اند، که کمک می‌کنند تا ظرفیت‌های پنهان و زیرزمینی خوشه‌های Kubernetes کشف و بهره‌برداری شوند.
در این مقاله موردی، به نمونه‌ای واقعی از شرکت Inditex پرداخته شده است، شرکتی که با استفاده از یک اپراتور منبع‌باز برای overcommit، توانسته است ظرفیت‌های بی‌استفاده سرورهای خود را دوباره فعال کند. این اپراتور به وسیله یک وب‌هوک تغییر دهنده قالب‌هتل، درخواست‌های پادها را بر اساس کلاس اولویت بازنویسی می‌کند، بدین ترتیب می‌تواند میان منابع در حال استراحت و نیازهای فوری، تعادل برقرار کند و میزان بهره‌برداری از سرورها را بهینه سازد.
با پیاده‌سازی چنین رویکردی، شرکت‌هایی مانند Inditex توانسته‌اند بدون نیاز به خرید سرورهای جدید، بهره‌وری منابع زیرساخت‌های خود را افزایش دهند و هزینه‌های عملیاتی را کاهش دهند. این مطالعه نشان می‌دهد که چگونه فناوری‌های نوین در مدیریت منابع، به شرکت‌ها امکان می‌دهند تا به صورت هوشمندانه‌تری از منابع خود بهره‌مند شوند و در عین حال، پایداری و انعطاف‌پذیری سیستم‌های خود را حفظ کنند.
#کلاستر #مدیریتمنابع #کوبنیتیز #بازدهیاستفاده
🟣لینک مقاله:
https://ku.bz/XV3rLBhJr
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
When is a cluster really full? Unlocking hidden capacity with the k8s-overcommit Operator
During 2025 high-demand period, Inditex k8s-overcommit Operator reduced microservices replicas by half without performance loss. Now, the…
🔵 عنوان مقاله
How Swiss Tables Work in Go's Built-in Map (28 minute read)
🟢 خلاصه مقاله:
در زبان برنامه‌نویسی Go، نسخه جدید ساختار نگهداری داده‌های نقشه (مپ) از طراحی مبتنی بر جدول سوئیس بهره می‌برد. این طراحی، ورودی‌ها را در بلوک‌های کوچک به همراه بایت‌های کنترل فشرده قرار می‌دهد، که این امر اجازه می‌دهد بسیاری از جایگاه‌های احتمالی برای ورود داده‌ها قبل از مقایسه کامل کلید‌ها بررسی شوند. این روش به ویژه در پردازشگرهای مدرن با قابلیت‌های SIMD مؤثر است، زیرا می‌توان چندین بایت کنترل را همزمان مقایسه کرد که سرعت جستجو را بسیار بالا می‌برد. علاوه بر این، چیدمان این ساختار و استراتژی توسعه آن به گونه‌ای طراحی شده است که در بهبود محلی‌سازی حافظه و کارایی جستجو نقش بسزایی دارد، و در نتیجه عملیات کار با مپ در برنامه‌های نویسنده به شکل قابل توجهی سریع‌تر انجام می‌گیرد.
مطمئناً، این فناوری نوآورانه در ساختار داخلی مپ در زبان Go، باعث بهبود چشمگیر در عملکرد برنامه‌ها می‌شود و توسعه‌دهندگان را قادر می‌سازد تا برنامه‌هایی با کارایی بالا و سرعت مناسب را پیاده‌سازی کنند. این پیشرفت‌ها نشان می‌دهد که تیم توسعه Go همواره در جستجوی راه‌حل‌های نوآورانه برای بهبود اثربخشی زبان و ابزارهای مربوطه است.
#برنامه‌نویسی #Go #ساختار داده #پرفورمنس
🟣لینک مقاله:
https://victoriametrics.com/blog/go-swiss-table-map/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
How Swiss Tables Work in Go's Built-in Map (28 minute read)
🟢 خلاصه مقاله:
در زبان برنامه‌نویسی Go، نسخه جدید ساختار نگهداری داده‌های نقشه (مپ) از طراحی مبتنی بر جدول سوئیس بهره می‌برد. این طراحی، ورودی‌ها را در بلوک‌های کوچک به همراه بایت‌های کنترل فشرده قرار می‌دهد، که این امر اجازه می‌دهد بسیاری از جایگاه‌های احتمالی برای ورود داده‌ها قبل از مقایسه کامل کلید‌ها بررسی شوند. این روش به ویژه در پردازشگرهای مدرن با قابلیت‌های SIMD مؤثر است، زیرا می‌توان چندین بایت کنترل را همزمان مقایسه کرد که سرعت جستجو را بسیار بالا می‌برد. علاوه بر این، چیدمان این ساختار و استراتژی توسعه آن به گونه‌ای طراحی شده است که در بهبود محلی‌سازی حافظه و کارایی جستجو نقش بسزایی دارد، و در نتیجه عملیات کار با مپ در برنامه‌های نویسنده به شکل قابل توجهی سریع‌تر انجام می‌گیرد.
مطمئناً، این فناوری نوآورانه در ساختار داخلی مپ در زبان Go، باعث بهبود چشمگیر در عملکرد برنامه‌ها می‌شود و توسعه‌دهندگان را قادر می‌سازد تا برنامه‌هایی با کارایی بالا و سرعت مناسب را پیاده‌سازی کنند. این پیشرفت‌ها نشان می‌دهد که تیم توسعه Go همواره در جستجوی راه‌حل‌های نوآورانه برای بهبود اثربخشی زبان و ابزارهای مربوطه است.
#برنامه‌نویسی #Go #ساختار داده #پرفورمنس
🟣لینک مقاله:
https://victoriametrics.com/blog/go-swiss-table-map/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
VictoriaMetrics
How Go’s Built-in Map Works with Swiss Tables
Go 1.24 replaced the built-in map’s bucket-based runtime with Swiss Tables. This article explains groups, control bytes, H1 and H2, probing, table growth, directories, deletion, load factor, and the experimental split-group layout.
🔵 عنوان مقاله
Kubernetes v1.36: Admission Policies That Can't Be Deleted
🟢 خلاصه مقاله:
در نسخه جدید اسکوب اومده است که سیاست‌های پذیرش (Admission Policies) در Kubernetes نسخه ۱.۳۶ دیگر قابلیت حذف ندارند. این تغییرات اهمیت زیادی در امنیت و کنترل ظرفیت‌های کلستر Kubernetes دارند، زیرا حالا این سیاست‌ها به عنوان بخشی حیاتی و غیر قابل تغییر سیستم تعریف شده‌اند. این سیاست‌ها نقش مهمی در تضمین صحت و امنیت عملیات در محیط‌های ابری دارند و مدیران دیگر نمی‌توانند آنها را به سادگی پاک یا ویرایش کنند، که این امر سطح بیشتری از محافظت و اطمینان در برابر تغییرات ناخواسته یا مخرب فراهم می‌کند.
در این نسخه، تیم توسعه‌دهندگان Kubernetes سعی کرده‌اند تا با این اصلاح، کنترل بیشتری روی محیط‌های تولید و پشتیبانی فراهم آورند و خطرات ناشی از حذف یا تغییر ناگهانی این سیاست‌ها را کاهش دهند. این تغییر به خصوص برای سازمان‌هایی که نیازمند سیاست‌های ثابت و کنترل‌شده برای امنیت و تطابق هستند، بسیار اهمیت دارد و می‌تواند نقش مؤثری در کاهش خطاهای انسانی و افزایش امن‌سازی ساختارهای ابری ایفا کند.
این ویژگی جدید، نشان می‌دهد که Kubernetes تمرکز بیشتری بر پایداری و امنیت کاربران دارد و ممکن است سیاست‌های غیر قابل حذف در آینده به عنوان استانداردی برای محیط‌های حساس و امنیتی معرفی شوند تا سیستم کاملا محافظت شده و قابل اعتماد باشد.
#Kubernetes #امنیت #فناوری_اطلاعات #مدیریت_کلستر
🟣لینک مقاله:
https://ku.bz/B9JxC5dVt
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Kubernetes v1.36: Admission Policies That Can't Be Deleted
🟢 خلاصه مقاله:
در نسخه جدید اسکوب اومده است که سیاست‌های پذیرش (Admission Policies) در Kubernetes نسخه ۱.۳۶ دیگر قابلیت حذف ندارند. این تغییرات اهمیت زیادی در امنیت و کنترل ظرفیت‌های کلستر Kubernetes دارند، زیرا حالا این سیاست‌ها به عنوان بخشی حیاتی و غیر قابل تغییر سیستم تعریف شده‌اند. این سیاست‌ها نقش مهمی در تضمین صحت و امنیت عملیات در محیط‌های ابری دارند و مدیران دیگر نمی‌توانند آنها را به سادگی پاک یا ویرایش کنند، که این امر سطح بیشتری از محافظت و اطمینان در برابر تغییرات ناخواسته یا مخرب فراهم می‌کند.
در این نسخه، تیم توسعه‌دهندگان Kubernetes سعی کرده‌اند تا با این اصلاح، کنترل بیشتری روی محیط‌های تولید و پشتیبانی فراهم آورند و خطرات ناشی از حذف یا تغییر ناگهانی این سیاست‌ها را کاهش دهند. این تغییر به خصوص برای سازمان‌هایی که نیازمند سیاست‌های ثابت و کنترل‌شده برای امنیت و تطابق هستند، بسیار اهمیت دارد و می‌تواند نقش مؤثری در کاهش خطاهای انسانی و افزایش امن‌سازی ساختارهای ابری ایفا کند.
این ویژگی جدید، نشان می‌دهد که Kubernetes تمرکز بیشتری بر پایداری و امنیت کاربران دارد و ممکن است سیاست‌های غیر قابل حذف در آینده به عنوان استانداردی برای محیط‌های حساس و امنیتی معرفی شوند تا سیستم کاملا محافظت شده و قابل اعتماد باشد.
#Kubernetes #امنیت #فناوری_اطلاعات #مدیریت_کلستر
🟣لینک مقاله:
https://ku.bz/B9JxC5dVt
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Kubernetes
Kubernetes v1.36: Admission Policies That Can't Be Deleted
If you've ever tried to enforce a security policy across a fleet of Kubernetes clusters, you've probably run into a frustrating chicken-and-egg problem. Your admission policies are API objects, which means they don't exist until someone creates them, and…
🔵 عنوان مقاله
How Netflix Simplified Batch Compute with Kueue
🟢 خلاصه مقاله:
نتفلیکس، سرویس استریمینگ معروف، در تلاش برای بهبود کارایی و سادگی فرآیندهای اجرایی خود، تصمیم گرفت سیستم مدیریت وظایف دسته‌ای خود را به‌روز کند. این شرکت بزرگ، میلیون‌ها وظیفه گروهی که قبلاً در سیستم انحصاری خود مدیریت می‌شد را جابه‌جا کرد و آنها را به سامانه جدیدی با نام کُیو منتقل کرد. نکته‌ی جالب این است که این انتقال به گونه‌ای انجام شد که کاربران و کسانی که وظایف را ثبت می‌کردند، هیچ تغییری در روند اجرای کارهای‌شان احساس نکردند.
برای نتفلیکس، این تغییر نه تنها به معنای ارتقاء زیرساخت بود، بلکه راهی مطمئن برای ساده‌سازی و بهبود بهره‌وری در پردازش وظایف دسته‌ای محسوب می‌شد. این شرکت توانست میلیون‌ها وظیفه را بدون توقف یا اختلال در سرویس‌های خود جابه‌جا کند، به‌طوری که تجربه کاربری همواره ثابت و بی‌وقفه باقی ماند. در واقع، با بهره‌گیری از سیستم کُیو، فرآیندهای داخل سازمان بسیار روان‌تر و یکپارچه‌تر شدند، و تیم‌های فناوری اطلاعات این شرکت توانستند مدیریت وظایف را به شکل موثرتری انجام دهند.
در نهایت، این استراتژی جدید نشان داد که چگونه می‌توان زیرساخت‌های پیچیده و قدیمی را به شیوه‌ای هوشمندانه و بدون اختلال در خدمات، به روزرسانی کرد. نتفلیکس با این حرکت نشان داد که استفاده از فناوری‌های نوین می‌تواند بهره‌وری را افزایش دهد و هزینه‌های عملیاتی را کاهش دهد، در حالی که کاربران نهایی هیچ تفاوتی در تجربه‌ی خود حس نمی‌کنند.
#نتفلیکس #کُیو #مدیریتوظایف #تکنولوژیپایدار
🟣لینک مقاله:
https://ku.bz/3WtH2Fml9
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
How Netflix Simplified Batch Compute with Kueue
🟢 خلاصه مقاله:
نتفلیکس، سرویس استریمینگ معروف، در تلاش برای بهبود کارایی و سادگی فرآیندهای اجرایی خود، تصمیم گرفت سیستم مدیریت وظایف دسته‌ای خود را به‌روز کند. این شرکت بزرگ، میلیون‌ها وظیفه گروهی که قبلاً در سیستم انحصاری خود مدیریت می‌شد را جابه‌جا کرد و آنها را به سامانه جدیدی با نام کُیو منتقل کرد. نکته‌ی جالب این است که این انتقال به گونه‌ای انجام شد که کاربران و کسانی که وظایف را ثبت می‌کردند، هیچ تغییری در روند اجرای کارهای‌شان احساس نکردند.
برای نتفلیکس، این تغییر نه تنها به معنای ارتقاء زیرساخت بود، بلکه راهی مطمئن برای ساده‌سازی و بهبود بهره‌وری در پردازش وظایف دسته‌ای محسوب می‌شد. این شرکت توانست میلیون‌ها وظیفه را بدون توقف یا اختلال در سرویس‌های خود جابه‌جا کند، به‌طوری که تجربه کاربری همواره ثابت و بی‌وقفه باقی ماند. در واقع، با بهره‌گیری از سیستم کُیو، فرآیندهای داخل سازمان بسیار روان‌تر و یکپارچه‌تر شدند، و تیم‌های فناوری اطلاعات این شرکت توانستند مدیریت وظایف را به شکل موثرتری انجام دهند.
در نهایت، این استراتژی جدید نشان داد که چگونه می‌توان زیرساخت‌های پیچیده و قدیمی را به شیوه‌ای هوشمندانه و بدون اختلال در خدمات، به روزرسانی کرد. نتفلیکس با این حرکت نشان داد که استفاده از فناوری‌های نوین می‌تواند بهره‌وری را افزایش دهد و هزینه‌های عملیاتی را کاهش دهد، در حالی که کاربران نهایی هیچ تفاوتی در تجربه‌ی خود حس نمی‌کنند.
#نتفلیکس #کُیو #مدیریتوظایف #تکنولوژیپایدار
🟣لینک مقاله:
https://ku.bz/3WtH2Fml9
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
How Netflix Simplified Batch Compute with Kueue
By Alvin Bao, Alex Petrov, Jennifer Lai, Aidan Sherr, and Samartha Chandrashekar
🔵 عنوان مقاله
AWS EKS Vulnerability
🟢 خلاصه مقاله:
در دنیای فناوری‌های ابری، امنیت همواره یکی از بزرگ‌ترین چالش‌ها برای شرکت‌ها و توسعه‌دهندگان است. اخیراً، با کشف یک آسیب‌پذیری در سرویس Amazon Elastic Kubernetes Service (EKS)، نگرانی‌هایی در مورد امنیت زیرساخت‌های مبتنی بر کلاود افزایش یافته است. این آسیب‌پذیری می‌تواند راه را برای حملات مخرب و سوءاستفاده‌های احتمالی هموار کند؛ بنابراین، شناخت و رفع سریع آن اهمیت فراوانی دارد.
این مشکل امنیتی در سطح سرویس EKS، به کاربران اجازه می‌دهد تا از طریق برخی روش‌ها، کنترل خود را بر کل کلاسترهای کبرنتس به خطر بیندازند. با توجه به گستردگی استفاده از این سرویس در پروژه‌های بزرگ و کوچک، اطلاع‌رسانی سریع و اقدام به‌موقع برای کاهش ریسک‌ها اهمیت ویژه‌ای پیدا می‌کند. تیم‌های فنی توصیه می‌کنند که صاحبان حساب‌های EKS هر چه زودتر آپدیت‌های لازم را نصب و تنظیمات امنیتی خود را بازبینی کنند تا در برابر احتمال حملات محافظت شوند.
در نتیجه، بررسی و برطرف کردن این آسیب‌پذیری نه تنها ایمنی پروژه‌های جاری را تضمین می‌کند بلکه اعتماد کاربران و مشتریان را نیز حفظ می‌نماید. با آگاهی رسانی به تیم‌های مرتبط و اجرای بهترین شیوه‌های امنیتی، می‌توان سطح حفاظت سامانه‌های مبتنی بر Kubernetes در فضای ابری را بالا برد. حفاظت از داده‌ها و کاهش خطر حمله، هدفی است که تمامی فعالان این حوزه باید در راستای آن گام بردارند.
#امنیت_ابری #حفاظت_کلاود #آسیب‌پذیری_امنیتی #AWS
🟣لینک مقاله:
https://ku.bz/DXYZGjvf2
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
AWS EKS Vulnerability
🟢 خلاصه مقاله:
در دنیای فناوری‌های ابری، امنیت همواره یکی از بزرگ‌ترین چالش‌ها برای شرکت‌ها و توسعه‌دهندگان است. اخیراً، با کشف یک آسیب‌پذیری در سرویس Amazon Elastic Kubernetes Service (EKS)، نگرانی‌هایی در مورد امنیت زیرساخت‌های مبتنی بر کلاود افزایش یافته است. این آسیب‌پذیری می‌تواند راه را برای حملات مخرب و سوءاستفاده‌های احتمالی هموار کند؛ بنابراین، شناخت و رفع سریع آن اهمیت فراوانی دارد.
این مشکل امنیتی در سطح سرویس EKS، به کاربران اجازه می‌دهد تا از طریق برخی روش‌ها، کنترل خود را بر کل کلاسترهای کبرنتس به خطر بیندازند. با توجه به گستردگی استفاده از این سرویس در پروژه‌های بزرگ و کوچک، اطلاع‌رسانی سریع و اقدام به‌موقع برای کاهش ریسک‌ها اهمیت ویژه‌ای پیدا می‌کند. تیم‌های فنی توصیه می‌کنند که صاحبان حساب‌های EKS هر چه زودتر آپدیت‌های لازم را نصب و تنظیمات امنیتی خود را بازبینی کنند تا در برابر احتمال حملات محافظت شوند.
در نتیجه، بررسی و برطرف کردن این آسیب‌پذیری نه تنها ایمنی پروژه‌های جاری را تضمین می‌کند بلکه اعتماد کاربران و مشتریان را نیز حفظ می‌نماید. با آگاهی رسانی به تیم‌های مرتبط و اجرای بهترین شیوه‌های امنیتی، می‌توان سطح حفاظت سامانه‌های مبتنی بر Kubernetes در فضای ابری را بالا برد. حفاظت از داده‌ها و کاهش خطر حمله، هدفی است که تمامی فعالان این حوزه باید در راستای آن گام بردارند.
#امنیت_ابری #حفاظت_کلاود #آسیب‌پذیری_امنیتی #AWS
🟣لینک مقاله:
https://ku.bz/DXYZGjvf2
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
wcarlsen.github.io
AWS EKS vulnerability - wcarlsen's blog
My personal blog
🔵 عنوان مقاله
Finding a Race Condition in Kuberenetes — Like a Detective
🟢 خلاصه مقاله:
در این مقاله، به یک مورد واقعی از اشکال در سیستم کوبرنتیس پرداخته می‌شود که باعث بروز مشکل در فرآیندهای استقرار و بروزرسانی شد. در این مورد، پادهای ارورده و بی‌سرپرست کوبرنتیس به صورت مداوم مانع اجرای نسخه‌های جدید برنامه شدند. این مشکل ناشی از یک رقابت یا race condition بود که بین کنترلر وظایف، جمع‌آوری‌کننده سطل زباله و یک سیاست propagation پیش‌فرض و غیرمستندس‌شده در هسته سیستم اتفاق افتاده بود.
در ادامه، مراحل تحلیل و عیب‌یابی این مشکل شرح داده می‌شود، جایی که تیم فنی با دقت بالا به بررسی روندهای همزمانی و علت تداخل پرداخته و سرانجام راه‌حلی موثر برای رفع مشکل ارائه دادند. این مطالعه نشان می‌دهد که چگونه در محیط‌های پیچیده، درک عمیق از نحوه تعامل اجزا نقش حیاتی در حل مشکلات ارتباطی و رقابتی سیستم ایفا می‌کند و اهمیت مانیتورینگ، لاگ‌گیری دقیق و آگاهی کامل از رفتارهای داخلی ابزارهای عملیاتی را برجسته می‌سازد.
در نتیجه، این مطالعه به مدیران و توسعه‌دهندگان نشان می‌دهد که چگونه با ردیابی و تحلیل رفتارهای همزمان در محیط کوبرنتیس، می‌توان خطاهای نوع race condition را شناسایی و برطرف کرد و سیستم‌های پایدارتر و امن‌تری را راه‌اندازی نمود.
#کوبریشن #اشکال_پیشرفته #رقابت_در_سیستم #مدیریت_پروسه
🟣لینک مقاله:
https://ku.bz/NmswYT7Zd
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Finding a Race Condition in Kuberenetes — Like a Detective
🟢 خلاصه مقاله:
در این مقاله، به یک مورد واقعی از اشکال در سیستم کوبرنتیس پرداخته می‌شود که باعث بروز مشکل در فرآیندهای استقرار و بروزرسانی شد. در این مورد، پادهای ارورده و بی‌سرپرست کوبرنتیس به صورت مداوم مانع اجرای نسخه‌های جدید برنامه شدند. این مشکل ناشی از یک رقابت یا race condition بود که بین کنترلر وظایف، جمع‌آوری‌کننده سطل زباله و یک سیاست propagation پیش‌فرض و غیرمستندس‌شده در هسته سیستم اتفاق افتاده بود.
در ادامه، مراحل تحلیل و عیب‌یابی این مشکل شرح داده می‌شود، جایی که تیم فنی با دقت بالا به بررسی روندهای همزمانی و علت تداخل پرداخته و سرانجام راه‌حلی موثر برای رفع مشکل ارائه دادند. این مطالعه نشان می‌دهد که چگونه در محیط‌های پیچیده، درک عمیق از نحوه تعامل اجزا نقش حیاتی در حل مشکلات ارتباطی و رقابتی سیستم ایفا می‌کند و اهمیت مانیتورینگ، لاگ‌گیری دقیق و آگاهی کامل از رفتارهای داخلی ابزارهای عملیاتی را برجسته می‌سازد.
در نتیجه، این مطالعه به مدیران و توسعه‌دهندگان نشان می‌دهد که چگونه با ردیابی و تحلیل رفتارهای همزمان در محیط کوبرنتیس، می‌توان خطاهای نوع race condition را شناسایی و برطرف کرد و سیستم‌های پایدارتر و امن‌تری را راه‌اندازی نمود.
#کوبریشن #اشکال_پیشرفته #رقابت_در_سیستم #مدیریت_پروسه
🟣لینک مقاله:
https://ku.bz/NmswYT7Zd
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
Finding a Race Condition in Kuberenetes — Like a Detective
During a project I working on I encountered an unusual problem: Orphaned pods would appear in the cluster throughout the day. These pods…
🔵 عنوان مقاله
Let's not water down the terms Continuous Integration and Continuous Delivery (5 minute read)
🟢 خلاصه مقاله:
یک نکته مهم در عصر فناوری اطلاعات این است که مفاهیم کلیدی نظیر "یکپارچه‌سازی پیوسته" و "تحویل پیوسته" باید به دقت شناخته شوند و از ابهام زدایی آنها اطمینان حاصل گردد. در مقاله‌ای که در ادامه می‌آید، توضیح داده می‌شود که "یکپارچه‌سازی پیوسته" به معنای ادغام کلیه تغییرات در مسیر اصلی پروژه حداقل روزانه است. این رویکرد کمک می‌کند تیم‌های توسعه بتوانند خطاها را سریع‌تر شناسایی و رفع کنند و در نتیجه روند توسعه نرم‌افزار به سمت استحکام و پایداری هدایت می‌شود.
از سوی دیگر، "تحویل پیوسته" یعنی حفظ قابلیت استقرار و راه‌اندازی نرم‌افزار در هر زمانی. این هدف با استفاده از خطوط لوله‌های اتوماسیون شده و فرآیندهای منظم پیاده‌سازی، به‌طور مداوم تضمین می‌شود. چنین رویکردی به تیم‌ها امکان می‌دهد تا سریع‌تر و با اطمینان بیشتری تغییرات را عرضه کرده و نیازهای کاربران را برآورده سازند.
نویسنده معتقد است هر دو اصطلاح دقیقا تعریف شده و مستندات معتبر دارند، نه مبهم و نامعلوم، برعکس مفاهیمی مانند "رویکرد چابک" و "دراپ‌آند در عملیات" که در طول زمان دچار ابهام و سوءتفاهم شده‌اند. او هشدار می‌دهد که نباید معنای این اصطلاحات مهم و حیاتی دچار تضعیف و مخدوش شود، چرا که درک صحیح و دقیق آنها کلید پیشرفت و بهره‌وری در توسعه نرم‌افزار است.
در نتیجه، باید مراقب باشیم که مفاهیم پایه‌ای فناوری را با رویکردهای سطحی و مبهم مخدوش نکنیم، و همواره بر دقت و شفافیت در اجرای آنها تأکید کنیم تا بتوانیم مسیر توسعه مستحکم و مطمئنی را پیش ببریم.
#توسعه_نرم‌افزار #یکپارچه‌سازی_پیوسته #تحویل_پیوسته #فناوری
🟣لینک مقاله:
https://octopus.com/blog/watering-down-ci-cd?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Let's not water down the terms Continuous Integration and Continuous Delivery (5 minute read)
🟢 خلاصه مقاله:
یک نکته مهم در عصر فناوری اطلاعات این است که مفاهیم کلیدی نظیر "یکپارچه‌سازی پیوسته" و "تحویل پیوسته" باید به دقت شناخته شوند و از ابهام زدایی آنها اطمینان حاصل گردد. در مقاله‌ای که در ادامه می‌آید، توضیح داده می‌شود که "یکپارچه‌سازی پیوسته" به معنای ادغام کلیه تغییرات در مسیر اصلی پروژه حداقل روزانه است. این رویکرد کمک می‌کند تیم‌های توسعه بتوانند خطاها را سریع‌تر شناسایی و رفع کنند و در نتیجه روند توسعه نرم‌افزار به سمت استحکام و پایداری هدایت می‌شود.
از سوی دیگر، "تحویل پیوسته" یعنی حفظ قابلیت استقرار و راه‌اندازی نرم‌افزار در هر زمانی. این هدف با استفاده از خطوط لوله‌های اتوماسیون شده و فرآیندهای منظم پیاده‌سازی، به‌طور مداوم تضمین می‌شود. چنین رویکردی به تیم‌ها امکان می‌دهد تا سریع‌تر و با اطمینان بیشتری تغییرات را عرضه کرده و نیازهای کاربران را برآورده سازند.
نویسنده معتقد است هر دو اصطلاح دقیقا تعریف شده و مستندات معتبر دارند، نه مبهم و نامعلوم، برعکس مفاهیمی مانند "رویکرد چابک" و "دراپ‌آند در عملیات" که در طول زمان دچار ابهام و سوءتفاهم شده‌اند. او هشدار می‌دهد که نباید معنای این اصطلاحات مهم و حیاتی دچار تضعیف و مخدوش شود، چرا که درک صحیح و دقیق آنها کلید پیشرفت و بهره‌وری در توسعه نرم‌افزار است.
در نتیجه، باید مراقب باشیم که مفاهیم پایه‌ای فناوری را با رویکردهای سطحی و مبهم مخدوش نکنیم، و همواره بر دقت و شفافیت در اجرای آنها تأکید کنیم تا بتوانیم مسیر توسعه مستحکم و مطمئنی را پیش ببریم.
#توسعه_نرم‌افزار #یکپارچه‌سازی_پیوسته #تحویل_پیوسته #فناوری
🟣لینک مقاله:
https://octopus.com/blog/watering-down-ci-cd?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Octopus
Let's not water down the terms Continuous Integration and Continuous Delivery
Find out why CI/CD aren't vague buzzwords. Here's what Continuous Integration and Continuous Delivery actually mean, and the common misconceptions worth correcting
🔵 عنوان مقاله
Kubernetes AuthN the Hard Way
🟢 خلاصه مقاله:
در این راهنما، نحوه اتصال سیستم احراز هویت کبرنتیس به سرویس LDAP از طریق Dex و پروتکل OIDC به دقت توضیح داده شده است. این فرآیند شامل تنظیم گواهینامه‌ها، راه‌اندازی OpenLDAP، پیکربندی Dex با استفاده از Helm، اعتمادسازی سرور API، نحوه بررسی ادعاهای توکن و همچنین نقشه‌برداری گروه‌های RBAC است. هدف این آموزش، فراهم کردن یک مسیر مطمئن و قابل انعطاف برای مدیریت دسترسی‌ها در کبرنتیس است، به طوری که بتوان نقش‌ها و گروه‌های مختلف را به طور مؤثر کنترل و مدیریت کرد.
در این راه، نحوه تنظیم گواهینامه‌ها و امنیت ارتباطات بین اجزا مختلف، نقش کلیدی دارد. سپس، با راه‌اندازی سرویس OpenLDAP، یک پایگاه داده کاربری مرکزی ایجاد می‌شود که تمامی اطلاعات هویتی کاربران در آن ثبت می‌شود. پس از آن، با استفاده از Helm، پکیج Dex نصب و پیکربندی می‌شود تا بتواند به عنوان میان‌افزار بین کبرنتیس و سرویس LDAP عمل کند. این مرحله اهمیت زیادی دارد، چون نقش Dex در تبدیل اطلاعات هویتی LDAP به توکن‌های OIDC و فراهم کردن یک لایه امنیتی است.
همچنین، تنظیمات مربوط به اعتماد سرور API و نحوه بررسی دقیق ادعاهای توکن، از موارد حیاتی در این فرآیند است. در نهایت، با نقشه‌برداری گروه‌های RBAC، مدیران می‌توانند سطوح دسترسی مختلف را بر اساس گروه‌های تعریف شده به راحتی کنترل کنند و امنیت سیستم را تضمین نمایند. این آموزش، یک مسیر جامع است برای توسعه‌دهندگانی که می‌خواهند سامانه‌های احراز هویت کبرنتیس را به صورت امن و مقیاس‌پذیر پیاده‌سازی کنند.
#کبرنتیس #احراز_هویت #LDAP #امنیت
🟣لینک مقاله:
https://ku.bz/nN1m_5FXK
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Kubernetes AuthN the Hard Way
🟢 خلاصه مقاله:
در این راهنما، نحوه اتصال سیستم احراز هویت کبرنتیس به سرویس LDAP از طریق Dex و پروتکل OIDC به دقت توضیح داده شده است. این فرآیند شامل تنظیم گواهینامه‌ها، راه‌اندازی OpenLDAP، پیکربندی Dex با استفاده از Helm، اعتمادسازی سرور API، نحوه بررسی ادعاهای توکن و همچنین نقشه‌برداری گروه‌های RBAC است. هدف این آموزش، فراهم کردن یک مسیر مطمئن و قابل انعطاف برای مدیریت دسترسی‌ها در کبرنتیس است، به طوری که بتوان نقش‌ها و گروه‌های مختلف را به طور مؤثر کنترل و مدیریت کرد.
در این راه، نحوه تنظیم گواهینامه‌ها و امنیت ارتباطات بین اجزا مختلف، نقش کلیدی دارد. سپس، با راه‌اندازی سرویس OpenLDAP، یک پایگاه داده کاربری مرکزی ایجاد می‌شود که تمامی اطلاعات هویتی کاربران در آن ثبت می‌شود. پس از آن، با استفاده از Helm، پکیج Dex نصب و پیکربندی می‌شود تا بتواند به عنوان میان‌افزار بین کبرنتیس و سرویس LDAP عمل کند. این مرحله اهمیت زیادی دارد، چون نقش Dex در تبدیل اطلاعات هویتی LDAP به توکن‌های OIDC و فراهم کردن یک لایه امنیتی است.
همچنین، تنظیمات مربوط به اعتماد سرور API و نحوه بررسی دقیق ادعاهای توکن، از موارد حیاتی در این فرآیند است. در نهایت، با نقشه‌برداری گروه‌های RBAC، مدیران می‌توانند سطوح دسترسی مختلف را بر اساس گروه‌های تعریف شده به راحتی کنترل کنند و امنیت سیستم را تضمین نمایند. این آموزش، یک مسیر جامع است برای توسعه‌دهندگانی که می‌خواهند سامانه‌های احراز هویت کبرنتیس را به صورت امن و مقیاس‌پذیر پیاده‌سازی کنند.
#کبرنتیس #احراز_هویت #LDAP #امنیت
🟣لینک مقاله:
https://ku.bz/nN1m_5FXK
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
Kubernetes AuthN the Hard Way
Bridging Enterprise LDAP and OIDC with Dex
🔵 عنوان مقاله
Sveltos ClusterPromotion: Progressive Rollouts and the mistake that made the architecture better
🟢 خلاصه مقاله:
در دنیای فناوری‌های نوین، مدیریت و توسعه برنامه‌های بزرگ و پیچیده همواره چالش‌برانگیز است. یکی از راهکارهای مؤثر در این زمینه، استفاده از رویکردهای تدریجی و مرحله‌ای در بهره‌برداری از آپدیت‌ها و قابلیت‌های جدید است. این استراتژی نه تنها امکان ارزیابی دقیق‌تر و کاهش خطاهای احتمالی را فراهم می‌کند، بلکه به تیم‌های فنی فرصت می‌دهد تا بر اساس بازخوردهای واقعی، بهبودهای لازم را در ساختار و معماری سیستم انجام دهند.
در همین راستا، مفهوم “ترویج مجموعه‌سلسله‌ای سولتوس” (Sveltos ClusterPromotion) به عنوان رویکردی پیشرفته مطرح شده است. این روش به گونه‌ای طراحی شده است که انتشار ویژگی‌های جدید در مجموعه‌های مختلف به صورت مرحله‌ای و کنترل‌شده صورت گیرد. با این شیوه، تیم‌های توسعه می‌توانند تغییرات را به صورت تدریجی اعمال کرده و بر اساس نتایج، اصلاحات لازم را انجام دهند.
یکی از بزرگ‌ترین اشتباهاتی که در فرآیندهای توسعه و استقرار فناوری رخ داد، عدم توجه کافی به آزمون‌های مرحله‌ای و کلی‌نگری در طراحی اولیه بود. این اشتباه، در عین حال، یک فرصت بی‌نظیر برای بهبود ساختار و معماری زیرساخت‌ها فراهم کرد. کارکردن در قالب این رویکرد، به تیم‌ها کمک کرد تا خطاهای سیستماتیک را شناسایی و اصلاح کنند و از این طریق، معماری پایدارتری بنا نهادند که انعطاف‌پذیرتر و مقیاس‌پذیرتر است.
در نتیجه، ما شاهد آن هستیم که اشتباهات اولیه و مواجهه با چالش‌ها، نه تنها به شکست منجر نشد، بلکه باعث شد معماری و ساختار سیستم به سطح بالاتری از کیفیت و پایداری برسد. این تجربه ارزشمند، نشان می‌دهد که رویکردهای مرحله‌ای و انعطاف‌پذیر در توسعه فناوری، کلید موفقیت در پروژه‌های بزرگ و پیچیده هستند.
#توسعه_نرم‌افزار #معماری_سازمانی #روندهای_تدریجی #بهبود_پایدار
🟣لینک مقاله:
https://ku.bz/sJZhQf25J
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Sveltos ClusterPromotion: Progressive Rollouts and the mistake that made the architecture better
🟢 خلاصه مقاله:
در دنیای فناوری‌های نوین، مدیریت و توسعه برنامه‌های بزرگ و پیچیده همواره چالش‌برانگیز است. یکی از راهکارهای مؤثر در این زمینه، استفاده از رویکردهای تدریجی و مرحله‌ای در بهره‌برداری از آپدیت‌ها و قابلیت‌های جدید است. این استراتژی نه تنها امکان ارزیابی دقیق‌تر و کاهش خطاهای احتمالی را فراهم می‌کند، بلکه به تیم‌های فنی فرصت می‌دهد تا بر اساس بازخوردهای واقعی، بهبودهای لازم را در ساختار و معماری سیستم انجام دهند.
در همین راستا، مفهوم “ترویج مجموعه‌سلسله‌ای سولتوس” (Sveltos ClusterPromotion) به عنوان رویکردی پیشرفته مطرح شده است. این روش به گونه‌ای طراحی شده است که انتشار ویژگی‌های جدید در مجموعه‌های مختلف به صورت مرحله‌ای و کنترل‌شده صورت گیرد. با این شیوه، تیم‌های توسعه می‌توانند تغییرات را به صورت تدریجی اعمال کرده و بر اساس نتایج، اصلاحات لازم را انجام دهند.
یکی از بزرگ‌ترین اشتباهاتی که در فرآیندهای توسعه و استقرار فناوری رخ داد، عدم توجه کافی به آزمون‌های مرحله‌ای و کلی‌نگری در طراحی اولیه بود. این اشتباه، در عین حال، یک فرصت بی‌نظیر برای بهبود ساختار و معماری زیرساخت‌ها فراهم کرد. کارکردن در قالب این رویکرد، به تیم‌ها کمک کرد تا خطاهای سیستماتیک را شناسایی و اصلاح کنند و از این طریق، معماری پایدارتری بنا نهادند که انعطاف‌پذیرتر و مقیاس‌پذیرتر است.
در نتیجه، ما شاهد آن هستیم که اشتباهات اولیه و مواجهه با چالش‌ها، نه تنها به شکست منجر نشد، بلکه باعث شد معماری و ساختار سیستم به سطح بالاتری از کیفیت و پایداری برسد. این تجربه ارزشمند، نشان می‌دهد که رویکردهای مرحله‌ای و انعطاف‌پذیر در توسعه فناوری، کلید موفقیت در پروژه‌های بزرگ و پیچیده هستند.
#توسعه_نرم‌افزار #معماری_سازمانی #روندهای_تدریجی #بهبود_پایدار
🟣لینک مقاله:
https://ku.bz/sJZhQf25J
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
Sveltos ClusterPromotion | Progressive Rollouts and the mistake that made the architecture better
Part 1 was about getting the tools running. Three clusters locally, Sveltos deploying across them, ArgoCD keeping everything in sync with…