🔵 عنوان مقاله
HAMi – Heterogeneous AI Computing Virtualization Middleware

🟢 خلاصه مقاله:
HAMi یک میان‌افزار Kubernetes-native برای مجازی‌سازی و مدیریت شتاب‌دهنده‌های ناهمگن مانند GPU، NPU و MLU است. این راهکار با ارائه دستگاه‌های مجازی، امکان اشتراک‌گذاری کارآمد و ایزوله‌سازی قوی را فراهم می‌کند، بهره‌وری را بالا می‌برد و از تداخل بارها جلوگیری می‌کند. با زمان‌بندی آگاه از توپولوژی، بارها در جایی قرار می‌گیرند که دسترسی به شتاب‌دهنده‌های مناسب با کمترین رقابت و تأخیر ممکن باشد. HAMi همچنین با سیاست‌های یکپارچه تخصیص و محدودسازی منابع، و ادغام طبیعی در Kubernetes، اجرای پایدار، قابل پیش‌بینی و مقیاس‌پذیر بارهای AI/ML را روی سخت‌افزارهای متنوع ممکن می‌سازد.

#Kubernetes #HeterogeneousComputing #AIInfrastructure #GPUVirtualization #ResourceIsolation #Scheduling #CloudNative #MLOps

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
More devops than I bargained for

🟢 خلاصه مقاله:
یک مهاجرت «ساده» از x86 به ARM64 تبدیل شد به یک بحران تمام‌عیار DevOps. به‌محض ورود نودهای ARM64، مشکل‌ها از چند جهت فوران کرد: نبودن base imageهای arm64، وابستگی سرویس‌ها به باینری‌ها و پکیج‌های بومی، و CrashLoop به‌خاطر “exec format error”. با ساخت multi-arch image و manifest list و اصلاح CI بخشی حل شد، اما Helm chartها هنوز فرض‌های amd64 داشتند و باعث زمان‌بندی نادرست، ImagePullBackOff و ناسازگاری در sidecarها شدند. بدتر از همه، شبکه بود: در کلاستر dual-stack، IPv6 زیر بار می‌برید؛ MTU ناهماهنگ، تنظیمات CNI، iptables/nft و محدودیت‌های conntrack دست‌به‌دست هم دادند و ما را ساعت ۴ صبح پای tcpdump و تنظیم sysctl نشاندند. جمع‌بندی: تغییر معماری، به‌روزرسانی OS، دست‌کاری CNI و فعال‌سازی dual-stack را یک‌جا انجام ندهید؛ برای هرکدام پنجره تست و rollback جدا بگذارید، observability و ابزارهای eBPF اضافه کنید، Ingress و sidecarها را از نظر multi-arch راستی‌آزمایی کنید و پوشش تست multi-arch را در CI اجباری کنید.

#DevOps #Kubernetes #ARM64 #x86 #IPv6 #CNI #Containers #CloudNative

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

‌
♨️ راز خواب 12 ساعته پاول دورف؛ جایی که ایده‌های تلگرام شکل می‌گیرن!

▪️پاول دورف، مدیرعامل تلگرام، گفته روزی بین ۱۱ تا ۱۲ ساعت می‌خوابه ، و جالبه که اینو نه تنبلی، بلکه منبع اصلی ایده‌های درخشانش می‌دونه!

▪️دورف صبح‌ها حتی سراغ گوشی هم نمی‌ره، چون معتقده موبایل‌ها جلوی تفکر مستقل رو می‌گیرن.

خودش می‌گه:

«می‌خوام خودم تصمیم بگیرم چی تو زندگیم مهمه، نه اینکه شرکت‌ها یا الگوریتم‌ها برام تعیین کنن.»

‌

🔵 عنوان مقاله
k8sgpt: Kubernetes analyzer

