داکر فقط نصف ماجراست.
بخش سختتر اونجاست که باید صدها کانتینر رو بین چند سرور اجرا، هماهنگ و پایدار نگهداری.
اینجاست که کوبرنتیز وارد عمل میشه.
کوبِرنِتیز چیه؟
کوبِرنِتیز یه سیستم متنباز (Open Source) برای مدیریت و هماهنگسازی کانتینرهاست.
بهش میگن Container Orchestrator چون مثل یه مغز مرکزی عمل میکنه و تصمیم میگیره
کِی، کجا و چطور کانتینرها اجرا بشن.
️ ساختار کلی کوبرنتیز
کوبرنتیز روی یه ساختار به اسم کلاستر (Cluster) کار میکنه.
کلاستر از چند سرور تشکیل شده:
(Control Plane): مغز سیستم که شاملAPI Server، Scheduler، Controller Manager و etcd میشه.
(Worker Nodes): جایی که کانتینرها واقعاً اجرا میشن (با استفاده از ابزاری مثل kubelet و Container Runtime مثل containerd یا CRI-O).
مفاهیم کلیدی در کوبرنتیز
پاد (Pod):
واحد اجرایی اصلی در کوبرنتیزه.
هر Pod معمولاً یه کانتینر داره، ولی ممکنه چندتا هم داشته باشه که با هم کار میکنن.
Kubernetes تضمین میکنه همیشه همون تعداد Podی که تعریف کردی در حال اجرا باشه (مثلاً سه نسخه از وبسرویس).
خودترمیمی (Self-Healing):
اگه یکی از Podها از کار بیفته، Controller Manager تشخیص میده و خودش اون Pod رو روی یه Node دیگه بالا میاره (بدون اینکه نیاز باشه دستی کاری بکنی).
مقیاسپذیری خودکار (Autoscaling):
وقتی ترافیک زیاد میشه، قابلیت Horizontal Pod Autoscaler (HPA) بر اساس معیارهایی مثل CPU یا Memory Usage تصمیم میگیره چندتا Pod جدید بسازه.
و وقتی ترافیک کاهش پیدا کنه، اونا رو حذف میکنه تا منابع هدر نرن.
سه جزء مهم کوبرنتیز
دیپلویمنت (Deployment): مشخص میکنه چند تا Pod باید اجرا بشن و آپدیتها چطور انجام بشن.
سرویس (Service): ترافیک رو بین Podها پخش میکنه تا همیشه در دسترس باشن.
اینگرس (Ingress): مسیر دسترسی کاربران بیرونی (مثل درخواستهای HTTP/HTTPS) رو به سرویسهای داخلی مدیریت میکنه.
چرا کوبرنتیز مهمه؟
چون اجرای برنامهها رو خودکار، پایدار و مقیاسپذیر میکنه.
به همین دلیل، امروز Kubernetes قلب دنیای DevOps و Cloud Native به حساب میاد.
از سیستمهای مایکروسرویسی گرفته تا پلتفرمهای یادگیری ماشین (ML) و اپهای بزرگ،
همه دارن روی K8s اجرا میشن.
<Monireh Savaedi/>
بخش سختتر اونجاست که باید صدها کانتینر رو بین چند سرور اجرا، هماهنگ و پایدار نگهداری.
اینجاست که کوبرنتیز وارد عمل میشه.
کوبِرنِتیز چیه؟
کوبِرنِتیز یه سیستم متنباز (Open Source) برای مدیریت و هماهنگسازی کانتینرهاست.
بهش میگن Container Orchestrator چون مثل یه مغز مرکزی عمل میکنه و تصمیم میگیره
کِی، کجا و چطور کانتینرها اجرا بشن.
️ ساختار کلی کوبرنتیز
کوبرنتیز روی یه ساختار به اسم کلاستر (Cluster) کار میکنه.
کلاستر از چند سرور تشکیل شده:
(Control Plane): مغز سیستم که شاملAPI Server، Scheduler، Controller Manager و etcd میشه.
(Worker Nodes): جایی که کانتینرها واقعاً اجرا میشن (با استفاده از ابزاری مثل kubelet و Container Runtime مثل containerd یا CRI-O).
مفاهیم کلیدی در کوبرنتیز
پاد (Pod):
واحد اجرایی اصلی در کوبرنتیزه.
هر Pod معمولاً یه کانتینر داره، ولی ممکنه چندتا هم داشته باشه که با هم کار میکنن.
Kubernetes تضمین میکنه همیشه همون تعداد Podی که تعریف کردی در حال اجرا باشه (مثلاً سه نسخه از وبسرویس).
خودترمیمی (Self-Healing):
اگه یکی از Podها از کار بیفته، Controller Manager تشخیص میده و خودش اون Pod رو روی یه Node دیگه بالا میاره (بدون اینکه نیاز باشه دستی کاری بکنی).
مقیاسپذیری خودکار (Autoscaling):
وقتی ترافیک زیاد میشه، قابلیت Horizontal Pod Autoscaler (HPA) بر اساس معیارهایی مثل CPU یا Memory Usage تصمیم میگیره چندتا Pod جدید بسازه.
و وقتی ترافیک کاهش پیدا کنه، اونا رو حذف میکنه تا منابع هدر نرن.
سه جزء مهم کوبرنتیز
دیپلویمنت (Deployment): مشخص میکنه چند تا Pod باید اجرا بشن و آپدیتها چطور انجام بشن.
سرویس (Service): ترافیک رو بین Podها پخش میکنه تا همیشه در دسترس باشن.
اینگرس (Ingress): مسیر دسترسی کاربران بیرونی (مثل درخواستهای HTTP/HTTPS) رو به سرویسهای داخلی مدیریت میکنه.
چرا کوبرنتیز مهمه؟
چون اجرای برنامهها رو خودکار، پایدار و مقیاسپذیر میکنه.
به همین دلیل، امروز Kubernetes قلب دنیای DevOps و Cloud Native به حساب میاد.
از سیستمهای مایکروسرویسی گرفته تا پلتفرمهای یادگیری ماشین (ML) و اپهای بزرگ،
همه دارن روی K8s اجرا میشن.
<Monireh Savaedi/>
👍2
🔵 عنوان مقاله
AI Infrastructure on Kubernetes
🟢 خلاصه مقاله:
** این گزارش از kube.today با اتکا به ۹۱۷ پاسخ نظرسنجی نشان میدهد تیمها در عمل چگونه بارهای کاری AI را روی Kubernetes مقیاس میدهند. نتیجه اصلی، شکاف میان ادعاهای فروشندگان و واقعیت بهرهگیری از GPU است: تأخیر در زمانبندی، تکهتکهشدن منابع، گلوگاههای داده و ضعف در مشاهدهپذیری باعث میشود GPUها کمتر از حد انتظار کار کنند. گزارش الگوهای عملی برای بهبود ارائه میکند؛ از right-sizing و bin-packing و زمانبندی آگاه از توپولوژی تا autoscaling مبتنی بر صف، اولویتدهی و preemption و رصد دقیق حافظه و I/O روی GPU. این رویکردها به تبدیل ظرفیت پرهزینه GPU به کار مفید کمک میکند و Kubernetes را برای بارهای کاری AI قابلاعتمادتر میسازد.
#Kubernetes #AI #GPU #MLOps #CloudNative #K8s #AIInfrastructure #Observability
🟣لینک مقاله:
https://ku.bz/B3nxKPYpV
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
AI Infrastructure on Kubernetes
🟢 خلاصه مقاله:
** این گزارش از kube.today با اتکا به ۹۱۷ پاسخ نظرسنجی نشان میدهد تیمها در عمل چگونه بارهای کاری AI را روی Kubernetes مقیاس میدهند. نتیجه اصلی، شکاف میان ادعاهای فروشندگان و واقعیت بهرهگیری از GPU است: تأخیر در زمانبندی، تکهتکهشدن منابع، گلوگاههای داده و ضعف در مشاهدهپذیری باعث میشود GPUها کمتر از حد انتظار کار کنند. گزارش الگوهای عملی برای بهبود ارائه میکند؛ از right-sizing و bin-packing و زمانبندی آگاه از توپولوژی تا autoscaling مبتنی بر صف، اولویتدهی و preemption و رصد دقیق حافظه و I/O روی GPU. این رویکردها به تبدیل ظرفیت پرهزینه GPU به کار مفید کمک میکند و Kubernetes را برای بارهای کاری AI قابلاعتمادتر میسازد.
#Kubernetes #AI #GPU #MLOps #CloudNative #K8s #AIInfrastructure #Observability
🟣لینک مقاله:
https://ku.bz/B3nxKPYpV
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Kube Today
AI Infrastructure on Kubernetes
Survey of 917 Kubernetes practitioners reveals 62% run clusters under 1,000 nodes, 54% struggle with GPU cost waste averaging $200K annually, and 51% prefer unified clusters with node separation over isolated infrastructure for AI workloads.
🔵 عنوان مقاله
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
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
Natkr
Wrangling Kubernetes contexts | natkr's ramblings
If you use Kubernetes on a regular basis, you've probably came across the dreaded context.
🔥1
🔵 عنوان مقاله
Akamai and Apiiro Expand Partnership on Application Security Posture Management (2 minute read)
🟢 خلاصه مقاله:
** همکاری Akamai و Apiiro گسترش یافته تا یک پلتفرم یکپارچه امنیت برنامه ارائه دهد که امنیت API، ASPM و محافظت در زمان اجرا را در سراسر چرخه عمر توسعه نرمافزار یکپارچه میکند. ترکیب هوش امنیتی Akamai با مدیریت وضعیت امنیتی Apiiro دید کامل، همبستگی ریسک مبتنی بر کانتکست و اولویتبندی مؤثر برای رفع اشکالات را فراهم میسازد. نتیجه این رویکرد، نوسازی امنیت برنامهها، سرعتبخشی به رفع مشکلات مهم و کاهش ریسک کسبوکار است.
#ApplicationSecurity #ASPM #APISecurity #RuntimeProtection #DevSecOps #Akamai #Apiiro #SDLC
🟣لینک مقاله:
https://www.devopsdigest.com/akamai-and-apiiro-expand-partnership-on-application-security-posture-management?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Akamai and Apiiro Expand Partnership on Application Security Posture Management (2 minute read)
🟢 خلاصه مقاله:
** همکاری Akamai و Apiiro گسترش یافته تا یک پلتفرم یکپارچه امنیت برنامه ارائه دهد که امنیت API، ASPM و محافظت در زمان اجرا را در سراسر چرخه عمر توسعه نرمافزار یکپارچه میکند. ترکیب هوش امنیتی Akamai با مدیریت وضعیت امنیتی Apiiro دید کامل، همبستگی ریسک مبتنی بر کانتکست و اولویتبندی مؤثر برای رفع اشکالات را فراهم میسازد. نتیجه این رویکرد، نوسازی امنیت برنامهها، سرعتبخشی به رفع مشکلات مهم و کاهش ریسک کسبوکار است.
#ApplicationSecurity #ASPM #APISecurity #RuntimeProtection #DevSecOps #Akamai #Apiiro #SDLC
🟣لینک مقاله:
https://www.devopsdigest.com/akamai-and-apiiro-expand-partnership-on-application-security-posture-management?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Devopsdigest
Akamai and Apiiro Expand Partnership on Application Security Posture Management | DEVOPSdigest
Akamai Technologies announced an expanded partnership with Apiiro, bringing together Akamai's application security platform and Apiiro's agentic application security posture management (ASPM) platform to help enterprises secure applications throughout the…
🔵 عنوان مقاله
Grafana Operator — Kubernetes Operator for Grafana
🟢 خلاصه مقاله:
Grafana Operator یک Operator در Kubernetes است که استقرار، پیکربندی و مدیریت Grafana را بهصورت اعلامی و مقیاسپذیر انجام میدهد. با تعریف داشبوردها، Data Sourceها و سیاستهای هشدار بهصورت کُد و ذخیره آنها در Git، تغییرات بهصورت خودکار و قابل ردیابی اعمال میشوند و با الگوی GitOps همراستا هستند. این ابزار وظایف چرخه عمر مانند نصب، ارتقا، بازیابی و اصلاح انحراف پیکربندی را خودکار میکند، از RBAC و Secrets برای کنترل دسترسی و مدیریت امن تنظیمات حساس استفاده میکند و با حلقه آشتی، پایداری و خودترمیمی را تضمین میکند. نتیجه، کاهش خطاهای دستی، سهولت ممیزی و یکپارچگی مدیریت Grafana در سناریوهای چندتیمی و چندکلاستری است.
#GrafanaOperator #Grafana #Kubernetes #K8s #Operators #DevOps #GitOps #Observability
🟣لینک مقاله:
https://ku.bz/j31586sqq
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Grafana Operator — Kubernetes Operator for Grafana
🟢 خلاصه مقاله:
Grafana Operator یک Operator در Kubernetes است که استقرار، پیکربندی و مدیریت Grafana را بهصورت اعلامی و مقیاسپذیر انجام میدهد. با تعریف داشبوردها، Data Sourceها و سیاستهای هشدار بهصورت کُد و ذخیره آنها در Git، تغییرات بهصورت خودکار و قابل ردیابی اعمال میشوند و با الگوی GitOps همراستا هستند. این ابزار وظایف چرخه عمر مانند نصب، ارتقا، بازیابی و اصلاح انحراف پیکربندی را خودکار میکند، از RBAC و Secrets برای کنترل دسترسی و مدیریت امن تنظیمات حساس استفاده میکند و با حلقه آشتی، پایداری و خودترمیمی را تضمین میکند. نتیجه، کاهش خطاهای دستی، سهولت ممیزی و یکپارچگی مدیریت Grafana در سناریوهای چندتیمی و چندکلاستری است.
#GrafanaOperator #Grafana #Kubernetes #K8s #Operators #DevOps #GitOps #Observability
🟣لینک مقاله:
https://ku.bz/j31586sqq
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - grafana/grafana-operator: An operator for Grafana that installs and manages Grafana instances, Dashboards and Datasources…
An operator for Grafana that installs and manages Grafana instances, Dashboards and Datasources through Kubernetes/OpenShift CRs - grafana/grafana-operator
Forwarded from Gopher Job
A Data Structure Algorithms Low Level Design and High Level Design collection of resources.
مجموعهای از منابع برای طراحی low level و high level توی مصاحبههای الگوریتمی و برنامهنویسی
#DSA #LLD #HLD #Algorithm #Interview #Leetcode #Question
https://github.com/arpit20adlakha/Data-Structure-Algorithms-LLD-HLD
مجموعهای از منابع برای طراحی low level و high level توی مصاحبههای الگوریتمی و برنامهنویسی
#DSA #LLD #HLD #Algorithm #Interview #Leetcode #Question
https://github.com/arpit20adlakha/Data-Structure-Algorithms-LLD-HLD
GitHub
GitHub - arpit20adlakha/Data-Structure-Algorithms-LLD-HLD: A Data Structure Algorithms Low Level Design and High Level Design collection…
A Data Structure Algorithms Low Level Design and High Level Design collection of resources. - arpit20adlakha/Data-Structure-Algorithms-LLD-HLD
👍1
یکی از جذاب ترین خبر برای باری کسانی که باگ بانتی کار میکنند یا علاقه دارند به این موضوع
مجموعهای از ایجنت های هوش مصنوعیبه اسم Strix که مثل یک هکر واقعی عمل میکنن! کد شما رو بهصورت پویا اجرا میکنن، حفرههای امنیتی رو پیدا میکنن، و حتی با نمونهی واقعی (Proof-of-Concept) اونها رو تأیید میکنه!
چرا مهمه؟
بزرگترین مشکل تست امنیتی سنتی اینه که با سرعت توسعهی نرمافزار هماهنگ نیست.
اما Strix مستقیماً در جریان کاری شما ادغام میشه:
اجرای خودکار در CI/CD برای کشف آسیبپذیریها قبل از انتشار!
دریافت PoC واقعی بهجای هشدارهای اشتباه تحلیلهای ایستا
تست کامل حملات تزریقی، کنترل دسترسی و باگهای منطقی
و بهترین بخش ماجرا:
نیازی نیست کارشناس امنیت باشید!
Strix با یک جعبهابزار کامل هک میاد از HTTP Proxy و مرورگر خودکار گرفته تا محیط اجرای Python برای توسعهی Exploit.
مثل اینه که یک تیم امنیتی حرفهای در سرعت خط CI/CD شما کار کنه!( البته فکر کنم بزرگنمایی شده ولی خب قطعا ارزش تست داره )!
یک نکته ی مهم دیگه هم اینه که میتونید اونو بصورت داکر و لوکال ران کنید !
آموزش نصب و توضیحات اولیه به فارسی:
https://github.com/xPOURY4/strix/blob/main/README_FA.md
نسخه اصلی:
https://github.com/usestrix/strix
@ | <POURYA/>
مجموعهای از ایجنت های هوش مصنوعیبه اسم Strix که مثل یک هکر واقعی عمل میکنن! کد شما رو بهصورت پویا اجرا میکنن، حفرههای امنیتی رو پیدا میکنن، و حتی با نمونهی واقعی (Proof-of-Concept) اونها رو تأیید میکنه!
چرا مهمه؟
بزرگترین مشکل تست امنیتی سنتی اینه که با سرعت توسعهی نرمافزار هماهنگ نیست.
اما Strix مستقیماً در جریان کاری شما ادغام میشه:
اجرای خودکار در CI/CD برای کشف آسیبپذیریها قبل از انتشار!
دریافت PoC واقعی بهجای هشدارهای اشتباه تحلیلهای ایستا
تست کامل حملات تزریقی، کنترل دسترسی و باگهای منطقی
و بهترین بخش ماجرا:
نیازی نیست کارشناس امنیت باشید!
Strix با یک جعبهابزار کامل هک میاد از HTTP Proxy و مرورگر خودکار گرفته تا محیط اجرای Python برای توسعهی Exploit.
مثل اینه که یک تیم امنیتی حرفهای در سرعت خط CI/CD شما کار کنه!( البته فکر کنم بزرگنمایی شده ولی خب قطعا ارزش تست داره )!
یک نکته ی مهم دیگه هم اینه که میتونید اونو بصورت داکر و لوکال ران کنید !
آموزش نصب و توضیحات اولیه به فارسی:
https://github.com/xPOURY4/strix/blob/main/README_FA.md
نسخه اصلی:
https://github.com/usestrix/strix
@ | <POURYA/>
GitHub
strix/README_FA.md at main · xPOURY4/strix
✨ Open-source AI hackers for your apps 👨🏻💻. Contribute to xPOURY4/strix development by creating an account on GitHub.
👍1
🔵 عنوان مقاله
Safeguarding OKE: Passwordless kubectl Access with OCI Instance Principals
🟢 خلاصه مقاله:
این آموزش نشان میدهد چگونه با تکیه بر OCI Instance Principals و بدون نیاز به رمز یا کلیدهای بلندمدت، دسترسی kubectl به یک کلاستر OKE را فعال کنیم. ایده اصلی این است که بارهای کاری روی Compute بهعنوان پرینسیپل خودِ ماشین احراز هویت شوند و با استفاده از توکنهای کوتاهعمر به API کلاستر دسترسی بگیرند. برای این کار، ابتدا ماشینها را در یک dynamic group قرار میدهیم، سپس با IAM policies محدود و دقیق، فقط کمینه مجوزهای لازم برای کلاستر (مثلاً use روی cluster) را در سطح یک compartment یا حتی یک کلاستر خاص میدهیم. روی همان ماشین، OCI CLI کنار kubectl نصب میشود و kubeconfig طوری پیکربندی میگردد که از OCI CLI exec plugin استفاده کند؛ در نتیجه هر بار kubectl اجرا میشود، توکن موقتی را از OCI با مکانیزم Instance Principals میگیرد و نیازی به ذخیره رمز/کلید نیست. در نهایت با تنظیم RBAC داخل کلاستر، دسترسیها دقیقاً به نقشهایی که تعریف کردهایم محدود میشود. این الگو امنیت را افزایش میدهد، از افشای اعتبارنامهها جلوگیری میکند، گردش توکنها را خودکار میسازد و برای سناریوهای CI/CD و زیرساختهای موقتی در OCI بسیار مناسب است.
#Kubernetes #OKE #OracleCloud #OCI #IAM #kubectl #DevOps #CloudSecurity
🟣لینک مقاله:
https://ku.bz/ZpCQLpM4V
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Safeguarding OKE: Passwordless kubectl Access with OCI Instance Principals
🟢 خلاصه مقاله:
این آموزش نشان میدهد چگونه با تکیه بر OCI Instance Principals و بدون نیاز به رمز یا کلیدهای بلندمدت، دسترسی kubectl به یک کلاستر OKE را فعال کنیم. ایده اصلی این است که بارهای کاری روی Compute بهعنوان پرینسیپل خودِ ماشین احراز هویت شوند و با استفاده از توکنهای کوتاهعمر به API کلاستر دسترسی بگیرند. برای این کار، ابتدا ماشینها را در یک dynamic group قرار میدهیم، سپس با IAM policies محدود و دقیق، فقط کمینه مجوزهای لازم برای کلاستر (مثلاً use روی cluster) را در سطح یک compartment یا حتی یک کلاستر خاص میدهیم. روی همان ماشین، OCI CLI کنار kubectl نصب میشود و kubeconfig طوری پیکربندی میگردد که از OCI CLI exec plugin استفاده کند؛ در نتیجه هر بار kubectl اجرا میشود، توکن موقتی را از OCI با مکانیزم Instance Principals میگیرد و نیازی به ذخیره رمز/کلید نیست. در نهایت با تنظیم RBAC داخل کلاستر، دسترسیها دقیقاً به نقشهایی که تعریف کردهایم محدود میشود. این الگو امنیت را افزایش میدهد، از افشای اعتبارنامهها جلوگیری میکند، گردش توکنها را خودکار میسازد و برای سناریوهای CI/CD و زیرساختهای موقتی در OCI بسیار مناسب است.
#Kubernetes #OKE #OracleCloud #OCI #IAM #kubectl #DevOps #CloudSecurity
🟣لینک مقاله:
https://ku.bz/ZpCQLpM4V
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
Safeguarding OKE: Passwordless kubectl Access with OCI Instance Principals
Using OCI Instance Principals to enable passwordless kubectl access to OKE significantly improves CI/CD pipeline security
🔵 عنوان مقاله
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
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
k8z.dev
K8Z | The Kubernetes Manager
The Kubernetes Manager for iOS and MacOS.
🔵 عنوان مقاله
Cluster Template: Talos + Flux: Kubernetes deployment
🟢 خلاصه مقاله:
این مقاله یک Cluster Template برای استقرار Kubernetes معرفی میکند که با ترکیب Talos و Flux روند راهاندازی و بهروزرسانی را ساده و تکرارپذیر میکند. Talos بهعنوان سیستمعامل مینیمال و ایمنِ ویژهی Kubernetes بهکار میرود و پیکربندیها بهصورت کد نگهداری میشوند. Flux با رویکرد GitOps مخزن Git را رصد کرده و وضعیت کلاستر را بهصورت خودکار با مانیفستهای اعلامی همگام میکند. جریان کاری شامل راهاندازی نودها با Talos، اتصال Flux به مخزن، و اعمال خودکار تغییرات با هر Commit است؛ بازگشت به عقب نیز صرفاً با Revert یک Commit انجام میشود. نتیجه، استقرار یکنواخت، کاهش Drift، و مدیریت سادهتر روز دوم در مقیاسهای مختلف است.
#Kubernetes #Talos #FluxCD #GitOps #ClusterTemplate #DevOps #CloudNative
🟣لینک مقاله:
https://ku.bz/8VP9H3B5B
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Cluster Template: Talos + Flux: Kubernetes deployment
🟢 خلاصه مقاله:
این مقاله یک Cluster Template برای استقرار Kubernetes معرفی میکند که با ترکیب Talos و Flux روند راهاندازی و بهروزرسانی را ساده و تکرارپذیر میکند. Talos بهعنوان سیستمعامل مینیمال و ایمنِ ویژهی Kubernetes بهکار میرود و پیکربندیها بهصورت کد نگهداری میشوند. Flux با رویکرد GitOps مخزن Git را رصد کرده و وضعیت کلاستر را بهصورت خودکار با مانیفستهای اعلامی همگام میکند. جریان کاری شامل راهاندازی نودها با Talos، اتصال Flux به مخزن، و اعمال خودکار تغییرات با هر Commit است؛ بازگشت به عقب نیز صرفاً با Revert یک Commit انجام میشود. نتیجه، استقرار یکنواخت، کاهش Drift، و مدیریت سادهتر روز دوم در مقیاسهای مختلف است.
#Kubernetes #Talos #FluxCD #GitOps #ClusterTemplate #DevOps #CloudNative
🟣لینک مقاله:
https://ku.bz/8VP9H3B5B
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - onedr0p/cluster-template: A template for deploying a Talos Kubernetes cluster including Flux for GitOps
A template for deploying a Talos Kubernetes cluster including Flux for GitOps - onedr0p/cluster-template
🔵 عنوان مقاله
Terraform & Ansible: Unifying infrastructure provisioning and configuration management (3 minute read)
🟢 خلاصه مقاله:
این یکپارچگی جدید با معرفی Terraform actions، همکاری Terraform و Ansible را عمیقتر میکند و یک مسیر یکپارچه از تامین زیرساخت تا پیکربندی و عملیات Day 2+ فراهم میکند. Terraform میتواند مستقیماً گردشهای کاری Ansible را پس از ایجاد زیرساخت اجرا کند و با اشتراک موجودی یکسان (inventory) و خروجیهای Terraform، از ناسازگاری و اسکریپتهای سفارشی جلوگیری کند. نتیجه، خودکارسازی روانتر و کاهش اصطکاک عملیاتی بهویژه در محیطهای هیبرید و چندابری است؛ ضمن اینکه کارهای مداوم مانند نصب وصلهها، اعمال انطباق، استقرار برنامه و رفع drift نیز بهصورت منظم و قابل تکرار انجام میشوند.
#Terraform #Ansible #InfrastructureAsCode #DevOps #Automation #MultiCloud #ConfigurationManagement #Day2Operations
🟣لینک مقاله:
https://www.hashicorp.com/en/blog/terraform-ansible-unifying-infrastructure-provisioning-configuration-management?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Terraform & Ansible: Unifying infrastructure provisioning and configuration management (3 minute read)
🟢 خلاصه مقاله:
این یکپارچگی جدید با معرفی Terraform actions، همکاری Terraform و Ansible را عمیقتر میکند و یک مسیر یکپارچه از تامین زیرساخت تا پیکربندی و عملیات Day 2+ فراهم میکند. Terraform میتواند مستقیماً گردشهای کاری Ansible را پس از ایجاد زیرساخت اجرا کند و با اشتراک موجودی یکسان (inventory) و خروجیهای Terraform، از ناسازگاری و اسکریپتهای سفارشی جلوگیری کند. نتیجه، خودکارسازی روانتر و کاهش اصطکاک عملیاتی بهویژه در محیطهای هیبرید و چندابری است؛ ضمن اینکه کارهای مداوم مانند نصب وصلهها، اعمال انطباق، استقرار برنامه و رفع drift نیز بهصورت منظم و قابل تکرار انجام میشوند.
#Terraform #Ansible #InfrastructureAsCode #DevOps #Automation #MultiCloud #ConfigurationManagement #Day2Operations
🟣لینک مقاله:
https://www.hashicorp.com/en/blog/terraform-ansible-unifying-infrastructure-provisioning-configuration-management?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
🔵 عنوان مقاله
Why keep your index set lean (8 minute read)
🟢 خلاصه مقاله:
** ایندکسهای اضافی در Postgres هزینه پنهان اما جدی دارند: نوشتنها را کند میکنند چون هر INSERT/UPDATE باید همه آنها را بهروزرسانی کند، زمان برنامهریزی را بالا میبرند و بهخاطر رقابت برای cache میتوانند خواندنها را هم کند کنند. علاوه بر اتلاف فضای دیسک، کار autovacuum بیشتر میشود و WAL بیشتری تولید میشود که هزینههای نگهداری و پشتیبانگیری را بالا میبرد. راهکار این است که ایندکسهای بلااستفاده یا تکراری حذف و ایندکسهای متورم بازسازی شوند، و با پایش منظم، مجموعهای کمحجم و کارآمد از ایندکسها حفظ شود.
#Postgres #Indexing #DatabasePerformance #WAL #Autovacuum #SQL #DBA #DevOps
🟣لینک مقاله:
https://postgres.ai/blog/20251110-postgres-marathon-2-013-why-keep-your-index-set-lean?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Why keep your index set lean (8 minute read)
🟢 خلاصه مقاله:
** ایندکسهای اضافی در Postgres هزینه پنهان اما جدی دارند: نوشتنها را کند میکنند چون هر INSERT/UPDATE باید همه آنها را بهروزرسانی کند، زمان برنامهریزی را بالا میبرند و بهخاطر رقابت برای cache میتوانند خواندنها را هم کند کنند. علاوه بر اتلاف فضای دیسک، کار autovacuum بیشتر میشود و WAL بیشتری تولید میشود که هزینههای نگهداری و پشتیبانگیری را بالا میبرد. راهکار این است که ایندکسهای بلااستفاده یا تکراری حذف و ایندکسهای متورم بازسازی شوند، و با پایش منظم، مجموعهای کمحجم و کارآمد از ایندکسها حفظ شود.
#Postgres #Indexing #DatabasePerformance #WAL #Autovacuum #SQL #DBA #DevOps
🟣لینک مقاله:
https://postgres.ai/blog/20251110-postgres-marathon-2-013-why-keep-your-index-set-lean?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
PostgresAI
#PostgresMarathon 2-013: Why keep your index set lean | PostgresAI
Your API is slowing down. You check your database and find 42 indexes on your users table. Which ones can you safely drop? How much performance are they costing you? Let's look at what actually happens in Postgres when you have too many indexes.
Forwarded from Linux Labdon
کاهش هزینه سیستمهای هوش مصنوعی با Semantic Caching
با رشد مدلهای زبانی بزرگ و پیشرفته، هزینه و زمان پاسخدهی هم به شدت افزایش پیدا کرده. مدلهایی مثل GPT-5 یا Claude برای کارهای پیچیده فوقالعادهاند، ولی استفاده از اونها هم پرهزینه و هم کند محسوب میشه. از طرف دیگه، AI Agentها واقعاً «توکنخور» هستن؛ یعنی برای انجام یک کار معمولاً چندین مرحله طی میکنن: تحقیق، برنامهریزی، عمل و بازتاب و تکرار. همین باعث میشه چندین بار با مدل تماس بگیرن و در نتیجه هزینه و تأخیر افزایش پیدا کنه و متنهای طولانیتر تولید بشه. برای مثال، یه بنچمارک اخیر از TheAgentCompany در ۲۰۲۵ نشون داده اجرای کامل یک Agent گاهی تا ۶.۸ دلار هزینه داره.
یکی از مشکلات اصلی در دنیای واقعی، تکراری بودن سوالهاست، مخصوصاً توی پشتیبانی مشتری. کاربران دائماً سوالهای مشابهی میپرسن: مثل «چطور پولم رو پس بگیرم؟» یا «شرایط بازگشت وجه چیه؟» و Agent مجبور میشه هر بار پاسخ رو از صفر تولید کنه. نتیجهش افزایش هزینه، طولانی شدن زمان پاسخ و فشار بیشتر روی سیستمهای RAG و زیرساختهاست.
در نگاه اول، ممکنه فکر کنیم کش کلاسیک کفایت میکنه. ایدهی کش ساده اینه که اگر یک سوال قبلاً پاسخ داده شده، دوباره سراغ مدل نریم. ولی مشکل اینجاست که کش سنتی دنبال Exact Match یا تطابق دقیق متنه. سوالهایی که از نظر معنی یکی هستن ولی عبارتهاشون فرق میکنه، مثل: «میخوام پولم رو پس بگیرم»، «چطور میتونم درخواست بازگشت وجه بدم؟» و «سیاست بازگشت پولتون چیه؟»، همه Cache Miss میشن و کش عملاً استفاده نمیشه.
اینجاست که Semantic Caching وارد میشه. به جای تطابق کلمهبهکلمه، کش به معنی و مفهوم جمله نگاه میکنه. مزیت اصلیش اینه که Recall و Hit Rate بالاتره و احتمال استفاده از کش و صرفهجویی خیلی بیشتر میشه. البته چالشش هم اینه که گاهی ممکنه جواب بیربط بده یا همون «False Positive» رخ بده.
روش کار Semantic Caching ساده است ولی هوشمندانه: ابتدا سوال کاربر به Embedding یا بردار عددی تبدیل میشه. بعد با بردارهای موجود در کش با Semantic Search مقایسه میشه. اگر فاصله معنایی کم باشه، پاسخ از کش برگردونده میشه؛ در غیر این صورت به RAG یا LLM میریم. در نهایت سوال و پاسخ جدید هم ذخیره میشه تا دفعه بعدی قابل استفاده باشه.
پیادهسازی Semantic Caching با چالشهایی همراهه؛ مثل دقت (Accuracy) که آیا کش جواب درست میده، کارایی (Performance) و میزان Cache Hit، سرعت سرویسدهی، آپدیتپذیری کش و اینکه آیا میتونیم کش رو گرم، تازهسازی یا پاکسازی کنیم. همچنین مشاهدهپذیری (Observability) مهمه تا بتونیم hit rate، latency، صرفهجویی هزینه و کیفیت کش رو بسنجیم.
معیارهای اصلی سنجش کش شامل Cache Hit Rate هست که نشون میده چند درصد درخواستها از کش پاسخ داده میشن و Precision/Recall/F1 Score که کیفیت و دقت پاسخها رو مشخص میکنه. برای بهبود دقت و کارایی کش هم میتونیم Threshold فاصله رو تنظیم کنیم، Reranker اضافه کنیم مثل Cross-encoder یا LLM-as-a-judge، از Fuzzy Matching برای تایپوها استفاده کنیم و فیلترهای اضافی مثل تشخیص پرسشهای زمانمحور (Temporal) یا تشخیص کد (Python، Java و…) اعمال کنیم تا سوالات اشتباه وارد کش نشن.
یه مثال واقعی از این تکنولوژی پروژه waLLMartCache در Walmart هست. اونها با نوآوریهایی مثل Load Balancer برای توزیع کش روی چند Node و Dual-tiered Storage که L1 = Vector DB و L2 = In-memory Cache مثل Redis هست، هم سرعت و هم دقت رو بالا بردن. Multi-tenancy هم باعث شده چند تیم یا اپلیکیشن از یک زیرساخت مشترک استفاده کنن. Decision Engine هم شامل تشخیص کد و زمانه و اگر سوال مناسب کش نباشه مستقیماً به LLM یا RAG میره. نتیجهش رسیدن به دقت نزدیک ۹۰٪ بوده.
<Reza Jafari/>
👉 https://t.iss.one/addlist/AJ7rh2IzIh02NTI0
با رشد مدلهای زبانی بزرگ و پیشرفته، هزینه و زمان پاسخدهی هم به شدت افزایش پیدا کرده. مدلهایی مثل GPT-5 یا Claude برای کارهای پیچیده فوقالعادهاند، ولی استفاده از اونها هم پرهزینه و هم کند محسوب میشه. از طرف دیگه، AI Agentها واقعاً «توکنخور» هستن؛ یعنی برای انجام یک کار معمولاً چندین مرحله طی میکنن: تحقیق، برنامهریزی، عمل و بازتاب و تکرار. همین باعث میشه چندین بار با مدل تماس بگیرن و در نتیجه هزینه و تأخیر افزایش پیدا کنه و متنهای طولانیتر تولید بشه. برای مثال، یه بنچمارک اخیر از TheAgentCompany در ۲۰۲۵ نشون داده اجرای کامل یک Agent گاهی تا ۶.۸ دلار هزینه داره.
یکی از مشکلات اصلی در دنیای واقعی، تکراری بودن سوالهاست، مخصوصاً توی پشتیبانی مشتری. کاربران دائماً سوالهای مشابهی میپرسن: مثل «چطور پولم رو پس بگیرم؟» یا «شرایط بازگشت وجه چیه؟» و Agent مجبور میشه هر بار پاسخ رو از صفر تولید کنه. نتیجهش افزایش هزینه، طولانی شدن زمان پاسخ و فشار بیشتر روی سیستمهای RAG و زیرساختهاست.
در نگاه اول، ممکنه فکر کنیم کش کلاسیک کفایت میکنه. ایدهی کش ساده اینه که اگر یک سوال قبلاً پاسخ داده شده، دوباره سراغ مدل نریم. ولی مشکل اینجاست که کش سنتی دنبال Exact Match یا تطابق دقیق متنه. سوالهایی که از نظر معنی یکی هستن ولی عبارتهاشون فرق میکنه، مثل: «میخوام پولم رو پس بگیرم»، «چطور میتونم درخواست بازگشت وجه بدم؟» و «سیاست بازگشت پولتون چیه؟»، همه Cache Miss میشن و کش عملاً استفاده نمیشه.
اینجاست که Semantic Caching وارد میشه. به جای تطابق کلمهبهکلمه، کش به معنی و مفهوم جمله نگاه میکنه. مزیت اصلیش اینه که Recall و Hit Rate بالاتره و احتمال استفاده از کش و صرفهجویی خیلی بیشتر میشه. البته چالشش هم اینه که گاهی ممکنه جواب بیربط بده یا همون «False Positive» رخ بده.
روش کار Semantic Caching ساده است ولی هوشمندانه: ابتدا سوال کاربر به Embedding یا بردار عددی تبدیل میشه. بعد با بردارهای موجود در کش با Semantic Search مقایسه میشه. اگر فاصله معنایی کم باشه، پاسخ از کش برگردونده میشه؛ در غیر این صورت به RAG یا LLM میریم. در نهایت سوال و پاسخ جدید هم ذخیره میشه تا دفعه بعدی قابل استفاده باشه.
پیادهسازی Semantic Caching با چالشهایی همراهه؛ مثل دقت (Accuracy) که آیا کش جواب درست میده، کارایی (Performance) و میزان Cache Hit، سرعت سرویسدهی، آپدیتپذیری کش و اینکه آیا میتونیم کش رو گرم، تازهسازی یا پاکسازی کنیم. همچنین مشاهدهپذیری (Observability) مهمه تا بتونیم hit rate، latency، صرفهجویی هزینه و کیفیت کش رو بسنجیم.
معیارهای اصلی سنجش کش شامل Cache Hit Rate هست که نشون میده چند درصد درخواستها از کش پاسخ داده میشن و Precision/Recall/F1 Score که کیفیت و دقت پاسخها رو مشخص میکنه. برای بهبود دقت و کارایی کش هم میتونیم Threshold فاصله رو تنظیم کنیم، Reranker اضافه کنیم مثل Cross-encoder یا LLM-as-a-judge، از Fuzzy Matching برای تایپوها استفاده کنیم و فیلترهای اضافی مثل تشخیص پرسشهای زمانمحور (Temporal) یا تشخیص کد (Python، Java و…) اعمال کنیم تا سوالات اشتباه وارد کش نشن.
یه مثال واقعی از این تکنولوژی پروژه waLLMartCache در Walmart هست. اونها با نوآوریهایی مثل Load Balancer برای توزیع کش روی چند Node و Dual-tiered Storage که L1 = Vector DB و L2 = In-memory Cache مثل Redis هست، هم سرعت و هم دقت رو بالا بردن. Multi-tenancy هم باعث شده چند تیم یا اپلیکیشن از یک زیرساخت مشترک استفاده کنن. Decision Engine هم شامل تشخیص کد و زمانه و اگر سوال مناسب کش نباشه مستقیماً به LLM یا RAG میره. نتیجهش رسیدن به دقت نزدیک ۹۰٪ بوده.
<Reza Jafari/>
👉 https://t.iss.one/addlist/AJ7rh2IzIh02NTI0
❤2
🔵 عنوان مقاله
Kubernetes Headaches: Unsticking StatefulSets from EBS ReadWriteMany Drama
🟢 خلاصه مقاله:
با اجرای سرویسهای دارای حالت روی Kubernetes، خیلی زود محدودیت اصلی نمایان میشود: EBS در AWS برای ReadWriteMany طراحی نشده و همین باعث گیرکردن StatefulSetها، Pending شدن پادها و مشکل در اتصال ولومها بین نودها میشود. راهحلها سه مسیر اصلی دارند: یا ماهیت ReadWriteOnce را بپذیرید و هر replica را در همان AZ و کنار EBS خودش نگه دارید (با تنظیمات topology و ReadWriteOncePod)، یا به یک RWX واقعی مهاجرت کنید (EFS با EFS CSI و Access Pointها، یا سیستمهای توزیعشده مانند Rook Ceph/Longhorn/OpenEBS)، یا معماری برنامه را طوری بازطراحی کنید که نیاز به RWX از بین برود (sharding، استفاده از S3 برای blobها، و stream کردن WAL/backup).
برای مهاجرت امن: از VolumeSnapshot یا Jobهای کپی داده (rsync) بین PVCهای قدیم (EBS) و جدید (EFS/RWX) استفاده کنید، StatefulSet را بهصورت ترتیبی scale down کنید، persistentVolumeClaimRetentionPolicy را برای حفظ PVCها تنظیم کنید، StorageClass را در volumeClaimTemplates عوض کنید و سپس بهتدریج scale up کنید. رعایت PDB، readiness، fsGroup، و IRSA برای درایورهای CSI حیاتی است و باید قبل از سوییچ نهایی، کارایی و برگشتپذیری را با fio و پشتیبانگیری (Velero/اسنپشاتها) تست کرد. بهطور خلاصه: یا با EBS و تکنویسنده کنار بیایید، یا به EFS/ذخیرهسازی توزیعشده بروید؛ تلاش برای RWX با EBS معمولاً فقط مشکل را عقب میاندازد.
#Kubernetes #StatefulSet #EBS #EFS #RWX #CSI #AWS #CloudStorage
🟣لینک مقاله:
https://ku.bz/Zg29dRHx4
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Kubernetes Headaches: Unsticking StatefulSets from EBS ReadWriteMany Drama
🟢 خلاصه مقاله:
با اجرای سرویسهای دارای حالت روی Kubernetes، خیلی زود محدودیت اصلی نمایان میشود: EBS در AWS برای ReadWriteMany طراحی نشده و همین باعث گیرکردن StatefulSetها، Pending شدن پادها و مشکل در اتصال ولومها بین نودها میشود. راهحلها سه مسیر اصلی دارند: یا ماهیت ReadWriteOnce را بپذیرید و هر replica را در همان AZ و کنار EBS خودش نگه دارید (با تنظیمات topology و ReadWriteOncePod)، یا به یک RWX واقعی مهاجرت کنید (EFS با EFS CSI و Access Pointها، یا سیستمهای توزیعشده مانند Rook Ceph/Longhorn/OpenEBS)، یا معماری برنامه را طوری بازطراحی کنید که نیاز به RWX از بین برود (sharding، استفاده از S3 برای blobها، و stream کردن WAL/backup).
برای مهاجرت امن: از VolumeSnapshot یا Jobهای کپی داده (rsync) بین PVCهای قدیم (EBS) و جدید (EFS/RWX) استفاده کنید، StatefulSet را بهصورت ترتیبی scale down کنید، persistentVolumeClaimRetentionPolicy را برای حفظ PVCها تنظیم کنید، StorageClass را در volumeClaimTemplates عوض کنید و سپس بهتدریج scale up کنید. رعایت PDB، readiness، fsGroup، و IRSA برای درایورهای CSI حیاتی است و باید قبل از سوییچ نهایی، کارایی و برگشتپذیری را با fio و پشتیبانگیری (Velero/اسنپشاتها) تست کرد. بهطور خلاصه: یا با EBS و تکنویسنده کنار بیایید، یا به EFS/ذخیرهسازی توزیعشده بروید؛ تلاش برای RWX با EBS معمولاً فقط مشکل را عقب میاندازد.
#Kubernetes #StatefulSet #EBS #EFS #RWX #CSI #AWS #CloudStorage
🟣لینک مقاله:
https://ku.bz/Zg29dRHx4
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
Kubernetes Headaches: Unsticking StatefulSets from EBS ReadWriteMany Drama
Note: This post assumes some familiarity with AWS EKS, Kubernetes StatefulSets, and EBS volumes.
🔵 عنوان مقاله
topolvm: capacity-aware CSI
🟢 خلاصه مقاله:
TopoLVM یک درایور CSI برای Kubernetes است که با استفاده از LVM روی Linux، دیسکهای محلی هر نود را به PersistentVolumeهای پویا و قابل اطمینان تبدیل میکند. ویژگی اصلی آن «آگاه از ظرفیت» بودن است؛ یعنی ظرفیت آزاد واقعی هر نود را میشناسد و آن را به Scheduler اعلام میکند تا Podهایی که PVC دارند فقط روی نودهایی زمانبندی شوند که واقعا توان تامین آن حجم را دارند. این رویکرد از حلقههای شکست در زمانبندی و خطاهای دیرهنگام Provisioning جلوگیری میکند.
TopoLVM معمولا شامل یک Controller، یک Node Plugin و مولفه سبک lvmd روی هر نود است. StorageClassها میتوانند به Volume Groupها یا Device Classهای متفاوت نگاشت شوند تا لایههای کارایی مختلف ارائه شود. پشتیبانی از حجمهای فایلسیستمی و Block، توسعه حجم (در صورت پشتیبانی Kubernetes)، و تنظیمات Thin/Thick provisioning در LVM فراهم است. در کلاسترهایی که Storage Capacity Tracking را پشتیبانی میکنند، اطلاعات ظرفیت از طریق اشیای StorageCapacity در دسترس Scheduler قرار میگیرد.
این راهحل برای سناریوهای ذخیرهسازی محلی با کارایی بالا و نیاز به Locality مناسب است؛ مانند محیطهای Bare Metal و Edge. از آنجا که Volumeها محلیاند، تابآوری معمولا از طریق تکرار در سطح اپلیکیشن تامین میشود. در مقایسه با درایورهای ذخیرهسازی شبکهای، TopoLVM بر ظرفیت قابل پیشبینی روی نود، Provisioning سریع و کنترل مستقیم عملیاتی با LVM تمرکز دارد.
#Kubernetes #CSI #TopoLVM #LVM #Storage #PersistentVolume #CapacityAware #DevOps
🟣لینک مقاله:
https://ku.bz/nW4zYDCHT
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
topolvm: capacity-aware CSI
🟢 خلاصه مقاله:
TopoLVM یک درایور CSI برای Kubernetes است که با استفاده از LVM روی Linux، دیسکهای محلی هر نود را به PersistentVolumeهای پویا و قابل اطمینان تبدیل میکند. ویژگی اصلی آن «آگاه از ظرفیت» بودن است؛ یعنی ظرفیت آزاد واقعی هر نود را میشناسد و آن را به Scheduler اعلام میکند تا Podهایی که PVC دارند فقط روی نودهایی زمانبندی شوند که واقعا توان تامین آن حجم را دارند. این رویکرد از حلقههای شکست در زمانبندی و خطاهای دیرهنگام Provisioning جلوگیری میکند.
TopoLVM معمولا شامل یک Controller، یک Node Plugin و مولفه سبک lvmd روی هر نود است. StorageClassها میتوانند به Volume Groupها یا Device Classهای متفاوت نگاشت شوند تا لایههای کارایی مختلف ارائه شود. پشتیبانی از حجمهای فایلسیستمی و Block، توسعه حجم (در صورت پشتیبانی Kubernetes)، و تنظیمات Thin/Thick provisioning در LVM فراهم است. در کلاسترهایی که Storage Capacity Tracking را پشتیبانی میکنند، اطلاعات ظرفیت از طریق اشیای StorageCapacity در دسترس Scheduler قرار میگیرد.
این راهحل برای سناریوهای ذخیرهسازی محلی با کارایی بالا و نیاز به Locality مناسب است؛ مانند محیطهای Bare Metal و Edge. از آنجا که Volumeها محلیاند، تابآوری معمولا از طریق تکرار در سطح اپلیکیشن تامین میشود. در مقایسه با درایورهای ذخیرهسازی شبکهای، TopoLVM بر ظرفیت قابل پیشبینی روی نود، Provisioning سریع و کنترل مستقیم عملیاتی با LVM تمرکز دارد.
#Kubernetes #CSI #TopoLVM #LVM #Storage #PersistentVolume #CapacityAware #DevOps
🟣لینک مقاله:
https://ku.bz/nW4zYDCHT
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - topolvm/topolvm: Capacity-aware CSI plugin for Kubernetes
Capacity-aware CSI plugin for Kubernetes. Contribute to topolvm/topolvm development by creating an account on GitHub.
🔵 عنوان مقاله
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
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
Cloud Native Now
Most Cloud-Native Roles are Software Engineers
Cloud-native hiring: 47% of roles are Software Engineers, while SRE positions have dropped ~30% since 2023. Lead-level jobs outnumber junior ones. Skills are the differentiator.cloudnativenow.com/you-are-more-likely-to-land-a-lead-level-cloud-native-role…
❤1
🔵 عنوان مقاله
Inside Duolingo's FinOps Journey: Turning Cloud Spend into Engineering Insight (3 minute read)
🟢 خلاصه مقاله:
خلاصهای از مسیر FinOps در Duolingo نشان میدهد که این شرکت با وارد کردن آگاهی مالی به جریان کاری مهندسی، هزینههای ابری را به بینشی عملی برای توسعهدهندگان تبدیل کرده است. با نمایش بلادرنگِ اثر مالی تغییرات در کنار متریکهای عملیاتی، استفاده از تگگذاری و مالکیت منابع، هشدارهای خودکار و گاردریلهای بودجه، و حتی مقایسه «cost diff» در CI/CD، تیمها میتوانند پیش از استقرار، پیامدهای هزینهای انتخابهای معماری و کد را بسنجند. این رویکرد فرهنگ سازمان را به سمتی برده که «کارایی» همسطح «عملکرد» و «پایداری» بهعنوان یک معیار اصلی کیفیت دیده میشود و تصمیمگیریها—از برنامهریزی ظرفیت تا آزمایش و بازطراحی—با زبانی مشترک میان مهندسی و مالی انجام میگیرد. نتیجه، کاهش اتلاف، پیشبینیپذیری بهتر و سیستمهایی سریع، پایدار و آگاه از هزینه است.
#FinOps #CloudCost #Duolingo #CostOptimization #DevOps #EngineeringExcellence #CloudOps #SoftwareQuality
🟣لینک مقاله:
https://www.infoq.com/news/2025/10/duolingo-finops-engineering/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Inside Duolingo's FinOps Journey: Turning Cloud Spend into Engineering Insight (3 minute read)
🟢 خلاصه مقاله:
خلاصهای از مسیر FinOps در Duolingo نشان میدهد که این شرکت با وارد کردن آگاهی مالی به جریان کاری مهندسی، هزینههای ابری را به بینشی عملی برای توسعهدهندگان تبدیل کرده است. با نمایش بلادرنگِ اثر مالی تغییرات در کنار متریکهای عملیاتی، استفاده از تگگذاری و مالکیت منابع، هشدارهای خودکار و گاردریلهای بودجه، و حتی مقایسه «cost diff» در CI/CD، تیمها میتوانند پیش از استقرار، پیامدهای هزینهای انتخابهای معماری و کد را بسنجند. این رویکرد فرهنگ سازمان را به سمتی برده که «کارایی» همسطح «عملکرد» و «پایداری» بهعنوان یک معیار اصلی کیفیت دیده میشود و تصمیمگیریها—از برنامهریزی ظرفیت تا آزمایش و بازطراحی—با زبانی مشترک میان مهندسی و مالی انجام میگیرد. نتیجه، کاهش اتلاف، پیشبینیپذیری بهتر و سیستمهایی سریع، پایدار و آگاه از هزینه است.
#FinOps #CloudCost #Duolingo #CostOptimization #DevOps #EngineeringExcellence #CloudOps #SoftwareQuality
🟣لینک مقاله:
https://www.infoq.com/news/2025/10/duolingo-finops-engineering/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
InfoQ
Inside Duolingo’s FinOps Journey: Turning Cloud Spend into Engineering Insight
Duolingo's FinOps journey integrates financial awareness into engineering, empowering developers to link costs with performance. By leveraging real-time data, teams prioritize innovations for maximum impact. This collaborative culture shift transformed cost…
🔵 عنوان مقاله
SR-IOV Network Device Plugin
🟢 خلاصه مقاله:
این افزونه با بهرهگیری از SR-IOV امکان تخصیص مستقیم VFهای یک NIC فیزیکی به Podها را در Kubernetes فراهم میکند تا به کارایی نزدیک به سختافزار، تأخیر پایین و سربار CPU کم برسند. افزونه بهصورت DaemonSet روی نودها اجرا میشود، دستگاههای SR-IOV را کشف کرده و از طریق Device Plugin API بهعنوان منابع قابلدرخواست در اختیار kubelet میگذارد؛ با درخواست Pod یک VF بهطور انحصاری تخصیص مییابد و جداسازی و پیشبینیپذیری کارایی تضمین میشود. پیکربندی شبکه با SR-IOV CNI و معمولاً Multus انجام میشود و بسته به نیاز، VF میتواند به درایورهایی مانند vfio-pci برای DPDK یا درایورهای کرنلی متصل شود؛ همچنین در صورت پشتیبانی سختافزار، RDMA قابل استفاده است. استقرار نیازمند فعالسازی SR-IOV و IOMMU، NIC سازگار، ایجاد VFها و Linux است و در بسیاری از سناریوها SR-IOV Network Operator مدیریت خودکار و سیاستگذاری را ساده میکند. این راهکار برای CNFها، NFV، تحلیل بلادرنگ و محیطهای با حساسیت بالا به تأخیر کاربردی است و بهصورت استاندارد با اکوسیستم CNI در Kubernetes ادغام میشود.
#SRIOV #Kubernetes #CNI #Multus #DPDK #NFV #Networking #CloudNative
🟣لینک مقاله:
https://ku.bz/jVg_1VS-k
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
SR-IOV Network Device Plugin
🟢 خلاصه مقاله:
این افزونه با بهرهگیری از SR-IOV امکان تخصیص مستقیم VFهای یک NIC فیزیکی به Podها را در Kubernetes فراهم میکند تا به کارایی نزدیک به سختافزار، تأخیر پایین و سربار CPU کم برسند. افزونه بهصورت DaemonSet روی نودها اجرا میشود، دستگاههای SR-IOV را کشف کرده و از طریق Device Plugin API بهعنوان منابع قابلدرخواست در اختیار kubelet میگذارد؛ با درخواست Pod یک VF بهطور انحصاری تخصیص مییابد و جداسازی و پیشبینیپذیری کارایی تضمین میشود. پیکربندی شبکه با SR-IOV CNI و معمولاً Multus انجام میشود و بسته به نیاز، VF میتواند به درایورهایی مانند vfio-pci برای DPDK یا درایورهای کرنلی متصل شود؛ همچنین در صورت پشتیبانی سختافزار، RDMA قابل استفاده است. استقرار نیازمند فعالسازی SR-IOV و IOMMU، NIC سازگار، ایجاد VFها و Linux است و در بسیاری از سناریوها SR-IOV Network Operator مدیریت خودکار و سیاستگذاری را ساده میکند. این راهکار برای CNFها، NFV، تحلیل بلادرنگ و محیطهای با حساسیت بالا به تأخیر کاربردی است و بهصورت استاندارد با اکوسیستم CNI در Kubernetes ادغام میشود.
#SRIOV #Kubernetes #CNI #Multus #DPDK #NFV #Networking #CloudNative
🟣لینک مقاله:
https://ku.bz/jVg_1VS-k
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
GitHub
GitHub - k8snetworkplumbingwg/sriov-network-device-plugin: SRIOV network device plugin for Kubernetes
SRIOV network device plugin for Kubernetes. Contribute to k8snetworkplumbingwg/sriov-network-device-plugin development by creating an account on GitHub.
❤1
چجوری بفهمیم ایمیجهای Docker کی نسخه جدید میدن
خیلی وقتا سرویسهای داکری روی نسخههای قدیمی ایمیج میمونن و کسی هم به این زودی متوجه نمیشه!
برای همین ابزاری هست به اسم DIUN که کارش فقط یه چیزه:
بفهمه ایمیجی که داری استفاده میکنی، نسخه جدید داده یا نه.
حالا DIUN چطوری اینو تشخیص میده؟
خیلی ساده:
به docker.sock وصل میشه، میفهمه چه کانتینرهایی داری و از چه ایمیجهایی استفاده میکنی. بعد Digest همونا رو با Digest رجیستری مقایسه میکنه :)))
اگر فرق داشت، یعنی نسخهٔ جدید منتشر شده.
برای استفاده هم فقط کافیه یه کانتینر DIUN کنار سرویسهات بیاری بالا.
حالا DIUN میتونه خروجی رو به هرجایی که API میده بفرسته:
تلگرام، Slack و...
جزئیاتش اینجاست:
https://hashbang.nl/blog/receive-notifications-when-updates-to-docker-images-are-released-using-diun
البته تو محیطهای بزرگ تر معمولاً از ابزارهایی مثل Renovate یا watchtower استفاده میکنن،
ولی DIUN یه گزینه راحت و کار راه اندازه برای اینکه سریع بفهمی ایمیج جدید اومده یا نه!
@ | <Amir Haji Mohammad Sadegh/>
خیلی وقتا سرویسهای داکری روی نسخههای قدیمی ایمیج میمونن و کسی هم به این زودی متوجه نمیشه!
برای همین ابزاری هست به اسم DIUN که کارش فقط یه چیزه:
بفهمه ایمیجی که داری استفاده میکنی، نسخه جدید داده یا نه.
حالا DIUN چطوری اینو تشخیص میده؟
خیلی ساده:
به docker.sock وصل میشه، میفهمه چه کانتینرهایی داری و از چه ایمیجهایی استفاده میکنی. بعد Digest همونا رو با Digest رجیستری مقایسه میکنه :)))
اگر فرق داشت، یعنی نسخهٔ جدید منتشر شده.
برای استفاده هم فقط کافیه یه کانتینر DIUN کنار سرویسهات بیاری بالا.
حالا DIUN میتونه خروجی رو به هرجایی که API میده بفرسته:
تلگرام، Slack و...
جزئیاتش اینجاست:
https://hashbang.nl/blog/receive-notifications-when-updates-to-docker-images-are-released-using-diun
البته تو محیطهای بزرگ تر معمولاً از ابزارهایی مثل Renovate یا watchtower استفاده میکنن،
ولی DIUN یه گزینه راحت و کار راه اندازه برای اینکه سریع بفهمی ایمیج جدید اومده یا نه!
@ | <Amir Haji Mohammad Sadegh/>
Hashbang
Receive notifications when updates to docker images are released using DIUN
👍2
🔵 عنوان مقاله
Using LLMs to filter out false positives from static code analysis (5 minute read)
🟢 خلاصه مقاله:
**Datadog قابلیت فیلتر هوشمند «مثبت کاذب» را به ابزار Static Code Analysis اضافه کرده است. این ویژگی با تکیه بر Bits AI و LLMها، یافتههای امنیتی را به «احتمالاً واقعی» یا «احتمالاً مثبت کاذب» دستهبندی میکند تا نویز کاهش یابد، تریاژ سریعتر شود و تیمهای توسعه و امنیت بتوانند روی آسیبپذیریهای واقعاً مهم تمرکز کنند و رفع آنها را سریعتر پیش ببرند.
#StaticCodeAnalysis #Datadog #BitsAI #LLM #DevSecOps #ApplicationSecurity #CodeScanning #FalsePositives
🟣لینک مقاله:
https://www.datadoghq.com/blog/using-llms-to-filter-out-false-positives/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Using LLMs to filter out false positives from static code analysis (5 minute read)
🟢 خلاصه مقاله:
**Datadog قابلیت فیلتر هوشمند «مثبت کاذب» را به ابزار Static Code Analysis اضافه کرده است. این ویژگی با تکیه بر Bits AI و LLMها، یافتههای امنیتی را به «احتمالاً واقعی» یا «احتمالاً مثبت کاذب» دستهبندی میکند تا نویز کاهش یابد، تریاژ سریعتر شود و تیمهای توسعه و امنیت بتوانند روی آسیبپذیریهای واقعاً مهم تمرکز کنند و رفع آنها را سریعتر پیش ببرند.
#StaticCodeAnalysis #Datadog #BitsAI #LLM #DevSecOps #ApplicationSecurity #CodeScanning #FalsePositives
🟣لینک مقاله:
https://www.datadoghq.com/blog/using-llms-to-filter-out-false-positives/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Datadog
Using LLMs to filter out false positives from static code analysis | Datadog
Datadog’s false positive filtering for SAST uses Bits AI to reduce noise, improve accuracy, and help teams focus on real security vulnerabilities.
❤2
🔵 عنوان مقاله
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 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
Medium
How We Rebuilt Our Vault Architecture with Raft, Snapshots, and DR
Author: Moshe Levine, DevOps Team Lead, BioCatch. Follow Moshe on Medium at https://medium.com/@moshlevine.