Бенчмарк споживання ЦП для 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
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, тому що він значно спрощує початкове завантаження service mesh. Мені майже нічого не довелося робити. У продакшені ми не використовуємо SuperGloo, але для такого завдання він підходить ідеально. Довелося застосувати буквально пару команд на кожну службу mesh. Я використовував два кластери для ізоляції - по одному для Istio та Linkerd.

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

Потім я встановив обидві служби 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. Ми не говоритимемо про нього у цій статті. Скажу тільки, що це контролер, який стежить за доступом усіх нових 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. Робочий вузол можна настроїти статично під час запуску або динамічно через API REST. Ми використовуємо динамічне налаштування робочих вузлів, щоб створювати робочі процеси як регресивних тестів.

Ось приклад такого процесу:

• Запускаємо 10 серверів як bar сервісу, який повертає відповідь 200/OK через 100 мс.
• Запускаємо 10 клієнтів — кожен надсилає 100 запитів на секунду до bar.
• Кожні 10 секунд прибираємо 1 сервер, моніторимо помилки 5xx на клієнта.

Наприкінці робочого процесу ми вивчаємо логи та метрики та перевіряємо, чи пройдено тест. Так ми дізнаємося про продуктивність нашої service mesh і проводимо регресивний тест, щоб перевірити наші припущення про стійкість до відмови.

(Примітка. Ми подумуємо відкрити вихідний код симулятора відмови стійкості Istio, але ще не готові до цього.)

Симулятор відмовостійкості Istio для бенчмарку

Ми налаштовуємо кілька робочих нод симулятора:

• 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.

Sidecar проксі

Потім ми перевірили використання проксі. Тут має бути лінійна залежність від кількості запитів, але для кожного sidecar-а є деякі накладні витрати, які впливають на криву.

Linkerd: ~100 міліядер для irs-client, ~50 міліядер для irs-client-loadgen

Результати виглядають логічно, адже проксі client отримує вдвічі більше трафіку, ніж проксі loadgen: на кожен вихідний запит від loadgen у client припадає один вхідний та один вихідний.

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

Ми все ще думаємо про те, як скоротити ці витрати. Якщо у вас є ідеї, поділіться!

Джерело: habr.com