🔵 عنوان مقاله
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.
🔵 عنوان مقاله
Autoscaling .NET APIs with KEDA and Kubernetes Metrics
🟢 خلاصه مقاله:
** مقیاسپذیری خودکار برای APIهای .NET در Kubernetes با ترکیب HPA، Kubernetes Metrics و KEDA ممکن میشود. KEDA با تعریف ScaledObject و تریگرهایی مثل درخواستدرثانیه یا تأخیر از Prometheus، عمق صف در RabbitMQ/Kafka، و زمانبندی cron، متریکهای خارجی را به HPA میدهد و حتی قابلیت scale‑to‑zero را فراهم میکند. برای APIهای .NET میتوان روی نرخ درخواست، تعداد درخواستهای درحال پردازش، یا صف کارهای پسزمینه مقیاس داد و همزمان یک تکیهگاه CPU برای جهشهای محاسباتی داشت. بهترینعملها شامل تنظیم درست requests/limits، همکاری با Cluster Autoscaler، تعریف readiness/liveness/startup probes، کنترل همزمانی، و بهینهسازیهای .NET مانند async I/O، HttpClientFactory و connection pooling است. با پایش Prometheus/Grafana، آزمون بار مثل k6، و پنجرههای تثبیت و cooldown مناسب، API بهصورت رویدادمحور، دقیق و بهصرفه مقیاس میگیرد و در اوجها پایدار میماند.
#Kubernetes #KEDA #DotNet #Autoscaling #HPA #Prometheus #CloudNative #APIs
🟣لینک مقاله:
https://ku.bz/X_jPVf71Q
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Autoscaling .NET APIs with KEDA and Kubernetes Metrics
🟢 خلاصه مقاله:
** مقیاسپذیری خودکار برای APIهای .NET در Kubernetes با ترکیب HPA، Kubernetes Metrics و KEDA ممکن میشود. KEDA با تعریف ScaledObject و تریگرهایی مثل درخواستدرثانیه یا تأخیر از Prometheus، عمق صف در RabbitMQ/Kafka، و زمانبندی cron، متریکهای خارجی را به HPA میدهد و حتی قابلیت scale‑to‑zero را فراهم میکند. برای APIهای .NET میتوان روی نرخ درخواست، تعداد درخواستهای درحال پردازش، یا صف کارهای پسزمینه مقیاس داد و همزمان یک تکیهگاه CPU برای جهشهای محاسباتی داشت. بهترینعملها شامل تنظیم درست requests/limits، همکاری با Cluster Autoscaler، تعریف readiness/liveness/startup probes، کنترل همزمانی، و بهینهسازیهای .NET مانند async I/O، HttpClientFactory و connection pooling است. با پایش Prometheus/Grafana، آزمون بار مثل k6، و پنجرههای تثبیت و cooldown مناسب، API بهصورت رویدادمحور، دقیق و بهصرفه مقیاس میگیرد و در اوجها پایدار میماند.
#Kubernetes #KEDA #DotNet #Autoscaling #HPA #Prometheus #CloudNative #APIs
🟣لینک مقاله:
https://ku.bz/X_jPVf71Q
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
Autoscaling .NET APIs with KEDA and Kubernetes Metrics
Responding to Traffic Surges in Real-Time Using Event-Driven Scaling in Modern .NET Microservices
🔵 عنوان مقاله
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
🔵 عنوان مقاله
A practical guide to error handling in Go (10 minute read)
🟢 خلاصه مقاله:
** این مقاله یک راهنمای عملی ۱۰ دقیقهای برای مدیریت خطا در Go است که نشان میدهد این زبان از طراحی مینیمال مبتنی بر بازگرداندن و بررسی error شروع کرده و به مرور با الگوهایی مثل افزودن کانتکست و استفاده از errors.Is و errors.As غنیتر شده است. چالش مهم، نبود ردیابی داخلی برای دیدن مسیر انتشار خطا است؛ ابزارهای Datadog یعنی Error Tracking و Orchestrion این شکاف را با ارائه دید شفاف از محل بروز خطا و نحوه انتشار آن در کد پوشش میدهند و عیبیابی را سریعتر و دقیقتر میکنند. جمعبندی: بهکارگیری الگوهای idiomatic در Go در کنار این ابزارها، خطاها را از پیامهای کوتاه به روایتی قابل پیگیری از رخداد تا رفع تبدیل میکند.
#Go #Golang #ErrorHandling #Datadog #ErrorTracking #Orchestrion #Tracing #Observability
🟣لینک مقاله:
https://www.datadoghq.com/blog/go-error-handling/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
A practical guide to error handling in Go (10 minute read)
🟢 خلاصه مقاله:
** این مقاله یک راهنمای عملی ۱۰ دقیقهای برای مدیریت خطا در Go است که نشان میدهد این زبان از طراحی مینیمال مبتنی بر بازگرداندن و بررسی error شروع کرده و به مرور با الگوهایی مثل افزودن کانتکست و استفاده از errors.Is و errors.As غنیتر شده است. چالش مهم، نبود ردیابی داخلی برای دیدن مسیر انتشار خطا است؛ ابزارهای Datadog یعنی Error Tracking و Orchestrion این شکاف را با ارائه دید شفاف از محل بروز خطا و نحوه انتشار آن در کد پوشش میدهند و عیبیابی را سریعتر و دقیقتر میکنند. جمعبندی: بهکارگیری الگوهای idiomatic در Go در کنار این ابزارها، خطاها را از پیامهای کوتاه به روایتی قابل پیگیری از رخداد تا رفع تبدیل میکند.
#Go #Golang #ErrorHandling #Datadog #ErrorTracking #Orchestrion #Tracing #Observability
🟣لینک مقاله:
https://www.datadoghq.com/blog/go-error-handling/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Datadog
A practical guide to error handling in Go | Datadog
Learn about error handling patterns in Go and how they can be further enhanced by using Orchestrion with Datadog Error Tracking.
🔵 عنوان مقاله
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
🔵 عنوان مقاله
Kubernetes pod scheduling: balancing cost and resilience
🟢 خلاصه مقاله:
این مقاله از CAST AI نشان میدهد چگونه با تنظیم سیاستهای زمانبندی در Kubernetes میتوان هزینه را کاهش داد و در عین حال تابآوری را حفظ کرد. با استفاده از anti-affinity از هممکانی replicaها روی یک node یا zone جلوگیری میشود تا شعاع خرابی کم شود، اما سختگیری بیش از حد میتواند به fragmentation و افزایش بیمورد ظرفیت منجر شود؛ بنابراین ترکیب قوانین الزامی و ترجیحی پیشنهاد میشود. spread constraints نیز برای پخش یکنواخت podها میان nodeها/zoneها و کاهش نقاط داغ بهکار میرود، ولی اگر خیلی سخت تنظیم شوند ممکن است مقیاسگستری ناخواسته ایجاد کنند؛ تنظیم دقیق پارامترها راهحل است. در نهایت، affinity weights امکان میدهد بار را به ظرفیت ارزانتر هدایت کنید و مسیرهای جایگزین برای پایداری داشته باشید. جمعبندی مقاله: با پایش پیوسته و همافزایی این سیاستها، میتوان بین هزینه و تابآوری توازن مؤثری ساخت.
#Kubernetes
#PodScheduling
#CostOptimization
#Resilience
#AntiAffinity
#TopologySpreadConstraints
#NodeAffinity
🟣لینک مقاله:
https://ku.bz/2wgGRZMjd
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Kubernetes pod scheduling: balancing cost and resilience
🟢 خلاصه مقاله:
این مقاله از CAST AI نشان میدهد چگونه با تنظیم سیاستهای زمانبندی در Kubernetes میتوان هزینه را کاهش داد و در عین حال تابآوری را حفظ کرد. با استفاده از anti-affinity از هممکانی replicaها روی یک node یا zone جلوگیری میشود تا شعاع خرابی کم شود، اما سختگیری بیش از حد میتواند به fragmentation و افزایش بیمورد ظرفیت منجر شود؛ بنابراین ترکیب قوانین الزامی و ترجیحی پیشنهاد میشود. spread constraints نیز برای پخش یکنواخت podها میان nodeها/zoneها و کاهش نقاط داغ بهکار میرود، ولی اگر خیلی سخت تنظیم شوند ممکن است مقیاسگستری ناخواسته ایجاد کنند؛ تنظیم دقیق پارامترها راهحل است. در نهایت، affinity weights امکان میدهد بار را به ظرفیت ارزانتر هدایت کنید و مسیرهای جایگزین برای پایداری داشته باشید. جمعبندی مقاله: با پایش پیوسته و همافزایی این سیاستها، میتوان بین هزینه و تابآوری توازن مؤثری ساخت.
#Kubernetes
#PodScheduling
#CostOptimization
#Resilience
#AntiAffinity
#TopologySpreadConstraints
#NodeAffinity
🟣لینک مقاله:
https://ku.bz/2wgGRZMjd
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Cast AI
Kubernetes Pod Scheduling: Balancing Cost and Resilience
Master Kubernetes pod scheduling to balance cost efficiency and resilience. Learn optimization strategies for production clusters.
🔵 عنوان مقاله
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
🔵 عنوان مقاله
How we found a bug in Go's arm64 compiler (11 minute read)
🟢 خلاصه مقاله:
Cloudflare یک باگ از نوع race condition را در کامپایلر Go برای معماری arm64 پیدا کرد که باعث panicهای پراکنده روی ماشینهای arm64 به دلیل خرابشدن پشته میشد. این باگ وقتی فعال میشد که asynchronous preemption دقیقا بین دستورهای تنظیم پیاپی اشارهگر پشته در جریان garbage collection رخ میداد و در نتیجه پشته موقتا در وضعیت نامعتبر دیده میشد.
راهکار این است که بهجای تغییر پلهای اشارهگر پشته، ابتدا offset در یک رجیستر موقت ساخته میشود و سپس همان مقدار در قالب یک opcode غیرقابلتفکیک به RSP اضافه میگردد تا اشارهگر پشته همواره معتبر باشد. این اصلاح در نسخههای go1.23.12، go1.24.6 و go1.25.0 منتشر شده و کاربران Go روی arm64 باید برای جلوگیری از این کرشهای نادر اما جدی، ارتقا دهند.
#Go #arm64 #Compiler #RaceCondition #Cloudflare #GarbageCollection #Concurrency #BugFix
🟣لینک مقاله:
https://blog.cloudflare.com/how-we-found-a-bug-in-gos-arm64-compiler/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
How we found a bug in Go's arm64 compiler (11 minute read)
🟢 خلاصه مقاله:
Cloudflare یک باگ از نوع race condition را در کامپایلر Go برای معماری arm64 پیدا کرد که باعث panicهای پراکنده روی ماشینهای arm64 به دلیل خرابشدن پشته میشد. این باگ وقتی فعال میشد که asynchronous preemption دقیقا بین دستورهای تنظیم پیاپی اشارهگر پشته در جریان garbage collection رخ میداد و در نتیجه پشته موقتا در وضعیت نامعتبر دیده میشد.
راهکار این است که بهجای تغییر پلهای اشارهگر پشته، ابتدا offset در یک رجیستر موقت ساخته میشود و سپس همان مقدار در قالب یک opcode غیرقابلتفکیک به RSP اضافه میگردد تا اشارهگر پشته همواره معتبر باشد. این اصلاح در نسخههای go1.23.12، go1.24.6 و go1.25.0 منتشر شده و کاربران Go روی arm64 باید برای جلوگیری از این کرشهای نادر اما جدی، ارتقا دهند.
#Go #arm64 #Compiler #RaceCondition #Cloudflare #GarbageCollection #Concurrency #BugFix
🟣لینک مقاله:
https://blog.cloudflare.com/how-we-found-a-bug-in-gos-arm64-compiler/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
The Cloudflare Blog
How we found a bug in Go's arm64 compiler
84 million requests a second means even rare bugs appear often. We'll reveal how we discovered a race condition in the Go arm64 compiler and got it fixed.
❤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
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.