Кіріспе
Біз кіреміз Istio-ны қызмет көрсету торы ретінде қолдана бастады. Негізінде бәрі жақсы, тек бір нәрсені қоспағанда: Бұл қымбат.
В Istio үшін ол былай дейді:
Istio 1.1 көмегімен прокси секундына 0,6 сұрау үшін шамамен 1000 vCPU (виртуалды ядролар) тұтынады.
Қызметтік тордағы бірінші аймақ үшін (қосылымның әр жағында 2 прокси) бізде секундына бір миллион сұрау жылдамдығымен проксиге арналған 1200 ядро болады. Google құны калькуляторына сәйкес, ол конфигурация үшін айына шамамен $40 болады. n1-standard-64, яғни бұл аймақтың өзі секундына 50 миллион сұраныс үшін бізге айына 1 мың доллардан асады.
Иван Сим () өткен жылы қызмет көрсету торының кешігуі болды және жад пен процессорға бірдей уәде берді, бірақ ол нәтиже бермеді:
Шамасы, values-istio-test.yaml CPU сұрауларын айтарлықтай арттырады. Егер мен математиканы дұрыс орындаған болсам, басқару тақтасы үшін шамамен 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 қолданбасын өндірісте қолданбаймыз, бірақ ол мұндай тапсырма үшін өте қолайлы. Мен әрбір қызмет торы үшін бірнеше пәрменді қолдануға тура келді. Мен оқшаулау үшін екі кластерді қолдандым - әрқайсысы 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: ActiveIstio ақауларға төзімділік симуляторы
Shopify үшін бірегей трафикпен тәжірибе жасау үшін Istio деп аталатын ақауларға төзімділік симуляторын жасадық. Бізге арнайы жұмыс жүктемелерін модельдеу үшін динамикалық түрде конфигурацияланған қызмет көрсету графигінің белгілі бір бөлігін көрсететін теңшелетін топологияны жасау үшін құрал қажет болды.
Флеш сатылымдар кезінде Shopify инфрақұрылымы ауыр жүктемеде. Сонымен қатар, Shopify . Ірі тұтынушылар кейде жоспарланған флэш-сатылым туралы ескертеді. Басқалар оларды күннің немесе түннің кез келген уақытында біз үшін күтпеген жерден жасайды.
Біз икемділік симуляторымыздан бұрын Shopify инфрақұрылымын басып алған топологиялар мен жұмыс жүктемелеріне сәйкес келетін жұмыс үрдістерін модельдеуді қалаймыз. Қызметтік торды пайдаланудың негізгі мақсаты - бізге желі деңгейінде сенімділік пен ақауларға төзімділік қажет және біз үшін сервистік тордың бұрын қызметтерді бұзған жүктемелерді тиімді жеңуі маңызды.
Ақауларға төзімділік симуляторының негізінде жұмысшы түйін болып табылады, ол қызмет көрсететін тор түйіні қызметін атқарады. Жұмысшы түйінді іске қосу кезінде статикалық немесе REST API арқылы динамикалық конфигурациялауға болады. Регрессиялық сынақтар түріндегі жұмыс үрдістерін жасау үшін жұмысшы түйіндерінің динамикалық конфигурациясын қолданамыз.
Міне, осындай процестің мысалы:
- ретінде 10 серверді іске қосамыз
barжауапты қайтаратын қызмет200/OK100 мс кейін. - Біз 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/OK100 мс кейін.
Бұл конфигурациямен біз 9 соңғы нүкте арасындағы тұрақты трафик ағынын өлшей аламыз. Вагондар irs-client-loadgen и irs-server секундына 100 сұрауды қабылдау және irs-client — 200 (кіріс және шығыс).
Біз ресурстарды пайдалануды бақылаймыз өйткені бізде Прометей кластері жоқ.
нәтижелері
Басқару панелі
Алдымен біз процессорды тұтынуды қарастырдық.
Linkerd басқару тақтасы ~ 22 миллион ядро
Istio басқару тақтасы: ~ 750 миллион ядро
Istio басқару тақтасы шамамен пайдаланады 35 есе көп процессор ресурстарыЛинкердке қарағанда. Әрине, бәрі әдепкі бойынша орнатылады және истио-телеметрия мұнда көптеген процессор ресурстарын тұтынады (оны кейбір функцияларды өшіру арқылы өшіруге болады). Егер біз бұл компонентті алып тастасақ, біз әлі де 100-ден астам милликор аламыз, яғни 4 есе көпЛинкердке қарағанда.
Жанама прокси
Содан кейін біз проксиді пайдалануды сынадық. Сұраныс санымен сызықтық қатынас болуы керек, бірақ әрбір бүйірлік үшін қисыққа әсер ететін кейбір үстеме шығындар бар.
Linkerd: irs-клиент үшін ~100 милликор, irs-client-loadgen үшін ~50 милликор
Нәтижелер қисынды көрінеді, себебі клиент проксиі loadgen проксиіне қарағанда екі есе көп трафикті алады: loadgen жіберген әрбір шығыс сұрауы үшін клиентте бір кіріс және бір шығыс болады.
Istio/Envoy: irs-клиент үшін ~155 милликор, irs-client-loadgen үшін ~75 милликор
Біз Istio бүйірлік көліктеріне ұқсас нәтижелерді көреміз.
Бірақ жалпы алғанда, Istio/Envoy проксилері тұтынады шамамен 50% көбірек CPU ресурстарыЛинкердке қарағанда.
Біз сервер жағында бірдей схеманы көреміз:
Linkerd: irs-сервері үшін ~50 миллиядро
Istio/Envoy: irs-сервері үшін ~80 миллион ядро
Сервер жағында Istio/Envoy қосалқы құралы тұтынады шамамен 60% көбірек CPU ресурстарыЛинкердке қарағанда.
қорытынды
Istio Envoy проксиі имитацияланған жұмыс жүктемемізде Linkerd-ге қарағанда 50+% көп процессорды тұтынады. Linkerd басқару тақтасы, әсіресе негізгі құрамдастарға қарағанда, Istio-ға қарағанда әлдеқайда аз ресурстарды тұтынады.
Біз әлі де осы шығындарды қалай азайтуға болатынын ойлап жатырмыз. Идеяларыңыз болса, бөлісіңіздер!
Ақпарат көзі: www.habr.com