Вовед
Ние сме во почна да го распоредува Istio како сервисна мрежа. Во принцип, сè е во ред, освен една работа: скапо е.
В за Истио вели:
Со Istio 1.1, проксито троши приближно 0,6 vCPU (виртуелни јадра) на 1000 барања во секунда.
За првиот регион во сервисната мрежа (2 прокси на секоја страна од врската), ќе имаме 1200 јадра само за прокси, со брзина од еден милион барања во секунда. Според калкулаторот за трошоци на Google, се чини дека е приближно 40 долари/месец/јадро за конфигурација n1-standard-64, односно само овој регион ќе не чини повеќе од 50 илјади долари месечно за 1 милион барања во секунда.
Иван Сим () Сервисната мрежа доцни минатата година и го вети истото за меморијата и процесорот, но не успеа:
Очигледно, values-istio-test.yaml сериозно ќе ги зголеми барањата за процесорот. Ако ја направив мојата математика правилно, потребни ви се приближно 24 јадра на процесорот за контролната табла и 0,5 процесор за секој прокси. Немам толку многу. Ќе ги повторам тестовите кога ќе ми бидат доделени повеќе ресурси.
Сакав сам да видам колку перформансите на Istio се слични со друга мрежа за услуги со отворен код: .
Инсталација на сервисна мрежа
Прво, го инсталирав во кластер :
$ 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 во производството, но е идеален за таква задача. Морав да користам буквално неколку команди за секоја сервисна мрежа. Користев два кластери за изолација - по еден за Истио и Линкерд.
Експериментот беше спроведен на 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 автоматско распоредување
За да го натераме 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
Направивме симулатор за толеранција на грешки наречен Istio за да експериментираме со сообраќај единствен за Shopify. Ни требаше алатка за да создадеме приспособена топологија која ќе претставува специфичен дел од нашиот графикон за услуги, динамички конфигуриран да моделира специфични оптоварувања.
Инфраструктурата на Shopify е под големо оптоварување за време на флеш-продажбите. Во исто време, Shopify . Големите клиенти понекогаш предупредуваат за планирана флеш-продажба. Други ги спроведуваат неочекувано за нас во секое време од денот или ноќта.
Сакавме нашиот симулатор за еластичност да моделира работни текови што одговараат на топологиите и оптоварувањата што ја преплавија инфраструктурата на Shopify во минатото. Главната цел на користењето на сервисната мрежа е дека ни треба доверливост и толеранција на грешки на ниво на мрежа и за нас е важно сервисната мрежа ефикасно да се справува со оптоварувањата кои претходно ги прекинале услугите.
Во срцето на симулаторот за толеранција на грешки е работник јазол, кој делува како сервисен мрежен јазол. Работничкиот јазол може да се конфигурира статички при стартување или динамички преку REST API. Ние користиме динамична конфигурација на работнички јазли за да креираме работни текови во форма на тестови за регресија.
Еве пример за таков процес:
- Лансираме 10 сервери како
barуслуга која враќа одговор200/OKпо 100 ms. - Лансираме 10 клиенти - секој испраќа по 100 барања во секунда до
bar. - На секои 10 секунди отстрануваме 1 сервер и мониторинг грешки
5xxна клиентот.
На крајот од работниот тек, ги испитуваме дневниците и метриката и проверуваме дали тестот поминал. На овој начин учиме за перформансите на нашата сервисна мрежа и спроведуваме тест за регресија за да ги тестираме нашите претпоставки за толеранција на грешки.
(Забелешка: Размислуваме за отворени извори на симулаторот за толеранција на грешки Istio, но сè уште не сме подготвени да го сториме тоа.)
Симулатор за толеранција на грешки Istio за репер за сервисна мрежа
Поставивме неколку работни јазли на симулаторот:
irs-client-loadgen: 3 реплики кои испраќаат 100 барања во секунда во секундаirs-client.irs-client: 3 реплики кои го примаат барањето, почекајте 100ms и препратете го барањето доirs-server.irs-server: 3 реплики кои се враќаат200/OKпо 100 ms.
Со оваа конфигурација, можеме да измериме стабилен проток на сообраќај помеѓу 9 крајни точки. Странични коли во irs-client-loadgen и irs-server добиваат 100 барања во секунда, и irs-client — 200 (дојдовни и појдовни).
Ние го следиме користењето на ресурсите преку затоа што немаме кластер Прометеј.
Наоди
Контролни панели
Прво, ја испитавме потрошувачката на процесорот.
Линкерд контролен панел ~22 миликори
Istio контролен панел: ~ 750 миликори
Контролната табла Istio користи приближно 35 пати повеќе ресурси на процесорототколку Линкерд. Се разбира, сè е стандардно инсталирано, а istio-telemetry троши многу ресурси на процесорот овде (може да се оневозможи со оневозможување на некои функции). Ако ја отстраниме оваа компонента, сепак добиваме повеќе од 100 миликори, т.е 4 пати повеќеотколку Линкерд.
Прокси за странична кола
Потоа ја тестиравме употребата на прокси. Треба да има линеарна врска со бројот на барања, но за секоја странична кола има некои надземни трошоци што влијае на кривата.
Линкерд: ~ 100 миликори за irs-client, ~50 миликори за irs-client-loadgen
Резултатите изгледаат логично, бидејќи клиентот прокси добива двојно повеќе сообраќај од проксито за вчитување: за секое појдовно барање од loadgen, клиентот има еден дојдовен и еден појдовен.
Istio/Envoy: ~155 миликори за irs-client, ~75 millicores за irs-client-loadgen
Гледаме слични резултати за страничните коли Istio.
Но, генерално, полномошниците на Istio/Envoy консумираат приближно 50% повеќе ресурси на процесорототколку Линкерд.
Ја гледаме истата шема на страната на серверот:
Линкерд: ~ 50 миликори за irs-сервер
Istio/Envoy: ~80 миликори за irs-сервер
На страната на серверот, страничната кола Istio/Envoy троши приближно 60% повеќе ресурси на процесорототколку Линкерд.
Заклучок
Проксито на Istio Envoy троши 50+% повеќе процесор од Linkerd на нашиот симулиран обем на работа. Контролната табла на Linkerd троши многу помалку ресурси од Istio, особено за основните компоненти.
Сè уште размислуваме како да ги намалиме овие трошоци. Ако имате идеи, ве молиме споделете!
Извор: www.habr.com