🔵 عنوان مقاله
Smesh: Lightweight Kubernetes-Integrated Sidecar Mesh Without Proxies

🟢 خلاصه مقاله:
** اسمش یک نمونهٔ آزمایشی از یک service mesh سبک برای Kubernetes است که با استفاده از eBPF ترافیک pod‌ها را در سطح کرنل رهگیری و به یک sidecar proxy هدایت می‌کند. رویکرد آن کاهش سربار مسیر داده با اتکا به eBPF برای interception و redirection است، در حالی که مدیریت ترافیک همچنان توسط یک مؤلفهٔ sidecar انجام می‌شود. هدف، یکپارچگی بهتر با Kubernetes و بهبود تأخیر و مصرف CPU نسبت به مش‌های سنتی است، اما این پروژه در حد اثبات مفهوم است و هنوز برای استفادهٔ تولیدی نیاز به بلوغ و آزمون‌های بیشتر دارد.

#Kubernetes #ServiceMesh #eBPF #Sidecar #CloudNative #ContainerNetworking #DevOps

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Observing Egress Traffic with Istio

🟢 خلاصه مقاله:
این مقاله نشان می‌دهد چگونه با استفاده از Istio در محیط Kubernetes می‌توان ترافیک خروجی را — چه در حالت بدون رمزنگاری و چه رمزگذاری‌شده — به‌صورت قابل اتکا مشاهده و کنترل کرد. رویکردهای اصلی شامل TLS origination برای آغاز TLS در پروکسی، TLS termination برای پایان دادن TLS در egress gateway و راه‌اندازی مجدد ارتباط رمزگذاری‌شده، و همچنین مدیریت گواهی‌ها برای حفظ هم‌زمان امنیت و مشاهده‌پذیری است.

برای ترافیک بدون رمزنگاری، با تعریف ServiceEntry، و مسیریابی از طریق VirtualService و DestinationRule، Istio قادر است ترافیک را شناسایی کرده و تلِمتری لایه ۷ مانند متد، مسیر، کدهای پاسخ و تأخیر را از طریق Envoy تولید و به Prometheus/OpenTelemetry ارسال کند.

در ترافیک رمزگذاری‌شده، اگر برنامه‌ها مستقیماً با HTTPS متصل شوند، مشاهده‌پذیری به سطح L3/L4 (مثل SNI، IP/Port، آمار بایت و خطاهای TLS) محدود می‌شود. برای دست‌یابی به دید لایه ۷، می‌توان TLS origination را در سایدکار یا ترجیحاً در egress gateway فعال کرد تا برنامه با HTTP به پروکسی صحبت کند و پروکسی اتصال TLS به سرویس خارجی را برقرار کند. در سناریوهایی که نیاز به بازرسی HTTPS وجود دارد و برنامه الزاماً HTTPS می‌زند، الگوی TLS termination در egress gateway و سپس re-origination به مقصد خارجی قابل استفاده است؛ این روش نیازمند توزیع ریشه CA مورداعتماد به ورک‌لودها و محدودسازی دامنه‌های قابل رهگیری است.

پایه‌ی این الگوها، مدیریت درست گواهی‌ها است: استفاده از SDS برای بارگذاری پویا، مدیریت ریشه‌های اعتماد عمومی، صدور گواهی‌های مشتری هنگام نیاز به mTLS سمت مقصد خارجی، و رعایت نکاتی مانند SNI/SAN، چرخش خودکار و فرآیند ابطال. در عمل، عبور تمام ترافیک از egress gateway، محدودسازی مقاصد با AuthorizationPolicy، و ترجیح TLS origination در gateway برای کنترل متمرکز توصیه می‌شود. بدین ترتیب، Istio امکان مشاهده‌پذیری ترافیک خروجی را با حفظ الزامات امنیتی و انطباق فراهم می‌کند.

