How We Migrated 30+ Kubernetes Clusters to Terraform
https://medium.com/learnings-from-the-paas/how-we-migrated-30-kubernetes-clusters-to-terraform-cd2b1cef8b84
#DevOps
#kubernetes
#byteforge
@byteforge_chan 🛸
Medium
How We Migrated 30+ Kubernetes Clusters to Terraform
In this blog post, we will guide you through the process of automating a complex infrastructure migration from a patchwork of Sceptre and…
❤1🔥1
در کوبرنتیز یه قابلیت کمترشناختهشده وجود داره به اسم Static Pods.
این پادها نه توسط API Server ساخته میشن، نه توی etcd ثبت میشن!
در عوض، خود kubelet روی هر ورکر نود مستقیم اون پادها رو از روی فایلهای YAML (مثلاً /etc/kubernetes/manifests/) میسازه و اجرا میکنه
حتی اگه کل کلاسترت بالا نیومده باشه
این پادها نه توسط API Server ساخته میشن، نه توی etcd ثبت میشن!
در عوض، خود kubelet روی هر ورکر نود مستقیم اون پادها رو از روی فایلهای YAML (مثلاً /etc/kubernetes/manifests/) میسازه و اجرا میکنه
حتی اگه کل کلاسترت بالا نیومده باشه
#DevOps
#kubernetes
#byteforge
@byteforge_chan 🛸
❤🔥1🔥1
اگه کلاسترت شلوغ شده، وقتشه Kor رو بندازی وسط
پاکسازی خودکار منابع اضافی در Kubernetes با Kor
اگه مدتیه با کوبرنتیز کارمیکنی، احتمالاً کلی resource بیمصرف ته کلاسترت جا خوش کردن. از ConfigMapهای قدیمی گرفته تا PVCهایی که هیچ پادی دیگه ازشون استفاده نمیکنه. این چیزا کمکم کلاستر رو شلوغ و کند میکنن و حتی باعث هزینههای اضافه هم میشن.
اینجاست که Kor به دادت میرسه:
Kor یه ابزار متنبازه که کمک میکنه منابع (Orphaned Resources) رو توی کلاستر پیدا کنی و اگه خواستی حذفشون کنی.
از ConfigMap و Secret گرفته تا Deployment، Service، PVC، RoleBinding و حتی NetworkPolicy رو چک میکنه و هرچی بلااستفادهست، برات لیست میکنه.
نصب از طریق کامند زیر :
و برای اجرا فقط کافیه اینو بزنی:
Kor خروجی مرتب و واضحی بهت میده، مثلاً میگه کدوم Secret هیچ پادی ازش استفاده نمیکنه یا کدوم Service endpoint نداره.
میتونی خروجی رو توی فرمتهای مختلف مثل table، json یا yaml بگیری تا راحتتر توی CI/CD یا مانیتورینگ ازش استفاده کنی.
توصیه:
میتونی Kor رو بهصورت CronJob ران کنی تا خودش بهصورت خودکار هر هفته یه گزارش پاکسازی از کلاستر برات بیاره.
پاکسازی خودکار منابع اضافی در Kubernetes با Kor
اگه مدتیه با کوبرنتیز کارمیکنی، احتمالاً کلی resource بیمصرف ته کلاسترت جا خوش کردن. از ConfigMapهای قدیمی گرفته تا PVCهایی که هیچ پادی دیگه ازشون استفاده نمیکنه. این چیزا کمکم کلاستر رو شلوغ و کند میکنن و حتی باعث هزینههای اضافه هم میشن.
اینجاست که Kor به دادت میرسه:
github.com/yonahd/kor
Kor یه ابزار متنبازه که کمک میکنه منابع (Orphaned Resources) رو توی کلاستر پیدا کنی و اگه خواستی حذفشون کنی.
از ConfigMap و Secret گرفته تا Deployment، Service، PVC، RoleBinding و حتی NetworkPolicy رو چک میکنه و هرچی بلااستفادهست، برات لیست میکنه.
نصب از طریق کامند زیر :
go install github.com/yonahd/kor@latest
و برای اجرا فقط کافیه اینو بزنی:
kor --namespace default
Kor خروجی مرتب و واضحی بهت میده، مثلاً میگه کدوم Secret هیچ پادی ازش استفاده نمیکنه یا کدوم Service endpoint نداره.
میتونی خروجی رو توی فرمتهای مختلف مثل table، json یا yaml بگیری تا راحتتر توی CI/CD یا مانیتورینگ ازش استفاده کنی.
توصیه:
میتونی Kor رو بهصورت CronJob ران کنی تا خودش بهصورت خودکار هر هفته یه گزارش پاکسازی از کلاستر برات بیاره.
فقط حواست باشه: قبل از حذف منابع، حتماً خروجی رو چک کن. بعضی resourceها ممکنه ظاهراً بیمصرف باشن ولی درواقع یه اپ دیگه بهش وابستهست. بهتره اول Kor رو توی محیط تست ران کنی تا مطمئن شی چیزی رو اشتباهی پاک نمیکنی.
#DevOps
#kubernetes
#byteforge
@byteforge_chan 🛸
GitHub
GitHub - yonahd/kor: A Golang Tool to discover unused Kubernetes Resources
A Golang Tool to discover unused Kubernetes Resources - GitHub - yonahd/kor: A Golang Tool to discover unused Kubernetes Resources
👌3
یک pipeline واحد برای همه چیز در Kubernetes!
Fatih Koç توی این پست نشون میده چطور با OpenTelemetry میتونیم لاگ، متریک و تراس رو در یک مسیر جمع کنیم و از alert تا root cause فقط چند ثانیه فاصله بگیریم.
اگر با observability و incident response سر و کار داری، این مقاله رو از دست نده 👇
https://fatihkoc.net/posts/opentelemetry-kubernetes-pipeline
Fatih Koç توی این پست نشون میده چطور با OpenTelemetry میتونیم لاگ، متریک و تراس رو در یک مسیر جمع کنیم و از alert تا root cause فقط چند ثانیه فاصله بگیریم.
اگر با observability و incident response سر و کار داری، این مقاله رو از دست نده 👇
🔗 Building a Unified OpenTelemetry Pipeline in Kubernetes
#DevOps
#kubernetes
#byteforge
@byteforge_chan 🛸
https://fatihkoc.net/posts/opentelemetry-kubernetes-pipeline
Fatih Koç
Building a Unified OpenTelemetry Pipeline in Kubernetes
Deploy OpenTelemetry Collector in Kubernetes to unify metrics, logs, and traces with correlation, smart sampling, and insights for faster incident resolution.
❤2👏1
Byteforge / بایــت فورج 🛸
میخوام ی سری رشته مطالب اموزشی جدید بذارم که محتوای کوتاهی از نظر تعداد کاراکتر دارند ولی حق مطلب رو ادا میکنند . البته مطالب اصلی که کاملتر هستند همچنان بی تغیر باقی میمانند و ادامه دار هستند .
کلاستر چیست؟
کلاستر cluster یعنی مجموعهای از چند سرور که بهصورت هماهنگ به هم متصلان و مثل یه سیستم یکپارچه کار میکنن
هدف از ساخت کلاستر اینه که بارِ پردازش بین سرورها تقسیم بشه تا سرعت و کارایی بالا بره، و اگه یکی از سرورها از کار افتاد، بقیه بدون توقف کار رو ادامه بدن
بهخلاصه، کلاستر باعث میشه سیستم پایدارتر، سریعتر و قابلاعتمادتر بشه.
#DevOps
#cluster
#byteforge
@byteforge_chan 🛸
❤6👌2😐1
پایش ترافیک بینزون در Kubernetes با kubezonnet
اگه خوشههات روی چند تا zone مختلف اجرا میشن، احتمالاً بخشی از هزینه یا کندی شبکهت از ترافیکی میاد که بین این zoneها رد و بدل میشه ترافیکی که معمولاً کسی حواسش بهش نیست.
اینجا kubezonnet بهدرد میخوره. یه ابزار متنباز از تیم Polar Signals که با eBPF کار میکنه و ترافیک بینزون رو بدون هیچ تغییری در سرویسها رصد میکنه. دادههاش مستقیماً به Prometheus فرستاده میشن، پس راحت میتونی تو Grafana یا هر ابزار مانیتورینگی که داری، وضعیت رو ببینی.
به کمک kubezonnet میفهمی دقیقاً کدوم پادها یا workloadها باعث ترافیک بین zoneها هستن، و این یعنی میتونی منابع رو بهتر جابهجا کنی، latency رو پایین بیاری و هزینهها رو کنترل کنی.
پروژه هنوز تازهست، ولی دقیقاً اون دیدی رو میده که معمولاً تو مانیتورینگ شبکه گم میکنیم: دید واقعی از ارتباط بین zoneها.
مخزن پروژه روی گیتهاب در دسترسه:
اگه خوشههات روی چند تا zone مختلف اجرا میشن، احتمالاً بخشی از هزینه یا کندی شبکهت از ترافیکی میاد که بین این zoneها رد و بدل میشه ترافیکی که معمولاً کسی حواسش بهش نیست.
اینجا kubezonnet بهدرد میخوره. یه ابزار متنباز از تیم Polar Signals که با eBPF کار میکنه و ترافیک بینزون رو بدون هیچ تغییری در سرویسها رصد میکنه. دادههاش مستقیماً به Prometheus فرستاده میشن، پس راحت میتونی تو Grafana یا هر ابزار مانیتورینگی که داری، وضعیت رو ببینی.
به کمک kubezonnet میفهمی دقیقاً کدوم پادها یا workloadها باعث ترافیک بین zoneها هستن، و این یعنی میتونی منابع رو بهتر جابهجا کنی، latency رو پایین بیاری و هزینهها رو کنترل کنی.
پروژه هنوز تازهست، ولی دقیقاً اون دیدی رو میده که معمولاً تو مانیتورینگ شبکه گم میکنیم: دید واقعی از ارتباط بین zoneها.
مخزن پروژه روی گیتهاب در دسترسه:
https://github.com/polarsignals/kubezonnet
#DevOps
#kubernetes
#byteforge
@byteforge_chan 🛸
GitHub
GitHub - polarsignals/kubezonnet: Monitor cross-zone network traffic in Kubernetes.
Monitor cross-zone network traffic in Kubernetes. Contribute to polarsignals/kubezonnet development by creating an account on GitHub.
🔥2
k3k تولد کلاستر درون کلاستر
اگه تاحالا خواستی برای هر تیم یا پروژه یه محیط Kubernetes جدا بسازی، ولی نخواستی درگیر ساخت و نگهداری چندتا کلاستر واقعی بشی، k3k دقیقاً همون چیزیه که دنبالش بودی.
k3k یه پروژه از تیم Rancherـه که اجازه میده کلاسترهای K3s ایزوله و سبک رو مستقیماً داخل یه کلاستر Kubernetes موجود بسازی.
یعنی هر کلاستر مجازی یه کنترلپلین مستقل (K3s) داره، با kube-apiserver و etcd خودش، اما همشون روی نودهای همون کلاستر میزبان اجرا میشن و از منابعش share میکنن
در عمل یعنی چی؟
یعنی برای هر تیم یا feature میتونی یه کلاستر مستقل بسازی بدون نیاز به VM یا سرور جدید.
هر کلاستر virtual، تنظیمات، RBAC و حتی نسخه خودش از Kubernetes رو میتونه داشته باشه، ولی مدیریت کلش از همون میزبان انجام میشه.
ساخت محیط dev یا sandbox جدا برای هر تیم
تست نسخههای مختلف از اپ یا operatorها
اجرای multi-tenant با جداسازی منطقی
کاهش هزینه زیرساخت نسبت به داشتن چند کلاستر فیزیکی
البته هنوز تو فاز experimentalـه، پس برای محیط production باید با احتیاط استفادهش کرد مخصوصاً از نظر persistence و networking.
ولی برای آزمایش، توسعه و مدیریت چند محیط همزمان، واقعاً یه ایدهی تمیز و آیندهداره.
اگه تاحالا خواستی برای هر تیم یا پروژه یه محیط Kubernetes جدا بسازی، ولی نخواستی درگیر ساخت و نگهداری چندتا کلاستر واقعی بشی، k3k دقیقاً همون چیزیه که دنبالش بودی.
k3k یه پروژه از تیم Rancherـه که اجازه میده کلاسترهای K3s ایزوله و سبک رو مستقیماً داخل یه کلاستر Kubernetes موجود بسازی.
یعنی هر کلاستر مجازی یه کنترلپلین مستقل (K3s) داره، با kube-apiserver و etcd خودش، اما همشون روی نودهای همون کلاستر میزبان اجرا میشن و از منابعش share میکنن
در عمل یعنی چی؟
یعنی برای هر تیم یا feature میتونی یه کلاستر مستقل بسازی بدون نیاز به VM یا سرور جدید.
هر کلاستر virtual، تنظیمات، RBAC و حتی نسخه خودش از Kubernetes رو میتونه داشته باشه، ولی مدیریت کلش از همون میزبان انجام میشه.
ساخت محیط dev یا sandbox جدا برای هر تیم
تست نسخههای مختلف از اپ یا operatorها
اجرای multi-tenant با جداسازی منطقی
کاهش هزینه زیرساخت نسبت به داشتن چند کلاستر فیزیکی
البته هنوز تو فاز experimentalـه، پس برای محیط production باید با احتیاط استفادهش کرد مخصوصاً از نظر persistence و networking.
ولی برای آزمایش، توسعه و مدیریت چند محیط همزمان، واقعاً یه ایدهی تمیز و آیندهداره.
لینک پروژه:
github.com/rancher/k3k
#DevOps
#cluster
#kubernetes
#byteforge
@byteforge_chan 🛸
GitHub
GitHub - rancher/k3k: Kubernetes in Kubernetes
Kubernetes in Kubernetes. Contribute to rancher/k3k development by creating an account on GitHub.
❤🔥3
Byteforge / بایــت فورج 🛸
اینهمه میگیم کوبرنتیز کوبرنتیز خوبه فلانه بیساره 🤔 اصلا چی هست این کوبرنتیز ؟؟ به ساده ترین روش الان با مثال توضیحاتش رو میذارم برای دوستان جدید که تازه اضافه شدن به کانال و اشنایی ندارن وعلاقه مند هستن
فرض کن یه رستوران بزرگ داری
توی آشپزخونهات کلی آشپز (Container) داری، هرکدوم یه بخش خاص از غذا رو درست میکنن
Kubernetes مثل مدیر رستورانه. خودش تصمیم میگیره چند تا آشپز لازم داری، کی یکی اضافه بشه یا اگه یکی خسته شد یا رفت، یکی دیگه جاش بیاد. اگه یه آشپز مریض شد یا سوختگی گرفت ( یعنی یه کانتینر کرش کرد)، Kubernetes سریع یه آشپز جدید (Pod جدید) جای اون میفرسته تا کار متوقف نشه.
اگه jاتفاقی مشتریها زیاد شدن (یعنی ترافیک زیاد شد)، Kubernetes خودش میگه
اگه شب شد و مشتریا رفتن، میگه
تازه Kubernetes حتی بلده اگه برق یه آشپزخونه رفت (یعنی یه Node از کار افتاد)، آشپزها رو بفرسته تو یه آشپزخونه دیگه که هنوز برق داره (یعنی تو یه Node سالم).
توی آشپزخونهات کلی آشپز (Container) داری، هرکدوم یه بخش خاص از غذا رو درست میکنن
Kubernetes مثل مدیر رستورانه. خودش تصمیم میگیره چند تا آشپز لازم داری، کی یکی اضافه بشه یا اگه یکی خسته شد یا رفت، یکی دیگه جاش بیاد. اگه یه آشپز مریض شد یا سوختگی گرفت ( یعنی یه کانتینر کرش کرد)، Kubernetes سریع یه آشپز جدید (Pod جدید) جای اون میفرسته تا کار متوقف نشه.
اگه jاتفاقی مشتریها زیاد شدن (یعنی ترافیک زیاد شد)، Kubernetes خودش میگه
«خب بچهها! باید آشپزخونهمون رو بزرگتر کنیم!»
و چند تا آشپز (Pod) دیگه اضافه میکنه.
اگه شب شد و مشتریا رفتن، میگه
«اوکی، الان لازم نیست ۱۰ تا آشپز کار کنن، ۳ تا کافیه.»
و خودش بقیه رو میفرسته خونه تا منابع هدر نره.
تازه Kubernetes حتی بلده اگه برق یه آشپزخونه رفت (یعنی یه Node از کار افتاد)، آشپزها رو بفرسته تو یه آشپزخونه دیگه که هنوز برق داره (یعنی تو یه Node سالم).
#DevOps
#cluster
#kubernetes
#byteforge
@byteforge_chan 🛸
❤🔥7
mcp-grafana
A Model Context Protocol (MCP) server for Grafana.
https://github.com/grafana/mcp-grafana
#DevOps
#byteforge
@byteforge_chan 🛸
GitHub
GitHub - grafana/mcp-grafana: MCP server for Grafana
MCP server for Grafana. Contribute to grafana/mcp-grafana development by creating an account on GitHub.
🔥2👏1
Byteforge / بایــت فورج 🛸
یه پست خفن در مورد argocd داریم که به ساده ترین شکل توضیح دادم این ابزار چیکار میکنه
«چطور ArgoCD تضمین میکنه Kubernetes همیشه با Git هماهنگ بمونه»
فرض کن یه رستوران بزرگ داری تو به عنوان مدیر، یه دفتر داری که توش دقیق نوشتی هر غذا چطوری باید درست بشه
چه مواد اولیهای داره، چند تا آشپز لازمه، دمای فر چقدره، و حتی چند تا غذا همزمان باید آماده بشن.
اون دفتر در دنیای نرمافزار، همون مخزن Gitه. یعنی جایی که «دستور اصلی کار» نوشته شده.
حالا توی آشپزخونه (که در دنیای ما همون Kubernetesه) چند تا آشپز مشغول کارن.
قراره همه طبق دستور دفتر کار کنن، ولی خب، معمولاً یکی یه تغییری میده!
یکی میگه «بیاین یه کم فلفل بیشتر بریزیم»،
یکی تصمیم میگیره دمای فر رو زیاد کنه که کار زودتر تموم شه،
یا یکی برای تست یه دستور جدید، خودش دستی یه چیز رو عوض میکنه.
اینجا دقیقاً همون اتفاقیه که توی سرورهای واقعی میافته:
اینجاست که ArgoCD وارد ماجرا میشه.
ArgoCD توی این مثال نقش سرآشپز ارشد و منظم رستوران رو داره.
اون دفتر دستور پخت (Git) رو همیشه دستشه و مدام بین آشپزها میچرخه تا مطمئن بشه همه دقیق طبق دستور عمل میکنن.
هر چند دقیقه یه بار میره سر میز کار آشپزها (یعنی سراغ Kubernetes) و نگاه میکنه ببینه همهچیز با دفتر یکی هست یا نه.
اگه ببینه دستور پخت تغییر کرده، دو حالت داره:
یا فقط خبر میده که «این غذا با دفتر یکی نیست» (که بهش میگن manual sync)
یا خودش بدون حرف اضافه، دستور درست رو دوباره اعمال میکنه (این میشه auto-sync)
از دید فنی، ArgoCD یه GitOps Controllerـه.
پس دیگه کسی نباید مستقیم بره چیزی رو روی سرور تغییر بده.
هر کاری بخوای بکنی، باید از Git انجامش بدی.
ArgoCD خودش بقیه مسیر رو میره، Deploymentها رو update میکنه، نسخهها رو sync میکنه، و حتی اگه کسی چیزی رو اشتباه عوض کنه، خودش برش میگردونه به حالت درست.
خلاصهاش:
به زبان خودمونی، ArgoCD تضمین میکنه اون چیزی که واقعاً روی سرور در حال اجراست، دقیقاً همون چیزیه که تو Git گفتی باید باشه.
نه کمتر، نه بیشتر.
فرض کن یه رستوران بزرگ داری تو به عنوان مدیر، یه دفتر داری که توش دقیق نوشتی هر غذا چطوری باید درست بشه
چه مواد اولیهای داره، چند تا آشپز لازمه، دمای فر چقدره، و حتی چند تا غذا همزمان باید آماده بشن.
اون دفتر در دنیای نرمافزار، همون مخزن Gitه. یعنی جایی که «دستور اصلی کار» نوشته شده.
حالا توی آشپزخونه (که در دنیای ما همون Kubernetesه) چند تا آشپز مشغول کارن.
قراره همه طبق دستور دفتر کار کنن، ولی خب، معمولاً یکی یه تغییری میده!
یکی میگه «بیاین یه کم فلفل بیشتر بریزیم»،
یکی تصمیم میگیره دمای فر رو زیاد کنه که کار زودتر تموم شه،
یا یکی برای تست یه دستور جدید، خودش دستی یه چیز رو عوض میکنه.
اینجا دقیقاً همون اتفاقیه که توی سرورهای واقعی میافته:
کسی ممکنه بره یه Deployment رو مستقیم ادیت کنه،
تعداد replicaها رو زیاد کنه،
یا نسخهی برنامه رو دستی عوض کنه.
در نتیجه، چیزی که واقعاً روی سرور در حال اجراست با اون چیزی که در Git نوشته شده فرق داره.
اینجاست که ArgoCD وارد ماجرا میشه.
ArgoCD توی این مثال نقش سرآشپز ارشد و منظم رستوران رو داره.
اون دفتر دستور پخت (Git) رو همیشه دستشه و مدام بین آشپزها میچرخه تا مطمئن بشه همه دقیق طبق دستور عمل میکنن.
هر چند دقیقه یه بار میره سر میز کار آشپزها (یعنی سراغ Kubernetes) و نگاه میکنه ببینه همهچیز با دفتر یکی هست یا نه.
اگه ببینه دستور پخت تغییر کرده، دو حالت داره:
یا فقط خبر میده که «این غذا با دفتر یکی نیست» (که بهش میگن manual sync)
یا خودش بدون حرف اضافه، دستور درست رو دوباره اعمال میکنه (این میشه auto-sync)
از دید فنی، ArgoCD یه GitOps Controllerـه.
یعنی چی؟ یعنی اون دائم داره وضعیت فعلی کلاستر Kubernetes رو با وضعیت تعریفشده در Git مقایسه میکنه.
به Git میگه “تو منبع حقیقتی (source of truth)”،
و هر چی اونجا تغییر کنه (مثلاً فایل YAML جدید یا یه commit تازه)، ArgoCD اون تغییر رو میفهمه، تفاوتش رو حساب میکنه و بعد تغییرات رو روی کلاستر اعمال میکنه.
پس دیگه کسی نباید مستقیم بره چیزی رو روی سرور تغییر بده.
هر کاری بخوای بکنی، باید از Git انجامش بدی.
ArgoCD خودش بقیه مسیر رو میره، Deploymentها رو update میکنه، نسخهها رو sync میکنه، و حتی اگه کسی چیزی رو اشتباه عوض کنه، خودش برش میگردونه به حالت درست.
خلاصهاش:
Git شده دفتر دستور پخت رسمی.
Kubernetes شده آشپزخونهای که غذاها اونجا درست میشن.
و ArgoCD شده سرآشپز وسواسی که نمیذاره هیچکس از دستور تخطی کنه.
به زبان خودمونی، ArgoCD تضمین میکنه اون چیزی که واقعاً روی سرور در حال اجراست، دقیقاً همون چیزیه که تو Git گفتی باید باشه.
نه کمتر، نه بیشتر.
#DevOps
#argocd
#cluster
#kubernetes
#byteforge
@byteforge_chan 🛸
👌3🏆1
caligula
https://github.com/ifd3f/caligula
Caligula is a user-friendly, lightweight TUI for imaging disks.
https://github.com/ifd3f/caligula
#DevOps
#byteforge
@byteforge_chan 🛸
GitHub
GitHub - ifd3f/caligula: A user-friendly, lightweight TUI for disk imaging
A user-friendly, lightweight TUI for disk imaging. Contribute to ifd3f/caligula development by creating an account on GitHub.
🔥2
داشتم ریپو های trend رو میدیدم
احتمالا خیلی زیاد میشنوید که ورکفلو های n8n
بازارش داغه و بحث زیاد میشه در موردش
این ریپو اومده و تعداد زیادی ورکفلو آماده رو جمع آوری کرده و اینجا گذاشته که بسته به نوع نیازتون میتونید استفاده کنید
احتمالا خیلی زیاد میشنوید که ورکفلو های n8n
بازارش داغه و بحث زیاد میشه در موردش
این ریپو اومده و تعداد زیادی ورکفلو آماده رو جمع آوری کرده و اینجا گذاشته که بسته به نوع نیازتون میتونید استفاده کنید
https://github.com/Zie619/n8n-workflows
#n8n
#DevOps
#byteforge
@byteforge_chan 🛸
❤1🔥1
شبکه در Kubernetes پیچیده اما قابل فهم! یه خلاصهی ساده
مقاله در کل داره درباره یه مشکل اصلی در Kubernetes حرف میزنه: پیچیدگی شبکه.
بهطور دقیق مشکل اینه :
هر پاد باید IP داشته باشه، مسیرها درست باشه، سرویسها ترافیک رو درست هدایت کنن، و DNS همیشه بروز باشه.
اگه این چیزها درست کار نکنه، نتیجهاش میشه پادهایی که به هم نمیرسن سرویسهایی که بالا نمیان و رفتارهای غیرقابلپیشبینی.
شبکه Kubernetes برخلاف Docker ساده نیست و برای همین نیاز به CNI، kube-proxy، Service Discovery و NetworkPolicy هست.
پس خلاصه بگم🤷
مقاله مشکل پیچیدگی ارتباطات داخل کلاستر Kubernetes رو توضیح میده و نشون میده این سیستم چطور شبکهسازی رو مدیریت میکنه تا پادها بتونن درست با هم و با بیرون ارتباط بگیرن.
مقاله در کل داره درباره یه مشکل اصلی در Kubernetes حرف میزنه: پیچیدگی شبکه.
بهطور دقیق مشکل اینه :
وقتی کلی پاد روی چند نود داری اینکه اینا چطور همدیگه رو پیدا کنن و حرف بزنن کار سادهای نیست.
هر پاد باید IP داشته باشه، مسیرها درست باشه، سرویسها ترافیک رو درست هدایت کنن، و DNS همیشه بروز باشه.
اگه این چیزها درست کار نکنه، نتیجهاش میشه پادهایی که به هم نمیرسن سرویسهایی که بالا نمیان و رفتارهای غیرقابلپیشبینی.
شبکه Kubernetes برخلاف Docker ساده نیست و برای همین نیاز به CNI، kube-proxy، Service Discovery و NetworkPolicy هست.
پس خلاصه بگم🤷
مقاله مشکل پیچیدگی ارتباطات داخل کلاستر Kubernetes رو توضیح میده و نشون میده این سیستم چطور شبکهسازی رو مدیریت میکنه تا پادها بتونن درست با هم و با بیرون ارتباط بگیرن.
لینک مقاله
https://www.freecodecamp.org/news/kubernetes-networking-tutorial-for-developers
#DevOps
#kubernetes
#byteforge
@byteforge_chan 🛸
🔥4⚡1❤1
در اغلب پروژههای مبتنی بر PostgreSQL، ضعف اصلی نه در خود دیتابیس، بلکه در بکاپگیری نامنظم، دستی و بدون مانیتورینگ دیده میشه.
یک خطای انسانی، یک اسکریپت ناقص یا یک اختلال دیسک برای نابودی داده کافیه
اینجا Postgresus بهعنوان یک راهکار بکاپ خودکار و self-hosted وارد میشه
Postgresus داخل زیرساخت پروژه اجرا خواهد شد و بدون وابستگی به SaaS، وظیفه زمانبندی، اجرا، نگهداری و گزارش بکاپ را برعهده خواهد گرفت.
شامل:
مزیت جدی نسبت به سرویسهای ابری:
داده از زیرساخت پروژه خارج نخواهد شد
وابستگی به سرویس ثالث ایجاد نخواهد شد
هزینه اشتراک ماهانه صفر باقی خواهد ماند
امکان کنترل کامل سطح دسترسی و امنیت وجود خواهد داشت
سورس پروژه روی GitHub بهصورت عمومی منتشر شده:
https://github.com/RostislavDugin/postgresus
یک خطای انسانی، یک اسکریپت ناقص یا یک اختلال دیسک برای نابودی داده کافیه
اینجا Postgresus بهعنوان یک راهکار بکاپ خودکار و self-hosted وارد میشه
Postgresus داخل زیرساخت پروژه اجرا خواهد شد و بدون وابستگی به SaaS، وظیفه زمانبندی، اجرا، نگهداری و گزارش بکاپ را برعهده خواهد گرفت.
قابلیتهای فنی مهم:
اجرای بکاپ بر پایه pg_dump با امکان تعریف چندین Job مستقل
زمانبندی دقیق از سطح دقیقه تا هفتگی
تعریف چند مقصد ذخیرهسازی بهصورت همزمان
شامل:
local filesystem
S3-compatible storage
مسیرهای network storage
نگهداری نسخههای قدیمی بر اساس سیاست Retention
داشبورد تحت وب برای مشاهده وضعیت Jobها
ارسال نوتیفیکیشن پس از هر Job موفق یا ناموفق
امکان تعریف چند PostgreSQL instance داخل یک پنل واحد
در سناریوی عملیاتی، معماری به این شکل پیادهسازی خواهد شد:
یک Container مرکزی Postgresus
اتصال امن به دیتابیسهای Production یا Staging
ذخیره بکاپ روی Volume مجزا یا Object Storage
مانیتورینگ خروجی Jobها از طریق اعلان
راهاندازی پایه بر اساس Docker انجام خواهد شد و نیاز به نصب مستقیم ابزار روی هاست دیتابیس وجود نخواهد داشت.
این موضوع ریسک دسترسی مستقیم به سرور اصلی دیتابیس را نیز کاهش خواهد داد.
مزیت جدی نسبت به سرویسهای ابری:
داده از زیرساخت پروژه خارج نخواهد شد
وابستگی به سرویس ثالث ایجاد نخواهد شد
هزینه اشتراک ماهانه صفر باقی خواهد ماند
امکان کنترل کامل سطح دسترسی و امنیت وجود خواهد داشت
سورس پروژه روی GitHub بهصورت عمومی منتشر شده:
https://github.com/RostislavDugin/postgresus
نکته فنی واقعبینانه :
برای دیتابیسهای بسیار سنگین با نیاز به WAL Archiving، Point-in-Time Recovery و بکاپ تفاضلی، ابزارهایی مانند pgBackRest انتخاب منطقیتری خواهند بود.
اما در اغلب پروژههای واقعی، Postgresus پوشش کامل نیاز بکاپ اتومات را فراهم خواهد کرد.
#DevOps
#database
#tools
#postgres
#byteforge
@byteforge_chan 🛸
GitHub
GitHub - databasus/databasus: Databases backup tool (PostgreSQL, MySQL, MongoDB)
Databases backup tool (PostgreSQL, MySQL, MongoDB) - databasus/databasus
👏6
fizzy
https://github.com/basecamp/fizzy
This is the source code of Fizzy, the Kanban tracking tool for issues and ideas by 37signals.
https://github.com/basecamp/fizzy
#DevOps
#byteforge
@byteforge_chan 🛸
GitHub
GitHub - basecamp/fizzy: Kanban as it should be. Not as it has been.
Kanban as it should be. Not as it has been. Contribute to basecamp/fizzy development by creating an account on GitHub.
❤4🔥1
GitHub گفته از ابتدای ۲۰۲۶ قراره مدل قیمتگذاری GitHub Actions عوض بشه
اولش شاید به نظر بیاد خبر خوبیه چون میگن هزینه runnerهای خود گیتهاب کمتر میشه ولی وقتی دقیقتر نگاه میکنی میبینی قضیه اونقدرها هم ساده نیست
قراره یه هزینه پلتفرم به ازای هر دقیقه اجرا اضافه بشه
یعنی حتی اگه runner رو خودت داشته باشی باز هم باید به GitHub پول بدی فقط برای اینکه از Actions استفاده میکنی فعلاً گفتن این بخش برای self hosted عقب افتاده ولی مشخصه که هنوز تصمیم نهایی گرفته نشده و احتمال پولی شدنش وجود داره
مسئله بعدی اینه که هرچی بیشتر از GitHub Actions استفاده کنی وابستهتر میشی
Workflowها اکشنها و کل CI/CD طوری طراحی شدن که اگه یه روز بخوای ازش جدا شی کلی دردسر داشته باشه
CI/CD بخش مهم پروژهست و وقتی قیمت و قوانینش دست یه شرکت متمرکز باشه همیشه این ریسک هست که یه تصمیم جدید همه چیز رو به هم بزنه
به همین خاطر GitLab برای خیلیها انتخاب منطقیتریه
CI/CD از اول جزو هسته گیتلب بوده نه یه چیز اضافه اگه self hosted بری جلو نه هزینه دقیقهای داری نه محدودیت عجیب و کنترل کامل دست خودته
خلاصه اینکه GitHub Actions هنوز کار راهاندازه
ولی مسیری که داره میره نشون میده بهتره از الان به گزینههای دیگه هم فکر کنی
حداقل GitLab یا Forgejo رو تست کن که اگه یه روز مجبور به مهاجرت شدی غافلگیر نشی
اولش شاید به نظر بیاد خبر خوبیه چون میگن هزینه runnerهای خود گیتهاب کمتر میشه ولی وقتی دقیقتر نگاه میکنی میبینی قضیه اونقدرها هم ساده نیست
قراره یه هزینه پلتفرم به ازای هر دقیقه اجرا اضافه بشه
یعنی حتی اگه runner رو خودت داشته باشی باز هم باید به GitHub پول بدی فقط برای اینکه از Actions استفاده میکنی فعلاً گفتن این بخش برای self hosted عقب افتاده ولی مشخصه که هنوز تصمیم نهایی گرفته نشده و احتمال پولی شدنش وجود داره
مسئله بعدی اینه که هرچی بیشتر از GitHub Actions استفاده کنی وابستهتر میشی
Workflowها اکشنها و کل CI/CD طوری طراحی شدن که اگه یه روز بخوای ازش جدا شی کلی دردسر داشته باشه
CI/CD بخش مهم پروژهست و وقتی قیمت و قوانینش دست یه شرکت متمرکز باشه همیشه این ریسک هست که یه تصمیم جدید همه چیز رو به هم بزنه
به همین خاطر GitLab برای خیلیها انتخاب منطقیتریه
CI/CD از اول جزو هسته گیتلب بوده نه یه چیز اضافه اگه self hosted بری جلو نه هزینه دقیقهای داری نه محدودیت عجیب و کنترل کامل دست خودته
اگه آزادی برات مهمتره Forgejo گزینه جدیتریه
کاملاً متنبازه self hosted واقعیه و خبری از هزینه دقیقهای و قفل شدن توی یه اکوسیستم خاص نیست بیشتر به نفع کاربر ساخته شده تا شرکت
خلاصه اینکه GitHub Actions هنوز کار راهاندازه
ولی مسیری که داره میره نشون میده بهتره از الان به گزینههای دیگه هم فکر کنی
حداقل GitLab یا Forgejo رو تست کن که اگه یه روز مجبور به مهاجرت شدی غافلگیر نشی
#DevOps
#byteforge
@byteforge_chan 🛸
❤🔥5❤1👍1
doh یه ابزار خطفرمان سبکه که باهاش DNS رو به شکل DNS over HTTPS میفرستی یعنی بهجای اینکه درخواست DNS معمولی و قابل شنود بفرستی، کوئری داخل HTTPS روی پورت ۴۴۳ میره سمت Cloudflare (1.1.1.1) و رمزنگاری میشه
به درد وقتایی میخوره که میخوای بدون درگیر شدن با DNS سیستمعاملت دامنهها رو resolve کنی یا وقتی DNS اینترنتت درست جواب نمیده، فیلتره یا دستکاری شده. برای دیباگ شبکه هم خیلی خوبه چون مستقیم میبینی هر دامنه دقیقاً چه رکوردایی برمیگردونه.
لینک ریپو :
https://github.com/mxssl/doh
به درد وقتایی میخوره که میخوای بدون درگیر شدن با DNS سیستمعاملت دامنهها رو resolve کنی یا وقتی DNS اینترنتت درست جواب نمیده، فیلتره یا دستکاری شده. برای دیباگ شبکه هم خیلی خوبه چون مستقیم میبینی هر دامنه دقیقاً چه رکوردایی برمیگردونه.
doh a google.com
doh mx gmail.com
doh txt example.com
لینک ریپو :
https://github.com/mxssl/doh
#tools
#DevOps
#byteforge
@byteforge_chan 🛸
👌5👍1
pgedge-postgres-mcp یه ابزاره که دیتابیس PostgreSQL رو به هوش مصنوعی وصلمیکنه.
بهجای نوشتن SQL، سوالتو ساده و متنی میپرسی و خودش کوئری میسازه و اجرامیکنه در اصل یه واسطهست که بین AI و دیتابیس میشینه و این دوتا رو با هم هماهنگمیکنه.
برای گزارش گرفتن، تحلیل داده و ابزارهای داخلی خیلی کاربردیه، ولی فعلاً بتاست.
لینک ریپو :
بهجای نوشتن SQL، سوالتو ساده و متنی میپرسی و خودش کوئری میسازه و اجرامیکنه در اصل یه واسطهست که بین AI و دیتابیس میشینه و این دوتا رو با هم هماهنگمیکنه.
برای گزارش گرفتن، تحلیل داده و ابزارهای داخلی خیلی کاربردیه، ولی فعلاً بتاست.
لینک ریپو :
https://github.com/pgEdge/pgedge-postgres-mcp
#tools
#DevOps
#byteforge
@byteforge_chan 🛸
👌3❤1
Extracting JVM Data from Crash-Looping Java Containers in Kubernetes
https://medium.com/@zelldon91/getting-data-out-of-burning-java-containers-6e0c8bb53eec
#kubernetes
#DevOps
#byteforge
@byteforge_chan 🛸
Medium
Extracting JVM Data from Crash-Looping Java Containers in Kubernetes
Learn hands-on strategies for retrieving heap dumps and flight recordings from crash-looping Java containers in Kubernetes.
👏3❤1