🔵 عنوان مقاله
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

🔵 عنوان مقاله
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

🔵 عنوان مقاله
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

🔵 عنوان مقاله
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

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

🟢 خلاصه مقاله:
k8sgpt یک ابزار متن‌باز برای تحلیل خوشه‌های Kubernetes است که با اسکن منابع و رویدادها، خطاها و پیکربندی‌های نادرست را شناسایی کرده و آن‌ها را به زبان ساده توضیح می‌دهد. این ابزار با تمرکز بر تشخیص و تریاژ، دلایل احتمالی مشکل و مراحل پیشنهادی رفع را ارائه می‌کند و زمان رفع اختلال را کاهش می‌دهد. k8sgpt برای تیم‌های SRE، مهندسان پلتفرم و توسعه‌دهندگان مفید است و پیچیدگی Kubernetes را در عملیات روزمره و مدیریت رخدادها قابل‌فهم‌تر می‌کند. کد و مستندات آن در GitHub در دسترس است.

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

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Non-HA Kubernetes Gotchas: Downtime and Autoscaling Pitfalls with Single Replica Workloads

🟢 خلاصه مقاله:
در محیط‌های غیرِ HA Kubernetes، مدیریت صحیح سرویس‌ها و کارایی سیستم اهمیت زیادی دارد. یکی از چالش‌های اصلی این است که در صورت عدم وجود نسخه پشتیبان، چه اتفاقی می‌افتد و چگونه می‌توان از بروز قطعی‌های ناخواسته جلوگیری کرد. این مقالات به میان می‌آید که چگونه با تنظیمات مناسب، از توقف برنامه‌ها و شکست در عملیات خودکار مقیاس‌بندی در workloads تک‌نسخه‌ای جلوگیری کنیم.

در این مقاله، به بررسی راهکارهای جلوگیری از downtime و خطاهای autoscaling در محیط‌های غیر-HA Kubernetes می‌پردازیم. یکی از ابزارهای مهم در این زمینه، PodDisruptionBudgets است که با تعیین محدودیت‌هایی در تعداد ناپایداری‌های مجاز، به سیستم اجازه می‌دهد بدون توقف کامل سرویس‌ها، تغییرات لازم انجام شود. همچنین، تنظیمات مناسب برای eviction pods نقش کلیدی در حفظ پایداری و جلوگیری از خاموشی‌های ناخواسته دارند، به ویژه در محیط‌هایی که تنها یک نمونه (single replica) فعال دارند.

در نتیجه، با آگاهی از نحوه پیکربندی صحیح این تنظیمات، مدیران سیستم می‌توانند از قطعی‌های ناخواسته جلوگیری کرده و عملیات‌های خودکار مقیاس‌بندی را بدون مشکل پیش ببرند. رعایت این نکات، کلید تضمین پایداری و دوام بهره‌وری در سیستم‌های Kubernetes است، به خصوص در موارد حساس به downtime.

#Kubernetes #HighAvailability #Autoscaling #PodDisruptionBudget

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
A Crash Course in running Kubernetes locally

🟢 خلاصه مقاله:
در این مقاله، به بررسی راهکارهای راه‌اندازی Kubernetes در محیط محلی می‌پردازیم. Kubernetes، سیستم متن‌باز مدیریت کانتینرها، به‌طور گسترده‌ای در محیط‌های بزرگ و توزیع‌شده استفاده می‌شود، اما توسعه‌دهندگان و تیم‌های کوچک‌تر نیز نیاز دارند تا نسخه‌ای از آن را در دستگاه‌های خود آزمایش و توسعه دهند.

در بخش اول، اهمیت راه‌اندازی Kubernetes در لوکال برای توسعه و آزمایش سریع توضیح داده می‌شود. راه‌اندازی این سیستم روی کامپیوتر شخصی یا سرورهای کوچک، امکان تست برنامه‌ها و اطمینان از عملکرد صحیح قبل از استقرار در محیط‌های بزرگ‌تر را فراهم می‌کند و زمان و هزینه‌های توسعه را کاهش می‌دهد.

در قسمت بعد، چند روش محبوب و ساده برای پیاده‌سازی Kubernetes در محیط محلی بررسی می‌شود. ابزارهایی مانند Minikube، Docker Desktop و Kind (Kubernetes IN Docker) گزینه‌هایی است که به توسعه‌دهندگان امکان می‌دهند نسخه‌ای سبک و قابل مدیریت از Kubernetes را روی دستگاه‌های خود اجرا کنند. هر یک از این ابزارها ویژگی‌ها و مزایای خاص خود را دارند که در انتخاب مناسب نقش مهمی ایفا می‌کند.

در پایان، نکات فنی و توصیه‌هایی برای بهره‌برداری بهتر از Kubernetes در لوکال ارائه می‌شود؛ از جمله نحوه پیکربندی، به‌روزرسانی‌ها، و مدیریت منابع سیستم. با شناخت این ابزارها و رعایت نکات مهم، می‌توان به راحتی در محیط محلی، توسعه، تست و آموزش کانتینرها و سرویس‌های مبتنی بر Kubernetes را انجام داد و در نهایت، مسیر توسعه نرم‌افزار را سریع‌تر و کارآمدتر کرد.

#Kubernetes #توسعه_محلی #Docker #کانتینرها

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Change Management with the Pulumi Kubernetes Operator and Kargo (5 minute read)

🟢 خلاصه مقاله:
مدیریت تغییرات با بهره‌گیری از اپراتور کوانتیس کیوبنتس Pulumi و پلتفرم Kargo

اپراتور Pulumi Kubernetes (PKO) حالا با Kargo، یک پلتفرم ترویج مستمر، ادغام شده است. این ادغام امکان مدیریت استک‌های Pulumi به‌عنوان منابع Kubernetes را فراهم می‌کند، در حالی‌که ترویج‌های مرحله‌ای و کنترل‌شده و فرآیندهای تأیید را آسان می‌سازد. زمانی که Kargo منابع استک را با شاخص‌های جدید گیت به‌روزرسانی می‌کند، این اقدام باعث می‌شود تا PKO عملیات تطابق استک را انجام دهد و تغییرات زیرساختی را به‌درستی اعمال کند. در نتیجه، روند استقرار در محیط‌های مختلف به صورت منظم و کنترل‌شده صورت می‌گیرد.

پلتفرم Kargo با بروزرسانی منابع استک، فرآیندهای انتشار و ترویج زیرساخت را کنترل می‌کند و تضمین می‌نماید که هر مرحله با دقت و تأیید انجام شود. همچنین، داشبورد Kargo امکان مشاهده بصری وضعیت فرآیندها، نسخه‌های باربری، مسیرهای ترویج و وضعیت عملیات را فراهم می‌کند. این ابزار به تیم‌های فنی کمک می‌کند تا نظارت دقیقی بر روند تغییرات داشته و خطاها و مشکلات را به موقع شناسایی کنند. در نتیجه، کارایی و کنترل بر روی استقرارهای زیرساخت، به میزان قابل توجهی افزایش می‌یابد.

در مجموع، ادغام این دو فناوری به تیم‌های توسعه و عملیات القدرة می‌دهد تا فرآیندهای تغییرات زیرساخت خود را به صورت مطمئن، مرحله‌ای و با نظارت کامل مدیریت کنند، که در نتیجه باعث بهبود کیفیت و سرعت استقرارها می‌شود.

#مدیریت_تغییرات #Kubernetes #Pulumi #Kargo

🟣لینک مقاله:
https://www.pulumi.com/blog/pulumi-kubernetes-operator-and-kargo/?utm_source=tldrdevops

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
k10ls — native K8s API port-forwarder

🟢 خلاصه مقاله:
ابزار k10ls که بر پایه‌ی API نیتیو Kubernetes طراحی شده است، امکان فوروارد پورت خودکار و هوشمند بر اساس برچسب‌ها را فراهم می‌کند. این ابزار به کاربران اجازه می‌دهد تا به راحتی و بدون نیاز به استفاده از دستور kubectl port-forward، بر روی پادها و سرویس‌های موردنظر خود، مسیرهای ارتباطی امن و کارآمد برقرار کنند.

با استفاده از k10ls، فرآیند فوروارد پورت‌ها به صورت خودکار و سازگار با نیازهای سازمانی انجام می‌شود. این ابزار از رویکردی مبتنی بر API Kubernetes بهره می‌برد که ضمن افزایش سرعت و کارایی، آسانی در مدیریت و مقیاس‌پذیری را نیز فراهم می‌آورد. بدون نیاز به نصب و پیکربندی اضافی، می‌توان به سادگی به منابع مختلف در کلاسترهای Kubernetes دسترسی پیدا کرد.

در مجموع، k10ls ابزار قدرتمندی است برای توسعه‌دهندگان و مدیران سیستم‌هایی که به دنبال راه‌حل‌های خودکار و مقیاس‌پذیر در پروسه مدیریت پورت‌های Kubernetes هستند. این فناوری، سطح جدیدی از سهولت و انعطاف‌پذیری در عملیات‌های روزمره بر بستر Kubernetes را رقم می‌زند.

#Kubernetes #PortForwarding #Automation #DevOps

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon