DevOps Labdon
530 subscribers
29 photos
4 videos
2 files
988 links
👑 DevOps Labdon

حمایت مالی:
https://www.coffeete.ir/mrbardia72

ادمین:
@mrbardia72
Download Telegram
🔵 عنوان مقاله
Troubleshooting packet drops in a Kubernetes-based observability platform

🟢 خلاصه مقاله:
** این مطالعهٔ موردی نشان می‌دهد تیم SRE در Kapital Bank چگونه افت‌های گهگاهی کارایی در یک پلتفرم observability مبتنی بر Kubernetes را که به Memcached متکی بود ریشه‌یابی کرد. آن‌ها با همبسته‌سازی سیگنال‌ها در سطح Kubernetes و شواهد کرنل لینوکس، مشکل را به دراپ بسته‌ها در مسیر شبکهٔ کرنل تحت الگوهای بار خاص محدود کردند. جمع‌بندی این بود که برخی مقادیر پیش‌فرض کرنل برای الگوهای اتصال پرتراکم و پرتلاطم در محیط‌های کانتینری مناسب نیست و باعث فشار روی صف‌ها و بافرهای شبکه می‌شود. با تنظیم دقیق پارامترهای کرنل و اعتبارسنجی تدریجی تغییرات روی نودهای میزبان Memcached، نرخ دراپ بسته‌ها کاهش یافت و پایداری و پیش‌بینی‌پذیری کارایی بهبود پیدا کرد. نتیجهٔ عملی: به مسائل کارایی به‌صورت میان‌لایه‌ای نگاه کنید، قبل و بعد از تغییرات اندازه‌گیری کنید، و تنظیمات ایمن کرنل را در ران‌بوک‌ها مستند سازید.

#Kubernetes #SRE #Observability #Memcached #LinuxKernel #Networking #DevOps #PerformanceTuning

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


👑 @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
🔵 عنوان مقاله
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
🔵 عنوان مقاله
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
🔵 عنوان مقاله
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
🔵 عنوان مقاله
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
1
🔵 عنوان مقاله
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
🔵 عنوان مقاله
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
🔵 عنوان مقاله
A Hands-on Guide to Kubernetes Observability with Whisker

🟢 خلاصه مقاله:
** این راهنمای عملی با تمرکز بر Kubernetes Observability و ابزار متن‌باز Whisker، در قالب یک لَب تعاملی نشان می‌دهد چگونه مشکلات مربوط به NetworkPolicy را سریع شناسایی و عیب‌یابی کنید. با بررسی رفتار اتصال بین سرویس‌ها و نگاشت محدودیت‌ها به قوانین NetworkPolicy، می‌آموزید مشکل از کجاست، چگونه فرضیه‌ها را آزمایش و راه‌حل را اعتبارسنجی کنید، و پس از اصلاح، صحت عملکرد را تأیید نمایید. نتیجه این لَب یک روند تکرارشونده و کاربردی برای تشخیص علت ریشه‌ای و کاهش زمان بازیابی است که برای تیم‌های پلتفرم، SRE و توسعه‌دهندگان مفید است.

#Kubernetes #Observability #Whisker #NetworkPolicy #Troubleshooting #CloudNative #SRE #OpenSource

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


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

🟢 خلاصه مقاله:
Kubetail یک اسکریپت bash سبک است که لاگ‌های چندین pod را در Kubernetes به‌صورت هم‌زمان و در یک جریان واحد نمایش می‌دهد؛ یعنی همان کاری که kubectl logs -f انجام می‌دهد، اما برای چند pod به‌طور یکجا. این ابزار فقط روی کلاینت اجرا می‌شود و چیزی داخل کلاستر نصب نمی‌کند، بنابراین با kubeconfig و دسترسی‌های فعلی شما کار می‌کند.

با اشاره به الگوهای نام، برچسب‌ها یا namespace، می‌توانید لاگ‌ چندین سرویس را هم‌زمان دنبال کنید و خروجی هر pod را در یک تایم‌لاین یکپارچه—معمولاً با رنگ یا تفکیک—ببینید. Kubetail برای دیباگ سریع microservices و رفع اشکال سناریوهای توزیع‌شده عالی است. البته جایگزین سیستم‌های ذخیره‌سازی و مشاهده‌پذیری بلندمدت نیست؛ هدفش ساده‌سازی و سرعت‌بخشی به tail/trace لحظه‌ای لاگ‌هاست.

#Kubetail #Kubernetes #kubectl #DevOps #Logs #Bash #Observability #SRE

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


👑 @DevOps_Labdon
🔵 عنوان مقاله
Kubernetes Orphaned Resources Finder

🟢 خلاصه مقاله:
** خلاصه فارسی: Kor در آدرس github.com/yonahdKor ابزاری برای کشف منابع بلااستفاده در Kubernetes است. این ابزار منابعی مانند ConfigMaps، Secrets، Services، ServiceAccounts، Deployments، Statefulsets و Roles را که دیگر استفاده نمی‌شوند شناسایی و فهرست می‌کند تا پاکسازی ایمن، کاهش هزینه و بهبود امنیت و نگه‌داری کلاستر ساده‌تر شود. Kor برای ممیزی‌ها، مهاجرت‌ها و نگه‌داری دوره‌ای مفید است و با کاهش شلوغی کلاستر، ریسک و خطاهای عملیاتی را پایین می‌آورد.

#Kubernetes #Kor #DevOps #CloudNative #ClusterCleanup #CostOptimization #Security #SRE

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


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

🟢 خلاصه مقاله:
** k8sgpt یک ابزار تحلیل برای محیط‌های Kubernetes است که با جمع‌آوری نشانه‌های کلیدی مانند وضعیت Pod/Node، Events و پیکربندی‌ها، خطاها و بدپیکربندی‌ها را شناسایی و به زبان ساده و قابل اقدام توضیح می‌دهد. این ابزار در عملیات روزمره، از رفع اشکال در حالت on-call تا پیش‌گیری از خطا در توسعه و CI/CD، به کاهش زمان عیب‌یابی و بهبود پایداری کمک می‌کند. k8sgpt در کنار ابزارهایی مثل kubectl و در جریان‌های کاری موجود DevOps و SRE کار می‌کند و با ارائه‌ی جمع‌بندی‌های دقیق و پیشنهادهای اصلاحی، مسیر رسیدن از نشانه‌ها به ریشه مشکل را کوتاه می‌سازد.

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

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


👑 @DevOps_Labdon
🔵 عنوان مقاله
Wrangling Kubernetes contexts (3 minute read)

🟢 خلاصه مقاله:
**مشکل از یک وضعیت سراسری پنهان شروع می‌شود: خط current-context در ~/.kube/config تعیین می‌کند kubectl به کدام cluster وصل شود، و همین باعث می‌شود به‌سادگی اشتباهاً روی production فرمان اجرا کنید. راهکار امن‌تر این است که فقط config مربوط به development را به‌صورت پیش‌فرض نگه دارید و برای رفتن به production همیشه به‌طور صریح با KUBECONFIG (مثلاً از طریق shell aliases) سوییچ کنید. با این کار هر عمل پرریسک باید عمداً با یک پیشوند مشخص اجرا شود، به جای تکیه بر context سراسری و فراموش‌شدنی؛ نتیجه، کاهش چشمگیر خطاهای ناخواسته در محیط production است.

#Kubernetes #kubectl #DevOps #Kubeconfig #SRE #CloudNative #ProductionSafety

🟣لینک مقاله:
https://natkr.com/2025-11-14-kubernetes-contexts/?utm_source=tldrdevops


👑 @DevOps_Labdon
🔥1
🔵 عنوان مقاله
K8z: the Kubernetes manager

