🔵 عنوان مقاله
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
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
Linkerd
The Story Behind the Great Sidecar Debate
Pulling back the curtain on architectural choices in Linkerd, Istio Legacy, and Istio Ambient.