Istio жана Linkerd үчүн CPU керектөө эталону

тааныштыруу

биз Shopify Istio кызматтык тор катары жайылта баштады. Негизи, баары жакшы, бир нерседен башкасы: бул кымбат.

В көрсөткүчтөрү жарыяланган Istio үчүн мындай дейт:

Istio 1.1 менен прокси секундасына 0,6 суроо-талапка болжол менен 1000 vCPU (виртуалдык өзөктөр) керектейт.

Кызмат тармагындагы биринчи аймак үчүн (туташкандын ар бир тарабында 2 прокси) бизде секундасына бир миллион суроо ылдамдыгы менен прокси үчүн 1200 өзөк болот. Google'дун чыгаша калькуляторуна ылайык, конфигурациялоо үчүн ал болжол менен айына 40 долларды түзөт. n1-standard-64, башкача айтканда, бул аймак эле секундасына 50 миллион суроо-талап үчүн бизге айына 1 миң доллардан ашык чыгымга учурайт.

Иван Сим (Иван Сим) визуалдык салыштыруу Кызмат торунун кечигүүлөрү былтыркы жана эстутум жана процессор үчүн да ушундай убадаланган, бирок андан майнап чыккан жок:

Кыязы, values-istio-test.yaml CPU суроо-талаптарын олуттуу түрдө көбөйтөт. Эгер мен математиканы туура аткарган болсом, башкаруу панели үчүн болжол менен 24 CPU өзөгү жана ар бир прокси үчүн 0,5 CPU керек. Менде андай көп жок. Мага көбүрөөк ресурстар бөлүнгөндө, мен тесттерди кайталайм.

Мен Истионун иштеши башка ачык булактуу тейлөө торуна канчалык окшош экенин өз көзүм менен көргүм келди: Linkerd.

Кызматтык тор орнотуу

Биринчиден, мен аны кластерге орноттум суперглоо:

$ 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 колдондум, анткени ал тейлөө тармагын жүктөөнү бир топ жеңилдетет. Мага көп иш кылуунун кереги жок болчу. Биз өндүрүштө SuperGloo колдонбойбуз, бирок ал мындай тапшырма үчүн идеалдуу. Мен ар бир кызматтык тор үчүн түзмө-түз бир нече буйруктарды колдонууга туура келди. Мен изоляция үчүн эки кластер колдондум - ар бири Istio жана Linkerd үчүн.

Эксперимент Google Kubernetes Engineде жүргүзүлгөн. Мен Kubernetes колдондум 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      |
+---------+------------+---------+---------------------------+

Краш-луп бир нече мүнөткө созулду, андан кийин башкаруу панелдери турукташты.

(Эскертүү: SuperGloo азырынча Istio 1.0.xти гана колдойт. Мен Istio 1.1.3 менен экспериментти кайталадым, бирок эч кандай байкаларлык айырманы байкаган жокмун.)

Istio Automatic Deployment орнотуу

Istio капталдагы Envoy орнотуу үчүн, биз каптал инжектор - колдонобуз MutatingAdmissionWebhook. Бул макалада биз бул тууралуу сөз кылбайбыз. Жөн эле айта кетейин, бул бардык жаңы подкасттардын жеткиликтүүлүгүн көзөмөлдөгөн жана тапшырмалар үчүн жооптуу болгон каптал жана initContainer динамикалык түрдө кошо турган контроллер. iptables.

Биз Shopify'да капталдарды ишке ашыруу үчүн өзүбүздүн кирүү контроллерубузду жаздык, бирок бул эталон үчүн мен Istio менен келген контроллерди колдондум. Контроллер аттар мейкиндигинде жарлык болгондо демейки боюнча капталдарды инъекциялайт 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 жайгаштырууну орнотуу

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 Fault Tolerance Simulator

Биз Shopify үчүн уникалдуу трафикти эксперимент кылуу үчүн Istio деп аталган каталарга чыдамдуулук симуляторун курдук. Бизге атайын иш жүктөмдөрүн моделдөө үчүн динамикалык конфигурацияланган, биздин кызмат графигибиздин белгилүү бир бөлүгүн чагылдырган ыңгайлаштырылган топологияны түзүү үчүн курал керек болчу.

Флеш сатуу учурунда Shopify инфраструктурасы оор жүктө. Ошол эле учурда, Shopify сатуучуларга мындай сатууларды тез-тез өткөрүүгө сунуш кылат. Ири кардарлар кээде пландаштырылган флеш сатуу жөнүндө эскертишет. Башкалар аларды биз үчүн күнү-түнү каалаган убакта күтүүсүздөн өткөрүшөт.

Биз ийкемдүүлүк симуляторубуздан мурун Shopify инфраструктурасын басып алган топологияларга жана жумуш жүктөмөлөрүнө дал келген жумуш процесстерин моделдештирүүнү кааладык. Кызматтык торду колдонуунун негизги максаты - бизге тармак деңгээлинде ишенимдүүлүк жана каталарга чыдамдуулук керек жана биз үчүн сервистик тор мурда кызматтарды үзгүлтүккө учураткан жүктөрдү натыйжалуу көтөрүшү маанилүү.

Мүчүлүштүккө чыдамдуулук симуляторунун өзөгүндө жумушчу түйүн турат, ал тейлөөчү тор түйүн катары иштейт. Жумушчу түйүн ишке киргизүүдө статикалык же REST API аркылуу динамикалык түрдө конфигурацияланышы мүмкүн. Биз жумушчу түйүндөрүнүн динамикалык конфигурациясын регрессиялык тесттер түрүндө иш процесстерин түзүү үчүн колдонобуз.

Мына ушундай процесстин мисалы:

• катары 10 серверди ишке киргизебиз bar жооп кайтарган кызмат 200/OK 100 мс кийин.
• Биз 10 кардарды ишке киргизебиз - ар бири секундасына 100 суроо-талап жөнөтөт bar.
• Ар 10 секунд сайын биз 1 серверди өчүрүп, каталарды көзөмөлдөйбүз 5xx кардар боюнча.

Иш процессинин аягында биз журналдарды жана метрикаларды карап чыгып, тесттен өткөн-өтпөгөнүн текшеребиз. Ушундай жол менен биз кызматтык торубуздун иштеши жөнүндө билебиз жана катага чыдамкайлык жөнүндө божомолдорубузду текшерүү үчүн регрессиялык тестти өткөрөбүз.

(Эскертүү: Биз Istio катачылыкка чыдамкайлык симуляторун ачык булактардан алуу жөнүндө ойлонуп жатабыз, бирок азырынча даяр эмеспиз.)

Кызмат сетка эталон үчүн Istio катага чыдамдуу симулятор

Биз симулятордун бир нече жумушчу түйүндөрүн орнотуп жатабыз:

• 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 (кирүүчү жана чыгуучу).

Биз ресурстун колдонулушун көзөмөлдөйбүз DataDogанткени бизде Прометей кластери жок.

натыйжалары

башкаруу панели

Биринчиден, биз CPU керектөөсүн карап чыктык.

Linkerd башкаруу панели ~ 22 миллиcore

Istio башкаруу панели: ~ 750 millicore

Istio башкаруу панели болжол менен колдонот 35 эсе көп CPU ресурстарыLinkerd караганда. Албетте, баары демейки боюнча орнотулган жана истио-телеметрия бул жерде көп CPU ресурстарын сарптайт (айрым функцияларды өчүрүү менен аны өчүрүүгө болот). Бул компонентти алып салсак, биз дагы эле 100 милликордон ашык алабыз, башкача айтканда 4 эсегеLinkerd караганда.

Sidecar прокси

Андан кийин прокси колдонууну сынап көрдүк. Сурамдардын саны менен сызыктуу байланыш болушу керек, бирок ар бир каптал үчүн ийри сызыкка таасир этүүчү кошумча чыгымдар бар.

Linkerd: irs-кардар үчүн ~100 милликор, irs-client-loadgen үчүн ~50 милликор

Натыйжалар логикалык көрүнөт, анткени кардар проксиси loadgen проксиге караганда эки эсе көп трафикти алат: loadgenдин ар бир чыгуучу суроо-талабы үчүн кардар бир кирүүчү жана бир чыгуучуга ээ.

Istio/Envoy: irs-кардар үчүн ~155 милликор, irs-client-loadgen үчүн ~75 милликор

Биз Istio sidecars үчүн окшош натыйжаларды көрүп жатабыз.

Бирок жалпысынан, Istio/Envoy проксилери керектешет болжол менен 50% көбүрөөк CPU ресурстарыLinkerd караганда.

Ошол эле схеманы сервер тарапта көрүп жатабыз:

Linkerd: irs-сервер үчүн ~50 миллиcore

Istio/Envoy: irs-сервер үчүн ~80 милликор

Сервер тарапта, Istio/Envoy капталдары керектейт болжол менен 60% көбүрөөк CPU ресурстарыLinkerd караганда.

жыйынтыктоо

Istio Envoy проксиси биздин симуляцияланган иш жүгүбүздө Linkerdге караганда 50+% көбүрөөк CPU керектейт. Linkerd башкаруу панели, айрыкча, негизги компоненттери үчүн, Istio караганда алда канча аз ресурстарды керектейт.

Бул чыгымдарды кантип кыскартсак болот деп дагы эле ойлонуп жатабыз. Идеяларыңыз болсо бөлүшүңүз!

Source: www.habr.com