🔵 عنوان مقاله
uber/kraken
🟢 خلاصه مقاله:
Kraken از سوی Uber یک سامانه متن‌باز برای توزیع تصاویر Docker/OCI به‌صورت P2P است که مشکل کندی و فشار روی رجیستری مرکزی در مقیاس‌های بزرگ را حل می‌کند. هر میزبان پس از دریافت بخش‌هایی از تصویر، همان بخش‌ها را به همتایان نزدیک خود می‌دهد و به این شکل بار از روی منبع مرکزی برداشته می‌شود و استقرارها سریع‌تر انجام می‌شوند. Kraken با یک origin/registry، یک tracker و agentهای میزبان کار می‌کند و از طریق یک proxy سازگار با Docker Registry HTTP API v2 بدون نیاز به تغییر در Docker، containerd یا Kubernetes قابل استفاده است؛ در صورت نبود همتا، به‌صورت خودکار به origin برمی‌گردد. این سیستم با تکیه بر content-addressed storage و بررسی digest، یکپارچگی داده را تضمین کرده و با کش، deduplication، مشاهدهپذیری و امکان ادغام با CDN برای سناریوهای چند-دیتاسنتری همراه است. نتیجه، توزیع سریع‌تر و قابل‌اعتمادتر تصاویر در CI/CD، استقرارهای blue/green یا canary و کلاسترهای Kubernetes بزرگ است.
#Uber #Kraken #Docker #P2P #ContainerRegistry #Kubernetes #DevOps #OpenSource
🟣لینک مقاله:
https://ku.bz/Hvt7Zs8wg
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
uber/kraken
🟢 خلاصه مقاله:
Kraken از سوی Uber یک سامانه متن‌باز برای توزیع تصاویر Docker/OCI به‌صورت P2P است که مشکل کندی و فشار روی رجیستری مرکزی در مقیاس‌های بزرگ را حل می‌کند. هر میزبان پس از دریافت بخش‌هایی از تصویر، همان بخش‌ها را به همتایان نزدیک خود می‌دهد و به این شکل بار از روی منبع مرکزی برداشته می‌شود و استقرارها سریع‌تر انجام می‌شوند. Kraken با یک origin/registry، یک tracker و agentهای میزبان کار می‌کند و از طریق یک proxy سازگار با Docker Registry HTTP API v2 بدون نیاز به تغییر در Docker، containerd یا Kubernetes قابل استفاده است؛ در صورت نبود همتا، به‌صورت خودکار به origin برمی‌گردد. این سیستم با تکیه بر content-addressed storage و بررسی digest، یکپارچگی داده را تضمین کرده و با کش، deduplication، مشاهدهپذیری و امکان ادغام با CDN برای سناریوهای چند-دیتاسنتری همراه است. نتیجه، توزیع سریع‌تر و قابل‌اعتمادتر تصاویر در CI/CD، استقرارهای blue/green یا canary و کلاسترهای Kubernetes بزرگ است.
#Uber #Kraken #Docker #P2P #ContainerRegistry #Kubernetes #DevOps #OpenSource
🟣لینک مقاله:
https://ku.bz/Hvt7Zs8wg
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - uber/kraken: P2P Docker registry capable of distributing TBs of data in seconds
P2P Docker registry capable of distributing TBs of data in seconds - uber/kraken
🔵 عنوان مقاله
FRP — Fast Reverse Proxy
🟢 خلاصه مقاله:
FRP یا Fast Reverse Proxy یک ابزار متن‌باز و سریع برای در دسترس قرار دادن سرویس‌های داخل شبکه‌های خصوصی در اینترنت عمومی است؛ بدون نیاز به باز کردن پورت‌های ورودی یا تغییرات پیچیده در NAT و فایروال. معماری آن مبتنی بر frpc (در داخل شبکه) و frps (روی سرور عمومی) است و با اتصال پایدار و اتصال‌های چندگانه، تأخیر را کم و کارایی را بالا نگه می‌دارد. از TCP، UDP، HTTP و HTTPS پشتیبانی می‌کند و ویژگی‌هایی مانند مسیربندی بر اساس دامنه و زیر‌دامنه، SNI، احراز هویت، TLS و فشرده‌سازی را ارائه می‌دهد. داشبورد داخلی برای مشاهده ترافیک و وضعیت پروکسی‌ها در دسترس است و گزینه‌های امنیتی مانند STCP و محدودسازی دسترسی برای کاهش سطح حمله فراهم شده است. کاربردهای رایج شامل دسترسی راه‌دور به SSH/RDP، انتشار سرویس‌های توسعه برای دمو یا Webhook، تونل‌کردن پایگاه‌داده و کنترل دستگاه‌های IoT است. FRP یک باینری سبک و چندسکویی (Linux، Windows، macOS) نوشته‌شده با Go است و برای استقرار در محیط‌های تولیدی و پروژه‌های شخصی مناسب است.
#frp #reverse-proxy #tunneling #NATTraversal #Networking #DevOps #SelfHosting #GoLang
🟣لینک مقاله:
https://ku.bz/74QXmzGvz
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
FRP — Fast Reverse Proxy
🟢 خلاصه مقاله:
FRP یا Fast Reverse Proxy یک ابزار متن‌باز و سریع برای در دسترس قرار دادن سرویس‌های داخل شبکه‌های خصوصی در اینترنت عمومی است؛ بدون نیاز به باز کردن پورت‌های ورودی یا تغییرات پیچیده در NAT و فایروال. معماری آن مبتنی بر frpc (در داخل شبکه) و frps (روی سرور عمومی) است و با اتصال پایدار و اتصال‌های چندگانه، تأخیر را کم و کارایی را بالا نگه می‌دارد. از TCP، UDP، HTTP و HTTPS پشتیبانی می‌کند و ویژگی‌هایی مانند مسیربندی بر اساس دامنه و زیر‌دامنه، SNI، احراز هویت، TLS و فشرده‌سازی را ارائه می‌دهد. داشبورد داخلی برای مشاهده ترافیک و وضعیت پروکسی‌ها در دسترس است و گزینه‌های امنیتی مانند STCP و محدودسازی دسترسی برای کاهش سطح حمله فراهم شده است. کاربردهای رایج شامل دسترسی راه‌دور به SSH/RDP، انتشار سرویس‌های توسعه برای دمو یا Webhook، تونل‌کردن پایگاه‌داده و کنترل دستگاه‌های IoT است. FRP یک باینری سبک و چندسکویی (Linux، Windows، macOS) نوشته‌شده با Go است و برای استقرار در محیط‌های تولیدی و پروژه‌های شخصی مناسب است.
#frp #reverse-proxy #tunneling #NATTraversal #Networking #DevOps #SelfHosting #GoLang
🟣لینک مقاله:
https://ku.bz/74QXmzGvz
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - fatedier/frp: A fast reverse proxy to help you expose a local server behind a NAT or firewall to the internet.
A fast reverse proxy to help you expose a local server behind a NAT or firewall to the internet. - fatedier/frp
🔵 عنوان مقاله
Nelm – Helm 3 Replacement and Kubernetes Deployment Engine
🟢 خلاصه مقاله:
این مقاله ابزار جدیدی به نام Nelm را معرفی می‌کند که به‌عنوان جایگزینی برای Helm 3 و یک موتور استقرار برای Kubernetes مطرح شده است. هدف Nelm ساده‌سازی بسته‌بندی، قالب‌دهی و استقرار سرویس‌ها بر بستر Kubernetes است، به‌طوری که هم قدرت و هم سادگی در کنار هم حفظ شوند.
در این معرفی، بر استقرارهای اعلامی، قابلیت بازتولید، تشخیص drift و بازگشت ایمن (rollback) تأکید می‌شود. Nelm تلاش می‌کند چرخه انتقال بین محیط‌ها (از توسعه تا تولید) را استاندارد و قابل اطمینان کند و همراه با سیاست‌های کنترلی و امنیتی، الزامات سازمانی را بدون کندکردن تحویل برآورده سازد.
از نظر تجربه توسعه‌دهنده، مقاله می‌گوید Nelm با الهام از الگوهای آشنا در Helm 3، مشکلاتی مانند شکنندگی templating و مدیریت values را هدف قرار داده و روی اعتبارسنجی ورودی‌ها، مدیریت وابستگی‌ها و ماژول‌های قابل‌استفاده‌مجدد تمرکز دارد. همچنین هم‌نشینی با جریان‌های GitOps و CI/CD، پشتیبانی از رجیستری‌های OCI و مدیریت امن secrets از محورهای کلیدی است.
در مجموع، Nelm به‌عنوان مسیری عملی برای تیم‌هایی معرفی می‌شود که می‌خواهند از پیچیدگی‌ها و بار شناختی استقرارهای Kubernetes بکاهند، در عین حال با اکوسیستم موجود سازگار بمانند و مهاجرتی قابل‌مدیریت از Helm 3 داشته باشند.
#Kubernetes #Helm #DevOps #GitOps #CloudNative #Containers #InfrastructureAsCode
🟣لینک مقاله:
https://ku.bz/YTzSDVJdl
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Nelm – Helm 3 Replacement and Kubernetes Deployment Engine
🟢 خلاصه مقاله:
این مقاله ابزار جدیدی به نام Nelm را معرفی می‌کند که به‌عنوان جایگزینی برای Helm 3 و یک موتور استقرار برای Kubernetes مطرح شده است. هدف Nelm ساده‌سازی بسته‌بندی، قالب‌دهی و استقرار سرویس‌ها بر بستر Kubernetes است، به‌طوری که هم قدرت و هم سادگی در کنار هم حفظ شوند.
در این معرفی، بر استقرارهای اعلامی، قابلیت بازتولید، تشخیص drift و بازگشت ایمن (rollback) تأکید می‌شود. Nelm تلاش می‌کند چرخه انتقال بین محیط‌ها (از توسعه تا تولید) را استاندارد و قابل اطمینان کند و همراه با سیاست‌های کنترلی و امنیتی، الزامات سازمانی را بدون کندکردن تحویل برآورده سازد.
از نظر تجربه توسعه‌دهنده، مقاله می‌گوید Nelm با الهام از الگوهای آشنا در Helm 3، مشکلاتی مانند شکنندگی templating و مدیریت values را هدف قرار داده و روی اعتبارسنجی ورودی‌ها، مدیریت وابستگی‌ها و ماژول‌های قابل‌استفاده‌مجدد تمرکز دارد. همچنین هم‌نشینی با جریان‌های GitOps و CI/CD، پشتیبانی از رجیستری‌های OCI و مدیریت امن secrets از محورهای کلیدی است.
در مجموع، Nelm به‌عنوان مسیری عملی برای تیم‌هایی معرفی می‌شود که می‌خواهند از پیچیدگی‌ها و بار شناختی استقرارهای Kubernetes بکاهند، در عین حال با اکوسیستم موجود سازگار بمانند و مهاجرتی قابل‌مدیریت از Helm 3 داشته باشند.
#Kubernetes #Helm #DevOps #GitOps #CloudNative #Containers #InfrastructureAsCode
🟣لینک مقاله:
https://ku.bz/YTzSDVJdl
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - werf/nelm: Nelm is a Helm 3 alternative. It is a Kubernetes deployment tool that manages Helm Charts and deploys them…
Nelm is a Helm 3 alternative. It is a Kubernetes deployment tool that manages Helm Charts and deploys them to Kubernetes. - werf/nelm
👍1
🔵 عنوان مقاله
xdatabase-proxy – Kubernetes-Aware DB Proxy Service
🟢 خلاصه مقاله:
**xdatabase-proxy یک DB proxy آگاه به Kubernetes و نوشته‌شده با Go است که برای کارایی بالا در خوشه‌های Kubernetes طراحی شده. این ابزار با انجام TLS termination امنیت ارتباطات را متمرکز می‌کند، و با اتکا به Kubernetes labels مسیریابی پویا را ممکن می‌سازد تا ترافیک بر اساس محیط، تَنَنت یا استراتژی‌های استقرار مثل blue/green و canary به‌صورت لحظه‌ای هدایت شود. همچنین با مدیریت اتصال سبک، سربار منابع و تأخیر را کاهش می‌دهد و برای بارهای کاری مایکروسرویس مناسب است. مخزن پروژه در github.com/hasirciogli در دسترس است.
#Kubernetes #DatabaseProxy #Go #TLS #CloudNative #Microservices #DevOps #K8s
🟣لینک مقاله:
https://ku.bz/gsskv052H
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
xdatabase-proxy – Kubernetes-Aware DB Proxy Service
🟢 خلاصه مقاله:
**xdatabase-proxy یک DB proxy آگاه به Kubernetes و نوشته‌شده با Go است که برای کارایی بالا در خوشه‌های Kubernetes طراحی شده. این ابزار با انجام TLS termination امنیت ارتباطات را متمرکز می‌کند، و با اتکا به Kubernetes labels مسیریابی پویا را ممکن می‌سازد تا ترافیک بر اساس محیط، تَنَنت یا استراتژی‌های استقرار مثل blue/green و canary به‌صورت لحظه‌ای هدایت شود. همچنین با مدیریت اتصال سبک، سربار منابع و تأخیر را کاهش می‌دهد و برای بارهای کاری مایکروسرویس مناسب است. مخزن پروژه در github.com/hasirciogli در دسترس است.
#Kubernetes #DatabaseProxy #Go #TLS #CloudNative #Microservices #DevOps #K8s
🟣لینک مقاله:
https://ku.bz/gsskv052H
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
🔵 عنوان مقاله
MySQL Operator for Kubernetes – Oracle’s InnoDB Cluster Operator
🟢 خلاصه مقاله:
MySQL Operator برای Kubernetes (معروف به Oracle’s InnoDB Cluster Operator) با استفاده از CRDها مدیریت کاملاً اعلان‌محور یک InnoDBCluster را ممکن می‌کند. این اپراتور با استقرار خودکار چندین نمونه MySQL، پیکربندی Group Replication برای HA، راه‌اندازی MySQL Router جهت ارائه Endpointهای پایدار، و بهره‌گیری از MySQL Shell برای بوت‌استرپ و عملیات مدیریتی، چرخه عمر پایدار و تکرارپذیر پایگاه داده را فراهم می‌سازد. توانمندی‌های کلیدی شامل مقیاس‌پذیری کنترل‌شده، ارتقای مرحله‌ای (Rolling Upgrade)، خودترمیمی و Failover خودکار، و ادغام سناریوهای پشتیبان‌گیری و بازیابی است. رصدپذیری از طریق Probeها، رخدادهای Kubernetes و یکپارچه‌سازی با Prometheus/Grafana انجام می‌شود. برای شروع، کافی است Operator را نصب کرده و یک CR از نوع InnoDBCluster تعریف کنید؛ سپس با در نظر گرفتن کلاس ذخیره‌سازی، منابع، سیاست‌های امنیتی و سازگاری نسخه‌ها، برنامه‌ها را از طریق سرویس‌های MySQL Router متصل نمایید. نتیجه، اجرای ساده‌تر و قابل‌اتکای MySQL در محیط‌های ابری و GitOps با حفظ بهترین‌روش‌های عملیاتی است.
#MySQL #Kubernetes #Operator #InnoDBCluster #Oracle #CloudNative #DevOps #DatabaseOps
🟣لینک مقاله:
https://ku.bz/b-GysQSNm
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
MySQL Operator for Kubernetes – Oracle’s InnoDB Cluster Operator
🟢 خلاصه مقاله:
MySQL Operator برای Kubernetes (معروف به Oracle’s InnoDB Cluster Operator) با استفاده از CRDها مدیریت کاملاً اعلان‌محور یک InnoDBCluster را ممکن می‌کند. این اپراتور با استقرار خودکار چندین نمونه MySQL، پیکربندی Group Replication برای HA، راه‌اندازی MySQL Router جهت ارائه Endpointهای پایدار، و بهره‌گیری از MySQL Shell برای بوت‌استرپ و عملیات مدیریتی، چرخه عمر پایدار و تکرارپذیر پایگاه داده را فراهم می‌سازد. توانمندی‌های کلیدی شامل مقیاس‌پذیری کنترل‌شده، ارتقای مرحله‌ای (Rolling Upgrade)، خودترمیمی و Failover خودکار، و ادغام سناریوهای پشتیبان‌گیری و بازیابی است. رصدپذیری از طریق Probeها، رخدادهای Kubernetes و یکپارچه‌سازی با Prometheus/Grafana انجام می‌شود. برای شروع، کافی است Operator را نصب کرده و یک CR از نوع InnoDBCluster تعریف کنید؛ سپس با در نظر گرفتن کلاس ذخیره‌سازی، منابع، سیاست‌های امنیتی و سازگاری نسخه‌ها، برنامه‌ها را از طریق سرویس‌های MySQL Router متصل نمایید. نتیجه، اجرای ساده‌تر و قابل‌اتکای MySQL در محیط‌های ابری و GitOps با حفظ بهترین‌روش‌های عملیاتی است.
#MySQL #Kubernetes #Operator #InnoDBCluster #Oracle #CloudNative #DevOps #DatabaseOps
🟣لینک مقاله:
https://ku.bz/b-GysQSNm
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - mysql/mysql-operator: MySQL Operator for Kubernetes
MySQL Operator for Kubernetes. Contribute to mysql/mysql-operator development by creating an account on GitHub.
🔵 عنوان مقاله
KEDA HTTP Add-on: scale on requests
🟢 خلاصه مقاله:
مقیاس‌گذاری خودکار برای سرویس‌های HTTP در Kubernetes با تکیه بر سیگنال‌های CPU/Memory دقیق نیست. KEDA HTTP Add-on این مشکل را با مقیاس‌گذاری بر اساس ترافیک واقعی HTTP (درخواست‌های در حال پردازش و در صف) حل می‌کند. این افزونه با KEDA یکپارچه است، از scale-to-zero پشتیبانی می‌کند، با یک پروکسی سبک جلوی سرویس صف‌سازی و مسیربندی امن انجام می‌دهد تا هنگام جهش ترافیک، بارگذاری سرد و ازدحام کنترل شود. پیکربندی آن از طریق HTTPScaledObject انجام می‌شود و با Ingress و Service Mesh سازگار است، معمولاً بدون نیاز به تغییر کد برنامه. برای رصدپذیری، متریک‌ها به Prometheus صادر می‌شوند و با Grafana قابل مانیتور هستند. نتیجه، هم‌راست‌سازی تعداد Replicaها با تقاضای واقعی HTTP برای بهبود کارایی، کاهش هزینه و پوشش بهتر ترافیک‌های انفجاری است؛ همچنین می‌تواند در کنار HPA و سایر Scalerهای KEDA استفاده شود.
#KEDA #Kubernetes #Autoscaling #HTTP #Serverless #CloudNative #DevOps #Observability
🟣لینک مقاله:
https://ku.bz/9TQrYJkKK
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
KEDA HTTP Add-on: scale on requests
🟢 خلاصه مقاله:
مقیاس‌گذاری خودکار برای سرویس‌های HTTP در Kubernetes با تکیه بر سیگنال‌های CPU/Memory دقیق نیست. KEDA HTTP Add-on این مشکل را با مقیاس‌گذاری بر اساس ترافیک واقعی HTTP (درخواست‌های در حال پردازش و در صف) حل می‌کند. این افزونه با KEDA یکپارچه است، از scale-to-zero پشتیبانی می‌کند، با یک پروکسی سبک جلوی سرویس صف‌سازی و مسیربندی امن انجام می‌دهد تا هنگام جهش ترافیک، بارگذاری سرد و ازدحام کنترل شود. پیکربندی آن از طریق HTTPScaledObject انجام می‌شود و با Ingress و Service Mesh سازگار است، معمولاً بدون نیاز به تغییر کد برنامه. برای رصدپذیری، متریک‌ها به Prometheus صادر می‌شوند و با Grafana قابل مانیتور هستند. نتیجه، هم‌راست‌سازی تعداد Replicaها با تقاضای واقعی HTTP برای بهبود کارایی، کاهش هزینه و پوشش بهتر ترافیک‌های انفجاری است؛ همچنین می‌تواند در کنار HPA و سایر Scalerهای KEDA استفاده شود.
#KEDA #Kubernetes #Autoscaling #HTTP #Serverless #CloudNative #DevOps #Observability
🟣لینک مقاله:
https://ku.bz/9TQrYJkKK
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - kedacore/http-add-on: Add-on for KEDA to scale HTTP workloads
Add-on for KEDA to scale HTTP workloads. Contribute to kedacore/http-add-on development by creating an account on GitHub.
🔵 عنوان مقاله
Kompose
🟢 خلاصه مقاله:
Kompose یک ابزار متن‌باز برای تبدیل سریع فایل‌های docker-compose.yml به منابع Kubernetes است. با دستوراتی مثل kompose convert و kompose up می‌توانید از روی پیکربندی موجود، Manifestهای آمادهٔ Deployment، Service، Ingress، PersistentVolumeClaim، ConfigMap و Secret بسازید یا مستقیم روی کلاستر اعمال کنید. این ابزار برای مهاجرت از Docker Compose به Kubernetes، نمونه‌سازی و یادگیری نگاشت مفاهیم Compose به سازه‌های Kubernetes بسیار کاربردی است. بااین‌حال همهٔ کلیدهای Compose معادل مستقیم ندارند و برخی موارد مثل شبکه‌های پیچیده، وابستگی‌ها یا جزئیات Volume ممکن است نیازمند ویرایش دستی باشند. همچنین لازم است پیشاپیش Imageها را بسازید و در Registry قرار دهید. Kompose روی Linux، macOS و Windows اجرا می‌شود و در کنار kubectl به شما کمک می‌کند سریع‌تر به استقرار قابل اجرا برسید، سپس بنا به نیاز امنیت، مقیاس‌پذیری و مشاهدهپذیری را بهینه کنید.
#Kompose #Kubernetes #Docker #DockerCompose #DevOps #Containers #CloudNative #Migration
🟣لینک مقاله:
https://ku.bz/qThb7hDwd
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Kompose
🟢 خلاصه مقاله:
Kompose یک ابزار متن‌باز برای تبدیل سریع فایل‌های docker-compose.yml به منابع Kubernetes است. با دستوراتی مثل kompose convert و kompose up می‌توانید از روی پیکربندی موجود، Manifestهای آمادهٔ Deployment، Service، Ingress، PersistentVolumeClaim، ConfigMap و Secret بسازید یا مستقیم روی کلاستر اعمال کنید. این ابزار برای مهاجرت از Docker Compose به Kubernetes، نمونه‌سازی و یادگیری نگاشت مفاهیم Compose به سازه‌های Kubernetes بسیار کاربردی است. بااین‌حال همهٔ کلیدهای Compose معادل مستقیم ندارند و برخی موارد مثل شبکه‌های پیچیده، وابستگی‌ها یا جزئیات Volume ممکن است نیازمند ویرایش دستی باشند. همچنین لازم است پیشاپیش Imageها را بسازید و در Registry قرار دهید. Kompose روی Linux، macOS و Windows اجرا می‌شود و در کنار kubectl به شما کمک می‌کند سریع‌تر به استقرار قابل اجرا برسید، سپس بنا به نیاز امنیت، مقیاس‌پذیری و مشاهدهپذیری را بهینه کنید.
#Kompose #Kubernetes #Docker #DockerCompose #DevOps #Containers #CloudNative #Migration
🟣لینک مقاله:
https://ku.bz/qThb7hDwd
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - kubernetes/kompose: Convert Compose to Kubernetes
Convert Compose to Kubernetes. Contribute to kubernetes/kompose development by creating an account on GitHub.
👍1
🔵 عنوان مقاله
Kite — Kubernetes Dashboard
🟢 خلاصه مقاله:
Kite یک داشبورد مدرن برای Kubernetes است که دیدپذیری و ایمنی عملیات را بالا می‌برد و کارهای روزمره را ساده می‌کند. این ابزار با ارائه نمای زنده از کلاسترها، نودها، نام‌اسپیس‌ها و ورک‌لودها و امکان ورود سریع به جزئیات Deployment، StatefulSet، DaemonSet، Job و Pod، خطاها و ریسک‌ها را زودتر نمایان می‌کند. پشتیبانی از چندکلاستری، نمایش مبتنی بر RBAC و سابقه فعالیت‌ها، هم همکاری تیمی را آسان می‌کند و هم نیازهای حسابرسی را پوشش می‌دهد.
Kite برای ترابل‌شوتینگ و عملیات، امکاناتی مانند لاگ‌گیری لحظه‌ای، exec داخل Pod، راه‌اندازی مجدد امن و مقایسه تنظیمات را فراهم می‌کند و با تشخیص پیکربندی‌های نادرست، فشار منابع و خطاهای Probe به رفع سریع مشکل کمک می‌کند. همچنین با نمایش درخواست/سقف منابع و الگوهای مصرف، به بهینه‌سازی هزینه و پایداری کمک می‌کند.
در یکپارچه‌سازی، Kite با Prometheus و Grafana سازگار است و با Alertmanager همراستا می‌شود تا روایت واحدی از سلامت سیستم ارائه دهد. امنیت با SSO مبتنی بر OIDC/OAuth، RBAC دقیق، حالت‌های read‑only و قابلیت حسابرسی تقویت شده و اصول حداقل دسترسی رعایت می‌شود.
نصب Kite ساده است: می‌توان آن را داخل کلاستر با Helm نصب کرد یا از دسکتاپ با kubeconfig متصل شد. از CRDها پشتیبانی می‌کند و امکان افزودن نماهای سفارشی و اکشن‌های اختصاصی را می‌دهد. در مقایسه با Kubernetes Dashboard اصلی، تمرکز Kite بر پیش‌فرض‌های امن، چندمستاجری و جریان‌های کاری تیمی است تا تجربه‌ای شفاف، قابل‌ردیابی و مشترک در Kubernetes فراهم کند.
#Kubernetes #Dashboard #K8s #DevOps #CloudNative #Observability #RBAC #Helm
🟣لینک مقاله:
https://ku.bz/95jvldnx_
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Kite — Kubernetes Dashboard
🟢 خلاصه مقاله:
Kite یک داشبورد مدرن برای Kubernetes است که دیدپذیری و ایمنی عملیات را بالا می‌برد و کارهای روزمره را ساده می‌کند. این ابزار با ارائه نمای زنده از کلاسترها، نودها، نام‌اسپیس‌ها و ورک‌لودها و امکان ورود سریع به جزئیات Deployment، StatefulSet، DaemonSet، Job و Pod، خطاها و ریسک‌ها را زودتر نمایان می‌کند. پشتیبانی از چندکلاستری، نمایش مبتنی بر RBAC و سابقه فعالیت‌ها، هم همکاری تیمی را آسان می‌کند و هم نیازهای حسابرسی را پوشش می‌دهد.
Kite برای ترابل‌شوتینگ و عملیات، امکاناتی مانند لاگ‌گیری لحظه‌ای، exec داخل Pod، راه‌اندازی مجدد امن و مقایسه تنظیمات را فراهم می‌کند و با تشخیص پیکربندی‌های نادرست، فشار منابع و خطاهای Probe به رفع سریع مشکل کمک می‌کند. همچنین با نمایش درخواست/سقف منابع و الگوهای مصرف، به بهینه‌سازی هزینه و پایداری کمک می‌کند.
در یکپارچه‌سازی، Kite با Prometheus و Grafana سازگار است و با Alertmanager همراستا می‌شود تا روایت واحدی از سلامت سیستم ارائه دهد. امنیت با SSO مبتنی بر OIDC/OAuth، RBAC دقیق، حالت‌های read‑only و قابلیت حسابرسی تقویت شده و اصول حداقل دسترسی رعایت می‌شود.
نصب Kite ساده است: می‌توان آن را داخل کلاستر با Helm نصب کرد یا از دسکتاپ با kubeconfig متصل شد. از CRDها پشتیبانی می‌کند و امکان افزودن نماهای سفارشی و اکشن‌های اختصاصی را می‌دهد. در مقایسه با Kubernetes Dashboard اصلی، تمرکز Kite بر پیش‌فرض‌های امن، چندمستاجری و جریان‌های کاری تیمی است تا تجربه‌ای شفاف، قابل‌ردیابی و مشترک در Kubernetes فراهم کند.
#Kubernetes #Dashboard #K8s #DevOps #CloudNative #Observability #RBAC #Helm
🟣لینک مقاله:
https://ku.bz/95jvldnx_
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - zxh326/kite: 🪁 A modern, lightweight Kubernetes dashboard.
🪁 A modern, lightweight Kubernetes dashboard. . Contribute to zxh326/kite development by creating an account on GitHub.
🔵 عنوان مقاله
Helmper – Helm Charts and Image Registry Manager
🟢 خلاصه مقاله:
Helmper یک ابزار سبک در Go است که Helm Charts را از رجیستری‌های OCI می‌خواند، تصاویر کانتینری ارجاع‌شده در آن‌ها را به رجیستری‌های شما mirror می‌کند و در صورت نیاز OS-level vulnerability patching را روی آن تصاویر اعمال می‌کند. این کار کنترل منبع pull را به شما می‌دهد، قابلیت اتکا را بالا می‌برد و با الزامات امنیتی و انطباق سازمانی همراستا است. Helmper به‌خوبی در CI/CD، اجرای زمان‌بندی‌شده برای تازه‌سازی mirrorها و سناریوهای مهاجرت به رجیستری خصوصی جا می‌گیرد. استفاده‌های متداول شامل محیط‌های air-gapped، دورزدن نرخ‌محدودیت رجیستری‌های عمومی و اعمال حاکمیت متمرکز بر تصاویر است. توجه کنید که patch کردن سطح OS جایگزین به‌روزرسانی‌های لایهٔ اپلیکیشن نیست و نیاز به تست سازگاری دارد.
#Helm #Kubernetes #OCI #DevOps #ContainerSecurity #Go #Registry #SupplyChainSecurity
🟣لینک مقاله:
https://ku.bz/Cp52CfjHg
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Helmper – Helm Charts and Image Registry Manager
🟢 خلاصه مقاله:
Helmper یک ابزار سبک در Go است که Helm Charts را از رجیستری‌های OCI می‌خواند، تصاویر کانتینری ارجاع‌شده در آن‌ها را به رجیستری‌های شما mirror می‌کند و در صورت نیاز OS-level vulnerability patching را روی آن تصاویر اعمال می‌کند. این کار کنترل منبع pull را به شما می‌دهد، قابلیت اتکا را بالا می‌برد و با الزامات امنیتی و انطباق سازمانی همراستا است. Helmper به‌خوبی در CI/CD، اجرای زمان‌بندی‌شده برای تازه‌سازی mirrorها و سناریوهای مهاجرت به رجیستری خصوصی جا می‌گیرد. استفاده‌های متداول شامل محیط‌های air-gapped، دورزدن نرخ‌محدودیت رجیستری‌های عمومی و اعمال حاکمیت متمرکز بر تصاویر است. توجه کنید که patch کردن سطح OS جایگزین به‌روزرسانی‌های لایهٔ اپلیکیشن نیست و نیاز به تست سازگاری دارد.
#Helm #Kubernetes #OCI #DevOps #ContainerSecurity #Go #Registry #SupplyChainSecurity
🟣لینک مقاله:
https://ku.bz/Cp52CfjHg
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - ChristofferNissen/helmper: Import Helm Charts to OCI registries, optionally with vulnerability patching
Import Helm Charts to OCI registries, optionally with vulnerability patching - ChristofferNissen/helmper
🔵 عنوان مقاله
How Kubernetes Pod Priority and Preemption Work
🟢 خلاصه مقاله:
این مقاله仕 توضیح می‌دهد که چگونه Kubernetes با استفاده از PriorityClass برای هر Pod یک Priority عددی تعیین می‌کند و وقتی منابع کم است، با Preemption می‌تواند Podهای کم‌اهمیت‌تر را کنار بزند تا برای Podهای مهم‌تر جا باز شود. scheduler ابتدا Nodeهای ممکن را بررسی می‌کند و با شبیه‌سازی، کمترین مجموعه از Podهای با Priority پایین‌تر را برای حذف انتخاب می‌کند؛ هرگز به Podهایی با Priority برابر یا بالاتر دست نمی‌زند و در صورت امکان به PodDisruptionBudget هم احترام می‌گذارد. این فرایند فقط بر اساس resource requests تصمیم می‌گیرد و محدودیت‌هایی مثل Node affinity/anti-affinity، taints/tolerations و وابستگی‌های ذخیره‌سازی را دور نمی‌زند؛ اگر محدودیت‌ها برآورده نشوند، Preemption کمکی نمی‌کند. Priority مستقل از QoS است و می‌توان با preemptionPolicy: Never یک Pod را از کنارزدن دیگران معاف کرد. بهترین رویکرد، تعریف چند PriorityClass محدود و واضح برای تفکیک سرویس‌های حیاتی از کارهای دسته‌ای است؛ به‌همراه PDB و برنامه‌ریزی ظرفیت، این کار باعث می‌شود در شرایط فشار منابع، سرویس‌های کلیدی پایدار بمانند و سایر Podها به‌صورت کنترل‌شده تخلیه و بعداً دوباره زمان‌بندی شوند.
#Kubernetes #PodPriority #Preemption #PriorityClass #KubeScheduler #CloudNative #DevOps #SRE
🟣لینک مقاله:
https://ku.bz/FNdcf4LF3
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
How Kubernetes Pod Priority and Preemption Work
🟢 خلاصه مقاله:
این مقاله仕 توضیح می‌دهد که چگونه Kubernetes با استفاده از PriorityClass برای هر Pod یک Priority عددی تعیین می‌کند و وقتی منابع کم است، با Preemption می‌تواند Podهای کم‌اهمیت‌تر را کنار بزند تا برای Podهای مهم‌تر جا باز شود. scheduler ابتدا Nodeهای ممکن را بررسی می‌کند و با شبیه‌سازی، کمترین مجموعه از Podهای با Priority پایین‌تر را برای حذف انتخاب می‌کند؛ هرگز به Podهایی با Priority برابر یا بالاتر دست نمی‌زند و در صورت امکان به PodDisruptionBudget هم احترام می‌گذارد. این فرایند فقط بر اساس resource requests تصمیم می‌گیرد و محدودیت‌هایی مثل Node affinity/anti-affinity، taints/tolerations و وابستگی‌های ذخیره‌سازی را دور نمی‌زند؛ اگر محدودیت‌ها برآورده نشوند، Preemption کمکی نمی‌کند. Priority مستقل از QoS است و می‌توان با preemptionPolicy: Never یک Pod را از کنارزدن دیگران معاف کرد. بهترین رویکرد، تعریف چند PriorityClass محدود و واضح برای تفکیک سرویس‌های حیاتی از کارهای دسته‌ای است؛ به‌همراه PDB و برنامه‌ریزی ظرفیت، این کار باعث می‌شود در شرایط فشار منابع، سرویس‌های کلیدی پایدار بمانند و سایر Podها به‌صورت کنترل‌شده تخلیه و بعداً دوباره زمان‌بندی شوند.
#Kubernetes #PodPriority #Preemption #PriorityClass #KubeScheduler #CloudNative #DevOps #SRE
🟣لینک مقاله:
https://ku.bz/FNdcf4LF3
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
🔵 عنوان مقاله
KubeFTP-Proxy Helm Chart
🟢 خلاصه مقاله:
**این چارت Helm با نام KubeFTP-Proxy از مخزن github.com/adrghph اجرای یک سرور FTP/FTPS در حالت passive را روی Kubernetes ساده می‌کند: یک vsftpd مستقر می‌کند، آن را با NodePort در دسترس می‌گذارد و پیکربندی HAProxy را برای مسیریابی درست پورت‌های passive در سراسر نودها به‌صورت خودکار می‌سازد. چالش اصلی FTP در Kubernetes جداسازی کانال کنترل از پورت‌های داده پویا (PASV) و مشکلات NAT/NodePort است؛ این چارت با جلوتر قراردادن HAProxy و نگاشت رنج پورت‌های passive، آدرس/پورت‌های قابل‌دسترسی به کلاینت می‌دهد تا اتصال داده در هر نودی برقرار شود. تنظیمات از طریق مقادیر Helm (مثل رنج پورت passive، آدرس/Hostname خارجی و NodePort) انجام می‌شود و برای سناریوهای کلود یا برمتال و حفظ گردش‌کارهای قدیمی FTP/FTPS مناسب است؛ در عین حال بهتر است رنج پورت‌ها محدود، دسترسی شبکه کنترل و FTPS فعال شود.
#Kubernetes #Helm #FTP #FTPS #vsftpd #HAProxy #NodePort #DevOps
🟣لینک مقاله:
https://ku.bz/hWTY1Vq11
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
KubeFTP-Proxy Helm Chart
🟢 خلاصه مقاله:
**این چارت Helm با نام KubeFTP-Proxy از مخزن github.com/adrghph اجرای یک سرور FTP/FTPS در حالت passive را روی Kubernetes ساده می‌کند: یک vsftpd مستقر می‌کند، آن را با NodePort در دسترس می‌گذارد و پیکربندی HAProxy را برای مسیریابی درست پورت‌های passive در سراسر نودها به‌صورت خودکار می‌سازد. چالش اصلی FTP در Kubernetes جداسازی کانال کنترل از پورت‌های داده پویا (PASV) و مشکلات NAT/NodePort است؛ این چارت با جلوتر قراردادن HAProxy و نگاشت رنج پورت‌های passive، آدرس/پورت‌های قابل‌دسترسی به کلاینت می‌دهد تا اتصال داده در هر نودی برقرار شود. تنظیمات از طریق مقادیر Helm (مثل رنج پورت passive، آدرس/Hostname خارجی و NodePort) انجام می‌شود و برای سناریوهای کلود یا برمتال و حفظ گردش‌کارهای قدیمی FTP/FTPS مناسب است؛ در عین حال بهتر است رنج پورت‌ها محدود، دسترسی شبکه کنترل و FTPS فعال شود.
#Kubernetes #Helm #FTP #FTPS #vsftpd #HAProxy #NodePort #DevOps
🟣لینک مقاله:
https://ku.bz/hWTY1Vq11
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
adrghph - Overview
🌐. adrghph has 6 repositories available. Follow their code on GitHub.
🔵 عنوان مقاله
Troubleshooting packet drops in a Kubernetes-based observability platform
🟢 خلاصه مقاله:
این مطالعه موردی نشان می‌دهد تیم SRE در Kapital Bank چگونه افت‌های مقطعی بسته‌ها و افزایش تاخیر را در یک پلتفرم مشاهدهپذیری مبتنی بر Kubernetes که به لایه Memcached متکی بود، ریشه‌یابی کرد. با آنکه شاخص‌های سطح اپلیکیشن عادی به‌نظر می‌رسید، بررسی عمیق‌تر مسیر شبکه در سطح کرنل و شمارنده‌های گره‌ها و پادها، فشار لحظه‌ای ترافیک و اشباع صف‌ها را آشکار کرد. تیم با آزمایش‌های کنترل‌شده و تنظیم محتاطانه پارامترهای کرنل—از جمله عمق صف‌ها و اندازه بافرها—پارامترها را با الگوی ترافیک Memcached روی Kubernetes هم‌تراز کرد و در نتیجه، افت بسته‌ها کاهش یافت و پایداری و تاخیر انتها‌به‌انتها بهبود پیدا کرد. این روایت در medium.com یک روش عملی برای عیب‌یابی مسائل شبکه‌ای در سطح کرنل در محیط‌های کانتینری ارائه می‌دهد: مشاهدهپذیری لایه‌به‌لایه، اعتبارسنجی فرضیات، و تیونینگ مبتنی بر شواهد.
#Kubernetes #SRE #Memcached #Observability #Networking #KernelTuning #PacketLoss #DevOps
🟣لینک مقاله:
https://ku.bz/spNnnpsM-
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Troubleshooting packet drops in a Kubernetes-based observability platform
🟢 خلاصه مقاله:
این مطالعه موردی نشان می‌دهد تیم SRE در Kapital Bank چگونه افت‌های مقطعی بسته‌ها و افزایش تاخیر را در یک پلتفرم مشاهدهپذیری مبتنی بر Kubernetes که به لایه Memcached متکی بود، ریشه‌یابی کرد. با آنکه شاخص‌های سطح اپلیکیشن عادی به‌نظر می‌رسید، بررسی عمیق‌تر مسیر شبکه در سطح کرنل و شمارنده‌های گره‌ها و پادها، فشار لحظه‌ای ترافیک و اشباع صف‌ها را آشکار کرد. تیم با آزمایش‌های کنترل‌شده و تنظیم محتاطانه پارامترهای کرنل—از جمله عمق صف‌ها و اندازه بافرها—پارامترها را با الگوی ترافیک Memcached روی Kubernetes هم‌تراز کرد و در نتیجه، افت بسته‌ها کاهش یافت و پایداری و تاخیر انتها‌به‌انتها بهبود پیدا کرد. این روایت در medium.com یک روش عملی برای عیب‌یابی مسائل شبکه‌ای در سطح کرنل در محیط‌های کانتینری ارائه می‌دهد: مشاهدهپذیری لایه‌به‌لایه، اعتبارسنجی فرضیات، و تیونینگ مبتنی بر شواهد.
#Kubernetes #SRE #Memcached #Observability #Networking #KernelTuning #PacketLoss #DevOps
🟣لینک مقاله:
https://ku.bz/spNnnpsM-
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
Troubleshooting Packet Drops in a Kubernetes Cluster
One of the core responsibilities of our SRE team is maintaining a robust observability platform. Our platform is built using open-source…
❤1
🔵 عنوان مقاله
Help us test OpenTofu 1.11.0-beta1 (4 minute read)
🟢 خلاصه مقاله:
**نسخه بتای OpenTofu 1.11.0 با شناسه 1.11.0-beta1 منتشر شده و از جامعه برای آزمایش دعوت می‌کند. این نسخه ویژگی‌های deprecation ماژول‌ها را پایدار می‌کند تا هشدارها و مسیرهای مهاجرت روشن‌تری فراهم شود و همزمان بهبودهایی در کارایی ارائه می‌دهد. توصیه می‌شود آن را در محیط‌های غیرتولیدی امتحان کنید، از تنظیمات پشتیبان بگیرید و بازخورد خود را برای کمک به نهایی‌سازی نسخه 1.11.0 ارسال کنید.
#OpenTofu #IaC #DevOps #BetaRelease #Performance #ModuleDeprecation #Testing
🟣لینک مقاله:
https://opentofu.org/blog/help-us-test-opentofu-1-11-0-beta1/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Help us test OpenTofu 1.11.0-beta1 (4 minute read)
🟢 خلاصه مقاله:
**نسخه بتای OpenTofu 1.11.0 با شناسه 1.11.0-beta1 منتشر شده و از جامعه برای آزمایش دعوت می‌کند. این نسخه ویژگی‌های deprecation ماژول‌ها را پایدار می‌کند تا هشدارها و مسیرهای مهاجرت روشن‌تری فراهم شود و همزمان بهبودهایی در کارایی ارائه می‌دهد. توصیه می‌شود آن را در محیط‌های غیرتولیدی امتحان کنید، از تنظیمات پشتیبان بگیرید و بازخورد خود را برای کمک به نهایی‌سازی نسخه 1.11.0 ارسال کنید.
#OpenTofu #IaC #DevOps #BetaRelease #Performance #ModuleDeprecation #Testing
🟣لینک مقاله:
https://opentofu.org/blog/help-us-test-opentofu-1-11-0-beta1/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
opentofu.org
Help us test OpenTofu 1.11.0-beta1 | OpenTofu
OpenTofu 1.11.0-beta1 is Now Available
🔵 عنوان مقاله
kubectl-explore
🟢 خلاصه مقاله:
**kubectl-explore یک ابزار تعاملی بر پایه fuzzy finder است که تجربه کار با kubectl explain را سریع‌تر و قابل جست‌وجوتر می‌کند. به‌جای اجرای پرس‌وجوهای تکی، می‌توانید بین Group/Version/Kind، فیلدها و زیر‌فیلدها جست‌وجوی فازی انجام دهید، پیش‌نمایش توضیحات را همان‌جا ببینید و بین انواع مرتبط جابه‌جا شوید؛ همه داخل ترمینال و فقط با کیبورد. این کار کشف و یادگیری API در Kubernetes—به‌ویژه برای CRDها و بررسی فیلدهای مانيفست—را ساده‌تر می‌کند و با استفاده از همان منبع مستندات kubectl explain برای منابع هسته و (در صورت در دسترس بودن) CRDها عمل می‌کند.
#Kubernetes #kubectl #DevOps #CLI #FuzzyFinder #CRD #DeveloperExperience #Productivity
🟣لینک مقاله:
https://ku.bz/Q_P_Yp5lN
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
kubectl-explore
🟢 خلاصه مقاله:
**kubectl-explore یک ابزار تعاملی بر پایه fuzzy finder است که تجربه کار با kubectl explain را سریع‌تر و قابل جست‌وجوتر می‌کند. به‌جای اجرای پرس‌وجوهای تکی، می‌توانید بین Group/Version/Kind، فیلدها و زیر‌فیلدها جست‌وجوی فازی انجام دهید، پیش‌نمایش توضیحات را همان‌جا ببینید و بین انواع مرتبط جابه‌جا شوید؛ همه داخل ترمینال و فقط با کیبورد. این کار کشف و یادگیری API در Kubernetes—به‌ویژه برای CRDها و بررسی فیلدهای مانيفست—را ساده‌تر می‌کند و با استفاده از همان منبع مستندات kubectl explain برای منابع هسته و (در صورت در دسترس بودن) CRDها عمل می‌کند.
#Kubernetes #kubectl #DevOps #CLI #FuzzyFinder #CRD #DeveloperExperience #Productivity
🟣لینک مقاله:
https://ku.bz/Q_P_Yp5lN
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - keisku/kubectl-explore: A better kubectl explain with the fuzzy finder
A better kubectl explain with the fuzzy finder. Contribute to keisku/kubectl-explore development by creating an account on GitHub.
🔵 عنوان مقاله
PVC-Autoresizer: Dynamic Volume Expansion
🟢 خلاصه مقاله:
PVC-Autoresizer یک کنترلر در Kubernetes است که با پایش مصرف دیسک، اندازه PVC را به‌صورت خودکار و مرحله‌ای افزایش می‌دهد تا از پر شدن ناگهانی حجم و توقف سرویس جلوگیری شود. این ابزار بر اساس آستانه‌های قابل‌پیکربندی عمل می‌کند، تنها وقتی StorageClass و درایور CSI از گسترش پشتیبانی کنند اقدام می‌کند، و برای هر PVC/Namespace امکان سیاست‌های جداگانه (حداکثر اندازه، گام رشد، و Backoff) را فراهم می‌سازد. با فایل‌سیستم‌ها و درایورهای سازگار، گسترش اغلب آنلاین و بدون downtime انجام می‌شود؛ در غیر این صورت می‌تواند نیاز به راه‌اندازی مجدد کنترل‌شده را اعلام کند. موارد استفاده رایج شامل دیتابیس‌ها و بارهای Stateful با رشد غیرقابل‌پیش‌بینی است. محدودیت مهم این است که کوچک‌سازی معمولاً ممکن نیست و نیاز به allowVolumeExpansion و پشتیبانی CSI وجود دارد. نتیجه: خودکارسازی، پیشگیری از رخدادهای کمبود فضا، و کاهش کار عملیاتی در مدیریت ذخیره‌سازی.
#Kubernetes #PVC #PersistentVolume #CSI #DevOps #CloudNative #StatefulWorkloads #StorageAutomation
🟣لینک مقاله:
https://ku.bz/xwnlC772q
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
PVC-Autoresizer: Dynamic Volume Expansion
🟢 خلاصه مقاله:
PVC-Autoresizer یک کنترلر در Kubernetes است که با پایش مصرف دیسک، اندازه PVC را به‌صورت خودکار و مرحله‌ای افزایش می‌دهد تا از پر شدن ناگهانی حجم و توقف سرویس جلوگیری شود. این ابزار بر اساس آستانه‌های قابل‌پیکربندی عمل می‌کند، تنها وقتی StorageClass و درایور CSI از گسترش پشتیبانی کنند اقدام می‌کند، و برای هر PVC/Namespace امکان سیاست‌های جداگانه (حداکثر اندازه، گام رشد، و Backoff) را فراهم می‌سازد. با فایل‌سیستم‌ها و درایورهای سازگار، گسترش اغلب آنلاین و بدون downtime انجام می‌شود؛ در غیر این صورت می‌تواند نیاز به راه‌اندازی مجدد کنترل‌شده را اعلام کند. موارد استفاده رایج شامل دیتابیس‌ها و بارهای Stateful با رشد غیرقابل‌پیش‌بینی است. محدودیت مهم این است که کوچک‌سازی معمولاً ممکن نیست و نیاز به allowVolumeExpansion و پشتیبانی CSI وجود دارد. نتیجه: خودکارسازی، پیشگیری از رخدادهای کمبود فضا، و کاهش کار عملیاتی در مدیریت ذخیره‌سازی.
#Kubernetes #PVC #PersistentVolume #CSI #DevOps #CloudNative #StatefulWorkloads #StorageAutomation
🟣لینک مقاله:
https://ku.bz/xwnlC772q
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - topolvm/pvc-autoresizer: Auto-resize PersistentVolumeClaim objects based on Prometheus metrics
Auto-resize PersistentVolumeClaim objects based on Prometheus metrics - topolvm/pvc-autoresizer
🔵 عنوان مقاله
K8s cleaner
🟢 خلاصه مقاله:
K8s cleaner یک کنترلر برای Kubernetes است که توسط gianlucam76 در GitHub منتشر شده و به شناسایی و حذف یا به‌روزرسانی منابع قدیمی/یتیم یا ناسالم کمک می‌کند تا خوشه تمیز و کارآمد بماند. این ابزار با رصد مداوم وضعیت خوشه، مواردی مانند Pods ناموفق، PVCهای یتیم، ConfigMaps یا Secrets بلااستفاده، ReplicaSets قدیمی و Jobs پایان‌یافته را هدف می‌گیرد. با خودکارسازی این نظافت، ظرفیت آزاد می‌شود، نویز عملیاتی کاهش می‌یابد و قابلیت اطمینان و کارایی زمان‌بندی بهبود پیدا می‌کند؛ رویکردی که با جریان‌های کاری DevOps و SRE و حتی GitOps همخوان است.
#Kubernetes #K8s #DevOps #SRE #CloudNative #ClusterMaintenance #Automation #GitOps
🟣لینک مقاله:
https://ku.bz/6_tDbWysr
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
K8s cleaner
🟢 خلاصه مقاله:
K8s cleaner یک کنترلر برای Kubernetes است که توسط gianlucam76 در GitHub منتشر شده و به شناسایی و حذف یا به‌روزرسانی منابع قدیمی/یتیم یا ناسالم کمک می‌کند تا خوشه تمیز و کارآمد بماند. این ابزار با رصد مداوم وضعیت خوشه، مواردی مانند Pods ناموفق، PVCهای یتیم، ConfigMaps یا Secrets بلااستفاده، ReplicaSets قدیمی و Jobs پایان‌یافته را هدف می‌گیرد. با خودکارسازی این نظافت، ظرفیت آزاد می‌شود، نویز عملیاتی کاهش می‌یابد و قابلیت اطمینان و کارایی زمان‌بندی بهبود پیدا می‌کند؛ رویکردی که با جریان‌های کاری DevOps و SRE و حتی GitOps همخوان است.
#Kubernetes #K8s #DevOps #SRE #CloudNative #ClusterMaintenance #Automation #GitOps
🟣لینک مقاله:
https://ku.bz/6_tDbWysr
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - gianlucam76/k8s-cleaner: Cleaner is a Kubernetes controller that identifies unused or unhealthy resources, helping you…
Cleaner is a Kubernetes controller that identifies unused or unhealthy resources, helping you maintain a streamlined and efficient Kubernetes cluster. It provides flexible scheduling, label filteri...
🔵 عنوان مقاله
kvaps/kubectl-node-shell
🟢 خلاصه مقاله:
این ابزار یک افزونه سبک برای kubectl است که بدون نیاز به SSH، یک شِل روت روی نودهای Kubernetes باز می‌کند. افزونه توسط kvaps ارائه شده و با ساخت یک پاد موقتِ privileged روی نود هدف و استفاده از nsenter وارد فضای نام‌های میزبان می‌شود؛ به این ترتیب شِلی در اختیار دارید که مانند ورود مستقیم به نود عمل می‌کند و پس از خروج، پاد به‌طور خودکار پاک می‌شود.
این رویکرد برای عیب‌یابی سریع در محیط‌های ابری یا شبکه‌های محدود بسیار مفید است: بررسی لاگ‌ها و دایرکتوری‌های نود، وضعیت kubelet، قوانین شبکه و iptables، و داده‌های زمان‌اجرای کانتینرها مانند Docker، containerd یا CRI-O با ابزارهای آشنای Linux.
پیش‌نیازها و ملاحظات امنیتی را در نظر داشته باشید: معمولاً به دسترسی سطح cluster-admin برای ساخت پادهای privileged و ورود به namespaceهای میزبان نیاز است. این ابزار جایگزین سیاست‌های دسترسی و مدیریت امن نودها نیست و برای نودهای Linux طراحی شده است (Windows پشتیبانی نمی‌شود). نصب از طریق kubectl krew یا روش‌های موجود در مخزن انجام می‌شود و اجرای معمول به شکل kubectl node-shell <node-name> است.
#Kubernetes #kubectl #DevOps #SRE #Debugging #Security #Containers #Linux
🟣لینک مقاله:
https://ku.bz/ZXkDtpn5g
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
kvaps/kubectl-node-shell
🟢 خلاصه مقاله:
این ابزار یک افزونه سبک برای kubectl است که بدون نیاز به SSH، یک شِل روت روی نودهای Kubernetes باز می‌کند. افزونه توسط kvaps ارائه شده و با ساخت یک پاد موقتِ privileged روی نود هدف و استفاده از nsenter وارد فضای نام‌های میزبان می‌شود؛ به این ترتیب شِلی در اختیار دارید که مانند ورود مستقیم به نود عمل می‌کند و پس از خروج، پاد به‌طور خودکار پاک می‌شود.
این رویکرد برای عیب‌یابی سریع در محیط‌های ابری یا شبکه‌های محدود بسیار مفید است: بررسی لاگ‌ها و دایرکتوری‌های نود، وضعیت kubelet، قوانین شبکه و iptables، و داده‌های زمان‌اجرای کانتینرها مانند Docker، containerd یا CRI-O با ابزارهای آشنای Linux.
پیش‌نیازها و ملاحظات امنیتی را در نظر داشته باشید: معمولاً به دسترسی سطح cluster-admin برای ساخت پادهای privileged و ورود به namespaceهای میزبان نیاز است. این ابزار جایگزین سیاست‌های دسترسی و مدیریت امن نودها نیست و برای نودهای Linux طراحی شده است (Windows پشتیبانی نمی‌شود). نصب از طریق kubectl krew یا روش‌های موجود در مخزن انجام می‌شود و اجرای معمول به شکل kubectl node-shell <node-name> است.
#Kubernetes #kubectl #DevOps #SRE #Debugging #Security #Containers #Linux
🟣لینک مقاله:
https://ku.bz/ZXkDtpn5g
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - kvaps/kubectl-node-shell: Exec into node via kubectl
Exec into node via kubectl. Contribute to kvaps/kubectl-node-shell development by creating an account on GitHub.
🔵 عنوان مقاله
Kwatcher – External JSON-watch Kubernetes Operator
🟢 خلاصه مقاله:
** Kwatcher یک Operator در Kubernetes است که پیکربندی‌های خارجی با فرمت JSON را به‌صورت امن (با استفاده از Secret) واکشی می‌کند، آن‌ها را به ConfigMap تبدیل یا به‌روزرسانی می‌کند و در صورت تغییر داده، با راه‌اندازی مجدد هدفمند Podها، تنظیمات جدید را به برنامه‌ها می‌رساند. این کار خودکار، نیاز به به‌روزرسانی دستی و اسکریپت‌های موقت را حذف کرده، از رانش پیکربندی جلوگیری می‌کند و امنیت را با جداسازی کرِدِنشال‌ها از کد و ایمیج‌ها بهبود می‌دهد. Kwatcher برای محیط‌های microservices و الگوهای GitOps مناسب است و انتشار تغییرات پیکربندی مانند feature flagها یا پارامترهای زمان اجرا را در مقیاس ساده و قابل اتکا می‌سازد.
#Kubernetes #Operator #JSON #ConfigMap #Secrets #DevOps #GitOps #Automation
🟣لینک مقاله:
https://ku.bz/mQsWFDqzN
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Kwatcher – External JSON-watch Kubernetes Operator
🟢 خلاصه مقاله:
** Kwatcher یک Operator در Kubernetes است که پیکربندی‌های خارجی با فرمت JSON را به‌صورت امن (با استفاده از Secret) واکشی می‌کند، آن‌ها را به ConfigMap تبدیل یا به‌روزرسانی می‌کند و در صورت تغییر داده، با راه‌اندازی مجدد هدفمند Podها، تنظیمات جدید را به برنامه‌ها می‌رساند. این کار خودکار، نیاز به به‌روزرسانی دستی و اسکریپت‌های موقت را حذف کرده، از رانش پیکربندی جلوگیری می‌کند و امنیت را با جداسازی کرِدِنشال‌ها از کد و ایمیج‌ها بهبود می‌دهد. Kwatcher برای محیط‌های microservices و الگوهای GitOps مناسب است و انتشار تغییرات پیکربندی مانند feature flagها یا پارامترهای زمان اجرا را در مقیاس ساده و قابل اتکا می‌سازد.
#Kubernetes #Operator #JSON #ConfigMap #Secrets #DevOps #GitOps #Automation
🟣لینک مقاله:
https://ku.bz/mQsWFDqzN
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - Berg-it/Kwatcher
Contribute to Berg-it/Kwatcher development by creating an account on GitHub.
🔵 عنوان مقاله
cnquery: Native Query Tool
🟢 خلاصه مقاله:
cnquery یک ابزار Native Query است که با دسترسی مستقیم به منابع سیستم، پاسخ‌های سریع و ساخت‌یافته ارائه می‌دهد. بدون تکیه بر ایجنت‌های سنگین، داده‌ها را از منبع (فایل‌ها، پیکربندی‌ها، فرآیندها و سایر اجزای زمان اجرا) بازیابی می‌کند و برای موجودی‌گیری، انطباق، عیب‌یابی، تشخیص انحراف و بازبینی تغییرات کاربرد دارد. خروجی آن برای گزارش‌گیری و یکپارچه‌سازی در اسکریپت‌ها و پایپ‌لاین‌ها مناسب است و به تیم‌های پلتفرم، DevOps، SRE و امنیت کمک می‌کند محیط‌های متنوع را به‌صورت یکنواخت بررسی کنند. هدف آن تبدیل پرسش‌های عملیاتی به کوئری‌های قابل اقدام و کاهش کار دستی است.
#cnquery #QueryTool #DevOps #SRE #Security #Compliance #Automation
🟣لینک مقاله:
https://ku.bz/Jml2KcQ-N
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
cnquery: Native Query Tool
🟢 خلاصه مقاله:
cnquery یک ابزار Native Query است که با دسترسی مستقیم به منابع سیستم، پاسخ‌های سریع و ساخت‌یافته ارائه می‌دهد. بدون تکیه بر ایجنت‌های سنگین، داده‌ها را از منبع (فایل‌ها، پیکربندی‌ها، فرآیندها و سایر اجزای زمان اجرا) بازیابی می‌کند و برای موجودی‌گیری، انطباق، عیب‌یابی، تشخیص انحراف و بازبینی تغییرات کاربرد دارد. خروجی آن برای گزارش‌گیری و یکپارچه‌سازی در اسکریپت‌ها و پایپ‌لاین‌ها مناسب است و به تیم‌های پلتفرم، DevOps، SRE و امنیت کمک می‌کند محیط‌های متنوع را به‌صورت یکنواخت بررسی کنند. هدف آن تبدیل پرسش‌های عملیاتی به کوئری‌های قابل اقدام و کاهش کار دستی است.
#cnquery #QueryTool #DevOps #SRE #Security #Compliance #Automation
🟣لینک مقاله:
https://ku.bz/Jml2KcQ-N
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - mondoohq/cnquery: open source, cloud-native, graph-based asset inventory
open source, cloud-native, graph-based asset inventory - mondoohq/cnquery
🔵 عنوان مقاله
Kubernetes Logs Unavailable Behind a Proxy: Diagnosing API Server Communication Issues
🟢 خلاصه مقاله:
اگر محیط شما پشت یک HTTP proxy قرار دارد، ممکن است برخی دستورات kubectl مثل kubectl logs، kubectl exec و port-forward شکست بخورند، در حالی‌که kubectl get یا describe کار می‌کنند. دلیل رایج این مشکل تنظیم‌نشدن NO_PROXY برای آدرس‌ها و دامنه‌های داخلی کلاستر است؛ در نتیجه، ترافیک داخلی به‌اشتباه از proxy عبور می‌کند و اتصال‌های upgrade/stream (مثل SPDY/WebSocket) می‌شکنند. نشانه‌ها شامل خطاهایی مانند EOF یا context deadline exceeded است. برای رفع مشکل، NO_PROXY/no_proxy را با مواردی مانند localhost، 127.0.0.1، نام و IP مربوط به API server، دامنه‌های .cluster.local و .svc، و بازه‌های IP داخلی (مثلاً 10.0.0.0/8) تنظیم کنید. به حروف بزرگ/کوچک متغیرها دقت کنید و در سیستم‌عامل‌های مختلف مطابق دستورالعمل همان محیط آن‌ها را ست کنید. پس از به‌روزرسانی NO_PROXY، عملیات‌های stream مثل kubectl logs و exec معمولاً بدون مشکل انجام می‌شوند.
#Kubernetes #kubectl #Proxy #Networking #NO_PROXY #Troubleshooting #DevOps #HTTP
🟣لینک مقاله:
https://ku.bz/jCJf115lB
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Kubernetes Logs Unavailable Behind a Proxy: Diagnosing API Server Communication Issues
🟢 خلاصه مقاله:
اگر محیط شما پشت یک HTTP proxy قرار دارد، ممکن است برخی دستورات kubectl مثل kubectl logs، kubectl exec و port-forward شکست بخورند، در حالی‌که kubectl get یا describe کار می‌کنند. دلیل رایج این مشکل تنظیم‌نشدن NO_PROXY برای آدرس‌ها و دامنه‌های داخلی کلاستر است؛ در نتیجه، ترافیک داخلی به‌اشتباه از proxy عبور می‌کند و اتصال‌های upgrade/stream (مثل SPDY/WebSocket) می‌شکنند. نشانه‌ها شامل خطاهایی مانند EOF یا context deadline exceeded است. برای رفع مشکل، NO_PROXY/no_proxy را با مواردی مانند localhost، 127.0.0.1، نام و IP مربوط به API server، دامنه‌های .cluster.local و .svc، و بازه‌های IP داخلی (مثلاً 10.0.0.0/8) تنظیم کنید. به حروف بزرگ/کوچک متغیرها دقت کنید و در سیستم‌عامل‌های مختلف مطابق دستورالعمل همان محیط آن‌ها را ست کنید. پس از به‌روزرسانی NO_PROXY، عملیات‌های stream مثل kubectl logs و exec معمولاً بدون مشکل انجام می‌شوند.
#Kubernetes #kubectl #Proxy #Networking #NO_PROXY #Troubleshooting #DevOps #HTTP
🟣لینک مقاله:
https://ku.bz/jCJf115lB
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
Kubernetes logs unavailable behind a proxy: Diagnosing API server communication issues
Why kubectl logs times out in corporate networks: The missing NO_PROXY config that breaks K8s API-to-kubelet communication.