🔵 عنوان مقاله
Inlets-operator: LoadBalancer tool

🟢 خلاصه مقاله:
** Inlets-operator یک ابزار ایجاد LoadBalancer برای Kubernetes است که به کلاسترهای پشت NAT یا بدون ارائه‌دهنده ابری، یک نقطه دسترسی عمومی می‌دهد. با رصد Serviceهای نوع LoadBalancer، یک سرور خروجی در فضای عمومی فراهم می‌کند و از طریق تونل امن inlets ترافیک را از آن سرور به NodePort یا Podهای داخل کلاستر هدایت می‌کند. این روش برای محیط‌های on‑prem، لبه، k3s/microk8s و سناریوهای توسعه و آزمایشی مقرون‌به‌صرفه است و بدون وابستگی به LoadBalancerهای مدیریت‌شده ابری، انتشار سرویس‌ها را ساده و قابل‌حمل می‌سازد.

#Kubernetes #LoadBalancer #Inlets #DevOps #CloudNative #Networking #EdgeComputing

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Exposing Kubernetes Services Without Cloud LoadBalancers: A Practical Guide

🟢 خلاصه مقاله:
این راهنما برای محیط‌های bare‑metal و air‑gapped که به LoadBalancerهای ابری دسترسی ندارند، روشی عملی برای اکسپوز کردن سرویس‌های Kubernetes ارائه می‌دهد. با ترکیب MetalLB و NGINX Ingress، ابتدا MetalLB یک IP پایدار به Serviceهای نوع LoadBalancer اختصاص می‌دهد، سپس NGINX Ingress ترافیک را بر اساس host و path به سرویس‌های داخلی مسیردهی می‌کند. نتیجه، یک نقطه ورودی واحد با IP ثابت، مدیریت ساده‌تر DNS و عدم نیاز به باز کردن پورت‌های متعدد است. آموزش شامل نصب و پیکربندی MetalLB (L2 یا BGP)، استقرار NGINX Ingress، تعریف Ingressها، و نکاتی درباره TLS، پایداری، و عیب‌یابی است؛ و نشان می‌دهد چرا این الگو نسبت به NodePort یا hostNetwork تمیزتر و مقیاس‌پذیرتر بوده و تجربه‌ای مشابه فضای ابری را بدون وابستگی به آن فراهم می‌کند.

#Kubernetes #MetalLB #NGINXIngress #BareMetal #AirGapped #DevOps #Ingress #LoadBalancer

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Kubernetes On-Premise Service of type LoadBalancer with L2 / BGP

🟢 خلاصه مقاله:
** خلاصه فارسی: اجرای Service از نوع LoadBalancer در محیط‌های on‑premise نیازمند پیاده‌سازی همان لایه‌ای است که در ابرها به‌صورت آماده ارائه می‌شود. دو رویکرد اصلی برای اعلام و مسیریابی IPهای سرویس عبارت‌اند از L2 و BGP. در حالت L2 (مثل MetalLB در L2 mode)، VIP از طریق ARP/NDP در همان زیرشبکه اعلام می‌شود؛ راه‌اندازی ساده است و برای محیط‌های کوچک مناسب است، اما به دامنه لایه ۲ محدود است و در مقیاس زیاد به‌صرفه نیست. در حالت BGP (با MetalLB، Cilium یا Calico و معمولاً FRR)، کلاستر با روترهای بالادستی Peer می‌شود و مسیر VIPها را اعلام می‌کند؛ این روش از چند زیرشبکه، ECMP و سیاست‌های مسیریابی پشتیبانی می‌کند و برای مقیاس و کارایی بالاتر مناسب است، هرچند نیازمند هماهنگی شبکه و سیاست‌های امنیتی و فیلتراسیون مسیر است. در هر دو روش باید به مدیریت IP pool، مرزبندی استقرار VIP، ExternalTrafficPolicy، HA و observability (متریک‌ها و لاگ‌ها) و نکات امنیتی مانند BGP MD5 و کنترل ARP/NDP توجه کرد. انتخاب بین L2 و BGP به مقیاس و توپولوژی بستگی دارد: L2 برای یک زیرشبکه/رک ساده سریع و عملی است؛ BGP برای چند‌رکی، چند‌زیرشبکه و بار بالا گزینه پایدار و مقیاس‌پذیر محسوب می‌شود.

#Kubernetes #LoadBalancer #MetalLB #BGP #Layer2 #OnPrem #CloudNative #Networking

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon