Forwarded from Daniele Polencic
What's your biggest Kubernetes resource management headache?
Final Results
39%
🔥 CPU throttling/OOM kills
23%
🎯 Getting devs to set requests/limits
35%
📊 No idea what values to use
3%
🤔 Other (share your thought)
Forwarded from Daniele Polencic
Do you use network policies in your Kubernetes clusters?
Final Results
22%
✅ Yes, everywhere
41%
🔃 For ingress/egress traffic
9%
🧭 For east west traffic only
28%
🤔 Other
Forwarded from Daniele Polencic
What's the largest Kubernetes cluster size you've seen in production (or read in the news)?
Final Results
76%
🔢 <1,000 nodes
14%
⚡ 1,000-10,000 nodes
5%
🚀 >10,000 nodes
5%
🤔 Other
🔵 عنوان مقاله
Launch Kubernetes job on-demand with Python
🟢 خلاصه مقاله:
این آموزش نشان می‌دهد چگونه با یک سرویس پایتونی داخل کلاستر، شغل‌های Kubernetes را به‌صورت درخواستی و برنامه‌وار از طریق API کلاستر ایجاد، پایش و حذف کنید. راهنما شامل استقرار سرویس با ServiceAccount و RBAC حداقلی، استفاده از کلاینت رسمی پایتون، ساخت مانفیست Job با تنظیماتی مانند تصویر، فرمان، منابع، برچسب‌ها، backoffLimit، parallelism و TTL، و نیز پایش وضعیت، دریافت لاگ‌ها و پاک‌سازی پس از اتمام است. در پایان، الگوهای ادغام (HTTP/صف)، امنیت و مشاهده‌پذیری بررسی می‌شوند تا بتوانید وظایف دسته‌ای را هر زمان لازم شد به‌طور مطمئن اجرا کنید.
🟣لینک مقاله:
https://ku.bz/B7FCLZw4-
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Launch Kubernetes job on-demand with Python
🟢 خلاصه مقاله:
این آموزش نشان می‌دهد چگونه با یک سرویس پایتونی داخل کلاستر، شغل‌های Kubernetes را به‌صورت درخواستی و برنامه‌وار از طریق API کلاستر ایجاد، پایش و حذف کنید. راهنما شامل استقرار سرویس با ServiceAccount و RBAC حداقلی، استفاده از کلاینت رسمی پایتون، ساخت مانفیست Job با تنظیماتی مانند تصویر، فرمان، منابع، برچسب‌ها، backoffLimit، parallelism و TTL، و نیز پایش وضعیت، دریافت لاگ‌ها و پاک‌سازی پس از اتمام است. در پایان، الگوهای ادغام (HTTP/صف)، امنیت و مشاهده‌پذیری بررسی می‌شوند تا بتوانید وظایف دسته‌ای را هر زمان لازم شد به‌طور مطمئن اجرا کنید.
🟣لینک مقاله:
https://ku.bz/B7FCLZw4-
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
Launch Kubernetes Job on-demand with Python
Kubernetes Job launched programmatically with Python
❤1
🔵 عنوان مقاله
Securing Kubernetes Resources Without a VPN
🟢 خلاصه مقاله:
** این آموزش نشان می‌دهد چگونه بدون استفاده از VPN می‌توان دسترسی به سرویس‌های Kubernetes را با تکیه بر الگوی «احراز هویت در لبه» ایمن کرد. ترکیب ingress-nginx و oauth2-proxy احراز هویت OAuth 2.0/OIDC را برای سرویس‌ها فراهم می‌کند؛ کاربر به ارائه‌دهنده هویت (مثل Google، GitHub یا Azure AD) هدایت می‌شود، پس از ورود، کوکی جلسه صادر می‌گردد و فقط درخواست‌های معتبر به سرویس‌ها می‌رسند. پیکربندی شامل استقرار oauth2-proxy، تنظیم کلاینت/کوکی‌سیکرت، افزودن annotationهای احراز هویت به Ingress و فعال‌سازی TLS است. نتیجه: کنترل دسترسی متمرکز، SSO و MFA بدون پیچیدگی‌های VPN، مناسب برای حفاظت از داشبوردها و پنل‌های مدیریتی داخل کلاستر.
🟣لینک مقاله:
https://ku.bz/z67cDR8Fg
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Securing Kubernetes Resources Without a VPN
🟢 خلاصه مقاله:
** این آموزش نشان می‌دهد چگونه بدون استفاده از VPN می‌توان دسترسی به سرویس‌های Kubernetes را با تکیه بر الگوی «احراز هویت در لبه» ایمن کرد. ترکیب ingress-nginx و oauth2-proxy احراز هویت OAuth 2.0/OIDC را برای سرویس‌ها فراهم می‌کند؛ کاربر به ارائه‌دهنده هویت (مثل Google، GitHub یا Azure AD) هدایت می‌شود، پس از ورود، کوکی جلسه صادر می‌گردد و فقط درخواست‌های معتبر به سرویس‌ها می‌رسند. پیکربندی شامل استقرار oauth2-proxy، تنظیم کلاینت/کوکی‌سیکرت، افزودن annotationهای احراز هویت به Ingress و فعال‌سازی TLS است. نتیجه: کنترل دسترسی متمرکز، SSO و MFA بدون پیچیدگی‌های VPN، مناسب برای حفاظت از داشبوردها و پنل‌های مدیریتی داخل کلاستر.
🟣لینک مقاله:
https://ku.bz/z67cDR8Fg
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
Securing Kubernetes Resources Without a VPN
OAuth2 Proxy and NGINX
How Container Filesystem Works: Building a Docker-like Container From Scratch
https://labs.iximiuz.com/tutorials/container-filesystem-from-scratch
https://labs.iximiuz.com/tutorials/container-filesystem-from-scratch
iximiuz Labs
How Container Filesystem Works: Building a Docker-like Container From Scratch | iximiuz Labs
Learn how Linux containers are built from the ground up. Starting with the mount namespace and a root filesystem, see why PID, cgroup, UTS, and network namespaces naturally follow - and how this foundation makes concepts like bind mounts, volumes, and persistence…
🔵 عنوان مقاله
Kgateway – An amazing tool to simplify traffic management using Kubernetes API Gateway
🟢 خلاصه مقاله:
این مقاله Kgateway را به‌عنوان یک راهکار بومیِ Kubernetes برای ساده‌سازی مدیریت ترافیک معرفی می‌کند. Kgateway با تکیه بر Gateway API، تعریف ورودی‌ها، مسیرها و سیاست‌ها را استاندارد و قابل‌اتکا می‌کند و به‌جای وابستگی به Ingressهای ناهمگون، یک مدل واحد و نقش‌محور ارائه می‌دهد: تیم پلتفرم زیرساخت و TLS را تعریف می‌کند و تیم‌های اپلیکیشن به‌صورت ایمن و در سطح نام‌فضا، Route و سیاست‌های خود را متصل می‌کنند. قابلیت‌هایی مانند مسیریابی HTTP/TCP، اتصال امن با TLS، احراز هویت و محدودسازی نرخ، شکل‌دهی درخواست و نیز الگوهای انتشار تدریجی مانند ترافیک‌سپاری (canary/blue‑green) با تعریفات اعلان‌محور (CRD) و قابل‌خودکارسازی (GitOps) فراهم می‌شود. مقاله همچنین بر مشاهده‌پذیری، وضعیت‌دهی شفاف برای Gateway و Route، و اعمال سیاست‌های سراسری در کنار سفارشی‌سازی سرویس‌ها تأکید دارد و با مثال‌های کوتاه YAML نشان می‌دهد چگونه با چند مانیفست می‌توان مسیریابی، TLS و سیاست‌ها را پیاده‌سازی کرد. جمع‌بندی مقاله این است که Kgateway با همسویی با استانداردهای Kubernetes، پیچیدگی را کاهش داده، تحویل تغییرات را سریع‌تر و عملیات روزمره را قابل‌اتکاتر می‌کند.
🟣لینک مقاله:
https://ku.bz/skdrwG11K
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Kgateway – An amazing tool to simplify traffic management using Kubernetes API Gateway
🟢 خلاصه مقاله:
این مقاله Kgateway را به‌عنوان یک راهکار بومیِ Kubernetes برای ساده‌سازی مدیریت ترافیک معرفی می‌کند. Kgateway با تکیه بر Gateway API، تعریف ورودی‌ها، مسیرها و سیاست‌ها را استاندارد و قابل‌اتکا می‌کند و به‌جای وابستگی به Ingressهای ناهمگون، یک مدل واحد و نقش‌محور ارائه می‌دهد: تیم پلتفرم زیرساخت و TLS را تعریف می‌کند و تیم‌های اپلیکیشن به‌صورت ایمن و در سطح نام‌فضا، Route و سیاست‌های خود را متصل می‌کنند. قابلیت‌هایی مانند مسیریابی HTTP/TCP، اتصال امن با TLS، احراز هویت و محدودسازی نرخ، شکل‌دهی درخواست و نیز الگوهای انتشار تدریجی مانند ترافیک‌سپاری (canary/blue‑green) با تعریفات اعلان‌محور (CRD) و قابل‌خودکارسازی (GitOps) فراهم می‌شود. مقاله همچنین بر مشاهده‌پذیری، وضعیت‌دهی شفاف برای Gateway و Route، و اعمال سیاست‌های سراسری در کنار سفارشی‌سازی سرویس‌ها تأکید دارد و با مثال‌های کوتاه YAML نشان می‌دهد چگونه با چند مانیفست می‌توان مسیریابی، TLS و سیاست‌ها را پیاده‌سازی کرد. جمع‌بندی مقاله این است که Kgateway با همسویی با استانداردهای Kubernetes، پیچیدگی را کاهش داده، تحویل تغییرات را سریع‌تر و عملیات روزمره را قابل‌اتکاتر می‌کند.
🟣لینک مقاله:
https://ku.bz/skdrwG11K
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
DEV Community
kgateway: An amazing tool to simplify traffic management using Kubernetes API Gateway
Kgateway is a feature-rich, fast, and flexible Kubernetes-native ingress controller and...
Forwarded from Bardia & Erfan
✨ درود به همه دوستان ✨
به مناسبت روز برنامه‌نویس 🎉
می‌تونید فقط با ۲۰۰ هزار تومان تبلیغ‌تون رو توی تمام کانال‌های زیر منتشر کنید!
📌 این فرصت ویژه فقط تا پایان همین هفته اعتبار داره.
⏳برای هماهنگی بیشتر به ای دی زیر پیام بدید👾
@mrbardia72
🔽 لیست کانال‌هایی که تبلیغ در اون‌ها قرار می‌گیره:
https://t.iss.one/addlist/AJ7rh2IzIh02NTI0
به مناسبت روز برنامه‌نویس 🎉
می‌تونید فقط با ۲۰۰ هزار تومان تبلیغ‌تون رو توی تمام کانال‌های زیر منتشر کنید!
📌 این فرصت ویژه فقط تا پایان همین هفته اعتبار داره.
⏳برای هماهنگی بیشتر به ای دی زیر پیام بدید👾
@mrbardia72
🔽 لیست کانال‌هایی که تبلیغ در اون‌ها قرار می‌گیره:
https://t.iss.one/addlist/AJ7rh2IzIh02NTI0
🔵 عنوان مقاله
Why Kube-State-Metrics Matters for Kubernetes Observability
🟢 خلاصه مقاله:
کوبه‌استیت‌متریکس با تبدیل وضعیت اشیای کوبرنتیز به متریک‌های پرومتئوس، شکاف مهمی در مشاهده‌پذیری برطرف می‌کند: به‌جای فقط منابع و کانتینرها، می‌توانید سلامت واقعی اشیایی مثل Deployment، Pod، Job، CronJob، Node، PVC، HPA و ResourceQuota را ببینید. این سرویس فقط خواندنی است، از API کوبرنتیز وضعیت‌ها را می‌خواند و برای پرومتئوس اکسپوز می‌کند و در کنار node_exporter و cAdvisor و متریک‌های اپلیکیشن کار می‌کند. نصب معمولاً با Helm انجام می‌شود؛ سپس پرومتئوس باید سرویس KSM را اسکرپ کند (با ServiceMonitor در Prometheus Operator یا اسکرپ‌کانفیگ/Annotation). پس از آن می‌توانید هشدارها و داشبوردهایی برای مواردی مانند پادهای Pending یا CrashLoop، عدم کفایت Replica در Deployment/StatefulSet، شکست Job/CronJob، نودهای NotReady، PVC/PVهای Bind نشده، ناهماهنگی HPA و نزدیک‌شدن به حد Quota بسازید. برای کارایی بهتر، برچسب‌های پرکاردی‌نال را حذف کنید، از لیست سفید متریک‌ها استفاده کنید، RBAC را حداقلی نگه دارید و در صورت نیاز دامنه نام‌فضاها یا شاردینگ را تنظیم کنید. نتیجه، دید دقیق و کم‌هزینه‌ای از وضعیت واقعی کلاستر از منظر خود کوبرنتیز است.
🟣لینک مقاله:
https://ku.bz/3nNd4bDkK
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Why Kube-State-Metrics Matters for Kubernetes Observability
🟢 خلاصه مقاله:
کوبه‌استیت‌متریکس با تبدیل وضعیت اشیای کوبرنتیز به متریک‌های پرومتئوس، شکاف مهمی در مشاهده‌پذیری برطرف می‌کند: به‌جای فقط منابع و کانتینرها، می‌توانید سلامت واقعی اشیایی مثل Deployment، Pod، Job، CronJob، Node، PVC، HPA و ResourceQuota را ببینید. این سرویس فقط خواندنی است، از API کوبرنتیز وضعیت‌ها را می‌خواند و برای پرومتئوس اکسپوز می‌کند و در کنار node_exporter و cAdvisor و متریک‌های اپلیکیشن کار می‌کند. نصب معمولاً با Helm انجام می‌شود؛ سپس پرومتئوس باید سرویس KSM را اسکرپ کند (با ServiceMonitor در Prometheus Operator یا اسکرپ‌کانفیگ/Annotation). پس از آن می‌توانید هشدارها و داشبوردهایی برای مواردی مانند پادهای Pending یا CrashLoop، عدم کفایت Replica در Deployment/StatefulSet، شکست Job/CronJob، نودهای NotReady، PVC/PVهای Bind نشده، ناهماهنگی HPA و نزدیک‌شدن به حد Quota بسازید. برای کارایی بهتر، برچسب‌های پرکاردی‌نال را حذف کنید، از لیست سفید متریک‌ها استفاده کنید، RBAC را حداقلی نگه دارید و در صورت نیاز دامنه نام‌فضاها یا شاردینگ را تنظیم کنید. نتیجه، دید دقیق و کم‌هزینه‌ای از وضعیت واقعی کلاستر از منظر خود کوبرنتیز است.
🟣لینک مقاله:
https://ku.bz/3nNd4bDkK
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
Why Kube-State-Metrics Matters for Kubernetes Observability
Empower your Kubernetes monitoring with Kube-State-Metrics
🔵 عنوان مقاله
Pangolin: Self-Hosted Zero Trust Tunnel with Identity and Access Control
🟢 خلاصه مقاله:
**پنگولین یک تونل خودمیزبان مبتنی بر اصل «اعتماد صفر» است که دسترسی به سرویس‌های داخلی را هویت‌محور و سیاست‌محور می‌کند. به‌جای باز کردن پورت‌ها یا استفاده از VPNهای یکپارچه، پنگولین سرویس‌هایی مانند وب‌اپ‌ها، SSH و پایگاه‌داده را از طریق تونل‌های خروجیِ رمزنگاری‌شده منتشر می‌کند و برای هر درخواست، هویت و مجوز را بررسی می‌کند. عامل‌های سبک‌وزن نزدیک سرویس‌ها اجرا می‌شوند، تونل‌های رمزنگاری‌شده را به صفحهٔ کنترلِ خودمیزبان برقرار می‌کنند، و صفحهٔ کنترل به‌عنوان پراکسی آگاه از هویت، سیاست‌های دسترسی دقیق (کاربر/گروه/منبع/زمان) را اعمال می‌کند. نتیجه، اجرای حداقل دسترسی، اعتبارهای کوتاه‌عمر، لاگ‌های ممیزی متمرکز و مدیریت ساده‌تر است؛ با سطح حمله کمتر و کنترل کامل سازمان بر داده‌ها و کلیدها، و بدون نیاز به باز کردن پورت‌های ورودی.
🟣لینک مقاله:
https://ku.bz/MzkRYlF1l
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Pangolin: Self-Hosted Zero Trust Tunnel with Identity and Access Control
🟢 خلاصه مقاله:
**پنگولین یک تونل خودمیزبان مبتنی بر اصل «اعتماد صفر» است که دسترسی به سرویس‌های داخلی را هویت‌محور و سیاست‌محور می‌کند. به‌جای باز کردن پورت‌ها یا استفاده از VPNهای یکپارچه، پنگولین سرویس‌هایی مانند وب‌اپ‌ها، SSH و پایگاه‌داده را از طریق تونل‌های خروجیِ رمزنگاری‌شده منتشر می‌کند و برای هر درخواست، هویت و مجوز را بررسی می‌کند. عامل‌های سبک‌وزن نزدیک سرویس‌ها اجرا می‌شوند، تونل‌های رمزنگاری‌شده را به صفحهٔ کنترلِ خودمیزبان برقرار می‌کنند، و صفحهٔ کنترل به‌عنوان پراکسی آگاه از هویت، سیاست‌های دسترسی دقیق (کاربر/گروه/منبع/زمان) را اعمال می‌کند. نتیجه، اجرای حداقل دسترسی، اعتبارهای کوتاه‌عمر، لاگ‌های ممیزی متمرکز و مدیریت ساده‌تر است؛ با سطح حمله کمتر و کنترل کامل سازمان بر داده‌ها و کلیدها، و بدون نیاز به باز کردن پورت‌های ورودی.
🟣لینک مقاله:
https://ku.bz/MzkRYlF1l
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - fosrl/pangolin: Identity-Aware Tunneled Reverse Proxy Server with Dashboard UI
Identity-Aware Tunneled Reverse Proxy Server with Dashboard UI - fosrl/pangolin
🔵 عنوان مقاله
watchall: Track All Resource Changes
🟢 خلاصه مقاله:
**watchall راهی ساده و یکپارچه برای مشاهده همه تغییرات منابع، به‌صورت لحظه‌ای و در یک نماست. این ابزار با جمع‌آوری و نرمال‌سازی رویدادهای ایجاد، حذف و تغییر پیکربندی از انواع منابع، یک خط زمانی واحد می‌سازد که نشان می‌دهد چه تغییری، چه زمانی و توسط چه کسی/چیزی رخ داده است. با فیلتر و جست‌وجو می‌توان سریعاً بر یک سرویس، بازه زمانی یا نوع تغییر تمرکز کرد و رویدادها را با لاگ‌ها و متریک‌ها هم‌بند نمود. نتیجه، کاهش زمان عیب‌یابی، تسهیل ممیزی و پاسخ‌گویی به رخدادها، و دیدی روشن از «چه چیزی، چه زمانی تغییر کرد» است؛ آن هم با سربار کم، مقیاس‌پذیری مناسب، و امکان ادغام از طریق API/CLI/UI.
🟣لینک مقاله:
https://ku.bz/WncbdWtvp
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
watchall: Track All Resource Changes
🟢 خلاصه مقاله:
**watchall راهی ساده و یکپارچه برای مشاهده همه تغییرات منابع، به‌صورت لحظه‌ای و در یک نماست. این ابزار با جمع‌آوری و نرمال‌سازی رویدادهای ایجاد، حذف و تغییر پیکربندی از انواع منابع، یک خط زمانی واحد می‌سازد که نشان می‌دهد چه تغییری، چه زمانی و توسط چه کسی/چیزی رخ داده است. با فیلتر و جست‌وجو می‌توان سریعاً بر یک سرویس، بازه زمانی یا نوع تغییر تمرکز کرد و رویدادها را با لاگ‌ها و متریک‌ها هم‌بند نمود. نتیجه، کاهش زمان عیب‌یابی، تسهیل ممیزی و پاسخ‌گویی به رخدادها، و دیدی روشن از «چه چیزی، چه زمانی تغییر کرد» است؛ آن هم با سربار کم، مقیاس‌پذیری مناسب، و امکان ادغام از طریق API/CLI/UI.
🟣لینک مقاله:
https://ku.bz/WncbdWtvp
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - guettli/watchall: Watch all Kubernetes Resources
Watch all Kubernetes Resources. Contribute to guettli/watchall development by creating an account on GitHub.
🔵 عنوان مقاله
Helm Diff Plugin: Predict Your Helm Changes
🟢 خلاصه مقاله:
پلاگین Helm Diff قبل از اجرای upgrade یا rollback در Helm، با مقایسه وضعیت فعلی کلاستر با مانیفست‌های پیشنهادی، دقیقاً نشان می‌دهد چه منابعی اضافه، تغییر یا حذف می‌شوند. این مقایسه جزئیات تغییرات را در سطح فیلدهای مختلف منابع (مثل Deployment، ConfigMap و Service) قابل مشاهده می‌کند و ریسک غافلگیری در استقرار را کاهش می‌دهد. استفاده از آن پیش از upgrade یا rollback—به‌ویژه در جریان‌های CI/CD و بازبینی تغییرات—باعث می‌شود استقرارها شفاف‌تر، ایمن‌تر و قابل پیش‌بینی‌تر انجام شوند.
🟣لینک مقاله:
https://ku.bz/xHDpw9s3p
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Helm Diff Plugin: Predict Your Helm Changes
🟢 خلاصه مقاله:
پلاگین Helm Diff قبل از اجرای upgrade یا rollback در Helm، با مقایسه وضعیت فعلی کلاستر با مانیفست‌های پیشنهادی، دقیقاً نشان می‌دهد چه منابعی اضافه، تغییر یا حذف می‌شوند. این مقایسه جزئیات تغییرات را در سطح فیلدهای مختلف منابع (مثل Deployment، ConfigMap و Service) قابل مشاهده می‌کند و ریسک غافلگیری در استقرار را کاهش می‌دهد. استفاده از آن پیش از upgrade یا rollback—به‌ویژه در جریان‌های CI/CD و بازبینی تغییرات—باعث می‌شود استقرارها شفاف‌تر، ایمن‌تر و قابل پیش‌بینی‌تر انجام شوند.
🟣لینک مقاله:
https://ku.bz/xHDpw9s3p
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - databus23/helm-diff: A helm plugin that shows a diff explaining what a helm upgrade would change
A helm plugin that shows a diff explaining what a helm upgrade would change - databus23/helm-diff
👍1
🔵 عنوان مقاله
KubeTidy
🟢 خلاصه مقاله:
KubeTidy ابزاری برای پاک‌سازی، ادغام و بهینه‌سازی پیکربندی‌های Kubernetes است. با شناسایی موارد زائد و ناسازگاری‌ها، حذف منابع بلااستفاده و یکپارچه‌سازی مانيفست‌ها از محیط‌ها و تیم‌های مختلف، تعارض‌ها را کاهش می‌دهد و خروجی منسجم‌تری تولید می‌کند. همچنین با ترویج بهترین‌روش‌ها و ساده‌سازی تنظیمات، استقرارها را قابل‌اعتمادتر و کارآمدتر می‌سازد.
🟣لینک مقاله:
https://ku.bz/Y11pS6WY6
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
KubeTidy
🟢 خلاصه مقاله:
KubeTidy ابزاری برای پاک‌سازی، ادغام و بهینه‌سازی پیکربندی‌های Kubernetes است. با شناسایی موارد زائد و ناسازگاری‌ها، حذف منابع بلااستفاده و یکپارچه‌سازی مانيفست‌ها از محیط‌ها و تیم‌های مختلف، تعارض‌ها را کاهش می‌دهد و خروجی منسجم‌تری تولید می‌کند. همچنین با ترویج بهترین‌روش‌ها و ساده‌سازی تنظیمات، استقرارها را قابل‌اعتمادتر و کارآمدتر می‌سازد.
🟣لینک مقاله:
https://ku.bz/Y11pS6WY6
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
KubeTidy
Home
The docs page for KubeTidy!
🔵 عنوان مقاله
Stop Searching. Start Finding with AI-powered Enterprise Search. (Sponsor)
🟢 خلاصه مقاله:
این ایبوک جدید اسلک نشان می‌دهد جست‌وجوی سازمانی مبتنی بر هوش مصنوعه چگونه دانش پراکنده در ابزارها و گفتگوها را به پاسخ‌های سریع و قابل اتکا تبدیل می‌کند. با اتصال منابع، تعیین دسترسی و گنجاندن جست‌وجو در جریان کار، تیم‌ها به‌جای وقت‌گذرانی برای یافتن اطلاعات، به نتیجه می‌رسند. راهبردهای عملی کتاب—از بهبود برچسب‌گذاری و مستندسازی تا سنجش اثر—به واحدهای مختلف مثل پشتیبانی، فروش، فنی و منابع انسانی کمک می‌کند پاسخ‌ها و سوابق مرتبط را فوراً بیابند. حاصل کار، آزادسازی هوش جمعی سازمان و افزایش بهره‌وری در سراسر واحدهاست.
🟣لینک مقاله:
https://slack.com/resources/why-use-slack/from-searching-to-finding-the-new-era-of-ai-powered-enterprise-knowledge?d=701ed00000D87jZAAR&nc=701ed00000D8aGsAAJ&utm_source=&utm_medium=tp_email&utm_campaign=amer_us_slack->slackinvoice_&utm_content=allsegments_all-strategic-tldrai-primary-from-searching_701ed00000D87jZAAR_english_from-searching-to-finding-the-new-era-of-ai-powered-enterprise-knowledge
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Stop Searching. Start Finding with AI-powered Enterprise Search. (Sponsor)
🟢 خلاصه مقاله:
این ایبوک جدید اسلک نشان می‌دهد جست‌وجوی سازمانی مبتنی بر هوش مصنوعه چگونه دانش پراکنده در ابزارها و گفتگوها را به پاسخ‌های سریع و قابل اتکا تبدیل می‌کند. با اتصال منابع، تعیین دسترسی و گنجاندن جست‌وجو در جریان کار، تیم‌ها به‌جای وقت‌گذرانی برای یافتن اطلاعات، به نتیجه می‌رسند. راهبردهای عملی کتاب—از بهبود برچسب‌گذاری و مستندسازی تا سنجش اثر—به واحدهای مختلف مثل پشتیبانی، فروش، فنی و منابع انسانی کمک می‌کند پاسخ‌ها و سوابق مرتبط را فوراً بیابند. حاصل کار، آزادسازی هوش جمعی سازمان و افزایش بهره‌وری در سراسر واحدهاست.
🟣لینک مقاله:
https://slack.com/resources/why-use-slack/from-searching-to-finding-the-new-era-of-ai-powered-enterprise-knowledge?d=701ed00000D87jZAAR&nc=701ed00000D8aGsAAJ&utm_source=&utm_medium=tp_email&utm_campaign=amer_us_slack->slackinvoice_&utm_content=allsegments_all-strategic-tldrai-primary-from-searching_701ed00000D87jZAAR_english_from-searching-to-finding-the-new-era-of-ai-powered-enterprise-knowledge
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Slack
From Searching to Finding: The New Era of AI-Powered Enterprise Knowledge
Learn how Slack’s enterprise search connects all your apps and conversations into one secure, searchable interface—so answers come to you, not the other way around. Download now.
🔵 عنوان مقاله
Fine-grained control with configurable HPA tolerance
🟢 خلاصه مقاله:
** در Kubernetes v1.33، ویژگی «تحمل» در HPA از حالت ثابت و سراسری ۱۰٪ به حالتی قابل‌تنظیم تبدیل شده است. این تغییر امکان می‌دهد حساسیت مقیاس‌گذاری بر اساس نیاز هر بارکاری تنظیم شود؛ به‌طوری‌که برای سرویس‌های حساس، واکنش سریع‌تری فراهم شود و برای بارهای پرنوسان، نوسان و مقیاس‌گذاری بی‌مورد کاهش یابد. نتیجه، کنترل دقیق‌تر، ثبات بالاتر و انطباق بهتر رفتار مقیاس‌گذاری با اهداف عملکردی و هزینه‌ای هر سرویس است.
🟣لینک مقاله:
https://ku.bz/bKTsLjC6h
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Fine-grained control with configurable HPA tolerance
🟢 خلاصه مقاله:
** در Kubernetes v1.33، ویژگی «تحمل» در HPA از حالت ثابت و سراسری ۱۰٪ به حالتی قابل‌تنظیم تبدیل شده است. این تغییر امکان می‌دهد حساسیت مقیاس‌گذاری بر اساس نیاز هر بارکاری تنظیم شود؛ به‌طوری‌که برای سرویس‌های حساس، واکنش سریع‌تری فراهم شود و برای بارهای پرنوسان، نوسان و مقیاس‌گذاری بی‌مورد کاهش یابد. نتیجه، کنترل دقیق‌تر، ثبات بالاتر و انطباق بهتر رفتار مقیاس‌گذاری با اهداف عملکردی و هزینه‌ای هر سرویس است.
🟣لینک مقاله:
https://ku.bz/bKTsLjC6h
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Fine-Grained Control with Configurable HPA Tolerance
Kubernetes v1.33 adds per-HPA configurable tolerance, allowing fine-tuned scaling sensitivity for both scale-up and scale-down decisions.
🔵 عنوان مقاله
allowPrivilegeEscalation: false: The Kubernetes Security Flag With a Hidden Catch
🟢 خلاصه مقاله:
این مقاله توضیح می‌دهد که allowPrivilegeEscalation: false در کوبرنتیز فقط بخشی از مسئله را حل می‌کند. این تنظیم با تکیه بر no_new_privs لینوکس مانع افزایش دسترسی از مسیرهایی مثل setuid/setgid و قابلیت‌های فایل می‌شود، اما امتیازهای موجود را حذف نمی‌کند و جلوی راه‌های دیگر ارتقای دسترسی را نمی‌گیرد. اگر کانتینر با دسترسی‌های قوی (مثلاً root، قابلیت‌های زیاد، privileged)، اتصال به نام‌فضاهای میزبان، hostPath یا سوکت‌های ران‌تایم اجرا شود، یا توکن سرویس‌اکانت اختیار بالایی داشته باشد، مهاجم هنوز می‌تواند پیشروی کند. نتیجه این‌که این فلگ مفید است ولی کافی نیست و باید در کنار کنترل‌های مکمل مثل اجرا به‌صورت non-root، حذف کامل قابلیت‌ها و افزودن حداقل‌های لازم، فعال‌سازی seccomp/AppArmor/SELinux، فایل‌سیستم فقط‌خواندنی، منع privileged/hostPath/hostPID، و اعمال خط‌مشی‌های Pod Security و ابزارهایی مانند Kyverno/Gatekeeper به‌کار رود. نکته کلیدی: allowPrivilegeEscalation فقط جلوی بخشی از سناریوهای افزایش دسترسی را می‌گیرد و جایگزین دفاع چندلایه نیست.
🟣لینک مقاله:
https://ku.bz/RpcSdbpgK
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
allowPrivilegeEscalation: false: The Kubernetes Security Flag With a Hidden Catch
🟢 خلاصه مقاله:
این مقاله توضیح می‌دهد که allowPrivilegeEscalation: false در کوبرنتیز فقط بخشی از مسئله را حل می‌کند. این تنظیم با تکیه بر no_new_privs لینوکس مانع افزایش دسترسی از مسیرهایی مثل setuid/setgid و قابلیت‌های فایل می‌شود، اما امتیازهای موجود را حذف نمی‌کند و جلوی راه‌های دیگر ارتقای دسترسی را نمی‌گیرد. اگر کانتینر با دسترسی‌های قوی (مثلاً root، قابلیت‌های زیاد، privileged)، اتصال به نام‌فضاهای میزبان، hostPath یا سوکت‌های ران‌تایم اجرا شود، یا توکن سرویس‌اکانت اختیار بالایی داشته باشد، مهاجم هنوز می‌تواند پیشروی کند. نتیجه این‌که این فلگ مفید است ولی کافی نیست و باید در کنار کنترل‌های مکمل مثل اجرا به‌صورت non-root، حذف کامل قابلیت‌ها و افزودن حداقل‌های لازم، فعال‌سازی seccomp/AppArmor/SELinux، فایل‌سیستم فقط‌خواندنی، منع privileged/hostPath/hostPID، و اعمال خط‌مشی‌های Pod Security و ابزارهایی مانند Kyverno/Gatekeeper به‌کار رود. نکته کلیدی: allowPrivilegeEscalation فقط جلوی بخشی از سناریوهای افزایش دسترسی را می‌گیرد و جایگزین دفاع چندلایه نیست.
🟣لینک مقاله:
https://ku.bz/RpcSdbpgK
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
allowPrivilegeEscalation: false: The Kubernetes Security Flag With a Hidden Catch
A deep dive into what it claims, what it actually does, and where it fails
🔵 عنوان مقاله
Telepresence: code against remote clusters
🟢 خلاصه مقاله:
**تل‌پرزِنس ابزاری برای توسعه روی کوبرنتیز است که اجازه می‌دهد سرویس را محلی اجرا کنید اما آن را به کلاستر راه دور متصل نگه دارید. با ایجاد تونل دوطرفه، سرویس محلی شما مانند یک پاد داخل کلاستر عمل می‌کند: به DNS و سرویس‌های کلاستر دسترسی دارد و می‌تواند درخواست‌های سرویس هدف را به سمت ماشین شما «اینترسپت» کند. نتیجه این است که بدون ساخت و استقرار مداوم ایمیج‌ها، می‌توان با هات‌ریلود و دیباگ، تغییرات را سریع و روی وابستگی‌های واقعی آزمایش کرد. این روش چرخه بازخورد توسعه را کوتاه می‌کند و شکاف «روی سیستم من کار می‌کند» را کاهش می‌دهد. با وجود رعایت RBAC و امکان محدودسازی اینترسپت‌ها، باید به تأخیر شبکه، اختلاف نسخه‌ها و اثرات جانبی روی کلاسترهای اشتراکی توجه کرد.
🟣لینک مقاله:
https://ku.bz/XKwy1m0-k
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Telepresence: code against remote clusters
🟢 خلاصه مقاله:
**تل‌پرزِنس ابزاری برای توسعه روی کوبرنتیز است که اجازه می‌دهد سرویس را محلی اجرا کنید اما آن را به کلاستر راه دور متصل نگه دارید. با ایجاد تونل دوطرفه، سرویس محلی شما مانند یک پاد داخل کلاستر عمل می‌کند: به DNS و سرویس‌های کلاستر دسترسی دارد و می‌تواند درخواست‌های سرویس هدف را به سمت ماشین شما «اینترسپت» کند. نتیجه این است که بدون ساخت و استقرار مداوم ایمیج‌ها، می‌توان با هات‌ریلود و دیباگ، تغییرات را سریع و روی وابستگی‌های واقعی آزمایش کرد. این روش چرخه بازخورد توسعه را کوتاه می‌کند و شکاف «روی سیستم من کار می‌کند» را کاهش می‌دهد. با وجود رعایت RBAC و امکان محدودسازی اینترسپت‌ها، باید به تأخیر شبکه، اختلاف نسخه‌ها و اثرات جانبی روی کلاسترهای اشتراکی توجه کرد.
🟣لینک مقاله:
https://ku.bz/XKwy1m0-k
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
telepresence.io
Home | Telepresence
Telepresence: a local development environment for a remote Kubernetes cluster
🔵 عنوان مقاله
Zeta reduces banking incident response time by 80% with Amazon OpenSearch Service observability (15 minute read)
🟢 خلاصه مقاله:
زتا سامانه «Customer Service Navigator» را بر بستر Amazon OpenSearch Service پیاده‌سازی کرده تا مانیتورینگ سراسر پلتفرم بانکی چندمستاجری خود را یکپارچه کند. این راهکار با ارائه دید لحظه‌ای، تفکیک امن مستاجران و نگهداشت خودکار و مطابق مقررات، مرجع واحدی از لاگ‌ها، متریک‌ها و تریس‌ها در اختیار تیم‌ها می‌گذارد. سامانه روزانه حدود ۳ ترابایت داده را پردازش می‌کند و با تسهیل جست‌وجو و هم‌بستگی داده‌ها، یافتن ریشه مشکلات را سریع‌تر می‌سازد. نتیجه، کاهش بیش از ۸۰٪ در میانگین زمان رفع مشکل و کاهش زمان واکنش از بیش از ۳۰ دقیقه به کمتر از ۵ دقیقه بوده که به بهبود تاب‌آوری پلتفرم و رضایت مشتری انجامیده است.
🟣لینک مقاله:
https://aws.amazon.com/blogs/big-data/zeta-reduces-banking-incident-response-time-by-80-with-amazon-opensearch-service-observability/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Zeta reduces banking incident response time by 80% with Amazon OpenSearch Service observability (15 minute read)
🟢 خلاصه مقاله:
زتا سامانه «Customer Service Navigator» را بر بستر Amazon OpenSearch Service پیاده‌سازی کرده تا مانیتورینگ سراسر پلتفرم بانکی چندمستاجری خود را یکپارچه کند. این راهکار با ارائه دید لحظه‌ای، تفکیک امن مستاجران و نگهداشت خودکار و مطابق مقررات، مرجع واحدی از لاگ‌ها، متریک‌ها و تریس‌ها در اختیار تیم‌ها می‌گذارد. سامانه روزانه حدود ۳ ترابایت داده را پردازش می‌کند و با تسهیل جست‌وجو و هم‌بستگی داده‌ها، یافتن ریشه مشکلات را سریع‌تر می‌سازد. نتیجه، کاهش بیش از ۸۰٪ در میانگین زمان رفع مشکل و کاهش زمان واکنش از بیش از ۳۰ دقیقه به کمتر از ۵ دقیقه بوده که به بهبود تاب‌آوری پلتفرم و رضایت مشتری انجامیده است.
🟣لینک مقاله:
https://aws.amazon.com/blogs/big-data/zeta-reduces-banking-incident-response-time-by-80-with-amazon-opensearch-service-observability/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Amazon
Zeta reduces banking incident response time by 80% with Amazon OpenSearch Service observability | Amazon Web Services
In this post we explain how Zeta built a more unified monitoring solution using Amazon OpenSearch Service that improved performance, reduced manual processes, and increased end-user satisfaction. Zeta has achieved over an 80% reduction in mean time to resolution…
🔵 عنوان مقاله
Kubernetes Secrets Management with External Secrets Operator (ESO)
🟢 خلاصه مقاله:
** این آموزش نشان می‌دهد چگونه با External Secrets Operator (ESO) اسرار Kubernetes را مستقیماً از مدیرهای خارجی مانند AWS Secrets Manager همگام‌سازی کنیم. ESO با تعریف منابع سفارشی مانند SecretStore/ClusterSecretStore برای اتصال امن به ارائه‌دهنده و ExternalSecret برای نگاشت کلیدها، مقادیر را به صورت خودکار به Secrets بومی Kubernetes تبدیل و به‌روزرسانی می‌کند. در این راهنما نصب ESO، پیکربندی احراز هویت امن در AWS (مثل IRSA)، ایجاد SecretStore، تعریف ExternalSecret، مصرف Secret در پادها، و نمایش چرخش خودکار اسرار پوشش داده می‌شود. همچنین بهترین‌روش‌ها شامل حداقل‌سازی دسترسی‌های IAM، استفاده از KMS، محدوده‌دهی در سطح نام‌فضا یا کلاستر، و تنظیم بازه‌های تازه‌سازی مطرح می‌شود. خروجی کار، مدیریت خودکار و قابل اتکای اسرار با همگام‌سازی و چرخش آسان در Kubernetes است.
🟣لینک مقاله:
https://ku.bz/z4S56kDPQ
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Kubernetes Secrets Management with External Secrets Operator (ESO)
🟢 خلاصه مقاله:
** این آموزش نشان می‌دهد چگونه با External Secrets Operator (ESO) اسرار Kubernetes را مستقیماً از مدیرهای خارجی مانند AWS Secrets Manager همگام‌سازی کنیم. ESO با تعریف منابع سفارشی مانند SecretStore/ClusterSecretStore برای اتصال امن به ارائه‌دهنده و ExternalSecret برای نگاشت کلیدها، مقادیر را به صورت خودکار به Secrets بومی Kubernetes تبدیل و به‌روزرسانی می‌کند. در این راهنما نصب ESO، پیکربندی احراز هویت امن در AWS (مثل IRSA)، ایجاد SecretStore، تعریف ExternalSecret، مصرف Secret در پادها، و نمایش چرخش خودکار اسرار پوشش داده می‌شود. همچنین بهترین‌روش‌ها شامل حداقل‌سازی دسترسی‌های IAM، استفاده از KMS، محدوده‌دهی در سطح نام‌فضا یا کلاستر، و تنظیم بازه‌های تازه‌سازی مطرح می‌شود. خروجی کار، مدیریت خودکار و قابل اتکای اسرار با همگام‌سازی و چرخش آسان در Kubernetes است.
🟣لینک مقاله:
https://ku.bz/z4S56kDPQ
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
Kubernetes Secrets Management with External Secrets Operator (ESO)
How I moved from Kubernetes Generic Secrets to External Secrets Operator…