🔵 عنوان مقاله
Raspberry Pi K8S Cluster Setup for Home Lab with Cilium
🟢 خلاصه مقاله:
راهنمای dev.to نشان می‌دهد چگونه چند Raspberry Pi را به یک کلاستر چندگره‌ای Kubernetes برای هوم‌لب تبدیل کنید. در این روش، Cilium به‌عنوان CNI نصب می‌شود و با جایگزینی kube-proxy، کارایی شبکه و اجرای سیاست‌ها بهبود می‌یابد. مراحل اصلی شامل آماده‌سازی نودها (OS ۶۴بیتی، cgroup، IP ثابت، SSH)، راه‌اندازی کلاستر با containerd و kubeadm (init و join)، و سپس نصب و پیکربندی Cilium با فعال‌سازی kube-proxy replacement است. در ادامه، تست اتصال سرویس‌ها و Podها، اعمال NetworkPolicy برای کنترل دسترسی، و استفاده اختیاری از Hubble برای مشاهده و عیب‌یابی جریان‌ها انجام می‌شود. نتیجه، یک پلتفرم Kubernetes کم‌مصرف و منعطف برای آزمایش‌های خانگی با تأخیر کمتر و مدیریت ساده‌تر است.
#RaspberryPi #Kubernetes #K8s #Cilium #HomeLab #CNI #kubeproxy #DevOps
🟣لینک مقاله:
https://ku.bz/xVCFlHFY4
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Raspberry Pi K8S Cluster Setup for Home Lab with Cilium
🟢 خلاصه مقاله:
راهنمای dev.to نشان می‌دهد چگونه چند Raspberry Pi را به یک کلاستر چندگره‌ای Kubernetes برای هوم‌لب تبدیل کنید. در این روش، Cilium به‌عنوان CNI نصب می‌شود و با جایگزینی kube-proxy، کارایی شبکه و اجرای سیاست‌ها بهبود می‌یابد. مراحل اصلی شامل آماده‌سازی نودها (OS ۶۴بیتی، cgroup، IP ثابت، SSH)، راه‌اندازی کلاستر با containerd و kubeadm (init و join)، و سپس نصب و پیکربندی Cilium با فعال‌سازی kube-proxy replacement است. در ادامه، تست اتصال سرویس‌ها و Podها، اعمال NetworkPolicy برای کنترل دسترسی، و استفاده اختیاری از Hubble برای مشاهده و عیب‌یابی جریان‌ها انجام می‌شود. نتیجه، یک پلتفرم Kubernetes کم‌مصرف و منعطف برای آزمایش‌های خانگی با تأخیر کمتر و مدیریت ساده‌تر است.
#RaspberryPi #Kubernetes #K8s #Cilium #HomeLab #CNI #kubeproxy #DevOps
🟣لینک مقاله:
https://ku.bz/xVCFlHFY4
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
DEV Community
Raspberry Pi K8S Cluster Setup for Home Lab with Cilium
I’m setting up a Kubernetes cluster using Raspberry Pis for home lab testing and learning purposes....
🔵 عنوان مقاله
Volare: Kubernetes Volume Populator
🟢 خلاصه مقاله:
** Volare ابزاری در Kubernetes برای Volume Populator است که قبل از استفاده‌ی پادها، PVCها را با داده‌های منبع خارجی مثل S3 یا سرورهای HTTP پر می‌کند. با انتقال مرحله‌ی تزریق داده به زمان Provisioning، راه‌اندازی سریع‌تر و محیط‌های قابل‌تکرار فراهم می‌شود و نیاز به اسکریپت‌های دستی یا initContainerها کاهش می‌یابد. این کار برای داده‌های مرجع ML، بازیابی و مهاجرت داده، دیتابیس‌های اولیه و محیط‌های CI/CD بسیار مفید است. Volare در جریان ذخیره‌سازی Kubernetes ادغام می‌شود تا پادها فقط به حجمی دسترسی داشته باشند که به‌طور کامل مقداردهی اولیه شده است. مخزن پروژه در github.com/AdamShannagVolare در دسترس است.
#Kubernetes #PersistentVolume #DevOps #Storage #S3 #StatefulWorkloads #DataInitialization #CI_CD
🟣لینک مقاله:
https://ku.bz/pbqJC-mNp
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Volare: Kubernetes Volume Populator
🟢 خلاصه مقاله:
** Volare ابزاری در Kubernetes برای Volume Populator است که قبل از استفاده‌ی پادها، PVCها را با داده‌های منبع خارجی مثل S3 یا سرورهای HTTP پر می‌کند. با انتقال مرحله‌ی تزریق داده به زمان Provisioning، راه‌اندازی سریع‌تر و محیط‌های قابل‌تکرار فراهم می‌شود و نیاز به اسکریپت‌های دستی یا initContainerها کاهش می‌یابد. این کار برای داده‌های مرجع ML، بازیابی و مهاجرت داده، دیتابیس‌های اولیه و محیط‌های CI/CD بسیار مفید است. Volare در جریان ذخیره‌سازی Kubernetes ادغام می‌شود تا پادها فقط به حجمی دسترسی داشته باشند که به‌طور کامل مقداردهی اولیه شده است. مخزن پروژه در github.com/AdamShannagVolare در دسترس است.
#Kubernetes #PersistentVolume #DevOps #Storage #S3 #StatefulWorkloads #DataInitialization #CI_CD
🟣لینک مقاله:
https://ku.bz/pbqJC-mNp
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
🔵 عنوان مقاله
mcp-server-kubernetes – Kubernetes Management via MCP
🟢 خلاصه مقاله:
mcp-server-kubernetes یک سرور مبتنی بر Model Context Protocol است که لایه کامل مدیریت Kubernetes را در اختیار کلاینت‌های هوشمند قرار می‌دهد. این پروژه در github.com/Flux159mcp-server-kubernetes عرضه شده و کارهای رایج Kubernetes را به قابلیت‌های قابل‌فراخوانی و ایمن تبدیل می‌کند. با آن، ابزارهایی مثل Claude Desktop و mcp-chat می‌توانند دستورهای kubectl و Helm را به‌صورت کنترل‌شده اجرا کنند؛ از مشاهده و توصیف منابع و وضعیت کلاستر تا گرفتن لاگ‌ها، اعمال مانيفست‌ها، مدیریت chartها و بررسی rollout—بدون دسترسی مستقیم به شِل. اجرای دستورها از مسیر قابلیت‌های ازپیش‌تعریف‌شده و با اعتبارسنجی ورودی انجام می‌شود و خروجی‌ها به‌صورت ساخت‌یافته برمی‌گردند تا برای چت‌اَپ‌ها و خودکارسازی مناسب باشند. این رویکرد، مرز امنیتی روشن بین کلاینت و کلاستر حفظ می‌کند و به دلیل مبتنی‌بودن بر MCP، در چندین کلاینت سازگار به‌سادگی قابل استفاده است.
#Kubernetes #MCP #ModelContextProtocol #kubectl #Helm #DevOps #AIOps #AIAgents
🟣لینک مقاله:
https://ku.bz/gdfy-l6q7
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
mcp-server-kubernetes – Kubernetes Management via MCP
🟢 خلاصه مقاله:
mcp-server-kubernetes یک سرور مبتنی بر Model Context Protocol است که لایه کامل مدیریت Kubernetes را در اختیار کلاینت‌های هوشمند قرار می‌دهد. این پروژه در github.com/Flux159mcp-server-kubernetes عرضه شده و کارهای رایج Kubernetes را به قابلیت‌های قابل‌فراخوانی و ایمن تبدیل می‌کند. با آن، ابزارهایی مثل Claude Desktop و mcp-chat می‌توانند دستورهای kubectl و Helm را به‌صورت کنترل‌شده اجرا کنند؛ از مشاهده و توصیف منابع و وضعیت کلاستر تا گرفتن لاگ‌ها، اعمال مانيفست‌ها، مدیریت chartها و بررسی rollout—بدون دسترسی مستقیم به شِل. اجرای دستورها از مسیر قابلیت‌های ازپیش‌تعریف‌شده و با اعتبارسنجی ورودی انجام می‌شود و خروجی‌ها به‌صورت ساخت‌یافته برمی‌گردند تا برای چت‌اَپ‌ها و خودکارسازی مناسب باشند. این رویکرد، مرز امنیتی روشن بین کلاینت و کلاستر حفظ می‌کند و به دلیل مبتنی‌بودن بر MCP، در چندین کلاینت سازگار به‌سادگی قابل استفاده است.
#Kubernetes #MCP #ModelContextProtocol #kubectl #Helm #DevOps #AIOps #AIAgents
🟣لینک مقاله:
https://ku.bz/gdfy-l6q7
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
🔵 عنوان مقاله
Cloudflare Tunnel Ingress Controller
🟢 خلاصه مقاله:
Cloudflare Tunnel Ingress Controller روشی Kubernetes-native برای انتشار امن سرویس‌هاست که به‌جای باز کردن پورت‌های ورودی و ساخت Load Balancer عمومی، از اتصال‌های خروجی رمزنگاری‌شده به لبه Cloudflare استفاده می‌کند. این Controller با تماشای Ingress، Service و CRDها، مسیرها را به‌صورت خودکار روی Cloudflare Tunnel و DNS/TLS اعمال می‌کند و اجرای cloudflared درون کلاستر، مسیرهای افزونه و پایدار فراهم می‌سازد. از نظر امنیت، بدون IP عمومی کار می‌کند و مزایایی مثل DDoS/WAF، mTLS و Access (کنترل هویتی) را در راستای مدل Zero Trust ارائه می‌دهد. استقرار با Helm و GitOps ساده است، HA با چندین نمونه cloudflared تضمین می‌شود و مشاهده‌پذیری از طریق لاگ و متریک‌ها در دسترس است. این راهکار برای انتشار داشبوردها، APIها، محیط‌های آزمایشی/Preview و سناریوهای هیبریدی مناسب است و می‌تواند در کنار NGINX/Traefik به‌کار رود؛ با این پیش‌نیاز که حساب Cloudflare و اتصال خروجی فراهم باشد.
#Cloudflare #Tunnel #IngressController #Kubernetes #ZeroTrust #cloudflared #DevOps #ApplicationSecurity
🟣لینک مقاله:
https://ku.bz/pMRcpczmz
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Cloudflare Tunnel Ingress Controller
🟢 خلاصه مقاله:
Cloudflare Tunnel Ingress Controller روشی Kubernetes-native برای انتشار امن سرویس‌هاست که به‌جای باز کردن پورت‌های ورودی و ساخت Load Balancer عمومی، از اتصال‌های خروجی رمزنگاری‌شده به لبه Cloudflare استفاده می‌کند. این Controller با تماشای Ingress، Service و CRDها، مسیرها را به‌صورت خودکار روی Cloudflare Tunnel و DNS/TLS اعمال می‌کند و اجرای cloudflared درون کلاستر، مسیرهای افزونه و پایدار فراهم می‌سازد. از نظر امنیت، بدون IP عمومی کار می‌کند و مزایایی مثل DDoS/WAF، mTLS و Access (کنترل هویتی) را در راستای مدل Zero Trust ارائه می‌دهد. استقرار با Helm و GitOps ساده است، HA با چندین نمونه cloudflared تضمین می‌شود و مشاهده‌پذیری از طریق لاگ و متریک‌ها در دسترس است. این راهکار برای انتشار داشبوردها، APIها، محیط‌های آزمایشی/Preview و سناریوهای هیبریدی مناسب است و می‌تواند در کنار NGINX/Traefik به‌کار رود؛ با این پیش‌نیاز که حساب Cloudflare و اتصال خروجی فراهم باشد.
#Cloudflare #Tunnel #IngressController #Kubernetes #ZeroTrust #cloudflared #DevOps #ApplicationSecurity
🟣لینک مقاله:
https://ku.bz/pMRcpczmz
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - STRRL/cloudflare-tunnel-ingress-controller: 🚀 Expose the website directly into the internet! The Kuberntes Ingress Controller…
🚀 Expose the website directly into the internet! The Kuberntes Ingress Controller based on Cloudflare Tunnel. - STRRL/cloudflare-tunnel-ingress-controller
❤1
🔵 عنوان مقاله
Nginx Ingress Controller Upgrade
🟢 خلاصه مقاله:
ارتقای Nginx Ingress Controller برای به‌روزرسانی امنیت، کارایی و قابلیت‌ها در محیط‌های Kubernetes ضروری است. پیش از شروع، نسخه فعلی، روش استقرار (Helm یا Manifest)، وابستگی‌ها، و تغییرات API/CRD مانند Ingress و IngressClass را از روی Release Notes بررسی کنید و از پیکربندی‌ها، CRDها، Secrets (به‌ویژه TLS) و RBAC نسخه پشتیبان بگیرید. برای کاهش ریسک، از استراتژی بدون قطعی مانند blue/green یا canary با ingressClass جداگانه استفاده کنید؛ یا در خوشه‌های کوچک‌تر، با Rolling Upgrade و تنظیمات محتاطانه (Probeهای درست، PDB، و maxUnavailable صفر) ارتقا دهید. ارتقا را ابتدا در Staging انجام دهید، سپس Rollout، لاگ‌ها، سلامت سرویس، و شاخص‌هایی مثل نرخ 4xx/5xx، تأخیر، و پایداری LoadBalancer را رصد کنید و در صورت نیاز آماده Rollback باشید. پس از موفقیت، Annotationهای منسوخ را پاکسازی، به فیلدهای جدید مانند ingressClassName مهاجرت، و مستندات و Runbookها را به‌روزرسانی کنید تا با بهترین‌روش‌های Kubernetes همسو بمانید.
#Nginx #Kubernetes #IngressController #DevOps #Helm #ZeroDowntime #CRD #TLS
🟣لینک مقاله:
https://ku.bz/LKcy755z6
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Nginx Ingress Controller Upgrade
🟢 خلاصه مقاله:
ارتقای Nginx Ingress Controller برای به‌روزرسانی امنیت، کارایی و قابلیت‌ها در محیط‌های Kubernetes ضروری است. پیش از شروع، نسخه فعلی، روش استقرار (Helm یا Manifest)، وابستگی‌ها، و تغییرات API/CRD مانند Ingress و IngressClass را از روی Release Notes بررسی کنید و از پیکربندی‌ها، CRDها، Secrets (به‌ویژه TLS) و RBAC نسخه پشتیبان بگیرید. برای کاهش ریسک، از استراتژی بدون قطعی مانند blue/green یا canary با ingressClass جداگانه استفاده کنید؛ یا در خوشه‌های کوچک‌تر، با Rolling Upgrade و تنظیمات محتاطانه (Probeهای درست، PDB، و maxUnavailable صفر) ارتقا دهید. ارتقا را ابتدا در Staging انجام دهید، سپس Rollout، لاگ‌ها، سلامت سرویس، و شاخص‌هایی مثل نرخ 4xx/5xx، تأخیر، و پایداری LoadBalancer را رصد کنید و در صورت نیاز آماده Rollback باشید. پس از موفقیت، Annotationهای منسوخ را پاکسازی، به فیلدهای جدید مانند ingressClassName مهاجرت، و مستندات و Runbookها را به‌روزرسانی کنید تا با بهترین‌روش‌های Kubernetes همسو بمانید.
#Nginx #Kubernetes #IngressController #DevOps #Helm #ZeroDowntime #CRD #TLS
🟣لینک مقاله:
https://ku.bz/LKcy755z6
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Karuppiah Natarajan's Blog
Nginx Ingress Controller Upgrade
This is what I planned when I thought about this for my current company and team and our infrastructure. Funnily, I was told later that we had to upgrade only standalone nginx instances and not the nginx ingress controller. But I still kept this plan...
👍1
🔵 عنوان مقاله
Platform engineering toolkit for Kubernetes
🟢 خلاصه مقاله:
این جعبه‌ابزار مهندسی پلتفرم برای Kubernetes مسیرهای استاندارد و خودسرویس را برای ساخت، استقرار و اجرای نرم‌افزار فراهم می‌کند. هسته آن شامل IaC با Terraform یا Crossplane و Cluster API، مدیریت پیکربندی با Helm یا Kustomize و اعمال تغییرات به‌صورت GitOps توسط Argo CD یا Flux است. امنیت و انطباق با policy-as-code از طریق OPA Gatekeeper یا Kyverno، مدیریت اسرار با Vault یا SOPS، و امنیت زنجیره تأمین با امضا و اسکن تصویر (Sigstore Cosign، Trivy و SBOM) تضمین می‌شود. مشاهده‌پذیری و پایداری با Prometheus، Grafana، OpenTelemetry و بک‌اندهایی مانند Jaeger/Tempo/Loki، به‌همراه SLOها، مقیاس‌گذاری HPA/VPA/KEDA و در صورت نیاز service mesh مثل Istio یا Linkerd و شبکه‌سازی Cilium/Calico تقویت می‌گردد. تجربه توسعه‌دهنده از طریق یک Internal Developer Portal مانند Backstage، الگوهای طلایی، ادغام با CI/CD (GitHub Actions، GitLab CI، Jenkins)، محیط‌های پیش‌نمایش و تحویل تدریجی با Argo Rollouts یا Flagger بهبود می‌یابد. برای عملیات و حاکمیت، RBAC حداقلی، خط‌مشی‌های پذیرش، ممیزی، مدیریت هزینه با Kubecost و رویکرد چندکلاستری/چندابری به‌کار می‌رود. اندازه‌گیری موفقیت با شاخص‌های DORA و تمرکز بر کاهش بار شناختی انجام می‌شود و با اتخاذ تدریجی پشته، از GitOps و IaC آغاز و سپس به سیاست‌ها، مشاهده‌پذیری، automation و بهبود DX گسترش می‌یابد.
#Kubernetes #PlatformEngineering #DevOps #GitOps #CloudNative #SRE #Observability #Automation
🟣لینک مقاله:
https://ku.bz/TpyynNht7
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Platform engineering toolkit for Kubernetes
🟢 خلاصه مقاله:
این جعبه‌ابزار مهندسی پلتفرم برای Kubernetes مسیرهای استاندارد و خودسرویس را برای ساخت، استقرار و اجرای نرم‌افزار فراهم می‌کند. هسته آن شامل IaC با Terraform یا Crossplane و Cluster API، مدیریت پیکربندی با Helm یا Kustomize و اعمال تغییرات به‌صورت GitOps توسط Argo CD یا Flux است. امنیت و انطباق با policy-as-code از طریق OPA Gatekeeper یا Kyverno، مدیریت اسرار با Vault یا SOPS، و امنیت زنجیره تأمین با امضا و اسکن تصویر (Sigstore Cosign، Trivy و SBOM) تضمین می‌شود. مشاهده‌پذیری و پایداری با Prometheus، Grafana، OpenTelemetry و بک‌اندهایی مانند Jaeger/Tempo/Loki، به‌همراه SLOها، مقیاس‌گذاری HPA/VPA/KEDA و در صورت نیاز service mesh مثل Istio یا Linkerd و شبکه‌سازی Cilium/Calico تقویت می‌گردد. تجربه توسعه‌دهنده از طریق یک Internal Developer Portal مانند Backstage، الگوهای طلایی، ادغام با CI/CD (GitHub Actions، GitLab CI، Jenkins)، محیط‌های پیش‌نمایش و تحویل تدریجی با Argo Rollouts یا Flagger بهبود می‌یابد. برای عملیات و حاکمیت، RBAC حداقلی، خط‌مشی‌های پذیرش، ممیزی، مدیریت هزینه با Kubecost و رویکرد چندکلاستری/چندابری به‌کار می‌رود. اندازه‌گیری موفقیت با شاخص‌های DORA و تمرکز بر کاهش بار شناختی انجام می‌شود و با اتخاذ تدریجی پشته، از GitOps و IaC آغاز و سپس به سیاست‌ها، مشاهده‌پذیری، automation و بهبود DX گسترش می‌یابد.
#Kubernetes #PlatformEngineering #DevOps #GitOps #CloudNative #SRE #Observability #Automation
🟣لینک مقاله:
https://ku.bz/TpyynNht7
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
koreo.dev
A new approach to Kubernetes configuration management and resource orchestration.
k0s is the simple, solid & certified Kubernetes distribution that works on any infrastructure: bare-metal, on-premises, edge, IoT, public & private clouds.
اگه میخواید کوبرنتیز رو روی Bare Metal و جای شخصی بیارید بالا و نمیخواد دردسر زیادی برای قسمت‌های مختلفش بکشید میتونید از این پروژه استفاده کنید.
#K8s #kubernetes #Bare #Metal #DevOps #Infra #Infrastructure #Tools
https://k0sproject.io
اگه میخواید کوبرنتیز رو روی Bare Metal و جای شخصی بیارید بالا و نمیخواد دردسر زیادی برای قسمت‌های مختلفش بکشید میتونید از این پروژه استفاده کنید.
#K8s #kubernetes #Bare #Metal #DevOps #Infra #Infrastructure #Tools
https://k0sproject.io
🔵 عنوان مقاله
Kubernetes observability from day one - mixins on Grafana, mimir and alloy
🟢 خلاصه مقاله:
**این مقاله نشان می‌دهد چگونه با استفاده از Kubernetes Mixins (باندل‌هایی از dashboards، alerts و rules بر پایه Jsonnet) می‌توان از همان ابتدا یک پشته observability روی Grafana، Mimir و Alloy راه‌اندازی کرد. نویسنده نحوه رندر و استقرار Mixins برای تولید داشبوردها و قوانین عملیاتی، و نیز اعمال config overrides برای انطباق با برچسب‌ها، نام‌گذاری‌ها و متریک‌های اختصاصی را توضیح می‌دهد. نتیجه، یک نقطه شروع سریع و استاندارد برای observability است که همزمان امکان سفارشی‌سازی و توسعه تدریجی را فراهم می‌کند.
#Kubernetes #Observability #Grafana #Mimir #Alloy #Jsonnet #DevOps
🟣لینک مقاله:
https://ku.bz/HQ0lMwlh2
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Kubernetes observability from day one - mixins on Grafana, mimir and alloy
🟢 خلاصه مقاله:
**این مقاله نشان می‌دهد چگونه با استفاده از Kubernetes Mixins (باندل‌هایی از dashboards، alerts و rules بر پایه Jsonnet) می‌توان از همان ابتدا یک پشته observability روی Grafana، Mimir و Alloy راه‌اندازی کرد. نویسنده نحوه رندر و استقرار Mixins برای تولید داشبوردها و قوانین عملیاتی، و نیز اعمال config overrides برای انطباق با برچسب‌ها، نام‌گذاری‌ها و متریک‌های اختصاصی را توضیح می‌دهد. نتیجه، یک نقطه شروع سریع و استاندارد برای observability است که همزمان امکان سفارشی‌سازی و توسعه تدریجی را فراهم می‌کند.
#Kubernetes #Observability #Grafana #Mimir #Alloy #Jsonnet #DevOps
🟣لینک مقاله:
https://ku.bz/HQ0lMwlh2
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
www.amazinglyabstract.it
Kubernetes observability from day one - Mixins on Grafana, Mimir and Alloy
One of the things we quickly find out when using Kubernetes is that it’s hard to know what is going on in our cluster. In most cases, we implement monitoring...
🔵 عنوان مقاله
Managing Kubernetes Resources Across Multiple Clusters
🟢 خلاصه مقاله:
**این مطالعه‌ی موردی نشان می‌دهد چگونه با ساخت یک multi-cluster reconciler می‌توان منابع Kubernetes را میان چند کلاستر شاردشده مدیریت کرد تا تاب‌آوری و محدودسازی دامنه‌ی خرابی بهبود یابد. بارهای stateless میان سه کلاستر مستقل توزیع می‌شوند تا خرابی‌های زیرساختی یا ارتقاهای پرخطر، فقط بخشی از ظرفیت را تحت‌تأثیر قرار دهند.
هسته‌ی معماری یک CRD برای حالت مطلوب سراسری و یک reconciler است که آن را به مانیفست‌های هر کلاستر تبدیل می‌کند. شاردینگ، ظرفیت یا ترافیک را بین سه کلاستر تقسیم می‌کند. این reconciler ایدمپورنت است، با leader election و backoff پایدار می‌ماند، انحراف پیکربندی را اصلاح می‌کند و با RBAC و اعتبارهای محدودشده، دسترسی میان کلاستری را امن نگه می‌دارد.
مدیریت ترافیک با DNS یا Global Load Balancer انجام می‌شود و امکان تقسیم درصدی ترافیک را فراهم می‌کند. با اتکا به health check و پروب‌های سناریوی واقعی، در صورت افت سلامت یک کلاستر، ترافیک به‌صورت خودکار تخلیه و به کلاسترهای سالم بازتوزیع می‌شود. این راهکار با رعایت PDB، HPA و الگوهای progressive delivery، انتشارهای کم‌ریسک را هماهنگ می‌کند.
از نظر عملیات، ادغام با GitOps (مانند Argo CD یا Flux) نسخه‌پذیری و ممیزی‌پذیری وضعیت سراسری را تضمین می‌کند. رصد SLO، متریک‌های تجمیعی و برچسب‌های کلاستر در لاگ‌ها/تِرِیس‌ها، پایش و عیب‌یابی را ساده می‌سازد و آزمون‌های آشوب، رفتار در خرابی‌های جزئی را تأیید می‌کند. تمرکز مقاله بر سرویس‌های stateless است و برای سرویس‌های stateful به نیازهای اضافه مثل تکرار داده اشاره می‌کند. در نهایت، دستاورد اصلی افزایش دسترس‌پذیری و کنترل بهتر دامنه‌ی خرابی است، با هزینه‌ی پیچیدگی و سربار؛ و مقایسه‌ای کوتاه با KubeFed، Cluster API و راهکارهای Fleet برای تصمیم‌گیری ساخت یا خرید ارائه می‌شود.
#Kubernetes #MultiCluster #Sharding #HighAvailability #DevOps #GitOps #SRE
🟣لینک مقاله:
https://ku.bz/1HTWb0GLC
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Managing Kubernetes Resources Across Multiple Clusters
🟢 خلاصه مقاله:
**این مطالعه‌ی موردی نشان می‌دهد چگونه با ساخت یک multi-cluster reconciler می‌توان منابع Kubernetes را میان چند کلاستر شاردشده مدیریت کرد تا تاب‌آوری و محدودسازی دامنه‌ی خرابی بهبود یابد. بارهای stateless میان سه کلاستر مستقل توزیع می‌شوند تا خرابی‌های زیرساختی یا ارتقاهای پرخطر، فقط بخشی از ظرفیت را تحت‌تأثیر قرار دهند.
هسته‌ی معماری یک CRD برای حالت مطلوب سراسری و یک reconciler است که آن را به مانیفست‌های هر کلاستر تبدیل می‌کند. شاردینگ، ظرفیت یا ترافیک را بین سه کلاستر تقسیم می‌کند. این reconciler ایدمپورنت است، با leader election و backoff پایدار می‌ماند، انحراف پیکربندی را اصلاح می‌کند و با RBAC و اعتبارهای محدودشده، دسترسی میان کلاستری را امن نگه می‌دارد.
مدیریت ترافیک با DNS یا Global Load Balancer انجام می‌شود و امکان تقسیم درصدی ترافیک را فراهم می‌کند. با اتکا به health check و پروب‌های سناریوی واقعی، در صورت افت سلامت یک کلاستر، ترافیک به‌صورت خودکار تخلیه و به کلاسترهای سالم بازتوزیع می‌شود. این راهکار با رعایت PDB، HPA و الگوهای progressive delivery، انتشارهای کم‌ریسک را هماهنگ می‌کند.
از نظر عملیات، ادغام با GitOps (مانند Argo CD یا Flux) نسخه‌پذیری و ممیزی‌پذیری وضعیت سراسری را تضمین می‌کند. رصد SLO، متریک‌های تجمیعی و برچسب‌های کلاستر در لاگ‌ها/تِرِیس‌ها، پایش و عیب‌یابی را ساده می‌سازد و آزمون‌های آشوب، رفتار در خرابی‌های جزئی را تأیید می‌کند. تمرکز مقاله بر سرویس‌های stateless است و برای سرویس‌های stateful به نیازهای اضافه مثل تکرار داده اشاره می‌کند. در نهایت، دستاورد اصلی افزایش دسترس‌پذیری و کنترل بهتر دامنه‌ی خرابی است، با هزینه‌ی پیچیدگی و سربار؛ و مقایسه‌ای کوتاه با KubeFed، Cluster API و راهکارهای Fleet برای تصمیم‌گیری ساخت یا خرید ارائه می‌شود.
#Kubernetes #MultiCluster #Sharding #HighAvailability #DevOps #GitOps #SRE
🟣لینک مقاله:
https://ku.bz/1HTWb0GLC
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
Managing Kubernetes Resources Across Multiple Clusters
At Airtable, we use Amazon’s Elastic Kubernetes Service (EKS) to manage Kubernetes control planes so we can focus on deploying our…
🔵 عنوان مقاله
kubectx + kubens: Power tools for kubectl
🟢 خلاصه مقاله:
kubectx و kubens ابزارهای خط فرمانی هستند که کار با kubectl را در محیط‌های چندکلاستری و چند-namespace ساده و سریع می‌کنند. kubectx جابه‌جایی بین contextها (کلسترها) را تسهیل می‌کند و kubens تغییر و تنظیم namespace پیش‌فرض برای kubectl را به‌صورت سریع و ایمن انجام می‌دهد. ترکیب این دو ابزار بهره‌وری را بالا می‌برد، احتمال خطا را کم می‌کند و برای تیم‌هایی که بین محیط‌های مختلف کار می‌کنند بسیار کاربردی است. این پروژه‌ها روی GitHub در دسترس هستند.
#Kubernetes #kubectl #kubectx #kubens #DevOps #CLI #K8s #SRE
🟣لینک مقاله:
https://ku.bz/6f09cGVHG
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
kubectx + kubens: Power tools for kubectl
🟢 خلاصه مقاله:
kubectx و kubens ابزارهای خط فرمانی هستند که کار با kubectl را در محیط‌های چندکلاستری و چند-namespace ساده و سریع می‌کنند. kubectx جابه‌جایی بین contextها (کلسترها) را تسهیل می‌کند و kubens تغییر و تنظیم namespace پیش‌فرض برای kubectl را به‌صورت سریع و ایمن انجام می‌دهد. ترکیب این دو ابزار بهره‌وری را بالا می‌برد، احتمال خطا را کم می‌کند و برای تیم‌هایی که بین محیط‌های مختلف کار می‌کنند بسیار کاربردی است. این پروژه‌ها روی GitHub در دسترس هستند.
#Kubernetes #kubectl #kubectx #kubens #DevOps #CLI #K8s #SRE
🟣لینک مقاله:
https://ku.bz/6f09cGVHG
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - ahmetb/kubectx: Faster way to switch between clusters and namespaces in kubectl
Faster way to switch between clusters and namespaces in kubectl - ahmetb/kubectx
🔵 عنوان مقاله
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