🟢 خلاصه مقاله:
ک8z به‌عنوان یک مدیر یکپارچه برای Kubernetes معرفی می‌شود که چرخه عمر کلاسترها را در محیط‌های چندابر و on‑prem ساده می‌کند، در عین حال برای تیم‌های پلتفرم «گاردریل» فراهم می‌سازد و تجربه توسعه‌دهنده را روان‌تر می‌کند. هسته اصلی آن بر جریان‌های declarative و ادغام با GitOps تکیه دارد، با پشتیبانی از Helm و الگوهای کاربردی، ارتقا/بازگشت، و انتشار تدریجی مانند canary و blue/green. در حوزه امنیت و انطباق، کنترل متمرکز دسترسی با RBAC و SSO (مانند OIDC)، اعمال سیاست با OPA Gatekeeper یا Kyverno، و مدیریت امن اسرار از طریق Vault یا سرویس‌های KMS برجسته است؛ همچنین ثبت وقایع و دید هزینه‌ها فراهم می‌شود. برای قابلیت اتکا و مشاهده‌پذیری، اتصال آماده به Prometheus و Grafana، بررسی سلامت، مقیاس‌پذیری خودکار و پشتیبان‌گیری/بازیابی (شامل etcd و حجم‌های ماندگار) پوشش داده شده است. K8z پلتفرمی توسعه‌پذیر با API، CLI و افزونه‌ها ارائه می‌کند و با ابزارهایی مانند Terraform یکپارچه می‌شود تا بدون قفل‌شدن در تامین‌کننده، نیازهای تیم‌های Platform Engineering، SRE و اپلیکیشن را از تامین تا عملیات روز دوم پاسخ دهد.

#Kubernetes #DevOps #PlatformEngineering #GitOps #CloudNative #SRE #Containers #Observability

🟣لینک مقاله:
https://k8z.dev


👑 @DevOps_Labdon
🔵 عنوان مقاله
Most Cloud-Native Roles are Software Engineers

🟢 خلاصه مقاله:
این مقاله بازار کار cloud-native در سال ۲۰۲۵ را بررسی می‌کند و نشان می‌دهد که حدود ۴۷٪ از موقعیت‌های مرتبط با Kubernetes به عنوان Software Engineer آگهی می‌شوند؛ در حالی‌که نقش‌های DevOps، Platform، DevSecOps و SRE سهم کمتری دارند. این روند بیانگر استخدامِ مهندس‌محور و حرکت به‌سمت shift-left است: از توسعه‌دهندگان انتظار می‌رود علاوه بر توسعه، با Kubernetes و بخشی از زیرساخت، امنیت و تحویل نیز درگیر باشند. برای متقاضیان، تسلط بر Kubernetes همراه با مهارت‌های CI/CD، IaC، observability و اصول امنیت ضروری‌تر شده است و در عین حال همکاری نزدیک با تیم‌های DevOps/Platform/SRE همچنان اهمیت دارد.

#CloudNative #Kubernetes #SoftwareEngineering #DevOps #SRE #DevSecOps #PlatformEngineering #TechJobs2025

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


👑 @DevOps_Labdon
1
🔵 عنوان مقاله
How We Rebuilt Our Vault Architecture with Raft, Snapshots, and DR

🟢 خلاصه مقاله:
ما معماری Vault را با تکیه بر سه رکن Raft، Snapshots و DR بازطراحی کردیم تا پیچیدگی عملیاتی را کاهش دهیم، وابستگی‌های بیرونی را حذف کنیم و تاب‌آوری را افزایش دهیم. با مهاجرت به ذخیره‌سازی یکپارچه مبتنی بر Raft، کلاستر ساده‌تر و قابل‌اعتمادتر شد و مسیر مهاجرت با محیط staging، تمرین‌های بازیابی، معیارهای rollback و پایش لحظه‌ای کنترل شد. Snapshots به‌طور خودکار زمان‌بندی و رمزنگاری شدند، در فضای ذخیره‌سازی ایمن نگهداری و با تمرین‌های دوره‌ای بازیابی راستی‌آزمایی شدند تا RPO شفاف و بازیابی قابل پیش‌بینی باشد. برای DR یک کلاستر ثانویه در دامنه خرابی جدا راه‌اندازی و با تکرار DR، برنامه failover با RTO مشخص و مانیتورینگ تأخیر تکرار، سلامت Raft و تازگی Snapshotها پیاده‌سازی شد. با امنیت لایه‌به‌لایه، least-privilege برای مقصد پشتیبان، مستندسازی و خودکارسازی بررسی‌ها، به عملیات پایدارتر و بازیابی سریع‌تر رسیدیم و اطمینان به سکوی مدیریت اسرار افزایش یافت.

