🔵 عنوان مقاله
Terraform & Ansible: Unifying infrastructure provisioning and configuration management (3 minute read)
🟢 خلاصه مقاله:
این یکپارچگی جدید با معرفی Terraform actions، همکاری Terraform و Ansible را عمیق‌تر می‌کند و یک مسیر یکپارچه از تامین زیرساخت تا پیکربندی و عملیات Day 2+ فراهم می‌کند. Terraform می‌تواند مستقیماً گردش‌های کاری Ansible را پس از ایجاد زیرساخت اجرا کند و با اشتراک موجودی یکسان (inventory) و خروجی‌های Terraform، از ناسازگاری و اسکریپت‌های سفارشی جلوگیری کند. نتیجه، خودکارسازی روان‌تر و کاهش اصطکاک عملیاتی به‌ویژه در محیط‌های هیبرید و چندابری است؛ ضمن اینکه کارهای مداوم مانند نصب وصله‌ها، اعمال انطباق، استقرار برنامه و رفع drift نیز به‌صورت منظم و قابل تکرار انجام می‌شوند.
#Terraform #Ansible #InfrastructureAsCode #DevOps #Automation #MultiCloud #ConfigurationManagement #Day2Operations
🟣لینک مقاله:
https://www.hashicorp.com/en/blog/terraform-ansible-unifying-infrastructure-provisioning-configuration-management?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Terraform & Ansible: Unifying infrastructure provisioning and configuration management (3 minute read)
🟢 خلاصه مقاله:
این یکپارچگی جدید با معرفی Terraform actions، همکاری Terraform و Ansible را عمیق‌تر می‌کند و یک مسیر یکپارچه از تامین زیرساخت تا پیکربندی و عملیات Day 2+ فراهم می‌کند. Terraform می‌تواند مستقیماً گردش‌های کاری Ansible را پس از ایجاد زیرساخت اجرا کند و با اشتراک موجودی یکسان (inventory) و خروجی‌های Terraform، از ناسازگاری و اسکریپت‌های سفارشی جلوگیری کند. نتیجه، خودکارسازی روان‌تر و کاهش اصطکاک عملیاتی به‌ویژه در محیط‌های هیبرید و چندابری است؛ ضمن اینکه کارهای مداوم مانند نصب وصله‌ها، اعمال انطباق، استقرار برنامه و رفع drift نیز به‌صورت منظم و قابل تکرار انجام می‌شوند.
#Terraform #Ansible #InfrastructureAsCode #DevOps #Automation #MultiCloud #ConfigurationManagement #Day2Operations
🟣لینک مقاله:
https://www.hashicorp.com/en/blog/terraform-ansible-unifying-infrastructure-provisioning-configuration-management?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
🔵 عنوان مقاله
Why keep your index set lean (8 minute read)
🟢 خلاصه مقاله:
** ایندکس‌های اضافی در Postgres هزینه پنهان اما جدی دارند: نوشتن‌ها را کند می‌کنند چون هر INSERT/UPDATE باید همه آن‌ها را به‌روزرسانی کند، زمان برنامه‌ریزی را بالا می‌برند و به‌خاطر رقابت برای cache می‌توانند خواندن‌ها را هم کند کنند. علاوه بر اتلاف فضای دیسک، کار autovacuum بیشتر می‌شود و WAL بیشتری تولید می‌شود که هزینه‌های نگهداری و پشتیبان‌گیری را بالا می‌برد. راهکار این است که ایندکس‌های بلااستفاده یا تکراری حذف و ایندکس‌های متورم بازسازی شوند، و با پایش منظم، مجموعه‌ای کم‌حجم و کارآمد از ایندکس‌ها حفظ شود.
#Postgres #Indexing #DatabasePerformance #WAL #Autovacuum #SQL #DBA #DevOps
🟣لینک مقاله:
https://postgres.ai/blog/20251110-postgres-marathon-2-013-why-keep-your-index-set-lean?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Why keep your index set lean (8 minute read)
🟢 خلاصه مقاله:
** ایندکس‌های اضافی در Postgres هزینه پنهان اما جدی دارند: نوشتن‌ها را کند می‌کنند چون هر INSERT/UPDATE باید همه آن‌ها را به‌روزرسانی کند، زمان برنامه‌ریزی را بالا می‌برند و به‌خاطر رقابت برای cache می‌توانند خواندن‌ها را هم کند کنند. علاوه بر اتلاف فضای دیسک، کار autovacuum بیشتر می‌شود و WAL بیشتری تولید می‌شود که هزینه‌های نگهداری و پشتیبان‌گیری را بالا می‌برد. راهکار این است که ایندکس‌های بلااستفاده یا تکراری حذف و ایندکس‌های متورم بازسازی شوند، و با پایش منظم، مجموعه‌ای کم‌حجم و کارآمد از ایندکس‌ها حفظ شود.
#Postgres #Indexing #DatabasePerformance #WAL #Autovacuum #SQL #DBA #DevOps
🟣لینک مقاله:
https://postgres.ai/blog/20251110-postgres-marathon-2-013-why-keep-your-index-set-lean?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
PostgresAI
#PostgresMarathon 2-013: Why keep your index set lean | PostgresAI
Your API is slowing down. You check your database and find 42 indexes on your users table. Which ones can you safely drop? How much performance are they costing you? Let's look at what actually happens in Postgres when you have too many indexes.
Forwarded from Linux Labdon
کاهش هزینه سیستم‌های هوش مصنوعی با Semantic Caching
با رشد مدل‌های زبانی بزرگ و پیشرفته، هزینه و زمان پاسخ‌دهی هم به شدت افزایش پیدا کرده. مدل‌هایی مثل GPT-5 یا Claude برای کارهای پیچیده فوق‌العاده‌اند، ولی استفاده از اون‌ها هم پرهزینه و هم کند محسوب می‌شه. از طرف دیگه، AI Agentها واقعاً «توکن‌خور» هستن؛ یعنی برای انجام یک کار معمولاً چندین مرحله طی می‌کنن: تحقیق، برنامه‌ریزی، عمل و بازتاب و تکرار. همین باعث می‌شه چندین بار با مدل تماس بگیرن و در نتیجه هزینه و تأخیر افزایش پیدا کنه و متن‌های طولانی‌تر تولید بشه. برای مثال، یه بنچمارک اخیر از TheAgentCompany در ۲۰۲۵ نشون داده اجرای کامل یک Agent گاهی تا ۶.۸ دلار هزینه داره.
یکی از مشکلات اصلی در دنیای واقعی، تکراری بودن سوال‌هاست، مخصوصاً توی پشتیبانی مشتری. کاربران دائماً سوال‌های مشابهی می‌پرسن: مثل «چطور پولم رو پس بگیرم؟» یا «شرایط بازگشت وجه چیه؟» و Agent مجبور می‌شه هر بار پاسخ رو از صفر تولید کنه. نتیجه‌ش افزایش هزینه، طولانی شدن زمان پاسخ و فشار بیشتر روی سیستم‌های RAG و زیرساخت‌هاست.
در نگاه اول، ممکنه فکر کنیم کش کلاسیک کفایت می‌کنه. ایده‌ی کش ساده اینه که اگر یک سوال قبلاً پاسخ داده شده، دوباره سراغ مدل نریم. ولی مشکل اینجاست که کش سنتی دنبال Exact Match یا تطابق دقیق متنه. سوال‌هایی که از نظر معنی یکی هستن ولی عبارت‌هاشون فرق می‌کنه، مثل: «می‌خوام پولم رو پس بگیرم»، «چطور می‌تونم درخواست بازگشت وجه بدم؟» و «سیاست بازگشت پولتون چیه؟»، همه Cache Miss می‌شن و کش عملاً استفاده نمی‌شه.
اینجاست که Semantic Caching وارد می‌شه. به جای تطابق کلمه‌به‌کلمه، کش به معنی و مفهوم جمله نگاه می‌کنه. مزیت اصلی‌ش اینه که Recall و Hit Rate بالاتره و احتمال استفاده از کش و صرفه‌جویی خیلی بیشتر می‌شه. البته چالشش هم اینه که گاهی ممکنه جواب بی‌ربط بده یا همون «False Positive» رخ بده.
روش کار Semantic Caching ساده است ولی هوشمندانه: ابتدا سوال کاربر به Embedding یا بردار عددی تبدیل می‌شه. بعد با بردارهای موجود در کش با Semantic Search مقایسه می‌شه. اگر فاصله معنایی کم باشه، پاسخ از کش برگردونده می‌شه؛ در غیر این صورت به RAG یا LLM می‌ریم. در نهایت سوال و پاسخ جدید هم ذخیره می‌شه تا دفعه بعدی قابل استفاده باشه.
پیاده‌سازی Semantic Caching با چالش‌هایی همراهه؛ مثل دقت (Accuracy) که آیا کش جواب درست میده، کارایی (Performance) و میزان Cache Hit، سرعت سرویس‌دهی، آپدیت‌پذیری کش و اینکه آیا می‌تونیم کش رو گرم، تازه‌سازی یا پاکسازی کنیم. همچنین مشاهده‌پذیری (Observability) مهمه تا بتونیم hit rate، latency، صرفه‌جویی هزینه و کیفیت کش رو بسنجیم.
معیارهای اصلی سنجش کش شامل Cache Hit Rate هست که نشون میده چند درصد درخواست‌ها از کش پاسخ داده می‌شن و Precision/Recall/F1 Score که کیفیت و دقت پاسخ‌ها رو مشخص می‌کنه. برای بهبود دقت و کارایی کش هم می‌تونیم Threshold فاصله رو تنظیم کنیم، Reranker اضافه کنیم مثل Cross-encoder یا LLM-as-a-judge، از Fuzzy Matching برای تایپوها استفاده کنیم و فیلترهای اضافی مثل تشخیص پرسش‌های زمان‌محور (Temporal) یا تشخیص کد (Python، Java و…) اعمال کنیم تا سوالات اشتباه وارد کش نشن.
یه مثال واقعی از این تکنولوژی پروژه waLLMartCache در Walmart هست. اون‌ها با نوآوری‌هایی مثل Load Balancer برای توزیع کش روی چند Node و Dual-tiered Storage که L1 = Vector DB و L2 = In-memory Cache مثل Redis هست، هم سرعت و هم دقت رو بالا بردن. Multi-tenancy هم باعث شده چند تیم یا اپلیکیشن از یک زیرساخت مشترک استفاده کنن. Decision Engine هم شامل تشخیص کد و زمانه و اگر سوال مناسب کش نباشه مستقیماً به LLM یا RAG می‌ره. نتیجه‌ش رسیدن به دقت نزدیک ۹۰٪ بوده.
<Reza Jafari/>
👉 https://t.iss.one/addlist/AJ7rh2IzIh02NTI0
با رشد مدل‌های زبانی بزرگ و پیشرفته، هزینه و زمان پاسخ‌دهی هم به شدت افزایش پیدا کرده. مدل‌هایی مثل GPT-5 یا Claude برای کارهای پیچیده فوق‌العاده‌اند، ولی استفاده از اون‌ها هم پرهزینه و هم کند محسوب می‌شه. از طرف دیگه، AI Agentها واقعاً «توکن‌خور» هستن؛ یعنی برای انجام یک کار معمولاً چندین مرحله طی می‌کنن: تحقیق، برنامه‌ریزی، عمل و بازتاب و تکرار. همین باعث می‌شه چندین بار با مدل تماس بگیرن و در نتیجه هزینه و تأخیر افزایش پیدا کنه و متن‌های طولانی‌تر تولید بشه. برای مثال، یه بنچمارک اخیر از TheAgentCompany در ۲۰۲۵ نشون داده اجرای کامل یک Agent گاهی تا ۶.۸ دلار هزینه داره.
یکی از مشکلات اصلی در دنیای واقعی، تکراری بودن سوال‌هاست، مخصوصاً توی پشتیبانی مشتری. کاربران دائماً سوال‌های مشابهی می‌پرسن: مثل «چطور پولم رو پس بگیرم؟» یا «شرایط بازگشت وجه چیه؟» و Agent مجبور می‌شه هر بار پاسخ رو از صفر تولید کنه. نتیجه‌ش افزایش هزینه، طولانی شدن زمان پاسخ و فشار بیشتر روی سیستم‌های RAG و زیرساخت‌هاست.
در نگاه اول، ممکنه فکر کنیم کش کلاسیک کفایت می‌کنه. ایده‌ی کش ساده اینه که اگر یک سوال قبلاً پاسخ داده شده، دوباره سراغ مدل نریم. ولی مشکل اینجاست که کش سنتی دنبال Exact Match یا تطابق دقیق متنه. سوال‌هایی که از نظر معنی یکی هستن ولی عبارت‌هاشون فرق می‌کنه، مثل: «می‌خوام پولم رو پس بگیرم»، «چطور می‌تونم درخواست بازگشت وجه بدم؟» و «سیاست بازگشت پولتون چیه؟»، همه Cache Miss می‌شن و کش عملاً استفاده نمی‌شه.
اینجاست که Semantic Caching وارد می‌شه. به جای تطابق کلمه‌به‌کلمه، کش به معنی و مفهوم جمله نگاه می‌کنه. مزیت اصلی‌ش اینه که Recall و Hit Rate بالاتره و احتمال استفاده از کش و صرفه‌جویی خیلی بیشتر می‌شه. البته چالشش هم اینه که گاهی ممکنه جواب بی‌ربط بده یا همون «False Positive» رخ بده.
روش کار Semantic Caching ساده است ولی هوشمندانه: ابتدا سوال کاربر به Embedding یا بردار عددی تبدیل می‌شه. بعد با بردارهای موجود در کش با Semantic Search مقایسه می‌شه. اگر فاصله معنایی کم باشه، پاسخ از کش برگردونده می‌شه؛ در غیر این صورت به RAG یا LLM می‌ریم. در نهایت سوال و پاسخ جدید هم ذخیره می‌شه تا دفعه بعدی قابل استفاده باشه.
پیاده‌سازی Semantic Caching با چالش‌هایی همراهه؛ مثل دقت (Accuracy) که آیا کش جواب درست میده، کارایی (Performance) و میزان Cache Hit، سرعت سرویس‌دهی، آپدیت‌پذیری کش و اینکه آیا می‌تونیم کش رو گرم، تازه‌سازی یا پاکسازی کنیم. همچنین مشاهده‌پذیری (Observability) مهمه تا بتونیم hit rate، latency، صرفه‌جویی هزینه و کیفیت کش رو بسنجیم.
معیارهای اصلی سنجش کش شامل Cache Hit Rate هست که نشون میده چند درصد درخواست‌ها از کش پاسخ داده می‌شن و Precision/Recall/F1 Score که کیفیت و دقت پاسخ‌ها رو مشخص می‌کنه. برای بهبود دقت و کارایی کش هم می‌تونیم Threshold فاصله رو تنظیم کنیم، Reranker اضافه کنیم مثل Cross-encoder یا LLM-as-a-judge، از Fuzzy Matching برای تایپوها استفاده کنیم و فیلترهای اضافی مثل تشخیص پرسش‌های زمان‌محور (Temporal) یا تشخیص کد (Python، Java و…) اعمال کنیم تا سوالات اشتباه وارد کش نشن.
یه مثال واقعی از این تکنولوژی پروژه waLLMartCache در Walmart هست. اون‌ها با نوآوری‌هایی مثل Load Balancer برای توزیع کش روی چند Node و Dual-tiered Storage که L1 = Vector DB و L2 = In-memory Cache مثل Redis هست، هم سرعت و هم دقت رو بالا بردن. Multi-tenancy هم باعث شده چند تیم یا اپلیکیشن از یک زیرساخت مشترک استفاده کنن. Decision Engine هم شامل تشخیص کد و زمانه و اگر سوال مناسب کش نباشه مستقیماً به LLM یا RAG می‌ره. نتیجه‌ش رسیدن به دقت نزدیک ۹۰٪ بوده.
<Reza Jafari/>
👉 https://t.iss.one/addlist/AJ7rh2IzIh02NTI0
❤2
🔵 عنوان مقاله
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
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
Medium
Kubernetes Headaches: Unsticking StatefulSets from EBS ReadWriteMany Drama
Note: This post assumes some familiarity with AWS EKS, Kubernetes StatefulSets, and EBS volumes.
🔵 عنوان مقاله
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
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
GitHub
GitHub - topolvm/topolvm: Capacity-aware CSI plugin for Kubernetes
Capacity-aware CSI plugin for Kubernetes. Contribute to topolvm/topolvm development by creating an account on GitHub.
🔵 عنوان مقاله
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
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
Cloud Native Now
Most Cloud-Native Roles are Software Engineers
Cloud-native hiring: 47% of roles are Software Engineers, while SRE positions have dropped ~30% since 2023. Lead-level jobs outnumber junior ones. Skills are the differentiator.cloudnativenow.com/you-are-more-likely-to-land-a-lead-level-cloud-native-role…
❤1
🔵 عنوان مقاله
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
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
InfoQ
Inside Duolingo’s FinOps Journey: Turning Cloud Spend into Engineering Insight
Duolingo's FinOps journey integrates financial awareness into engineering, empowering developers to link costs with performance. By leveraging real-time data, teams prioritize innovations for maximum impact. This collaborative culture shift transformed cost…
🔵 عنوان مقاله
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
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
GitHub
GitHub - k8snetworkplumbingwg/sriov-network-device-plugin: SRIOV network device plugin for Kubernetes
SRIOV network device plugin for Kubernetes. Contribute to k8snetworkplumbingwg/sriov-network-device-plugin development by creating an account on GitHub.
❤1
چجوری بفهمیم ایمیج‌های 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/>
خیلی وقتا سرویس‌های داکری روی نسخه‌های قدیمی ایمیج می‌مونن و کسی هم به این زودی متوجه نمی‌شه!
برای همین ابزاری هست به اسم 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/>
Hashbang
Receive notifications when updates to docker images are released using DIUN
👍2