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

Бенчмарк за потребление на ЦП за 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 до другата open source 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 създаден
dependency.extensions/supergloo създаден
dependency.extensions/discovery създаден
dependency.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      |
+---------+------------+---------+---------------------------+

Краш-цикл занял несколько минут, а затем панели управления стабилизировались.

(Примечание. SuperGloo пока поддерживает только Istio 1.0.x. Я повторил эксперимент с Istio 1.1.3, но никакой ощутимой разницы не заметил.)

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

Чтобы Istio установил sidecar Envoy, мы используем sidecar-инжектор — MutatingAdmissionWebhook. Мы не будем говорить о нем в этой статье. Скажу только, что это контроллер, который следит за доступом всех новых pod’ов и динамически добавляет 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.

Резултати

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

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

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

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

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

Sidecar проксита

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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