🔵 عنوان مقاله
Kubernetes Headaches: Unsticking StatefulSets from EBS ReadWriteMany Drama

🟢 خلاصه مقاله:
با اجرای سرویس‌های دارای حالت روی Kubernetes، خیلی زود محدودیت اصلی نمایان می‌شود: EBS در AWS برای ReadWriteMany طراحی نشده و همین باعث گیرکردن StatefulSetها، Pending شدن پادها و مشکل در اتصال ولوم‌ها بین نودها می‌شود. راه‌حل‌ها سه مسیر اصلی دارند: یا ماهیت ReadWriteOnce را بپذیرید و هر replica را در همان AZ و کنار EBS خودش نگه دارید (با تنظیمات topology و ReadWriteOncePod)، یا به یک RWX واقعی مهاجرت کنید (EFS با EFS CSI و Access Pointها، یا سیستم‌های توزیع‌شده مانند Rook Ceph/Longhorn/OpenEBS)، یا معماری برنامه را طوری بازطراحی کنید که نیاز به RWX از بین برود (sharding، استفاده از S3 برای blobها، و stream کردن WAL/backup).
برای مهاجرت امن: از VolumeSnapshot یا Jobهای کپی داده (rsync) بین PVCهای قدیم (EBS) و جدید (EFS/RWX) استفاده کنید، StatefulSet را به‌صورت ترتیبی scale down کنید، persistentVolumeClaimRetentionPolicy را برای حفظ PVCها تنظیم کنید، StorageClass را در volumeClaimTemplates عوض کنید و سپس به‌تدریج scale up کنید. رعایت PDB، readiness، fsGroup، و IRSA برای درایورهای CSI حیاتی است و باید قبل از سوییچ نهایی، کارایی و برگشت‌پذیری را با fio و پشتیبان‌گیری (Velero/اسنپ‌شات‌ها) تست کرد. به‌طور خلاصه: یا با EBS و تک‌نویسنده کنار بیایید، یا به EFS/ذخیره‌سازی توزیع‌شده بروید؛ تلاش برای RWX با EBS معمولاً فقط مشکل را عقب می‌اندازد.

#Kubernetes #StatefulSet #EBS #EFS #RWX #CSI #AWS #CloudStorage

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
topolvm: capacity-aware CSI

🟢 خلاصه مقاله:
TopoLVM یک درایور CSI برای Kubernetes است که با استفاده از LVM روی Linux، دیسک‌های محلی هر نود را به PersistentVolumeهای پویا و قابل اطمینان تبدیل می‌کند. ویژگی اصلی آن «آگاه از ظرفیت» بودن است؛ یعنی ظرفیت آزاد واقعی هر نود را می‌شناسد و آن را به Scheduler اعلام می‌کند تا Podهایی که PVC دارند فقط روی نودهایی زمان‌بندی شوند که واقعا توان تامین آن حجم را دارند. این رویکرد از حلقه‌های شکست در زمان‌بندی و خطاهای دیرهنگام Provisioning جلوگیری می‌کند.

TopoLVM معمولا شامل یک Controller، یک Node Plugin و مولفه سبک lvmd روی هر نود است. StorageClassها می‌توانند به Volume Groupها یا Device Classهای متفاوت نگاشت شوند تا لایه‌های کارایی مختلف ارائه شود. پشتیبانی از حجم‌های فایل‌سیستمی و Block، توسعه حجم (در صورت پشتیبانی Kubernetes)، و تنظیمات Thin/Thick provisioning در LVM فراهم است. در کلاسترهایی که Storage Capacity Tracking را پشتیبانی می‌کنند، اطلاعات ظرفیت از طریق اشیای StorageCapacity در دسترس Scheduler قرار می‌گیرد.

این راه‌حل برای سناریوهای ذخیره‌سازی محلی با کارایی بالا و نیاز به Locality مناسب است؛ مانند محیط‌های Bare Metal و Edge. از آن‌جا که Volumeها محلی‌اند، تاب‌آوری معمولا از طریق تکرار در سطح اپلیکیشن تامین می‌شود. در مقایسه با درایورهای ذخیره‌سازی شبکه‌ای، TopoLVM بر ظرفیت قابل پیش‌بینی روی نود، Provisioning سریع و کنترل مستقیم عملیاتی با LVM تمرکز دارد.

