Увядзенне
мы ў заняліся разгортваннем Istio у якасці service mesh. У прынцыпе ўсё задавальняе, акрамя адной рэчы: гэта дорага.
В для Istio гаворыцца:
З Istio 1.1 проксі спажывае прыкладна 0,6 vCPU (віртуальных ядраў) на 1000 запытаў у секунду.
Для першага рэгіёну ў service mesh (па 2 проксі з кожнага боку злучэння) у нас будзе 1200 ядраў толькі для проксі, з разліку 40 запытаў у секунду. Згодна з калькулятарам кошту ад Google атрымліваецца прыкладна $XNUMX/месяц/ядро для канфігурацыі. n1-standard-64, гэта значыць адзін гэты рэгіён будзе каштаваць нам больш за 50 тыс. даляраў у месяц за 1 млн запытаў у секунду.
Айвен Сім () затрымкі service mesh у мінулым годзе і абяцаў тое ж самае для памяці і працэсара, але не атрымалася:
Судзячы па ўсім, values-istio-test.yaml сур'ёзна павялічыць запыты да працэсара. Калі я ўсё правільна палічыў, трэба прыкладна 24 працэсарных ядра для панэлі кіравання і 0,5 ЦП для кожнага проксі. У мяне столькі няма. Я паўтару тэсты, калі мне выдзеляць больш рэсурсаў.
Я жадаў сам пераканацца, наколькі паказчыкі Istio падобныя з іншай service mesh з адчыненым кодам: .
Устаноўка service mesh
Перш за ўсё я ўсталяваў у кластары :
$ 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, але для падобнай задачы ён падыходзіць ідэальна. Прыйшлося ўжыць літаральна пару каманд на кожную 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. Мы не будзем казаць аб ім у гэтым артыкуле. Скажу толькі, што гэта кантролер, які сочыць за доступам усіх новых 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 (ўваходныя і выходныя).
Мы адсочваем выкарыстанне рэсурсаў праз , таму што ў нас няма кластара 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