#Vault #Raft #DisasterRecovery #Snapshots #DevOps #SRE #HighAvailability #Infrastructure

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


👑 @DevOps_Labdon
🔵 عنوان مقاله
How to Prevent Failures with Kubernetes Topology Spread Constraints

🟢 خلاصه مقاله:
این مقاله نشان می‌دهد چرا استفاده از Pod Topology Spread Constraints در زمان rolling updates می‌تواند باعث توزیع ناعادلانه پادها شود و در پایان استقرار، یک یا چند ناحیه بیش‌ازحد شلوغ بماند. علت این است که Scheduler در هنگام جای‌گذاری پادهای جدید، پادهای قدیمی و جدید را با هم در نظر می‌گیرد؛ بنابراین پادهای تازه را به نواحی «فعلاً» کم‌تراکم می‌فرستد، اما با حذف تدریجی پادهای قدیمی، همان نواحی از نسخه جدید اشباع می‌شوند.

راه‌حل پیشنهادی استفاده از matchLabelKeys (برای نمونه با کلید pod-template-hash) است تا Scheduler هر نسل از پادها را فقط نسبت به هم‌نسل‌های خودش پخش کند. بدین ترتیب هر ReplicaSet به‌طور مستقل متعادل می‌شود و چون نسل قبلی نیز از قبل متعادل بوده، مجموع پادها در طول و پس از rollout یکنواخت باقی می‌ماند.

برای اجرای درست، از پشتیبانی Kubernetes v1.25+ نسبت به matchLabelKeys مطمئن شوید، topologyKey مناسب (مثلاً topology.kubernetes.io/zone) و maxSkew معقول انتخاب کنید و سیاست whenUnsatisfiable را بسته به نیاز سخت‌گیرانه (DoNotSchedule) یا منعطف (ScheduleAnyway) تنظیم کنید.

#Kubernetes #PodTopologySpreadConstraints #TopologySpread #RollingUpdates #DevOps #SRE #HighAvailability #matchLabelKeys

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


👑 @DevOps_Labdon
🔵 عنوان مقاله
How Kubernetes Pod Priority and Preemption Work

🟢 خلاصه مقاله:
Kubernetes با استفاده از PriorityClass برای هر Pod اولویت تعیین می‌کند و kube-scheduler ابتدا Pods با اولویت بالاتر را زمان‌بندی می‌کند. اگر منابع کافی پیدا نشود، مکانیزم Preemption فعال می‌شود: scheduler روی یک Node کاندید بررسی می‌کند که با حذف Podهای کم‌اولویت‌تر (و بدون نقض PodDisruptionBudget) آیا می‌توان جا باز کرد یا نه. Pods با اولویت برابر یا بالاتر هرگز قربانی نمی‌شوند، و با PreemptionPolicy: Never می‌توان از ایجاد Preemption توسط یک Pod جلوگیری کرد. علاوه بر زمان‌بندی، در وضعیت کمبود منبع روی Node، kubelet در صورت نیاز معمولاً Podهای کم‌اولویت را زودتر Evict می‌کند تا سرویس‌های مهم پایدار بمانند. برای بهره‌گیری امن، چند PriorityClass مشخص (مثلاً system-critical، high، standard، batch) تعریف کنید، همراه با requests/limits مناسب، PDB برای حفاظت سرویس‌های حیاتی، و ResourceQuota؛ و رفتار Preemption را در محیط staging آزمایش کنید.

#Kubernetes #Pod #PriorityClass #Preemption #Scheduler #CloudNative #DevOps #SRE

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


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

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

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

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


👑 @DevOps_Labdon