🟢 خلاصه مقاله:
k8sgpt یک تحلیلگر هوشمند برای خوشه‌های Kubernetes است که با بررسی وضعیت منابع، رویدادها و لاگ‌ها، الگوهای خرابی رایج را شناسایی می‌کند و ریشه مشکل را با زبان ساده همراه با راهکارهای عملی توضیح می‌دهد. این ابزار می‌تواند به‌صورت CLI کنار جریان‌های کاری مبتنی بر kubectl یا داخل خوشه اجرا شود، در CI/CD و فرایندهای DevOps/SRE به تشخیص سریع و کاهش زمان رفع اشکال کمک کند، و خلاصه‌های قابل‌اشتراک ارائه دهد. امکاناتی مانند حذف اطلاعات حساس و انعطاف‌پذیری در استقرار نیز برای استفاده امن و سازگار با محیط‌های مختلف در نظر گرفته شده است.

#Kubernetes #k8sgpt #DevOps #SRE #CloudNative #Troubleshooting #Observability #AIOps

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Smesh: Lightweight Kubernetes-Integrated Sidecar Mesh Without Proxies

🟢 خلاصه مقاله:
smesh یک نمونه اولیه از یک service mesh برای Kubernetes است که با تکیه بر eBPF، ترافیک pod را در سطح کرنل رهگیری و به یک sidecar proxy هدایت می‌کند. ایده اصلی این است که به‌جای اتکا به سازوکارهای سنتیِ capture مانند iptables، رهگیری و تغییر مسیر در خود کرنل انجام شود تا هدایت ترافیک به sidecar ساده‌تر و کم‌هزینه‌تر شود. رویکرد smesh «سبک» و یکپارچه با Kubernetes است و می‌کوشد سربار و پیچیدگی عملیاتی را کاهش دهد. هرچند شعار «بدون پروکسی» مطرح است، تمایز اصلی در smesh استفاده از eBPF برای interception است و همچنان sidecar مقصد نهایی جریان‌های هدایت‌شده باقی می‌ماند. این پروژه فعلاً در سطح آزمایشی است و برای ارزیابی امکان‌پذیری و مزایای بالقوه‌ی رهگیری مبتنی بر eBPF عرضه شده است.

#Kubernetes #eBPF #ServiceMesh #Sidecar #CloudNative #Networking #DevOps

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
OCI Registry As Storage (ORAS)

🟢 خلاصه مقاله:
OCI Registry As Storage (ORAS) روشی و ابزاری است که با تکیه بر استانداردهای OCI، رجیستری‌های سازگار را به یک مخزن عمومی برای هر نوع محتوا تبدیل می‌کند؛ نه فقط ایمیج‌های کانتینری. با ORAS می‌توان انواع آرتیفکت‌ها مثل SBOM، Helm chart، گزارش‌های امنیتی، مدل‌های ML و داده‌ها را با همان پروتکل توزیع، احراز هویت و کنترل دسترسی رایج در رجیستری‌ها ذخیره و بازیابی کرد. این رویکرد با استفاده از manifestهای OCI و API مربوط به referrers امکان اتصال آرتیفکت‌ها به یک ایمیج (یا آرتیفکت دیگر) را فراهم می‌کند؛ مثلاً پیوست‌کردن SBOM، امضاهای cosign یا Notary v2 و گزارش‌های آسیب‌پذیری به یک digest مشخص و ساخت زنجیره‌ای قابل‌راستی‌آزمایی برای تامین امنیت نرم‌افزار. ORAS بدون پیکربندی خاص در رجیستری‌هایی مثل Docker Hub، GitHub Container Registry و Azure Container Registry کار می‌کند و مزایایی مانند یکپارچگی با CI/CD، کشف سریع referrerها، ردگیری و ممیزی آسان، و ترفیع همزمان ایمیج‌ها و آرتیفکت‌های مرتبط در محیط‌های مختلف را فراهم می‌سازد.

#ORAS #OCI #ContainerRegistry #DevOps #SupplyChainSecurity #SBOM #CloudNative #CI_CD

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Test Orchestration: You're Doing It, You Just Don’t Know It

