معیار مصرف CPU برای Istio و Linkerd

معرفی

ما در Shopify شروع به استقرار ایستیو به عنوان یک سرویس مش کرد. در اصل، همه چیز خوب است، به جز یک چیز: گرونه.

В معیارهای منتشر شده برای ایستیو می گوید:

با 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:

$ 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 (ورودی و خروجی).

ما استفاده از منابع را از طریق پیگیری می کنیم DataDogچون ما خوشه پرومتئوس نداریم.

یافته ها

پانل های کنترل

ابتدا مصرف 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