Бенчмарк за консумация на процесора за Istio и Linkerd

въведение

Вътре сме Shopify започна да внедрява Istio като сервизна мрежа. По принцип всичко е наред, с изключение на едно нещо: скъпо е.

В публикувани бенчмаркове за Istio пише:

С Istio 1.1 проксито консумира приблизително 0,6 vCPU (виртуални ядра) на 1000 заявки в секунда.

За първия регион в мрежата на услугата (2 проксита от всяка страна на връзката) ще имаме 1200 ядра само за проксито, при скорост от един милион заявки в секунда. Според калкулатора на разходите на Google, това струва приблизително $40/месец/ядро за конфигурация n1-standard-64, тоест само този регион ще ни струва повече от 50 хиляди долара на месец за 1 милион заявки в секунда.

Иван Сим (Иван Сим) визуално сравнени service mesh забави миналата година и обеща същото за паметта и процесора, но не се получи:

Очевидно values-istio-test.yaml ще увеличи сериозно заявките на процесора. Ако съм направил правилно изчисленията си, имате нужда от приблизително 24 CPU ядра за контролния панел и 0,5 CPU за всяко прокси. Нямам толкова много. Ще повторя тестовете, когато ми бъдат разпределени повече ресурси.

Исках сам да видя колко подобно е представянето на Istio на друга услуга с отворен код: Linkerd.

Сервизен монтаж на мрежи

Първо, инсталирах го в клъстер 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 в производството, но е идеален за такава задача. Трябваше да използвам буквално няколко команди за всяка сервизна мрежа. Използвах два клъстера за изолация - по един за Istio и Linkerd.

Експериментът е проведен на Google Kubernetes Engine. Използвах Kubernetes 1.12.7-gke.7 и набор от възли n1-standard-4 с автоматично мащабиране на възли (минимум 4, максимум 16).

След това инсталирах и двете сервизни мрежи от командния ред.

Първи Linkerd:

$ 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 |
+---------+--------------+---------+---------------------------+

Тогава Istio:

$ 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

За да накараме Istio да инсталира коша Envoy, ние използваме инжектора за кош - MutatingAdmissionWebhook. Няма да говорим за това в тази статия. Нека само да кажа, че това е контролер, който следи достъпа на всички нови подове и динамично добавя странична кола и initContainer, който отговаря за задачите iptables.

Ние от Shopify написахме наш собствен контролер за достъп, за да внедрим странични коли, но за този бенчмарк използвах контролера, който идва с 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, използваме анотации (добавих ги ръчно чрез 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 Fault Tolerance Simulator

Създадохме симулатор за устойчивост на грешки, наречен Istio, за да експериментираме с уникален за Shopify трафик. Имахме нужда от инструмент за създаване на персонализирана топология, която да представлява конкретна част от нашата графика на услугата, динамично конфигурирана да моделира специфични работни натоварвания.

Инфраструктурата на Shopify е под голямо натоварване по време на флаш разпродажби. В същото време Shopify препоръчва на продавачите да провеждат такива продажби по-често. Големите клиенти понякога предупреждават за планирана бърза продажба. Други ги провеждат неочаквано за нас по всяко време на деня и нощта.

Искахме нашият симулатор на устойчивост да моделира работни потоци, които съответстват на топологиите и натоварванията, които са претоварвали инфраструктурата на Shopify в миналото. Основната цел на използването на мрежова мрежа за услуги е, че се нуждаем от надеждност и устойчивост на грешки на мрежово ниво и за нас е важно мрежовата мрежа за услуги да се справя ефективно с натоварвания, които преди това са прекъсвали услугите.

В сърцето на симулатора за устойчивост на грешки е работен възел, който действа като сервизен мрежов възел. Работният възел може да бъде конфигуриран статично при стартиране или динамично чрез REST API. Използваме динамична конфигурация на работни възли, за да създаваме работни потоци под формата на регресионни тестове.

Ето пример за такъв процес:

• Пускаме 10 сървъра като bar услуга, която връща отговор 200/OK след 100 ms.
• Пускаме 10 клиента - всеки изпраща 100 заявки в секунда до bar.
• На всеки 10 секунди премахваме 1 сървър и наблюдаваме грешки 5xx на клиента.

В края на работния процес проверяваме регистрационните файлове и показателите и проверяваме дали тестът е преминал. По този начин ние научаваме за производителността на нашата сервизна мрежа и провеждаме регресионен тест, за да проверим нашите допускания относно толерантността към грешки.

(Забележка: Обмисляме отваряне на симулатора за устойчивост на грешки Istio, но все още не сме готови да го направим.)

Симулатор на толерантност към грешки на Istio за бенчмарк на мрежата на услугата

Настроихме няколко работни възела на симулатора:

• irs-client-loadgen: 3 реплики, които изпращат 100 заявки в секунда на irs-client.
• irs-client: 3 реплики, които получават заявката, изчакват 100ms и препращат заявката на irs-server.
• irs-server: 3 реплики, които се връщат 200/OK след 100 ms.

С тази конфигурация можем да измерим стабилен трафик между 9 крайни точки. Странични колички в irs-client-loadgen и irs-server получават 100 заявки в секунда и irs-client — 200 (входящи и изходящи).

Проследяваме използването на ресурси чрез DataDogзащото нямаме клъстер Прометей.

резултати

Контролни панели

Първо, проверихме консумацията на процесора.

Контролен панел на Linkerd ~22 милиядра

Istio контролен панел: ~750 милиядра

Контролният панел Istio използва приблизително 35 пъти повече процесорни ресурсиотколкото Linkerd. Разбира се, всичко е инсталирано по подразбиране и istio-telemetry консумира много ресурси на процесора тук (може да бъде деактивирано чрез деактивиране на някои функции). Ако премахнем този компонент, пак получаваме повече от 100 миликора, т.е 4 пъти повечеотколкото Linkerd.

Sidecar прокси

След това тествахме използването на прокси. Трябва да има линейна връзка с броя на заявките, но за всяка странична количка има някои допълнителни разходи, които влияят на кривата.

Linkerd: ~100 милиядрени за irs-клиент, ~50 милиядрени за irs-client-loadgen

Резултатите изглеждат логични, тъй като проксито на клиента получава два пъти повече трафик от проксито на loadgen: за всяка изходяща заявка от loadgen клиентът има една входяща и една изходяща.

Istio/Envoy: ~155 милиядра за irs-client, ~75 милиядра за irs-client-loadgen

Виждаме подобни резултати за кошовете на Istio.

Но като цяло прокситата Istio/Envoy консумират приблизително 50% повече процесорни ресурсиотколкото Linkerd.

Виждаме същата схема от страната на сървъра:

Linkerd: ~50 millicore за irs-сървър

Istio/Envoy: ~80 millicore за irs-сървър

От страна на сървъра, страничният автомобил Istio/Envoy консумира приблизително 60% повече процесорни ресурсиотколкото Linkerd.

Заключение

Проксито Istio Envoy консумира 50+% повече CPU от Linkerd при нашето симулирано работно натоварване. Контролният панел на Linkerd консумира много по-малко ресурси от Istio, особено за основните компоненти.

Все още мислим как да намалим тези разходи. Ако имате идеи, моля споделете!

Източник: www.habr.com