معرفی
ما در
В
با Istio 1.1، پروکسی تقریباً 0,6 vCPU (هسته مجازی) در هر 1000 درخواست در ثانیه مصرف می کند.
برای اولین منطقه در سرویس مش (2 پراکسی در هر طرف اتصال)، ما 1200 هسته فقط برای پراکسی خواهیم داشت، با نرخ یک میلیون درخواست در ثانیه. طبق محاسبهگر هزینه گوگل، برای پیکربندی تقریباً 40 دلار در ماه/هسته است. n1-standard-64
یعنی این منطقه به تنهایی برای 50 میلیون درخواست در ثانیه بیش از 1 هزار دلار در ماه برای ما هزینه خواهد داشت.
ایوان سیم (
ظاهرا values-istio-test.yaml درخواست های CPU را به طور جدی افزایش می دهد. اگر محاسبات خود را به درستی انجام داده باشم، تقریباً به 24 هسته CPU برای کنترل پنل و 0,5 CPU برای هر پروکسی نیاز دارید. من آنقدر ندارم. زمانی که منابع بیشتری به من اختصاص داده شد، تست ها را تکرار می کنم.
من میخواستم ببینم که عملکرد Istio چقدر شبیه به مش خدمات منبع باز دیگر است:
نصب مش سرویس
اول از همه، من آن را در یک کلاستر نصب کردم
$ supergloo init
installing supergloo version 0.3.12
using chart uri https://storage.googleapis.com/supergloo-helm/charts/supergloo-0.3.12.tgz
configmap/sidecar-injection-resources created
serviceaccount/supergloo created
serviceaccount/discovery created
serviceaccount/mesh-discovery created
clusterrole.rbac.authorization.k8s.io/discovery created
clusterrole.rbac.authorization.k8s.io/mesh-discovery created
clusterrolebinding.rbac.authorization.k8s.io/supergloo-role-binding created
clusterrolebinding.rbac.authorization.k8s.io/discovery-role-binding created
clusterrolebinding.rbac.authorization.k8s.io/mesh-discovery-role-binding created
deployment.extensions/supergloo created
deployment.extensions/discovery created
deployment.extensions/mesh-discovery created
install successful!
من از SuperGloo استفاده کردم زیرا بوت استرپ کردن سرویس مش را بسیار ساده تر می کند. من مجبور نبودم کار زیادی انجام دهم. ما از SuperGloo در تولید استفاده نمی کنیم، اما برای چنین کاری ایده آل است. من مجبور شدم به معنای واقعی کلمه از چند دستور برای هر سرویس مش استفاده کنم. من از دو خوشه برای جداسازی استفاده کردم - هر کدام برای ایستیو و لینکرد.
این آزمایش بر روی Google Kubernetes Engine انجام شد. من از Kubernetes استفاده کردم 1.12.7-gke.7
و مجموعه ای از گره ها n1-standard-4
با مقیاس خودکار گره (حداقل 4، حداکثر 16).
سپس هر دو مش سرویس را از خط فرمان نصب کردم.
پیوند اول:
$ supergloo install linkerd --name linkerd
+---------+--------------+---------+---------------------------+
| INSTALL | TYPE | STATUS | DETAILS |
+---------+--------------+---------+---------------------------+
| linkerd | Linkerd Mesh | Pending | enabled: true |
| | | | version: stable-2.3.0 |
| | | | namespace: linkerd |
| | | | mtls enabled: true |
| | | | auto inject enabled: true |
+---------+--------------+---------+---------------------------+
سپس ایستیو:
$ supergloo install istio --name istio --installation-namespace istio-system --mtls=true --auto-inject=true
+---------+------------+---------+---------------------------+
| INSTALL | TYPE | STATUS | DETAILS |
+---------+------------+---------+---------------------------+
| istio | Istio Mesh | Pending | enabled: true |
| | | | version: 1.0.6 |
| | | | namespace: istio-system |
| | | | mtls enabled: true |
| | | | auto inject enabled: true |
| | | | grafana enabled: true |
| | | | prometheus enabled: true |
| | | | jaeger enabled: true |
+---------+------------+---------+---------------------------+
چرخه تصادف چند دقیقه طول کشید و سپس پانل های کنترل تثبیت شدند.
(توجه: SuperGloo در حال حاضر فقط Istio 1.0.x را پشتیبانی می کند. آزمایش را با Istio 1.1.3 تکرار کردم، اما تفاوت محسوسی مشاهده نکردم.)
راه اندازی Istio Automatic Deployment
برای اینکه ایستیو انویی را نصب کند، از انژکتور سایدکار − استفاده می کنیم MutatingAdmissionWebhook
. ما در این مقاله در مورد آن صحبت نمی کنیم. فقط این را بگویم که این یک کنترلر است که دسترسی همه پادهای جدید را نظارت می کند و به صورت پویا یک sidecar و initContainer اضافه می کند که وظیفه وظایف را بر عهده دارد. iptables
.
ما در Shopify کنترلر دسترسی خود را برای پیاده سازی sidecars نوشتیم، اما برای این معیار من از کنترل کننده ای استفاده کردم که همراه با Istio است. هنگامی که یک میانبر در فضای نام وجود دارد، کنترلر به صورت پیش فرض، سایدکارها را تزریق می کند istio-injection: enabled
:
$ kubectl label namespace irs-client-dev istio-injection=enabled
namespace/irs-client-dev labeled
$ kubectl label namespace irs-server-dev istio-injection=enabled
namespace/irs-server-dev labeled
راه اندازی استقرار خودکار Linkerd
برای راه اندازی Linkerd sidecar embedding، از حاشیه نویسی استفاده می کنیم (من آنها را به صورت دستی از طریق اضافه کردم kubectl edit
):
metadata:
annotations:
linkerd.io/inject: enabled
$ k edit ns irs-server-dev
namespace/irs-server-dev edited
$ k get ns irs-server-dev -o yaml
apiVersion: v1
kind: Namespace
metadata:
annotations:
linkerd.io/inject: enabled
name: irs-server-dev
spec:
finalizers:
- kubernetes
status:
phase: Active
شبیه ساز تحمل خطا Istio
ما یک شبیه ساز تحمل خطا به نام Istio ساختیم تا ترافیک منحصر به فرد Shopify را آزمایش کند. ما به ابزاری برای ایجاد یک توپولوژی سفارشی نیاز داشتیم که بخش خاصی از گراف سرویس ما را نشان دهد که به صورت پویا برای مدلسازی بارهای کاری خاص پیکربندی شده است.
زیرساخت Shopify در هنگام فروش فلش تحت بار سنگینی قرار دارد. در همان زمان، Shopify
ما میخواستیم شبیهساز انعطافپذیری خود، جریانهای کاری را مدلسازی کند که با توپولوژیها و بارهای کاری که در گذشته زیرساخت Shopify را تحت تأثیر قرار داده است، مطابقت داشته باشد. هدف اصلی استفاده از سرویس مش این است که ما به قابلیت اطمینان و تحمل خطا در سطح شبکه نیاز داریم و برای ما مهم است که سرویس مش به طور موثر با بارهایی که قبلاً خدمات را مختل کرده است مقابله کند.
در قلب شبیه ساز تحمل خطا، یک گره کارگر قرار دارد که به عنوان یک گره مش سرویس عمل می کند. گره کارگر را می توان به صورت ایستا در هنگام راه اندازی یا به صورت پویا از طریق یک REST API پیکربندی کرد. ما از پیکربندی پویا گره های کارگر برای ایجاد گردش کار در قالب آزمون های رگرسیون استفاده می کنیم.
در اینجا نمونه ای از چنین فرآیندی آورده شده است:
- ما 10 سرور را راه اندازی می کنیم
bar
سرویسی که پاسخی را برمی گرداند200/OK
بعد از 100 میلی ثانیه - ما 10 مشتری راه اندازی می کنیم - هر کدام 100 درخواست در ثانیه به آنها ارسال می کند
bar
. - هر 10 ثانیه یک خطای سرور و مانیتور را حذف می کنیم
5xx
روی مشتری
در پایان گردش کار، لاگ ها و متریک ها را بررسی می کنیم و بررسی می کنیم که آیا آزمون قبول شده است یا خیر. به این ترتیب ما در مورد عملکرد مش سرویس خود یاد می گیریم و یک تست رگرسیون را برای آزمایش فرضیات خود در مورد تحمل خطا اجرا می کنیم.
(توجه: ما در حال فکر کردن به منبع باز شبیه ساز تحمل خطا Istio هستیم، اما هنوز برای انجام این کار آماده نیستیم.)
شبیه ساز تحمل خطا Istio برای معیار مش سرویس
ما چندین گره کاری شبیه ساز را راه اندازی کردیم:
irs-client-loadgen
: 3 کپی که در هر ثانیه 100 درخواست ارسال می کندirs-client
.irs-client
: 3 کپی که درخواست را دریافت می کنند، 100 میلی ثانیه صبر کنید و درخواست را به آن فوروارد کنیدirs-server
.irs-server
: 3 ماکت که برمی گردند200/OK
بعد از 100 میلی ثانیه
با این پیکربندی، میتوانیم یک جریان ترافیک پایدار بین ۹ نقطه پایانی را اندازهگیری کنیم. ماشین های جانبی در irs-client-loadgen
и irs-server
دریافت 100 درخواست در ثانیه، و irs-client
- 200 (ورودی و خروجی).
ما استفاده از منابع را از طریق پیگیری می کنیم
یافته ها
پانل های کنترل
ابتدا مصرف CPU را بررسی کردیم.
کنترل پنل Linkerd ~22 میلیکور
کنترل پنل ایستیو: ~750 میلیکور
کنترل پنل ایستیو تقریباً استفاده می کند 35 برابر بیشتر منابع CPUاز لینکرد البته همه چیز به صورت پیش فرض نصب شده است و istio-telemetry منابع پردازنده زیادی را در اینجا مصرف می کند (با غیرفعال کردن برخی از عملکردها می توان آن را غیرفعال کرد). اگر این جزء را حذف کنیم، باز هم بیش از 100 میلیکور میگیریم، یعنی 4 برابر بیشتراز لینکرد
پراکسی سایدکار
سپس استفاده از پروکسی را آزمایش کردیم. باید یک رابطه خطی با تعداد درخواست ها وجود داشته باشد، اما برای هر سایدکار مقداری سربار وجود دارد که روی منحنی تاثیر می گذارد.
لینک: 100 میلیکور برای irs-client، ~50 میلیکور برای irs-client-loadgen
نتایج منطقی به نظر می رسند، زیرا پروکسی مشتری دو برابر پراکسی loadgen ترافیک دریافت می کند: برای هر درخواست خروجی از loadgen، مشتری یک ورودی و یک خروجی دارد.
Istio/Envoy: ~ 155 میلی کور برای irs-client، ~ 75 میلی کور برای irs-client-loadgen
ما نتایج مشابهی را برای سایدکارهای ایستیو می بینیم.
اما به طور کلی پروکسی های ایستیو/انوی مصرف می کنند تقریباً 50٪ منابع CPU بیشتراز لینکرد
ما همان طرح را در سمت سرور می بینیم:
پیوند دهنده: ~50 میلیکور برای irs-server
Istio/Envoy: ~80 میلیکور برای irs-server
در سمت سرور، Sidecar Istio/Envoy مصرف می کند تقریباً 60٪ منابع CPU بیشتراز لینکرد
نتیجه
پروکسی Istio Envoy در حجم کار شبیه سازی شده ما، 50+٪ CPU بیشتری نسبت به Linkerd مصرف می کند. کنترل پنل Linkerd نسبت به Istio منابع بسیار کمتری مصرف می کند، به خصوص برای اجزای اصلی.
ما همچنان به این فکر می کنیم که چگونه این هزینه ها را کاهش دهیم. اگر ایده ای دارید، لطفا به اشتراک بگذارید!
منبع: www.habr.com