#Istio #Kubernetes #Egress #TLS #ServiceMesh #Observability #mTLS #CertificateManagement

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
Smesh: Lightweight Kubernetes-Integrated Sidecar Mesh Without Proxies

🟢 خلاصه مقاله:
smesh یک نمونه اولیه از یک service mesh برای Kubernetes است که با تکیه بر eBPF، ترافیک pod را در سطح کرنل رهگیری و به یک sidecar proxy هدایت می‌کند. ایده اصلی این است که به‌جای اتکا به سازوکارهای سنتیِ capture مانند iptables، رهگیری و تغییر مسیر در خود کرنل انجام شود تا هدایت ترافیک به sidecar ساده‌تر و کم‌هزینه‌تر شود. رویکرد smesh «سبک» و یکپارچه با Kubernetes است و می‌کوشد سربار و پیچیدگی عملیاتی را کاهش دهد. هرچند شعار «بدون پروکسی» مطرح است، تمایز اصلی در smesh استفاده از eBPF برای interception است و همچنان sidecar مقصد نهایی جریان‌های هدایت‌شده باقی می‌ماند. این پروژه فعلاً در سطح آزمایشی است و برای ارزیابی امکان‌پذیری و مزایای بالقوه‌ی رهگیری مبتنی بر eBPF عرضه شده است.

#Kubernetes #eBPF #ServiceMesh #Sidecar #CloudNative #Networking #DevOps

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon

🔵 عنوان مقاله
The story behind the great sidecar debate

🟢 خلاصه مقاله:
این مقاله با محور «جدال بزرگ sidecar» نشان می‌دهد چگونه می‌توان مصرف منابع data plane را میان Linkerd، Istio Legacy و Istio Ambient روی GKE به شکلی عادلانه و قابل‌تکرار مقایسه کرد. روش کار با ساخت یک تست‌بد استاندارد روی GKE آغاز می‌شود: خوشه‌ای با اندازه و نوع نود یکسان، غیرفعال‌کردن autoscaling، یک بارکاری پایه برای سنجش، و اندازه‌گیری CPU، حافظه و تاخیرهای p95/p99 بدون mesh به‌عنوان خط مبنا.

سپس هر mesh با سطح امکانات برابر تنظیم می‌شود: فعال‌سازی mTLS، حداقل telemetry یکسان، و کنترل دقیق منابع. در Linkerd و Istio Legacy از sidecar برای هر پاد استفاده می‌شود و در Istio Ambient اجزای مشترک مانند ztunnel/waypoint پیکربندی می‌گردد. آزمایش در فازهای افزایشی انجام می‌شود: ابتدا فقط mTLS، سپس سیاست‌های L7 و مسیریابی، و در نهایت telemetry؛ در هر فاز، بار گرم‌کردن، افزایش و پایداری اعمال و داده‌ها با Prometheus و ابزارهای observability جمع‌آوری می‌شود. برای اطمینان از بی‌طرفی، اجراها تکرار و ترتیب آزمون‌ها تصادفی می‌شود.

تحلیل نتایج دو سطح را پوشش می‌دهد: سربار هر پاد و اثر کلان در مقیاس خوشه. طراحی‌های مبتنی بر sidecar با افزایش تعداد پادها سربار را خطی بالا می‌برند، درحالی‌که Ambient هزینه‌ها را به اجزای مشترک منتقل می‌کند و منحنی هزینه را در مقیاس تغییر می‌دهد. مقاله همچنین ملاحظات عملی مانند جداسازی خرابی، امنیت، سادگی عملیات، و نیازهای واقعی قابلیت‌ها را مطرح می‌کند و یک الگوی مرجع برای تکرار آزمایش با Terraform/Helm و داشبوردهای استاندارد ارائه می‌دهد تا تیم‌ها بتوانند بر اساس داده‌های واقعی تصمیم بگیرند.

#ServiceMesh #Istio #Linkerd #Kubernetes #GKE #Sidecar #AmbientMesh #Benchmark

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

➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon