Мерило потрошње ЦПУ-а за Истио и Линкерд

Увод

Унутра смо Схопифи почео да примењује Истио као сервисну мрежу. У принципу, све је у реду, осим једне ствари: скуп је.

В објављена мерила за Истио каже:

Са Истио 1.1, прокси троши приближно 0,6 вЦПУ-а (виртуелних језгара) на 1000 захтева у секунди.

За први регион у сервисној мрежи (2 проксија са сваке стране везе), имаћемо 1200 језгара само за прокси, по стопи од милион захтева у секунди. Према Гоогле-овом калкулатору трошкова, испада да је око 40 УСД месечно по језгру за конфигурацију n1-standard-64, односно само овај регион коштаће нас више од 50 хиљада долара месечно за милион захтева у секунди.

Иван Сим (Иван Сим) визуелно упоредити сервисна мрежа каснила прошле године и обећала исто за меморију и процесор, али није успело:

Очигледно, валуес-истио-тест.иамл ће озбиљно повећати ЦПУ захтеве. Ако сам добро урадио своју математику, потребно вам је отприлике 24 ЦПУ језгра за контролну таблу и 0,5 ЦПУ-а за сваки прокси. Немам толико. Поновићу тестове када ми буде додељено више средстава.

Желео сам да се лично уверим колико су перформансе Истио-а сличне другој мрежи отвореног кода: Линкерд.

Уградња сервисне мреже

Пре свега, инсталирао сам га у кластер СуперГлоо:

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

Користио сам СуперГлоо јер то олакшава покретање сервисне мреже. Нисам морао много да радим. СуперГлоо не користимо у производњи, али је идеалан за такав задатак. Морао сам да користим буквално неколико команди за сваку сервисну мрежу. Користио сам два кластера за изолацију - по један за Истио и Линкерд.

Експеримент је спроведен на Гоогле Кубернетес Енгине-у. Користио сам Кубернетес 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      |
+---------+------------+---------+---------------------------+

Петља судара је трајала неколико минута, а затим су се контролне табле стабилизовале.

(Напомена: СуперГлоо за сада подржава само Истио 1.0.к. Поновио сам експеримент са Истио 1.1.3, али нисам приметио никакву приметну разлику.)

Подешавање Истио аутоматске имплементације

Да бисмо натерали Истио да инсталира Енвои бочне приколице, користимо ињектор бочне приколице − MutatingAdmissionWebhook. Нећемо о томе говорити у овом чланку. Само да кажем да је ово контролер који надгледа приступ свим новим подовима и динамички додаје сидецар и инитЦонтаинер, који је одговоран за задатке iptables.

Ми у Схопифи-у смо написали сопствени контролер приступа за имплементацију бочних приколица, али за овај бенцхмарк користио сам контролер који долази уз Истио. Контролер подразумевано убацује приколице када постоји пречица у именском простору 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

Подешавање аутоматског постављања Линкерд-а

Да бисмо подесили уграђивање Линкерд сидецар-а, користимо напомене (додао сам их ручно преко 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

Истио симулатор толеранције грешака

Направили смо симулатор толеранције грешака под називом Истио да бисмо експериментисали са саобраћајем јединственим за Схопифи. Требао нам је алат за креирање прилагођене топологије која би представљала одређени део нашег графа услуге, динамички конфигурисан за моделирање специфичних радних оптерећења.

Схопифи-јева инфраструктура је под великим оптерећењем током флеш продаје. Истовремено, Схопифи препоручује продавцима да чешће одржавају такве распродаје. Велики купци понекад упозоравају на планирану распродају. Други их спроводе неочекивано за нас у било које доба дана и ноћи.

Желели смо да наш симулатор отпорности моделира токове посла који одговарају топологијама и радним оптерећењима која су преплавила Схопифи-ову инфраструктуру у прошлости. Основна сврха коришћења сервисне мреже је да нам је потребна поузданост и толеранција грешака на нивоу мреже, а за нас је важно да се сервисна мрежа ефикасно носи са оптерећењима која су претходно пореметила услуге.

У срцу симулатора толеранције грешака је радни чвор, који делује као сервисни мрежни чвор. Радни чвор се може конфигурисати статички при покретању или динамички преко РЕСТ АПИ-ја. Користимо динамичку конфигурацију радних чворова за креирање радних токова у облику регресионих тестова.

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

• Покрећемо 10 сервера као bar сервис који враћа одговор 200/OK после 100 мс.
• Покрећемо 10 клијената - сваки шаље 100 захтева у секунди bar.
• Сваких 10 секунди уклањамо 1 сервер и пратимо грешке 5xx на клијента.

На крају тока рада испитујемо евиденције и метрике и проверавамо да ли је тест прошао. Овако учимо о перформансама наше сервисне мреже и покрећемо регресијски тест да бисмо тестирали наше претпоставке о толеранцији грешака.

(Напомена: Размишљамо о отвореном извору Истио симулатора толеранције грешака, али још нисмо спремни за то.)

Истио симулатор толеранције грешака за бенцхмарк сервисне мреже

Поставили смо неколико радних чворова симулатора:

• irs-client-loadgen: 3 реплике које шаљу 100 захтева у секунди по irs-client.
• irs-client: 3 реплике које приме захтев, сачекају 100мс и проследе захтев на irs-server.
• irs-server: 3 реплике које се враћају 200/OK после 100 мс.

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

Пратимо коришћење ресурса ДатаДогјер немамо Прометејев кластер.

Налази

Контролне табле

Прво смо испитали потрошњу процесора.

Линкерд контролни панел ~22 милицоре

Истио контролна табла: ~750 милицоре

Истио контролна табла користи приближно 35 пута више ЦПУ ресурсанего Линкерд. Наравно, све је подразумевано инсталирано, а истио-телеметрија овде троши много процесорских ресурса (може се онемогућити онемогућавањем неких функција). Ако уклонимо ову компоненту, и даље добијамо више од 100 милиликора, тј 4 пута вишенего Линкерд.

Сидецар проки

Затим смо тестирали употребу проксија. Требало би да постоји линеарна веза са бројем захтева, али за сваку приколицу постоје неки додатни трошкови који утичу на криву.

Веза: ~100 миликора за ИРС-цлиент, ~50 миликора за ИРС-цлиент-лоадген

Резултати изгледају логично, јер клијентски прокси прима двоструко више саобраћаја од лоадген проксија: за сваки одлазни захтев од лоадген-а, клијент има један долазни и један одлазни.

Истио/Енвои: ~155 миликора за ИРС-цлиент, ~75 миликора за ИРС-цлиент-лоадген

Видимо сличне резултате за Истио бочне приколице.

Али генерално, Истио/Енвои проксији троше приближно 50% више ЦПУ ресурсанего Линкерд.

Видимо исту шему на страни сервера:

Веза: ~50 милицоре за ИРС-сервер

Истио/Енвои: ~80 милицоре за ИРС-сервер

На страни сервера троши Истио/Енвои бочна колица приближно 60% више ЦПУ ресурсанего Линкерд.

Закључак

Истио Енвои проки троши 50+% више ЦПУ-а него Линкерд на нашем симулираном радном оптерећењу. Линкерд контролна табла троши много мање ресурса него Истио, посебно за основне компоненте.

Још размишљамо како да смањимо ове трошкове. Ако имате идеје, поделите их!

Извор: ввв.хабр.цом