kirish
Biz shu yerdamiz Istio-ni xizmat ko'rsatish tarmog'i sifatida joylashtirishni boshladi. Aslida, hamma narsa yaxshi, bitta narsadan tashqari: bu qimmat.
В Istio uchun u shunday deydi:
Istio 1.1 bilan proksi-server soniyasiga 0,6 ta so'rov uchun taxminan 1000 vCPU (virtual yadro) iste'mol qiladi.
Xizmat tarmog'idagi birinchi mintaqa uchun (ulanishning har bir tomonida 2 ta proksi), bizda proksi-server uchun sekundiga bir million so'rov tezligida 1200 yadro bo'ladi. Google-ning xarajat kalkulyatoriga ko'ra, u konfiguratsiya uchun oyiga taxminan 40 dollarni tashkil qiladi. n1-standard-64, ya'ni bu mintaqaning o'zi sekundiga 50 million so'rov uchun bizga oyiga 1 ming dollardan oshadi.
Ivan Sim () O'tgan yili xizmat ko'rsatish kechikishlari va xotira va protsessor uchun xuddi shunday va'da qilingan, ammo bu ish bermadi:
Ko'rinishidan, values-istio-test.yaml CPU so'rovlarini jiddiy ravishda oshiradi. Agar men matematikani to'g'ri bajargan bo'lsam, sizga boshqaruv paneli uchun taxminan 24 ta protsessor yadrosi va har bir proksi-server uchun 0,5 protsessor kerak bo'ladi. Menda unchalik ko'p narsa yo'q. Menga ko'proq resurslar ajratilganda testlarni takrorlayman.
Men Istio-ning ishlashi boshqa ochiq manbali xizmat tarmog'iga qanchalik o'xshashligini o'zim ko'rmoqchi edim: .
Xizmat tarmog'ini o'rnatish
Avvalo, men uni klasterga o'rnatdim :
$ 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!Men SuperGloo-dan foydalandim, chunki u xizmat ko'rsatish tarmog'ini yuklashni ancha osonlashtiradi. Men ko'p ish qilishim shart emas edi. Biz ishlab chiqarishda SuperGloo-dan foydalanmaymiz, lekin u bunday vazifa uchun ideal. Men har bir xizmat tarmog'i uchun tom ma'noda bir nechta buyruqlardan foydalanishim kerak edi. Izolyatsiya uchun ikkita klasterdan foydalandim - har biri Istio va Linkerd uchun.
Tajriba Google Kubernetes Engine’da o‘tkazildi. Men Kubernetes-dan foydalandim 1.12.7-gke.7 va tugunlar hovuzi n1-standard-4 avtomatik tugun miqyosi bilan (minimal 4, maksimal 16).
Keyin ikkala xizmat ko'rsatish tarmog'ini buyruq satridan o'rnatdim.
Birinchi bog'lovchi:
$ 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 |
+---------+--------------+---------+---------------------------+Keyin 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 bir necha daqiqa davom etdi va keyin boshqaruv panellari barqarorlashdi.
(Eslatma: SuperGloo hozircha faqat Istio 1.0.x ni qo‘llab-quvvatlaydi. Men Istio 1.1.3 bilan tajribani takrorladim, lekin sezilarli farqni sezmadim.)
Istio Automatic Deployment sozlanmoqda
Istio-ga Envoy yonboshini o'rnatish uchun biz yonbosh injektoridan foydalanamiz - MutatingAdmissionWebhook. Biz bu maqolada bu haqda gapirmaymiz. Aytmoqchimanki, bu barcha yangi podslarning kirishini nazorat qiluvchi va vazifalar uchun mas'ul bo'lgan yonbosh va initContainer-ni dinamik ravishda qo'shadigan kontroller. iptables.
Biz Shopify'da yonbosh mashinalarni amalga oshirish uchun o'z kirish boshqaruvchisini yozdik, ammo bu mezon uchun men Istio bilan birga kelgan kontrollerdan foydalandim. Nomlar maydonida yorliq mavjud bo'lganda, nazoratchi sukut bo'yicha sidecarlarni in'ektsiya qiladi 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 labeledAvtomatik Linkerd joylashtirishni sozlash
Linkerd yonboshini joylashtirishni o'rnatish uchun biz izohlardan foydalanamiz (men ularni qo'lda qo'shdim 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 nosozliklarga chidamlilik simulyatori
Shopify-ga xos trafik bilan tajriba qilish uchun Istio nomli nosozliklarga chidamlilik simulyatorini yaratdik. Bizga maxsus ish yuklarini modellashtirish uchun dinamik ravishda sozlangan, xizmat grafigimizning ma'lum bir qismini aks ettiruvchi maxsus topologiyani yaratish uchun vosita kerak edi.
Shopify infratuzilmasi tez sotuvlar paytida katta yuk ostida. Shu bilan birga, Shopify . Katta mijozlar ba'zan rejalashtirilgan flesh-sotiq haqida ogohlantiradilar. Boshqalar ularni biz uchun kunduz yoki tunning istalgan vaqtida kutilmaganda o'tkazadilar.
Biz moslashuvchanlik simulyatorimizdan o‘tmishda Shopify infratuzilmasini to‘sib qo‘ygan topologiyalar va ish yuklariga mos keladigan ish oqimlarini modellashtirishni xohladik. Xizmat ko'rsatish tarmog'idan foydalanishning asosiy maqsadi shundaki, bizga tarmoq darajasida ishonchlilik va nosozliklarga chidamlilik kerak va biz uchun xizmat ko'rsatish tarmog'i ilgari xizmatlarni buzgan yuklarni samarali tarzda engishi muhim.
Xatolarga chidamlilik simulyatorining markazida xizmat ko'rsatish tarmog'i tugunining vazifasini bajaradigan ishchi tugun joylashgan. Ishchi tugunni ishga tushirishda statik yoki REST API orqali dinamik ravishda sozlash mumkin. Regressiya testlari shaklida ish oqimlarini yaratish uchun ishchi tugunlarining dinamik konfiguratsiyasidan foydalanamiz.
Mana shunday jarayonga misol:
- Biz 10 ta serverni ishga tushiramiz
barjavob qaytaradigan xizmat200/OK100 ms dan keyin. - Biz 10 ta mijozni ishga tushiramiz - har biri soniyasiga 100 ta so'rov yuboradi
bar. - Har 10 soniyada biz 1 ta serverni olib tashlaymiz va xatolarni kuzatamiz
5xxmijoz ustida.
Ish jarayonining oxirida biz jurnallar va ko'rsatkichlarni tekshiramiz va testdan o'tganligini tekshiramiz. Shunday qilib, biz xizmat ko'rsatish tarmog'ining ishlashi haqida bilib olamiz va nosozliklarga chidamlilik haqidagi taxminlarimizni tekshirish uchun regressiya testini o'tkazamiz.
(Eslatma: Biz Istio nosozliklarga chidamlilik simulyatorini ochiq manbalardan foydalanishni ko'rib chiqmoqdamiz, lekin hali bunga tayyor emasmiz.)
Xizmat mesh ko'rsatkichi uchun Istio nosozliklarga chidamlilik simulyatori
Biz simulyatorning bir nechta ishchi tugunlarini o'rnatdik:
irs-client-loadgen: soniyada 3 ta so'rov yuboradigan 100 ta nusxairs-client.irs-client: So'rovni qabul qiladigan 3 ta nusxa, 100 ms kuting va so'rovni yuboringirs-server.irs-server: Qaytgan 3 ta nusxa200/OK100 ms dan keyin.
Ushbu konfiguratsiya yordamida biz 9 ta oxirgi nuqta orasidagi barqaror trafik oqimini o'lchashimiz mumkin. Ichkaridagi vagonlar irs-client-loadgen и irs-server soniyada 100 ta so'rovni qabul qilish va irs-client — 200 (kiruvchi va chiquvchi).
Biz resurslardan foydalanishni kuzatib boramiz chunki bizda Prometey klasteri yo'q.
Natijalar
Boshqaruv panellari
Birinchidan, biz CPU iste'molini ko'rib chiqdik.
Linkerd boshqaruv paneli ~ 22 millicore
Istio boshqaruv paneli: ~ 750 millicore
Istio boshqaruv paneli taxminan foydalanadi 35 marta ko'proq CPU resurslariLinkerdga qaraganda. Albatta, hamma narsa sukut bo'yicha o'rnatiladi va istio-temetriya bu erda juda ko'p protsessor resurslarini sarflaydi (uni ba'zi funktsiyalarni o'chirib qo'yish orqali o'chirib qo'yish mumkin). Agar biz ushbu komponentni olib tashlasak, biz hali ham 100 dan ortiq millikorni olamiz, ya'ni 4 baravar ko'pLinkerdga qaraganda.
Sidecar proksi
Keyin proksi-serverdan foydalanishni sinab ko'rdik. So'rovlar soni bilan chiziqli bog'liqlik bo'lishi kerak, lekin har bir yon vagon uchun egri chiziqqa ta'sir qiluvchi ba'zi bir yuklar mavjud.
Linkerd: irs-mijoz uchun ~100 millicores, irs-client-loadgen uchun ~50 millicores
Natijalar mantiqiy ko'rinadi, chunki mijoz proksi-serveri loadgen proksi-serveriga qaraganda ikki baravar ko'p trafik oladi: loadgen-dan har bir chiquvchi so'rov uchun mijoz bitta kiruvchi va bitta chiquvchiga ega.
Istio/Elchi: irs-mijoz uchun ~155 millikor, irs-client-loadgen uchun ~75 millikor
Biz Istio sidecars uchun shunga o'xshash natijalarni ko'ramiz.
Ammo umuman olganda, Istio/Envoy proksi-serverlari iste'mol qiladi taxminan 50% ko'proq CPU resurslariLinkerdga qaraganda.
Xuddi shu sxemani server tomonida ko'ramiz:
Linkerd: irs-server uchun ~50 millicore
Istio/Elchi: irs-server uchun ~80 millicore
Server tomonida Istio/Envoy yonboshi iste'mol qiladi taxminan 60% ko'proq CPU resurslariLinkerdga qaraganda.
xulosa
Istio Envoy proksi-serveri bizning simulyatsiya qilingan ish yukimizda Linkerdga qaraganda 50+% ko'proq CPU iste'mol qiladi. Linkerd boshqaruv paneli Istio-ga qaraganda kamroq resurslarni, ayniqsa asosiy komponentlar uchun sarflaydi.
Biz hali ham bu xarajatlarni qanday kamaytirish haqida o'ylaymiz. Fikrlaringiz bo'lsa, baham ko'ring!
Manba: www.habr.com