🟢 خلاصه مقاله:
این مقاله می‌گوید بیشتر تیم‌ها همین حالا هم نوعی Test Orchestration انجام می‌دهند، اما به‌صورت وصله‌پینه در اسکریپت‌های CI/CD. مشکل از آن‌جاست که منطق تست به پیکربندی pipeline گره می‌خورد و باعث شکنندگی، تکرار، دشواری اجرا در محیط‌های مختلف و تجربه بد توسعه‌دهنده می‌شود. راه‌حل، جدا کردن منطق تست از CI/CD و انتقال آن به یک لایه orchestration هدفمند است تا pipeline فقط یک فراخوان باریک باشد. نتیجه این کار: مقیاس‌پذیری، نگه‌داری ساده‌تر، اجرای یکسان در حالت محلی و روی runnerهای مختلف، مشاهده‌پذیری پایدار و Continuous Testing قابل اتکا. برای شروع: ممیزی اسکریپت‌های موجود، استخراج مراحل مشترک به ماژول‌های قابل‌استفاده‌مجدد، تعریف یک CLI/API روشن، ساده‌سازی تدریجی pipeline و افزودن سنجه‌ها برای پایش پایداری و زمان اجرا.

#TestOrchestration #CICD #ContinuousTesting #DevOps #TestAutomation #QualityEngineering #DeveloperExperience #ScalableTesting

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Zarf: airgapped installation

🟢 خلاصه مقاله:
Zarf ابزاری برای نصب امن و قابل اتکا در محیط‌های بدون اتصال (air-gapped) است که با ساخت یک بسته قابل‌حمل شامل همه وابستگی‌ها—از جمله تصاویر کانتینری، نمودارهای Helm، مانیفست‌های Kubernetes، باینری‌ها و پیکربندی—استقرار را بدون نیاز به اینترنت ممکن می‌کند. این بسته‌ها نسخه‌قفل، دارای چک‌سام و قابل امضا هستند؛ روی سیستم متصل ساخته می‌شوند، با رسانه قابل‌حمل منتقل می‌گردند و در مقصد با چند فرمان نصب می‌شوند. Zarf می‌تواند پیش‌نیازهایی مانند رجیستری محلی و سرویس Git را راه‌اندازی کند و ارجاع تصاویر را به رجیستری داخلی بازنویسی کند. برای انطباق و شفافیت زنجیره تامین، امکان SBOM، امضا و رهگیری فراهم است و ادغام با CI به انتشارهای تکرارپذیر کمک می‌کند. این رویکرد برای شبکه‌های دولتی/دفاعی، صنعتی و سلامت مناسب است و نگهداری بارهای کاری Kubernetes را بدون تضعیف مرزهای امنیتی ساده می‌سازد.

#Zarf #AirGapped #OfflineDeployment #Kubernetes #DevSecOps #SupplyChainSecurity #Helm #Containers

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Kubernetes v1.33: Streaming List responses

🟢 خلاصه مقاله:
Kubernetes v1.33 قابلیت streaming برای پاسخ‌های List را معرفی می‌کند تا مصرف حافظه API server در درخواست‌های بزرگ کاهش یابد. سرور به‌جای ساختن کل پاسخ در حافظه، هر آیتم را جداگانه پردازش و ارسال می‌کند و بلافاصله حافظه را آزاد می‌سازد؛ در عین حال ساختار پاسخ، ترتیب اقلام و semantics مربوط به resourceVersion برای کلاینت‌ها تغییر نمی‌کند. نتیجه این رویکرد، کاهش پیک حافظه، بهبود تاخیرهای انتهایی و پایداری بهتر زیر بار است و با الگوهای موجود مانند pagination (limit/continue) و watch کاملاً سازگار می‌ماند، بدون نیاز به تغییر در API یا کلاینت‌ها.

#Kubernetes #APIServer #Streaming #ListAPI #Performance #Scalability #MemoryOptimization #CloudNative

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon