Бенчмарк за потребление на ЦП за Istio и Linkerd

Въведение

Ние в Shopify започнахме внедряването на Istio като service mesh. В принципе всичко е наред, освен една вещ: това е скъпо.

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

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

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

Айвен Сим (Ivan Sim) нагледно сравни закъсненията на service mesh миналата година и обеща същото за памет и процесор, но не успя:

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

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

Инсталиране на service mesh

Първото нещо, което направих, беше да инсталирам в кластера SuperGloo:

$ supergloo init
инсталиране на supergloo версия 0.3.12
използвайки chart uri https://storage.googleapis.com/supergloo-helm/charts/supergloo-0.3.12.tgz
configmap/sidecar-injection-resources създаден
serviceaccount/supergloo създаден
serviceaccount/discovery създаден
serviceaccount/mesh-discovery създаден
clusterrole.rbac.authorization.k8s.io/discovery създаден
clusterrole.rbac.authorization.k8s.io/mesh-discovery създаден
clusterrolebinding.rbac.authorization.k8s.io/supergloo-role-binding създаден
clusterrolebinding.rbac.authorization.k8s.io/discovery-role-binding създаден
clusterrolebinding.rbac.authorization.k8s.io/mesh-discovery-role-binding създаден
deployment.extensions/supergloo създаден
deployment.extensions/discovery създаден
deployment.extensions/mesh-discovery създаден
инсталацията е успешна!

Използвах SuperGloo, защото значително улеснява началното зареждане на service mesh. Почти не ми се наложи да правя нищо. В продукция не използваме SuperGloo, но за подобна задача той е абсолютно подходящ. Наложи се да приложа буквално няколко команди за всяка service mesh. Използвах два клъстера за изолация - по един за Istio и Linkerd.

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

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

Първо 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      |
+---------+------------+---------+---------------------------+

Crash-loop отне няколко минути, след което контролният панел се стабилизира.

(Бележка. SuperGloo в момента поддържа само Istio 1.0.x. Повторих експеримента с Istio 1.1.3, но не забелязах никаква съществена разлика.)

Настройка на автоматично внедряване на Istio

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

Ние в Shopify написахме свой контролер за достъп за внедряване на sidecar, но за този бенчмарк използвах контролера, който идва с Istio. Контролерът по подразбиране внедрява sidecar, когато в пространството на имената има етикет 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

За да настроим внедряването на sidecar на Linkerd, използваме анотации (добавих ги ръчно чрез 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 в миналото. Основната цел на използването на service mesh — ни е нужна надеждност и устойчивост на нивото на мрежата, и ни е важно service mesh ефективно да се справя с натоварванията, които преди са нарушавали работата на сервисите.

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

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

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

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

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

Симулатор на устойчивост на Istio за бенчмарк на service mesh

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

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

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

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

Резултати

Панели за управление

Първо проучихме потреблението на ЦП.

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

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

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

Proxy на Sidecar

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

Linkerd: ~100 милиарда за irs-client, ~50 милиарда за irs-client-loadgen

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

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

Виждаме подобни резултати за sidecar-ите на Istio.

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

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

Linkerd: ~50 милиарда за irs-server

Istio/Envoy: ~80 милиарда за irs-server

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

Заключение

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

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

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