🔵 عنوان مقاله
SecretForge — A Sidecar for Kubernetes Secrets
🟢 خلاصه مقاله:
مدیریت محرمانهها در کوبرنتیز چالشهایی مانند رمزنگاری ناکافی پیشفرض، بهروزرسانی دشوار و وابستگی برنامهها به منبع محرمانه دارد. SecretForge بهعنوان یک سایدکار کنار هر پاد اجرا میشود و دریافت امن محرمانهها، بهروزرسانی خودکار، رندرکردن به فایل/تمپلیت و راهاندازی مجدد سبک یا هاتریلود را بر عهده میگیرد؛ بنابراین بدون تغییر در کد برنامه میتوان چرخش کلیدها و گواهیها را اعمال کرد. پیکربندی ساده، هویت مبتنی بر پاد و حداقل سطح دسترسی، بههمراه لاگ و متریک، مدیریت و پایش را استاندارد میکند. در نتیجه، SecretForge مصرف محرمانهها را یکپارچه و امن میکند و مهاجرت یا ترکیب منابع مختلف محرمانه را آسانتر میسازد.
🟣لینک مقاله:
https://ku.bz/xKKXSNvb7
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
SecretForge — A Sidecar for Kubernetes Secrets
🟢 خلاصه مقاله:
مدیریت محرمانهها در کوبرنتیز چالشهایی مانند رمزنگاری ناکافی پیشفرض، بهروزرسانی دشوار و وابستگی برنامهها به منبع محرمانه دارد. SecretForge بهعنوان یک سایدکار کنار هر پاد اجرا میشود و دریافت امن محرمانهها، بهروزرسانی خودکار، رندرکردن به فایل/تمپلیت و راهاندازی مجدد سبک یا هاتریلود را بر عهده میگیرد؛ بنابراین بدون تغییر در کد برنامه میتوان چرخش کلیدها و گواهیها را اعمال کرد. پیکربندی ساده، هویت مبتنی بر پاد و حداقل سطح دسترسی، بههمراه لاگ و متریک، مدیریت و پایش را استاندارد میکند. در نتیجه، SecretForge مصرف محرمانهها را یکپارچه و امن میکند و مهاجرت یا ترکیب منابع مختلف محرمانه را آسانتر میسازد.
🟣لینک مقاله:
https://ku.bz/xKKXSNvb7
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
SecretForge — A Sidecar for Kubernetes Secrets
From Mounted Secrets to Ready-to-Use File
❤1
🔵 عنوان مقاله
werf: full cycle CI/CD
🟢 خلاصه مقاله:
**werf یک ابزار CLI برای پیادهسازی full-cycle CICD روی Kubernetes است که کل چرخهٔ عمر اپلیکیشن کانتینری—از ساخت تا انتشار و استقرار ایمیجها—را یکپارچه میکند. با کش خودکارِ بیلد، زمان اجرای pipeline کاهش مییابد و نتایج تکرارپذیر و سازگار در محیطهای مختلف تضمین میشود. این رویکرد یک ابزار واحد برای توسعهٔ محلی و سیستمهای CI فراهم میکند و پیچیدگی عملیات را پایین میآورد.
#werf #CICD #Kubernetes #DevOps #Containers #BuildCaching #CLI #ContinuousDelivery
🟣لینک مقاله:
https://ku.bz/bcbMgkHcz
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
werf: full cycle CI/CD
🟢 خلاصه مقاله:
**werf یک ابزار CLI برای پیادهسازی full-cycle CICD روی Kubernetes است که کل چرخهٔ عمر اپلیکیشن کانتینری—از ساخت تا انتشار و استقرار ایمیجها—را یکپارچه میکند. با کش خودکارِ بیلد، زمان اجرای pipeline کاهش مییابد و نتایج تکرارپذیر و سازگار در محیطهای مختلف تضمین میشود. این رویکرد یک ابزار واحد برای توسعهٔ محلی و سیستمهای CI فراهم میکند و پیچیدگی عملیات را پایین میآورد.
#werf #CICD #Kubernetes #DevOps #Containers #BuildCaching #CLI #ContinuousDelivery
🟣لینک مقاله:
https://ku.bz/bcbMgkHcz
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - werf/werf: A solution for implementing efficient and consistent software delivery to Kubernetes facilitating best practices.
A solution for implementing efficient and consistent software delivery to Kubernetes facilitating best practices. - werf/werf
❤1
🔵 عنوان مقاله
Smesh: Lightweight Kubernetes-Integrated Sidecar Mesh Without Proxies
🟢 خلاصه مقاله:
** اسمش یک نمونهٔ آزمایشی از یک service mesh سبک برای Kubernetes است که با استفاده از eBPF ترافیک podها را در سطح کرنل رهگیری و به یک sidecar proxy هدایت میکند. رویکرد آن کاهش سربار مسیر داده با اتکا به eBPF برای interception و redirection است، در حالی که مدیریت ترافیک همچنان توسط یک مؤلفهٔ sidecar انجام میشود. هدف، یکپارچگی بهتر با Kubernetes و بهبود تأخیر و مصرف CPU نسبت به مشهای سنتی است، اما این پروژه در حد اثبات مفهوم است و هنوز برای استفادهٔ تولیدی نیاز به بلوغ و آزمونهای بیشتر دارد.
#Kubernetes #ServiceMesh #eBPF #Sidecar #CloudNative #ContainerNetworking #DevOps
🟣لینک مقاله:
https://ku.bz/Wx7wMJLqF
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Smesh: Lightweight Kubernetes-Integrated Sidecar Mesh Without Proxies
🟢 خلاصه مقاله:
** اسمش یک نمونهٔ آزمایشی از یک service mesh سبک برای Kubernetes است که با استفاده از eBPF ترافیک podها را در سطح کرنل رهگیری و به یک sidecar proxy هدایت میکند. رویکرد آن کاهش سربار مسیر داده با اتکا به eBPF برای interception و redirection است، در حالی که مدیریت ترافیک همچنان توسط یک مؤلفهٔ sidecar انجام میشود. هدف، یکپارچگی بهتر با Kubernetes و بهبود تأخیر و مصرف CPU نسبت به مشهای سنتی است، اما این پروژه در حد اثبات مفهوم است و هنوز برای استفادهٔ تولیدی نیاز به بلوغ و آزمونهای بیشتر دارد.
#Kubernetes #ServiceMesh #eBPF #Sidecar #CloudNative #ContainerNetworking #DevOps
🟣لینک مقاله:
https://ku.bz/Wx7wMJLqF
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - thebsdbox/smesh
Contribute to thebsdbox/smesh development by creating an account on GitHub.
توی این مقاله از اهمیت یادگیری Docker برای فرانتاند دولوپرا گفتم؛ اینکه چرا نیازه و از کجا و چطور یاد بگیریمش. سعی کردم زبانم تا حد امکان ساده و روان باشه. خوشحال میشم بخونید و اگر نظری دارید برام بنویسید.
https://vrgl.ir/GiGV1
https://vrgl.ir/GiGV1
ویرگول
چرا یک برنامهنویس فرانتاند نیازه Docker بلد باشه؟ - ویرگول
توی این مقاله میخوایم ببینیم چرا یادگیری (یا حداقل آشنایی) با Docker برای تیم فرانتاند نیازه؛ بدونیم از کجا شروع کنیم و تا کجا ادامه بدیم…
🔵 عنوان مقاله
kubectl-sql: Query Kubernetes with SQL Syntax
🟢 خلاصه مقاله:
افزونه kubectl-sql برای kubectl امکان اجرای پرسوجوهای شبیه SQL روی منابع Kubernetes را فراهم میکند. با آن میتوانید روی اشیایی مثل Pods و PVCs عمل فیلتر، انتخاب فیلد و مرتبسازی انجام دهید، بدون اینکه مجبور باشید از jq یا JSONPath بهصورت خام استفاده کنید. نتیجه، پرسوجوهای خواناتر و سریعتر برای رفع اشکال، با روالی آشنا برای کسانی که SQL میدانند و در چارچوب خط فرمان kubectl کار میکنند.
#Kubernetes #kubectl #SQL #DevOps #CloudNative #CLI #jq #JSONPath
🟣لینک مقاله:
https://ku.bz/908njZKBb
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
kubectl-sql: Query Kubernetes with SQL Syntax
🟢 خلاصه مقاله:
افزونه kubectl-sql برای kubectl امکان اجرای پرسوجوهای شبیه SQL روی منابع Kubernetes را فراهم میکند. با آن میتوانید روی اشیایی مثل Pods و PVCs عمل فیلتر، انتخاب فیلد و مرتبسازی انجام دهید، بدون اینکه مجبور باشید از jq یا JSONPath بهصورت خام استفاده کنید. نتیجه، پرسوجوهای خواناتر و سریعتر برای رفع اشکال، با روالی آشنا برای کسانی که SQL میدانند و در چارچوب خط فرمان kubectl کار میکنند.
#Kubernetes #kubectl #SQL #DevOps #CloudNative #CLI #jq #JSONPath
🟣لینک مقاله:
https://ku.bz/908njZKBb
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - yashbhutwala/kubectl-df-pv: kubectl plugin - giving admins df (disk free) like utility for persistent volumes
kubectl plugin - giving admins df (disk free) like utility for persistent volumes - yashbhutwala/kubectl-df-pv
👾1
🔵 عنوان مقاله
Mastering Kubernetes StatefulSets: Expanding PVCs Without Downtime or GitOps Drift
🟢 خلاصه مقاله:
این آموزش روش افزایش حجم PVCs در StatefulSets روی Kubernetes را بدون downtime توضیح میدهد و همزمان مشکل GitOps drift در ArgoCD را رفع میکند. ابتدا با اطمینان از پشتیبانی StorageClass از online expansion، هر PVC مربوط به StatefulSet بهصورت دستی افزایش حجم مییابد و وضعیت resize تا تکمیل بررسی میشود. سپس برای همراستا کردن وضعیت با Git و حذف خطاهای sync در ArgoCD، اندازه جدید در volumeClaimTemplates ثبت و با استفاده از cascade orphan deletion، StatefulSet بدون توقف سرویسها بازایجاد و Pods/PVCs موجود حفظ میشوند. نتیجه: افزایش امن و بیوقفه فضای ذخیرهسازی و همگامی کامل با GitOps.
#Kubernetes #StatefulSets #PVC #ArgoCD #GitOps #DevOps #Storage #ZeroDowntime
🟣لینک مقاله:
https://ku.bz/P6gHZ5sDt
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Mastering Kubernetes StatefulSets: Expanding PVCs Without Downtime or GitOps Drift
🟢 خلاصه مقاله:
این آموزش روش افزایش حجم PVCs در StatefulSets روی Kubernetes را بدون downtime توضیح میدهد و همزمان مشکل GitOps drift در ArgoCD را رفع میکند. ابتدا با اطمینان از پشتیبانی StorageClass از online expansion، هر PVC مربوط به StatefulSet بهصورت دستی افزایش حجم مییابد و وضعیت resize تا تکمیل بررسی میشود. سپس برای همراستا کردن وضعیت با Git و حذف خطاهای sync در ArgoCD، اندازه جدید در volumeClaimTemplates ثبت و با استفاده از cascade orphan deletion، StatefulSet بدون توقف سرویسها بازایجاد و Pods/PVCs موجود حفظ میشوند. نتیجه: افزایش امن و بیوقفه فضای ذخیرهسازی و همگامی کامل با GitOps.
#Kubernetes #StatefulSets #PVC #ArgoCD #GitOps #DevOps #Storage #ZeroDowntime
🟣لینک مقاله:
https://ku.bz/P6gHZ5sDt
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
Mastering Kubernetes StatefulSets: Expanding PVCs Without Downtime or GitOps Drift
Persistent Volume Claims (PVCs) are central to managing storage in Kubernetes, especially for stateful applications like PostgreSQL. But…
👍1
🔵 عنوان مقاله
Jobnik: RESTful Triggering and Monitoring of Kubernetes Jobs
🟢 خلاصه مقاله:
**Jobnik یک سرویس سبک و API-first است که با ارائه RESTful endpoints، اجرای Kubernetes Jobs و پایش آنها را ساده میکند. هر سیستمی که بتواند یک HTTP call بزند، میتواند با اطمینان Job بسازد، وضعیتش را بگیرد و لاگها را مشاهده کند. Jobnik امکان ارسال درخواست اجرای Job (بر اساس spec یا template با پارامتر)، اعمال idempotency برای جلوگیری از اجرای تکراری، کنترل همزمانی، بازیابی وضعیت و دریافت لاگ را از طریق API فراهم میکند. از نظر عملیاتی، احراز هویت/مجوز، محدودهگذاری چندمستاجره بر اساس namespace، rate limiting و quota، timeout و سیاستهای پاکسازی و همچنین retry/backoff را پوشش میدهد. برای observability نیز متریکها، audit logs و tracing ارائه میشود و میتواند با webhook/callback پایان یا شکست Job را اعلان کند. Jobnik بهخوبی با CI/CD، پردازش داده و جریانهای ML یکپارچه میشود و بهعنوان یک درگاه ساده و متمرکز، بهجای راهاندازی موتورهای پیچیده، اجرای قابل اتکا و پایش Kubernetes Jobs را ممکن میسازد.
#Kubernetes #RESTfulAPI #DevOps #JobOrchestration #CloudNative #Observability #CICD #PlatformEngineering
🟣لینک مقاله:
https://ku.bz/_w5D-BjXn
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Jobnik: RESTful Triggering and Monitoring of Kubernetes Jobs
🟢 خلاصه مقاله:
**Jobnik یک سرویس سبک و API-first است که با ارائه RESTful endpoints، اجرای Kubernetes Jobs و پایش آنها را ساده میکند. هر سیستمی که بتواند یک HTTP call بزند، میتواند با اطمینان Job بسازد، وضعیتش را بگیرد و لاگها را مشاهده کند. Jobnik امکان ارسال درخواست اجرای Job (بر اساس spec یا template با پارامتر)، اعمال idempotency برای جلوگیری از اجرای تکراری، کنترل همزمانی، بازیابی وضعیت و دریافت لاگ را از طریق API فراهم میکند. از نظر عملیاتی، احراز هویت/مجوز، محدودهگذاری چندمستاجره بر اساس namespace، rate limiting و quota، timeout و سیاستهای پاکسازی و همچنین retry/backoff را پوشش میدهد. برای observability نیز متریکها، audit logs و tracing ارائه میشود و میتواند با webhook/callback پایان یا شکست Job را اعلان کند. Jobnik بهخوبی با CI/CD، پردازش داده و جریانهای ML یکپارچه میشود و بهعنوان یک درگاه ساده و متمرکز، بهجای راهاندازی موتورهای پیچیده، اجرای قابل اتکا و پایش Kubernetes Jobs را ممکن میسازد.
#Kubernetes #RESTfulAPI #DevOps #JobOrchestration #CloudNative #Observability #CICD #PlatformEngineering
🟣لینک مقاله:
https://ku.bz/_w5D-BjXn
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - wix-incubator/jobnik: Jobnik is a tiny web application that allows triggering and monitoring Kubernetes Jobs using standard…
Jobnik is a tiny web application that allows triggering and monitoring Kubernetes Jobs using standard Rest-API - wix-incubator/jobnik
🔵 عنوان مقاله
k8sgpt: Kubernetes analyzer
🟢 خلاصه مقاله:
k8sgpt یک ابزار متنباز برای تحلیل Kubernetes است که خطاها و هشدارهای پیچیده را به توضیحات قابلفهم و راهکارهای عملی تبدیل میکند. این ابزار با اسکن منابعی مانند Pod، Deployment، Service، Ingress، Node و همچنین Events و لاگها، خطاهای رایج مثل CrashLoopBackOff، ImagePullBackOff، OOM، ایراد در Resource Limit/Request، Selector نادرست Service، مشکلات DNS و خطاهای RBAC را پیدا و ریشهیابی میکند. k8sgpt با استفاده از LLMها (مثلاً OpenAI یا مدلهای محلی) خلاصهای انسانی و مرحلهبهمرحله ارائه میدهد و برای حفظ حریم خصوصی، اطلاعات حساس را قبل از ارسال به سرویسهای خارجی حذف میکند و قابلیت اجرای آفلاین نیز دارد. میتوان آن را بهصورت CLI روی context فعلی kubectl اجرا کرد یا داخل کلاستر مستقر نمود، خروجی انسانخوان یا JSON برای اتوماسیون گرفت و در CI/CD بهکار برد. هرچند عیبیابی را سرعت میدهد، جایگزین پایش و امنیت کامل نیست و کیفیت نتایج به دادهها و مدل انتخابی وابسته است.
#Kubernetes #k8sgpt #DevOps #SRE #CloudNative #Observability #AI #LLM
🟣لینک مقاله:
https://ku.bz/sV6Dnd99T
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
k8sgpt: Kubernetes analyzer
🟢 خلاصه مقاله:
k8sgpt یک ابزار متنباز برای تحلیل Kubernetes است که خطاها و هشدارهای پیچیده را به توضیحات قابلفهم و راهکارهای عملی تبدیل میکند. این ابزار با اسکن منابعی مانند Pod، Deployment، Service، Ingress، Node و همچنین Events و لاگها، خطاهای رایج مثل CrashLoopBackOff، ImagePullBackOff، OOM، ایراد در Resource Limit/Request، Selector نادرست Service، مشکلات DNS و خطاهای RBAC را پیدا و ریشهیابی میکند. k8sgpt با استفاده از LLMها (مثلاً OpenAI یا مدلهای محلی) خلاصهای انسانی و مرحلهبهمرحله ارائه میدهد و برای حفظ حریم خصوصی، اطلاعات حساس را قبل از ارسال به سرویسهای خارجی حذف میکند و قابلیت اجرای آفلاین نیز دارد. میتوان آن را بهصورت CLI روی context فعلی kubectl اجرا کرد یا داخل کلاستر مستقر نمود، خروجی انسانخوان یا JSON برای اتوماسیون گرفت و در CI/CD بهکار برد. هرچند عیبیابی را سرعت میدهد، جایگزین پایش و امنیت کامل نیست و کیفیت نتایج به دادهها و مدل انتخابی وابسته است.
#Kubernetes #k8sgpt #DevOps #SRE #CloudNative #Observability #AI #LLM
🟣لینک مقاله:
https://ku.bz/sV6Dnd99T
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - k8sgpt-ai/k8sgpt: Giving Kubernetes Superpowers to everyone
Giving Kubernetes Superpowers to everyone. Contribute to k8sgpt-ai/k8sgpt development by creating an account on GitHub.
❤1👏1
📢 اگر تلگرام پرمیوم دارید، کانال ما رو Boost کنید ! 🚀
با Boost کردن کانال، به رشد و دیده شدن ما بیشتر کمک کنید💙
https://t.iss.one/boost/DevOps_Labdon
با Boost کردن کانال، به رشد و دیده شدن ما بیشتر کمک کنید💙
https://t.iss.one/boost/DevOps_Labdon
🔵 عنوان مقاله
kclipper: declarative helm management
🟢 خلاصه مقاله:
kclipper روشی سبک برای مدیریت declarative در Helm روی Kubernetes معرفی میکند. بهجای اجرای دستورات پراکنده helm، وضعیت مطلوب شامل نام Chart، نسخه، Namespace و مقادیر در فایلهای نسخهپذیر تعریف میشود تا تغییرات قابل تکرار، بازبینی و حسابرسی باشند. این رویکرد با الگوی GitOps همراستا است و با تکیه بر اعلان وضعیت مطلوب، به کاهش Drift، استانداردسازی سرویسها و تسهیل ارتقا و بازگشت کمک میکند. با حفظ سازگاری با اکوسیستم Helm، تیمهای SRE و DevOps میتوانند سرویسها را در محیطها و کلاسترهای مختلف بهصورت قابل اتکا و یکپارچه مدیریت کنند.
#kclipper #Helm #Kubernetes #GitOps #DevOps #InfrastructureAsCode #CICD #PlatformEngineering
🟣لینک مقاله:
https://ku.bz/qGTw90Kmy
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
kclipper: declarative helm management
🟢 خلاصه مقاله:
kclipper روشی سبک برای مدیریت declarative در Helm روی Kubernetes معرفی میکند. بهجای اجرای دستورات پراکنده helm، وضعیت مطلوب شامل نام Chart، نسخه، Namespace و مقادیر در فایلهای نسخهپذیر تعریف میشود تا تغییرات قابل تکرار، بازبینی و حسابرسی باشند. این رویکرد با الگوی GitOps همراستا است و با تکیه بر اعلان وضعیت مطلوب، به کاهش Drift، استانداردسازی سرویسها و تسهیل ارتقا و بازگشت کمک میکند. با حفظ سازگاری با اکوسیستم Helm، تیمهای SRE و DevOps میتوانند سرویسها را در محیطها و کلاسترهای مختلف بهصورت قابل اتکا و یکپارچه مدیریت کنند.
#kclipper #Helm #Kubernetes #GitOps #DevOps #InfrastructureAsCode #CICD #PlatformEngineering
🟣لینک مقاله:
https://ku.bz/qGTw90Kmy
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - MacroPower/kclipper: KCL + Helm = kclipper
KCL + Helm = kclipper. Contribute to MacroPower/kclipper development by creating an account on GitHub.
🔵 عنوان مقاله
Observing Egress Traffic with Istio
🟢 خلاصه مقاله:
این مقاله نشان میدهد چگونه با استفاده از Istio در محیط Kubernetes میتوان ترافیک خروجی را — چه در حالت بدون رمزنگاری و چه رمزگذاریشده — بهصورت قابل اتکا مشاهده و کنترل کرد. رویکردهای اصلی شامل TLS origination برای آغاز TLS در پروکسی، TLS termination برای پایان دادن TLS در egress gateway و راهاندازی مجدد ارتباط رمزگذاریشده، و همچنین مدیریت گواهیها برای حفظ همزمان امنیت و مشاهدهپذیری است.
برای ترافیک بدون رمزنگاری، با تعریف ServiceEntry، و مسیریابی از طریق VirtualService و DestinationRule، Istio قادر است ترافیک را شناسایی کرده و تلِمتری لایه ۷ مانند متد، مسیر، کدهای پاسخ و تأخیر را از طریق Envoy تولید و به Prometheus/OpenTelemetry ارسال کند.
در ترافیک رمزگذاریشده، اگر برنامهها مستقیماً با HTTPS متصل شوند، مشاهدهپذیری به سطح L3/L4 (مثل SNI، IP/Port، آمار بایت و خطاهای TLS) محدود میشود. برای دستیابی به دید لایه ۷، میتوان TLS origination را در سایدکار یا ترجیحاً در egress gateway فعال کرد تا برنامه با HTTP به پروکسی صحبت کند و پروکسی اتصال TLS به سرویس خارجی را برقرار کند. در سناریوهایی که نیاز به بازرسی HTTPS وجود دارد و برنامه الزاماً HTTPS میزند، الگوی TLS termination در egress gateway و سپس re-origination به مقصد خارجی قابل استفاده است؛ این روش نیازمند توزیع ریشه CA مورداعتماد به ورکلودها و محدودسازی دامنههای قابل رهگیری است.
پایهی این الگوها، مدیریت درست گواهیها است: استفاده از SDS برای بارگذاری پویا، مدیریت ریشههای اعتماد عمومی، صدور گواهیهای مشتری هنگام نیاز به mTLS سمت مقصد خارجی، و رعایت نکاتی مانند SNI/SAN، چرخش خودکار و فرآیند ابطال. در عمل، عبور تمام ترافیک از egress gateway، محدودسازی مقاصد با AuthorizationPolicy، و ترجیح TLS origination در gateway برای کنترل متمرکز توصیه میشود. بدین ترتیب، Istio امکان مشاهدهپذیری ترافیک خروجی را با حفظ الزامات امنیتی و انطباق فراهم میکند.
#Istio #Kubernetes #Egress #TLS #ServiceMesh #Observability #mTLS #CertificateManagement
🟣لینک مقاله:
https://ku.bz/rc3DypN0f
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Observing Egress Traffic with Istio
🟢 خلاصه مقاله:
این مقاله نشان میدهد چگونه با استفاده از Istio در محیط Kubernetes میتوان ترافیک خروجی را — چه در حالت بدون رمزنگاری و چه رمزگذاریشده — بهصورت قابل اتکا مشاهده و کنترل کرد. رویکردهای اصلی شامل TLS origination برای آغاز TLS در پروکسی، TLS termination برای پایان دادن TLS در egress gateway و راهاندازی مجدد ارتباط رمزگذاریشده، و همچنین مدیریت گواهیها برای حفظ همزمان امنیت و مشاهدهپذیری است.
برای ترافیک بدون رمزنگاری، با تعریف ServiceEntry، و مسیریابی از طریق VirtualService و DestinationRule، Istio قادر است ترافیک را شناسایی کرده و تلِمتری لایه ۷ مانند متد، مسیر، کدهای پاسخ و تأخیر را از طریق Envoy تولید و به Prometheus/OpenTelemetry ارسال کند.
در ترافیک رمزگذاریشده، اگر برنامهها مستقیماً با HTTPS متصل شوند، مشاهدهپذیری به سطح L3/L4 (مثل SNI، IP/Port، آمار بایت و خطاهای TLS) محدود میشود. برای دستیابی به دید لایه ۷، میتوان TLS origination را در سایدکار یا ترجیحاً در egress gateway فعال کرد تا برنامه با HTTP به پروکسی صحبت کند و پروکسی اتصال TLS به سرویس خارجی را برقرار کند. در سناریوهایی که نیاز به بازرسی HTTPS وجود دارد و برنامه الزاماً HTTPS میزند، الگوی TLS termination در egress gateway و سپس re-origination به مقصد خارجی قابل استفاده است؛ این روش نیازمند توزیع ریشه CA مورداعتماد به ورکلودها و محدودسازی دامنههای قابل رهگیری است.
پایهی این الگوها، مدیریت درست گواهیها است: استفاده از SDS برای بارگذاری پویا، مدیریت ریشههای اعتماد عمومی، صدور گواهیهای مشتری هنگام نیاز به mTLS سمت مقصد خارجی، و رعایت نکاتی مانند SNI/SAN، چرخش خودکار و فرآیند ابطال. در عمل، عبور تمام ترافیک از egress gateway، محدودسازی مقاصد با AuthorizationPolicy، و ترجیح TLS origination در gateway برای کنترل متمرکز توصیه میشود. بدین ترتیب، Istio امکان مشاهدهپذیری ترافیک خروجی را با حفظ الزامات امنیتی و انطباق فراهم میکند.
#Istio #Kubernetes #Egress #TLS #ServiceMesh #Observability #mTLS #CertificateManagement
🟣لینک مقاله:
https://ku.bz/rc3DypN0f
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
Observing Egress Traffic with Istio
In your Kubernetes cluster, do you observe traffic from your own services to external services?
🔵 عنوان مقاله
Keeper Secrets Manager: Eliminate hard-coded credentials across your environment (Sponsor)
🟢 خلاصه مقاله:
Keeper Secrets Manager راهکار سختکد شدن اعتبارنامهها را با یک معماری zero-knowledge برطرف میکند: اسرار بهصورت سرتاسری رمز میشوند و در زمان اجرا به اپلیکیشنها و پایپلاینها تزریق میگردند تا هیچ کلید یا رمزی در کد و ایمیجها باقی نماند. این سرویس cloud-based و کاملاً مدیریتشده، با ابزارهای رایج DevOps (مثل Jenkins، GitHub Actions، GitLab CI، Kubernetes، Terraform و Ansible) یکپارچه میشود و با چرخش خودکار اعتبارنامهها، سیاستهای دسترسی حداقلی و گزارشگیری، سطح حمله و ریسک انطباق را کاهش میدهد. برای مشاهده قابلیتها میتوانید درخواست دمو بدهید.
#SecretsManagement #DevOps #ZeroKnowledge #CredentialRotation #CloudSecurity #CICD #PAM #ApplicationSecurity
🟣لینک مقاله:
https://www.keepersecurity.com/secrets-manager.html?utm_source=TLDR-Newsletter&utm_medium=Sponsored-Ad-Placement&utm_campaign=September-Secrets-Manager
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Keeper Secrets Manager: Eliminate hard-coded credentials across your environment (Sponsor)
🟢 خلاصه مقاله:
Keeper Secrets Manager راهکار سختکد شدن اعتبارنامهها را با یک معماری zero-knowledge برطرف میکند: اسرار بهصورت سرتاسری رمز میشوند و در زمان اجرا به اپلیکیشنها و پایپلاینها تزریق میگردند تا هیچ کلید یا رمزی در کد و ایمیجها باقی نماند. این سرویس cloud-based و کاملاً مدیریتشده، با ابزارهای رایج DevOps (مثل Jenkins، GitHub Actions، GitLab CI، Kubernetes، Terraform و Ansible) یکپارچه میشود و با چرخش خودکار اعتبارنامهها، سیاستهای دسترسی حداقلی و گزارشگیری، سطح حمله و ریسک انطباق را کاهش میدهد. برای مشاهده قابلیتها میتوانید درخواست دمو بدهید.
#SecretsManagement #DevOps #ZeroKnowledge #CredentialRotation #CloudSecurity #CICD #PAM #ApplicationSecurity
🟣لینک مقاله:
https://www.keepersecurity.com/secrets-manager.html?utm_source=TLDR-Newsletter&utm_medium=Sponsored-Ad-Placement&utm_campaign=September-Secrets-Manager
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Keeper® Password Manager & Digital Vault
Keeper Secrets Manager
Protect secrets and non-human identities with Keeper. Cloud-native, zero-trust secrets management with seamless DevOps integration and automated rotation.
👌1
🔵 عنوان مقاله
kubeseal-convert
🟢 خلاصه مقاله:
kubeseal-convert یک ابزار CLI سبک در کنار Sealed Secrets است که تبدیل مانيفستهای مرتبط با Secret را ساده میکند. این ابزار میتواند Secretهای معمول Kubernetes را به SealedSecret تبدیل کند و همچنین SealedSecretهای موجود را با نسخههای جدید API هماهنگ سازد تا مهاجرتها و نگهداری روزمره بدون خطای دستی انجام شود. kubeseal-convert برای خودکارسازی طراحی شده و بهراحتی در CI/CD، pre-commit و جریانهای GitOps (مثل Argo CD یا Flux) قرار میگیرد تا سازگاری مانيفستها در طول ارتقای کلاستر یا کنترلر حفظ شود. این ابزار جایگزین kubeseal نیست و دادههای محرمانه را رمزگشایی نمیکند؛ تمرکز آن صرفاً بر تبدیل و همسانسازی مانيفستها است. نتیجه، کاهش ریسک عملیاتی و تسهیل مهاجرت در تیمهایی است که با ریپازیتوریهای بزرگ یا چند کلاستر کار میکنند.
#Kubernetes #SealedSecrets #kubeseal #GitOps #DevOps #Security #CI/CD
🟣لینک مقاله:
https://ku.bz/fQPD8MvbX
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
kubeseal-convert
🟢 خلاصه مقاله:
kubeseal-convert یک ابزار CLI سبک در کنار Sealed Secrets است که تبدیل مانيفستهای مرتبط با Secret را ساده میکند. این ابزار میتواند Secretهای معمول Kubernetes را به SealedSecret تبدیل کند و همچنین SealedSecretهای موجود را با نسخههای جدید API هماهنگ سازد تا مهاجرتها و نگهداری روزمره بدون خطای دستی انجام شود. kubeseal-convert برای خودکارسازی طراحی شده و بهراحتی در CI/CD، pre-commit و جریانهای GitOps (مثل Argo CD یا Flux) قرار میگیرد تا سازگاری مانيفستها در طول ارتقای کلاستر یا کنترلر حفظ شود. این ابزار جایگزین kubeseal نیست و دادههای محرمانه را رمزگشایی نمیکند؛ تمرکز آن صرفاً بر تبدیل و همسانسازی مانيفستها است. نتیجه، کاهش ریسک عملیاتی و تسهیل مهاجرت در تیمهایی است که با ریپازیتوریهای بزرگ یا چند کلاستر کار میکنند.
#Kubernetes #SealedSecrets #kubeseal #GitOps #DevOps #Security #CI/CD
🟣لینک مقاله:
https://ku.bz/fQPD8MvbX
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - EladLeev/kubeseal-convert: A tool for importing secrets from a pre-existing secrets management systems (e.g. Vault, Secrets…
A tool for importing secrets from a pre-existing secrets management systems (e.g. Vault, Secrets Manager) into a SealedSecret :shushing_face: - EladLeev/kubeseal-convert
Forwarded from Gopher Academy
واسه برنامه نویسی سیستمی کدوم رو ترجیح میدید؟
البته: با توضیح زیر در نظر بگیرید و انتخاب کنید
اگر میخوای کاملاً به سختافزار نزدیک باشی → برو سراغ C. اگر میخوای ساختار بهتر + سرعت بالا داشته باشی → C++. اگر برات ایمنی و مدرن بودن مهمه → Rust.
البته: با توضیح زیر در نظر بگیرید و انتخاب کنید
اگر میخوای کاملاً به سختافزار نزدیک باشی → برو سراغ C. اگر میخوای ساختار بهتر + سرعت بالا داشته باشی → C++. اگر برات ایمنی و مدرن بودن مهمه → Rust.
Anonymous Poll
35%
C
36%
C++
53%
Rust
🔵 عنوان مقاله
Kubernetes 1.33: Resizing Pods Without the Drama (Finally!)
🟢 خلاصه مقاله:
کوبرنیتس 1.33 روی حل یک درد قدیمی تمرکز دارد: تغییر CPU و Memory یک Pod بدون ریاستارت و رولاوتهای پرهزینه. در نسخههای قبلی، تنظیم request/limit معمولاً به بازسازی Pod یا تغییرات پیچیده در Deployment/StatefulSet ختم میشد که برای سرویسهای حساس یا اپهای stateful دردسرساز بود. در این نسخه، امکان تغییر منابع بهصورت in-place در سطح Pod بسیار روانتر شده است؛ kubelet تغییرات cgroup را روی نود اعمال میکند، حسابداری منابع و زمانبند با درخواستهای جدید هماهنگ میشوند و محدودیتهایی مثل ResourceQuota و LimitRange همچنان رعایت میگردند. نتیجه این است که برای رایتسایزینگ واقعی، کمتر نیاز به رولاوت دارید، ریسک وقفه کاهش مییابد و هزینهها بهتر کنترل میشود. با این حال، همه منابع یکسان قابل تغییر لحظهای نیستند و کاهش تهاجمی Memory میتواند خطر OOM داشته باشد؛ بنابراین توصیه میشود تغییرات مرحلهای انجام شود و با مانیتورینگ دقیق همراه باشد. خلاصه اینکه 1.33 رایتسایزینگ را به یک عملیات کمدردسر و کاربردی تبدیل میکند و زمان تیمها را از مدیریت رولاوتهای غیرضروری به بهینهسازی عملکرد و هزینه روی بارهای واقعی منتقل میسازد.
#Kubernetes #Pods #DevOps #SRE #CloudNative #Autoscaling #ResourceManagement #Containers
🟣لینک مقاله:
https://ku.bz/WwX8zwk0S
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Kubernetes 1.33: Resizing Pods Without the Drama (Finally!)
🟢 خلاصه مقاله:
کوبرنیتس 1.33 روی حل یک درد قدیمی تمرکز دارد: تغییر CPU و Memory یک Pod بدون ریاستارت و رولاوتهای پرهزینه. در نسخههای قبلی، تنظیم request/limit معمولاً به بازسازی Pod یا تغییرات پیچیده در Deployment/StatefulSet ختم میشد که برای سرویسهای حساس یا اپهای stateful دردسرساز بود. در این نسخه، امکان تغییر منابع بهصورت in-place در سطح Pod بسیار روانتر شده است؛ kubelet تغییرات cgroup را روی نود اعمال میکند، حسابداری منابع و زمانبند با درخواستهای جدید هماهنگ میشوند و محدودیتهایی مثل ResourceQuota و LimitRange همچنان رعایت میگردند. نتیجه این است که برای رایتسایزینگ واقعی، کمتر نیاز به رولاوت دارید، ریسک وقفه کاهش مییابد و هزینهها بهتر کنترل میشود. با این حال، همه منابع یکسان قابل تغییر لحظهای نیستند و کاهش تهاجمی Memory میتواند خطر OOM داشته باشد؛ بنابراین توصیه میشود تغییرات مرحلهای انجام شود و با مانیتورینگ دقیق همراه باشد. خلاصه اینکه 1.33 رایتسایزینگ را به یک عملیات کمدردسر و کاربردی تبدیل میکند و زمان تیمها را از مدیریت رولاوتهای غیرضروری به بهینهسازی عملکرد و هزینه روی بارهای واقعی منتقل میسازد.
#Kubernetes #Pods #DevOps #SRE #CloudNative #Autoscaling #ResourceManagement #Containers
🟣لینک مقاله:
https://ku.bz/WwX8zwk0S
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
Kubernetes 1.33: Resizing Pods Without the Drama (Finally!) 🎉
Remember that feeling? You meticulously configured your Kubernetes pods, set the CPU and memory just right (or so you thought), only to…
🎉2
🔵 عنوان مقاله
KubeNodeUsage: Real-Time K8s Node & Pod Metrics from the Terminal
🟢 خلاصه مقاله:
**KubeNodeUsage یک ابزار ترمینالی برای نمایش لحظهای شاخصهای منابع در K8s است که مصرف CPU و حافظه را در سطح Node و Pod نشان میدهد. با نمایی شبیه top و امکان مرتبسازی و فیلتر بر اساس namespace، node یا pod، شناسایی هاتاسپاتها و عیبیابی سریع را ممکن میکند. این ابزار در سناریوهای on-call، استقرار و تست بار، و نیز در محیطهای headless یا CI کاربردی است و با تکیه بر kubeconfig فعلی، بدون نیاز به داشبورد، بینشی فوری از وضعیت کلاستر را مستقیماً در Terminal ارائه میدهد.
#Kubernetes #K8s #Monitoring #Observability #DevOps #SRE #CLI
🟣لینک مقاله:
https://ku.bz/T9pnyMHT4
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
KubeNodeUsage: Real-Time K8s Node & Pod Metrics from the Terminal
🟢 خلاصه مقاله:
**KubeNodeUsage یک ابزار ترمینالی برای نمایش لحظهای شاخصهای منابع در K8s است که مصرف CPU و حافظه را در سطح Node و Pod نشان میدهد. با نمایی شبیه top و امکان مرتبسازی و فیلتر بر اساس namespace، node یا pod، شناسایی هاتاسپاتها و عیبیابی سریع را ممکن میکند. این ابزار در سناریوهای on-call، استقرار و تست بار، و نیز در محیطهای headless یا CI کاربردی است و با تکیه بر kubeconfig فعلی، بدون نیاز به داشبورد، بینشی فوری از وضعیت کلاستر را مستقیماً در Terminal ارائه میدهد.
#Kubernetes #K8s #Monitoring #Observability #DevOps #SRE #CLI
🟣لینک مقاله:
https://ku.bz/T9pnyMHT4
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - AKSarav/KubeNodeUsage: KubeNodeUsage is a Terminal App designed to provide insights into Kubernetes node and pod usage.…
KubeNodeUsage is a Terminal App designed to provide insights into Kubernetes node and pod usage. It offers both interactive exploration and command-line filtering options to help you analyze your c...
🏆1🤝1
👋 درود به همه دوستان عزیز
📌 اگر شما هم مقاله، مطلب آموزشی یا هر چیزی که فکر میکنید درباره devops میتونه مفید باشه دارید، خوشحال میشم برام بفرستید تا با اسم خودتون توی کانال منتشر کنم.
🤝 اینطوری هم به بقیه کمک میکنید و هم محتوای ارزشمندتون بیشتر دیده میشه.
📌 اگر شما هم مقاله، مطلب آموزشی یا هر چیزی که فکر میکنید درباره devops میتونه مفید باشه دارید، خوشحال میشم برام بفرستید تا با اسم خودتون توی کانال منتشر کنم.
🤝 اینطوری هم به بقیه کمک میکنید و هم محتوای ارزشمندتون بیشتر دیده میشه.
❤1
🔵 عنوان مقاله
Orchestrating thousands of speedtests, using Kubernetes
🟢 خلاصه مقاله:
اجرای هزاران تست سرعت در مقیاس بالا یک مسئله هماهنگی و مقیاسپذیری است. با کانتینریکردن رانرها و اجرای آنها بهصورت Jobs/CronJobs در Kubernetes میتوان تعداد زیادی Pod را موازی اجرا کرد، منابع را با requests/limits کنترل نمود و با برچسبگذاری، affinity و taints/tolerations آنها را در نودها و ریجنهای مناسب جایگذاری کرد. HPA و autoscaling کلاستر امکان انفجار مقیاس و جمعشدن تا صفر را میدهند و با زمانبندی پلهای، پینکردن CPU و policyهای شبکه، خطای اندازهگیری کاهش مییابد. جمعآوری داده از اجرای تستها از مسیر صف/ذخیرهسازی شیگرا یا پایگاه سریزمان مستقل میشود و یک سرویس aggregator اعتبارسنجی و خلاصهسازی را انجام میدهد. مشاهدهپذیری با Prometheus و داشبوردهای Grafana خط سیر اجرا، نرخ خطا و توزیع تاخیرها را نشان میدهد؛ همچنین با backoff، idempotency، rate limiting و مدیریت secrets پایداری افزایش مییابد و همگامسازی زمان، مقایسهپذیری را بهبود میدهد. برای هزینه و تابآوری، از batch window، priority class، نودهای spot/preemptible، PDB و چندریجنی/چندابری استفاده میشود. نتیجه اینکه با تکیه بر الگوهای بومی Kubernetes مانند Jobs، CronJobs، autoscaling و صفها، ارکستریشن هزاران تست سرعت قابل اتکا، تکرارپذیر و مقرونبهصرفه میشود.
#Kubernetes #SpeedTest #LoadTesting #NetworkPerformance #Scalability #DevOps #CloudNative #Observability
🟣لینک مقاله:
https://ku.bz/m-yzWmZCh
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Orchestrating thousands of speedtests, using Kubernetes
🟢 خلاصه مقاله:
اجرای هزاران تست سرعت در مقیاس بالا یک مسئله هماهنگی و مقیاسپذیری است. با کانتینریکردن رانرها و اجرای آنها بهصورت Jobs/CronJobs در Kubernetes میتوان تعداد زیادی Pod را موازی اجرا کرد، منابع را با requests/limits کنترل نمود و با برچسبگذاری، affinity و taints/tolerations آنها را در نودها و ریجنهای مناسب جایگذاری کرد. HPA و autoscaling کلاستر امکان انفجار مقیاس و جمعشدن تا صفر را میدهند و با زمانبندی پلهای، پینکردن CPU و policyهای شبکه، خطای اندازهگیری کاهش مییابد. جمعآوری داده از اجرای تستها از مسیر صف/ذخیرهسازی شیگرا یا پایگاه سریزمان مستقل میشود و یک سرویس aggregator اعتبارسنجی و خلاصهسازی را انجام میدهد. مشاهدهپذیری با Prometheus و داشبوردهای Grafana خط سیر اجرا، نرخ خطا و توزیع تاخیرها را نشان میدهد؛ همچنین با backoff، idempotency، rate limiting و مدیریت secrets پایداری افزایش مییابد و همگامسازی زمان، مقایسهپذیری را بهبود میدهد. برای هزینه و تابآوری، از batch window، priority class، نودهای spot/preemptible، PDB و چندریجنی/چندابری استفاده میشود. نتیجه اینکه با تکیه بر الگوهای بومی Kubernetes مانند Jobs، CronJobs، autoscaling و صفها، ارکستریشن هزاران تست سرعت قابل اتکا، تکرارپذیر و مقرونبهصرفه میشود.
#Kubernetes #SpeedTest #LoadTesting #NetworkPerformance #Scalability #DevOps #CloudNative #Observability
🟣لینک مقاله:
https://ku.bz/m-yzWmZCh
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
Orchestrating thousands of Speedtests, using Kubernetes
Orchestrating thousands of Speedtests, using Kubernetes To monitor the network usability and speed of our store systems over time, we addressed the challenge by implementing a distributed speed test …
🔵 عنوان مقاله
From CI to Kubernetes Catalog: Building a Composable Platform with GitOps and vCluster
🟢 خلاصه مقاله:
** این مقاله مسیر گذار از CI به یک Kubernetes Catalog کامل را توضیح میدهد و نشان میدهد چگونه میتوان با یک معماری سهلایه و ماژولار روی Kubernetes یک Internal Developer Platform ترکیبپذیر ساخت. در لایه زیرین، vCluster محیطهای ایزوله و چندمستاجره ایجاد میکند؛ در لایه میانی، بهترینروشها بهصورت قالبها و Helm chartهای قابلاستفادهمجدد کپسوله میشوند؛ و در لایه بالایی، خروجیهای CI از طریق GitOps بهصورت امن و قابل ردیابی به محیطهای مقصد اعمال میگردند. در نهایت، یک Kubernetes Catalog بهعنوان درگاه سلفسرویس برای مؤلفههای تأییدشده و مسیرهای طلایی فراهم میشود تا تیمها با حفظ استانداردها، سریعتر و مطمئنتر استقرار دهند.
#Kubernetes #GitOps #PlatformEngineering #InternalDeveloperPlatform #Helm #vCluster #DevOps #CICD
🟣لینک مقاله:
https://ku.bz/tr_Py62FF
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
From CI to Kubernetes Catalog: Building a Composable Platform with GitOps and vCluster
🟢 خلاصه مقاله:
** این مقاله مسیر گذار از CI به یک Kubernetes Catalog کامل را توضیح میدهد و نشان میدهد چگونه میتوان با یک معماری سهلایه و ماژولار روی Kubernetes یک Internal Developer Platform ترکیبپذیر ساخت. در لایه زیرین، vCluster محیطهای ایزوله و چندمستاجره ایجاد میکند؛ در لایه میانی، بهترینروشها بهصورت قالبها و Helm chartهای قابلاستفادهمجدد کپسوله میشوند؛ و در لایه بالایی، خروجیهای CI از طریق GitOps بهصورت امن و قابل ردیابی به محیطهای مقصد اعمال میگردند. در نهایت، یک Kubernetes Catalog بهعنوان درگاه سلفسرویس برای مؤلفههای تأییدشده و مسیرهای طلایی فراهم میشود تا تیمها با حفظ استانداردها، سریعتر و مطمئنتر استقرار دهند.
#Kubernetes #GitOps #PlatformEngineering #InternalDeveloperPlatform #Helm #vCluster #DevOps #CICD
🟣لینک مقاله:
https://ku.bz/tr_Py62FF
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
From CI to Kubernetes Catalog: Building a Composable Platform with GitOps and vCluster
A practical guide for Platform Engineers to create reusable, self-service Kubernetes environments using Helm, Score, Kro, and more.
🔵 عنوان مقاله
Scalable ML with Azure, Kubernetes and KEDA: Generating Inputs with 500 Pods
🟢 خلاصه مقاله:
**
این مطالعهٔ موردی نشان میدهد چگونه میتوان یک خط لولهٔ ML مقیاسپذیر روی Azure ساخت که با استفاده از Kubernetes و KEDA ورودیها را بهصورت رویدادمحور و تا سقف 500 پاد تولید میکند و سپس مدلها را از طریق Azure ML آموزش، ثبت و استقرار میدهد. در این معماری، KEDA با پایش صفها یا استریمها اندازهٔ خوشه را بهطور خودکار بالا و پایین میبرد، هر پاد بخشی از کار را پردازش میکند، و خروجیها در ذخیرهسازی پایدار ذخیره میشوند تا Azure ML آنها را برای آموزش و ارزیابی مصرف کند. استقرار مدلها روی online/batch endpoints (مدیریتشده یا AKS) انجام میشود و کل فرایند با CI/CD، مانیتورینگ در Azure Monitor/Application Insights، کنترل هزینه و ملاحظات امنیتی (managed identity و شبکه خصوصی) پشتیبانی میگردد. نتیجه، الگویی مطمئن برای آمادهسازی ورودی با توان انفجاری 500 پاد و MLOps استاندارد روی Azure است.
#Azure #Kubernetes #KEDA #AzureML #AKS #MLOps #Scalability #DataEngineering
🟣لینک مقاله:
https://ku.bz/0lYz58fTX
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Scalable ML with Azure, Kubernetes and KEDA: Generating Inputs with 500 Pods
🟢 خلاصه مقاله:
**
این مطالعهٔ موردی نشان میدهد چگونه میتوان یک خط لولهٔ ML مقیاسپذیر روی Azure ساخت که با استفاده از Kubernetes و KEDA ورودیها را بهصورت رویدادمحور و تا سقف 500 پاد تولید میکند و سپس مدلها را از طریق Azure ML آموزش، ثبت و استقرار میدهد. در این معماری، KEDA با پایش صفها یا استریمها اندازهٔ خوشه را بهطور خودکار بالا و پایین میبرد، هر پاد بخشی از کار را پردازش میکند، و خروجیها در ذخیرهسازی پایدار ذخیره میشوند تا Azure ML آنها را برای آموزش و ارزیابی مصرف کند. استقرار مدلها روی online/batch endpoints (مدیریتشده یا AKS) انجام میشود و کل فرایند با CI/CD، مانیتورینگ در Azure Monitor/Application Insights، کنترل هزینه و ملاحظات امنیتی (managed identity و شبکه خصوصی) پشتیبانی میگردد. نتیجه، الگویی مطمئن برای آمادهسازی ورودی با توان انفجاری 500 پاد و MLOps استاندارد روی Azure است.
#Azure #Kubernetes #KEDA #AzureML #AKS #MLOps #Scalability #DataEngineering
🟣لینک مقاله:
https://ku.bz/0lYz58fTX
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
Scalable ML with Azure, Kubernetes and KEDA: Generating Inputs with 500 Pods
A real-world look at building a scalable ML system on Azure — from dynamic input generation to model inference using Kubernetes and…