#Kubernetes #CSI #TopoLVM #LVM #Storage #PersistentVolume #CapacityAware #DevOps

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Most Cloud-Native Roles are Software Engineers

🟢 خلاصه مقاله:
این مقاله بازار کار cloud-native در سال ۲۰۲۵ را بررسی می‌کند و نشان می‌دهد که حدود ۴۷٪ از موقعیت‌های مرتبط با Kubernetes به عنوان Software Engineer آگهی می‌شوند؛ در حالی‌که نقش‌های DevOps، Platform، DevSecOps و SRE سهم کمتری دارند. این روند بیانگر استخدامِ مهندس‌محور و حرکت به‌سمت shift-left است: از توسعه‌دهندگان انتظار می‌رود علاوه بر توسعه، با Kubernetes و بخشی از زیرساخت، امنیت و تحویل نیز درگیر باشند. برای متقاضیان، تسلط بر Kubernetes همراه با مهارت‌های CI/CD، IaC، observability و اصول امنیت ضروری‌تر شده است و در عین حال همکاری نزدیک با تیم‌های DevOps/Platform/SRE همچنان اهمیت دارد.

#CloudNative #Kubernetes #SoftwareEngineering #DevOps #SRE #DevSecOps #PlatformEngineering #TechJobs2025

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Inside Duolingo's FinOps Journey: Turning Cloud Spend into Engineering Insight (3 minute read)

🟢 خلاصه مقاله:
خلاصه‌ای از مسیر FinOps در Duolingo نشان می‌دهد که این شرکت با وارد کردن آگاهی مالی به جریان کاری مهندسی، هزینه‌های ابری را به بینشی عملی برای توسعه‌دهندگان تبدیل کرده است. با نمایش بلادرنگِ اثر مالی تغییرات در کنار متریک‌های عملیاتی، استفاده از تگ‌گذاری و مالکیت منابع، هشدارهای خودکار و گاردریل‌های بودجه، و حتی مقایسه «cost diff» در CI/CD، تیم‌ها می‌توانند پیش از استقرار، پیامدهای هزینه‌ای انتخاب‌های معماری و کد را بسنجند. این رویکرد فرهنگ سازمان را به سمتی برده که «کارایی» هم‌سطح «عملکرد» و «پایداری» به‌عنوان یک معیار اصلی کیفیت دیده می‌شود و تصمیم‌گیری‌ها—از برنامه‌ریزی ظرفیت تا آزمایش و بازطراحی—با زبانی مشترک میان مهندسی و مالی انجام می‌گیرد. نتیجه، کاهش اتلاف، پیش‌بینی‌پذیری بهتر و سیستم‌هایی سریع، پایدار و آگاه از هزینه است.

#FinOps #CloudCost #Duolingo #CostOptimization #DevOps #EngineeringExcellence #CloudOps #SoftwareQuality

🟣لینک مقاله:
https://www.infoq.com/news/2025/10/duolingo-finops-engineering/?utm_source=tldrdevops

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
SR-IOV Network Device Plugin

🟢 خلاصه مقاله:
این افزونه با بهره‌گیری از SR-IOV امکان تخصیص مستقیم VFهای یک NIC فیزیکی به Podها را در Kubernetes فراهم می‌کند تا به کارایی نزدیک به سخت‌افزار، تأخیر پایین و سربار CPU کم برسند. افزونه به‌صورت DaemonSet روی نودها اجرا می‌شود، دستگاه‌های SR-IOV را کشف کرده و از طریق Device Plugin API به‌عنوان منابع قابل‌درخواست در اختیار kubelet می‌گذارد؛ با درخواست Pod یک VF به‌طور انحصاری تخصیص می‌یابد و جداسازی و پیش‌بینی‌پذیری کارایی تضمین می‌شود. پیکربندی شبکه با SR-IOV CNI و معمولاً Multus انجام می‌شود و بسته به نیاز، VF می‌تواند به درایورهایی مانند vfio-pci برای DPDK یا درایورهای کرنلی متصل شود؛ همچنین در صورت پشتیبانی سخت‌افزار، RDMA قابل استفاده است. استقرار نیازمند فعال‌سازی SR-IOV و IOMMU، NIC سازگار، ایجاد VFها و Linux است و در بسیاری از سناریوها SR-IOV Network Operator مدیریت خودکار و سیاست‌گذاری را ساده می‌کند. این راهکار برای CNFها، NFV، تحلیل بلادرنگ و محیط‌های با حساسیت بالا به تأخیر کاربردی است و به‌صورت استاندارد با اکوسیستم CNI در Kubernetes ادغام می‌شود.

#SRIOV #Kubernetes #CNI #Multus #DPDK #NFV #Networking #CloudNative

🟣لینک مقاله:
https://ku.bz/jVg_1VS-k

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

چجوری بفهمیم ایمیج‌های Docker کی نسخه جدید میدن

خیلی وقتا سرویس‌های داکری روی نسخه‌های قدیمی ایمیج می‌مونن و کسی هم به این زودی متوجه نمی‌شه!

برای همین ابزاری هست به اسم DIUN که کارش فقط یه چیزه:
بفهمه ایمیجی که داری استفاده می‌کنی، نسخه جدید داده یا نه.

حالا DIUN چطوری اینو تشخیص می‌ده؟

خیلی ساده:
به docker.sock وصل می‌شه، می‌فهمه چه کانتینرهایی داری و از چه ایمیج‌هایی استفاده می‌کنی. بعد Digest همونا رو با Digest رجیستری مقایسه می‌کنه :)))
اگر فرق داشت، یعنی نسخهٔ جدید منتشر شده.

برای استفاده هم فقط کافیه یه کانتینر DIUN کنار سرویس‌هات بیاری بالا.

حالا DIUN میتونه خروجی رو به هرجایی که API میده بفرسته:
تلگرام، Slack و...

جزئیاتش اینجاست:
https://hashbang.nl/blog/receive-notifications-when-updates-to-docker-images-are-released-using-diun

البته تو محیط‌های بزرگ تر معمولاً از ابزارهایی مثل Renovate یا watchtower استفاده می‌کنن،
ولی DIUN یه گزینه راحت و کار راه اندازه برای اینکه سریع بفهمی ایمیج جدید اومده یا نه!

@ | <Amir Haji Mohammad Sadegh/>

🔵 عنوان مقاله
Using LLMs to filter out false positives from static code analysis (5 minute read)

🟢 خلاصه مقاله:
**Datadog قابلیت فیلتر هوشمند «مثبت کاذب» را به ابزار Static Code Analysis اضافه کرده است. این ویژگی با تکیه بر Bits AI و LLMها، یافته‌های امنیتی را به «احتمالاً واقعی» یا «احتمالاً مثبت کاذب» دسته‌بندی می‌کند تا نویز کاهش یابد، تریاژ سریع‌تر شود و تیم‌های توسعه و امنیت بتوانند روی آسیب‌پذیری‌های واقعاً مهم تمرکز کنند و رفع آن‌ها را سریع‌تر پیش ببرند.

#StaticCodeAnalysis #Datadog #BitsAI #LLM #DevSecOps #ApplicationSecurity #CodeScanning #FalsePositives

🟣لینک مقاله:
https://www.datadoghq.com/blog/using-llms-to-filter-out-false-positives/?utm_source=tldrdevops

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
How We Rebuilt Our Vault Architecture with Raft, Snapshots, and DR

🟢 خلاصه مقاله:
ما معماری Vault را با تکیه بر سه رکن Raft، Snapshots و DR بازطراحی کردیم تا پیچیدگی عملیاتی را کاهش دهیم، وابستگی‌های بیرونی را حذف کنیم و تاب‌آوری را افزایش دهیم. با مهاجرت به ذخیره‌سازی یکپارچه مبتنی بر Raft، کلاستر ساده‌تر و قابل‌اعتمادتر شد و مسیر مهاجرت با محیط staging، تمرین‌های بازیابی، معیارهای rollback و پایش لحظه‌ای کنترل شد. Snapshots به‌طور خودکار زمان‌بندی و رمزنگاری شدند، در فضای ذخیره‌سازی ایمن نگهداری و با تمرین‌های دوره‌ای بازیابی راستی‌آزمایی شدند تا RPO شفاف و بازیابی قابل پیش‌بینی باشد. برای DR یک کلاستر ثانویه در دامنه خرابی جدا راه‌اندازی و با تکرار DR، برنامه failover با RTO مشخص و مانیتورینگ تأخیر تکرار، سلامت Raft و تازگی Snapshotها پیاده‌سازی شد. با امنیت لایه‌به‌لایه، least-privilege برای مقصد پشتیبان، مستندسازی و خودکارسازی بررسی‌ها، به عملیات پایدارتر و بازیابی سریع‌تر رسیدیم و اطمینان به سکوی مدیریت اسرار افزایش یافت.

#Vault #Raft #DisasterRecovery #Snapshots #DevOps #SRE #HighAvailability #Infrastructure

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Debugging the One-in-a-Million Failure: Migrating Pinterest’s Search Infrastructure to Kubernetes

🟢 خلاصه مقاله:
** این مقاله روایت مهاجرت زیرساخت جست‌وجوی Pinterest به Kubernetes است و چگونگی برخورد تیم با یک خطای بسیار نادر را شرح می‌دهد؛ خطایی که در محیط‌های آزمایشی دیده نمی‌شد اما در بار واقعی تولید، به‌صورت افزایش‌های مقطعی در تاخیر و تایم‌اوت‌های پراکنده بروز می‌کرد. تیم با تقویت مشاهده‌پذیری، هم‌بند کردن لاگ‌ها، متریک‌ها و تریس‌ها، و اجرای آزمایش‌های کنترل‌شده و تدریجی روی پیکربندی‌ها، مسئله را مانند یک معمای سیستم‌های توزیع‌شده واکاوی کرد. نتیجه نشان داد مشکل ناشی از برهم‌کنش چند عامل بود: زمان‌بندی ارکستریشن، محدودیت‌های منابع، و سیاست‌های retry/timeout که در شرایط خاص همدیگر را تقویت می‌کردند. راه‌حل شامل مجموعه‌ای از بهبودهای کوچک اما مکمل بود—از تنظیم دقیق درخواست/سقف منابع و آماده‌سازی سرویس تا هموار کردن رفتار autoscaling، بهینه‌سازی زمان‌بندی readiness، و مقاوم‌سازی سیاست‌های backoff و فشار معکوس. درس‌های کلیدی نیز بر مهاجرت‌های مبتنی بر SLO، آینه‌سازی ترافیک تولید، آزمایش خرابی متمرکز بر رخدادهای Kubernetes، و اتوماسیون علائم هشداردهنده برای تشدیدهای نادر تاکید دارند. در نهایت، مهاجرت مزایای مقیاس‌پذیری و یکنواختی استقرار را به‌همراه داشت و نشان داد که در مقیاس بزرگ، رخدادهای «یک در میلیون» باید به‌طور نظام‌مند دیده، سنجیده و مهار شوند.

#Kubernetes #Pinterest #SearchInfrastructure #DistributedSystems #Debugging #ReliabilityEngineering #Migration #ProductionIncidents

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

مدل opus 4.5 دیروز اومد. بینظیره. بهترین مدل دنیا برای coding با اختلاف زیاد.
یک اتفاق مهم دیگه اینکه Anthropic برای اولین بار قیمت بهترین مدل خودش رو به یک سوم تا یک پنجم قیمت قبلی کاهش داده!!
هر میلیون اینپوت از ۲۵ دلار شده ۵ دلار و هر میلیون output هم از ۷۵ دلار شده ۱۵ دلار!

<Amin Anvary/>

👉 https://t.iss.one/addlist/AJ7rh2IzIh02NTI0

🔵 عنوان مقاله
How to Prevent Failures with Kubernetes Topology Spread Constraints

🟢 خلاصه مقاله:
این مقاله نشان می‌دهد چرا استفاده از Pod Topology Spread Constraints در زمان rolling updates می‌تواند باعث توزیع ناعادلانه پادها شود و در پایان استقرار، یک یا چند ناحیه بیش‌ازحد شلوغ بماند. علت این است که Scheduler در هنگام جای‌گذاری پادهای جدید، پادهای قدیمی و جدید را با هم در نظر می‌گیرد؛ بنابراین پادهای تازه را به نواحی «فعلاً» کم‌تراکم می‌فرستد، اما با حذف تدریجی پادهای قدیمی، همان نواحی از نسخه جدید اشباع می‌شوند.

راه‌حل پیشنهادی استفاده از matchLabelKeys (برای نمونه با کلید pod-template-hash) است تا Scheduler هر نسل از پادها را فقط نسبت به هم‌نسل‌های خودش پخش کند. بدین ترتیب هر ReplicaSet به‌طور مستقل متعادل می‌شود و چون نسل قبلی نیز از قبل متعادل بوده، مجموع پادها در طول و پس از rollout یکنواخت باقی می‌ماند.

برای اجرای درست، از پشتیبانی Kubernetes v1.25+ نسبت به matchLabelKeys مطمئن شوید، topologyKey مناسب (مثلاً topology.kubernetes.io/zone) و maxSkew معقول انتخاب کنید و سیاست whenUnsatisfiable را بسته به نیاز سخت‌گیرانه (DoNotSchedule) یا منعطف (ScheduleAnyway) تنظیم کنید.

#Kubernetes #PodTopologySpreadConstraints #TopologySpread #RollingUpdates #DevOps #SRE #HighAvailability #matchLabelKeys

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Bringing Node.js HTTP servers to Cloudflare Workers (4 minute read)

🟢 خلاصه مقاله:
** Cloudflare Workers با افزودن APIهای client و server از طریق node:http و با فعال‌سازی پرچم nodejs_compat، امکان اجرای مستقیم برنامه‌های Node.js را فراهم کرده است. این قابلیت پلی بین مدل سرورهای سبک Node.js (مانند http.createServer و الگوی req/res) و مدل رسیدگی به درخواست در Workers می‌سازد؛ در این روش، شماره پورت به‌عنوان شناسه برای نگاشت سرور Node.js به خط لوله داخلی درخواست‌ها استفاده می‌شود. نتیجه این است که برنامه‌های مبتنی بر Express.js و Koa می‌توانند بدون بازنویسی اساسی، به‌صورت سراسری روی لبه اجرا شوند و از مزایای zero cold start و مقیاس‌پذیری خودکار بهره ببرند.

#CloudflareWorkers #Nodejs #Express #Koa #Serverless #EdgeComputing #HTTP #JavaScript

🟣لینک مقاله:
https://blog.cloudflare.com/bringing-node-js-http-servers-to-cloudflare-workers/?utm_source=tldrdevops

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Numaflow: serverless event platform

🟢 خلاصه مقاله:
**Numaflow یک پلتفرم serverless برای پردازش رویدادهاست که ساخت و اجرای پایپ‌لاین‌های داده‌ی رویدادمحور را بدون دردسر مدیریت زیرساخت ممکن می‌کند. با تعریف جریان‌های شفاف بین منبع، پردازش و مقصد، توسعه‌دهنده فقط منطق کسب‌وکار را به‌صورت توابع سبک پیاده‌سازی می‌کند و پلتفرم مقیاس‌پذیری افقی، مدیریت فشار، بازیابی خطا و پایش را بر عهده می‌گیرد. Numaflow برای سناریوهای کم‌تأخیر و جریان‌های آنی طراحی شده، الگوهای بی‌حالت و حالت‌دار (مثل پنجره‌بندی) را پشتیبانی می‌کند و روی محیط‌های cloud-native مانند Kubernetes به‌صورت قابل‌حمل اجرا می‌شود. نتیجه، چابکی بیشتر تیم‌ها و کاهش هزینه از طریق مقیاس‌پذیری خودکار و scale-to-zero برای کاربردهایی مانند تحلیل بلادرنگ، ETL جریانی، تشخیص ناهنجاری/تقلب و پردازش IoT است.

#Numaflow #Serverless #EventDriven #DataPipelines #StreamingData #CloudNative #Kubernetes #RealTimeAnalytics

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Deploying a .NET Weather Forecast App to AKS Using GitHub Actions and Argo CD

🟢 خلاصه مقاله:
**این آموزش نشان می‌دهد چگونه یک اپلیکیشن ساده .NET برای پیش‌بینی وضعیت هوا را با بهره‌گیری از GitHub Actions و Argo CD روی AKS مستقر کنید. GitHub Actions وظیفه ساخت و انتشار ایمیج کانتینر در رجیستری (مثل Azure Container Registry یا Docker Hub) را بر عهده دارد و Argo CD با رویکرد GitOps وضعیت مطلوب تعریف‌شده در مخزن را با خوشه AKS همگام می‌کند.

گام‌ها شامل آماده‌سازی خوشه AKS، رجیستری، و یک مخزن GitHub با کد و مانیفست‌های Kubernetes یا Helm است. سپس با یک Dockerfile اپلیکیشن .NET را کانتینری می‌کنید و یک Workflow در GitHub Actions می‌سازید که با هر تغییر کد، ایمیج را می‌سازد، تگ می‌زند و به رجیستری Push می‌کند. Argo CD در خوشه نصب و طوری پیکربندی می‌شود که مسیر مانیفست‌ها/چارت را از مخزن دنبال کرده و با سیاست همگام‌سازی دلخواه (دستی یا خودکار) تغییرات را اعمال کند.

در این جریان، هر Commit باعث ساخت ایمیج جدید و Push می‌شود و Argo CD تغییر وضعیت مطلوب را تشخیص داده و نسخه جدید را روی AKS مستقر می‌کند. آموزش به نکاتی مثل جداسازی محیط‌ها، RBAC و Namespace، انتشار سرویس از طریق Service/Ingress و پایش و Rollback نیز اشاره دارد تا استقرارها ایمن و قابل تکرار باشند.

#AKS #ArgoCD #GitHubActions #DotNet #Kubernetes #GitOps #Azure #DevOps

🟣لینک مقاله:
https://ku.bz/yj4-3B2y-

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
k8s-libsonnet: Kubernetes library

🟢 خلاصه مقاله:
**k8s-libsonnet یک کتابخانه برای ساده‌سازی تولید و نگه‌داری پیکربندی‌های Kubernetes است که با الگوی DRY، اجزای قابل‌استفاده‌مجدد و پیش‌فرض‌های امن را ارائه می‌دهد. این رویکرد باعث کاهش تکرار، یکنواختی میان سرویس‌ها و سهولت اعمال تغییرات در محیط‌های مختلف می‌شود. در عمل، اجزا را وارد کرده و پارامتری می‌کنید، خروجی YAML/JSON می‌گیرید، سپس با ابزارهای مرسوم آن را اعتبارسنجی و Deploy می‌کنید. این راهکار با جریان‌های GitOps و CI/CD هم‌خوان است و می‌تواند در کنار ابزارهایی مانند Helm یا Kustomize به‌عنوان جایگزین یا مکمل، مدیریت پیکربندی را شفاف و مقیاس‌پذیر کند.

#Kubernetes #Jsonnet #k8s #GitOps #DevOps #InfrastructureAsCode #PlatformEngineering

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
gRPC Load Balancing Test Suite for Kubernetes & Istio

🟢 خلاصه مقاله:
این کار یک مجموعه آزمون متمرکز را معرفی می‌کند که برای ارزیابی و تقویت Load Balancing در gRPC روی Kubernetes و Istio طراحی شده است. این مجموعه با تولید الگوهای ترافیکی کنترل‌شده و پوشش‌دادن سناریوهای واقعی مانند نوسان پادها، خرابی‌ها، تغییر توپولوژی و مقایسه حالتِ بدون مش (Kubernetes Service) و با مش (Istio)، توزیع درخواست‌ها، تأخیر p50 تا p99.9، نرخ خطا و زمان بازیابی را اندازه‌گیری می‌کند. سیاست‌های رایج مانند round-robin، pick-first، weighted و locality-aware و همچنین سلامت‌سنجی، مدیریت outlier و backoff ارزیابی می‌شوند تا پیکربندی کلاینت و سیاست‌های مش بهینه شوند. با ادغام در Prometheus، Grafana و OpenTelemetry، نتایج به‌صورت قابل تکرار در خوشه‌ها و CI قابل پایش است. در نهایت، راهنمای عملی برای انتخاب سیاست مناسب، تنظیم connection pool، timeout و retry، و درک اثر mTLS و سیاست‌های Istio ارائه می‌شود و یک چک‌لیست آمادگی gRPC به کاهش ریسک و بهبود پایداری در مقیاس کمک می‌کند.

#gRPC #Kubernetes #Istio #LoadBalancing #ServiceMesh #PerformanceTesting #DevOps

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
How Kubernetes Pod Priority and Preemption Work

🟢 خلاصه مقاله:
Kubernetes با استفاده از PriorityClass برای هر Pod اولویت تعیین می‌کند و kube-scheduler ابتدا Pods با اولویت بالاتر را زمان‌بندی می‌کند. اگر منابع کافی پیدا نشود، مکانیزم Preemption فعال می‌شود: scheduler روی یک Node کاندید بررسی می‌کند که با حذف Podهای کم‌اولویت‌تر (و بدون نقض PodDisruptionBudget) آیا می‌توان جا باز کرد یا نه. Pods با اولویت برابر یا بالاتر هرگز قربانی نمی‌شوند، و با PreemptionPolicy: Never می‌توان از ایجاد Preemption توسط یک Pod جلوگیری کرد. علاوه بر زمان‌بندی، در وضعیت کمبود منبع روی Node، kubelet در صورت نیاز معمولاً Podهای کم‌اولویت را زودتر Evict می‌کند تا سرویس‌های مهم پایدار بمانند. برای بهره‌گیری امن، چند PriorityClass مشخص (مثلاً system-critical، high، standard، batch) تعریف کنید، همراه با requests/limits مناسب، PDB برای حفاظت سرویس‌های حیاتی، و ResourceQuota؛ و رفتار Preemption را در محیط staging آزمایش کنید.

#Kubernetes #Pod #PriorityClass #Preemption #Scheduler #CloudNative #DevOps #SRE

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

نسخه جدید Docker Engine 29 منتشر شد!
حالا containerd به‌صورت پیش‌فرض نقش «image store» داره
و پشتیبانی آزمایشی از nftables برای فایروال/شبکه لینوکس اضافه شده
یک گام بزرگ به سمت مدرنیته!

er | <MehrdadLinux/>

قابلیتِ جالبِ Gemini 3 که با Banana Pro میسر هست !

مثلا اگر یک ویدئو آموزشی ۲۰ دقیقه ای یوتیوب دارید و وقت ندارید کامل ببینید و میخواید خلاصه ش رو به صورت یک پوستر گرافیکی ( اینفوگرافیک ) داشته باشید !

آموزش نحوه استفاده از این قابلیت :

۱ لینک ویدئو یوتیوب رو Copy میکنید .

۲ وارد Gemini میشید .

۳ لینک کپی شده رو Paste میکنید و ازش بخواید که ویدئو رو آنالیز و بررسی کنه .

۴ بعد از اینکه بررسی کرد ، حالا این پرامپت وارد کنید !

Prompt :  Generate an image of an infographic explaining the concept presented in the video.

♨️ با احترام به تمام پزشکان، امروز میخوام یه هوش مصنوعی پزشک معرفی کنم.

▪️همه ما ممکنه روزانه سوالات پزشکی رو در مورد علائم یا حال ناخوش خودمون یا اطرافیانمون داشته باشیم. چی میشد اگه یه هوش مصنوعی وجود داشت که به آخرین اطلاعات علم پزشکی هم دسترسی داشت و میشد ازش مشورت گرفت؟

👩‍⚕️داکوس در کنار شماست ؛)

▪️یک پلتفرم سلامت هوشمنده که از یه چت بات برای تولید گزارشهای سلامت شخصی‌سازی‌شده متناسب با هر فرد استفاده میکنه.
▪️کاربرها میتونن با چت بات گفتگو کنن و یه گزارش سلامت تولید کنن یا احتمال انواع ابتلا به بیماری رو شناسایی کنن. 

+ اینم بگم که شما فقط اجازه ارسال و دریافت تا 7 پیغام رو به صورت رایگان و روزانه دارید و برای ادامه استفاده باید اشتراک ماهانه تهیه کرد. 👇👇

▫️https://docus.ai

بلک‌فرایدی تبدیل شد به یک بازی کثیف؛ قیمت‌ها قبلش باد شد، امید کاذب ساختند، مردم رو ساعت‌ها پشت گوشی نگه داشتند که شاید «محصول ۲۰۰ میلیونی رو با ۹۰٪ تخفیف» بگیرن.

اینفلوئنسرهایی که با اعتماد همین مردم مشهور شدند، برای چندصد میلیون، هیزم آتیش فریب شدند.
فروشگاه‌هایی که به‌جای بازاریابی علمی، دروغ و تکنیک زرد رو انتخاب کردند.

نتیجه؟
نه «اعتبار برند» ساختید، نه «وفاداری مشتری»… فقط یک کوله‌بار نفرت روی دوش مردم گذاشتید.
اینا تخفیف نبود؛ یک توهین به شعور عمومی بود.
به امید روزی که هرجا چیزی «مفت» دیدیم، کورکورانه نپریم توش.

#بلک_فرایدی #فریب_تخفیف #تکنوکسب #بازاریابی #مردم #ایران