Istio bilan mikroservislarga qaytish. 2-qism

Eslatma. tarjima.: Birinchi qism bu sikl Istio imkoniyatlari bilan tanishish va ularni amalda ko'rsatishga bag'ishlandi. Endi biz ushbu xizmat tarmog'ini sozlash va undan foydalanishning yanada murakkab jihatlari, xususan, nozik sozlangan marshrutlash va tarmoq trafigini boshqarish haqida gaplashamiz.

Shuningdek, maqolada ombordan konfiguratsiyalar (Kubernetes va Istio uchun manifestlar) ishlatilganligini eslatib o'tamiz. ustalik.

transport boshqaruvi

Istio bilan klasterga yangi xususiyatlar qo'shiladi:

• Dinamik so'rovni yo'naltirish: kanareykalarni chiqarish, A/B testi;
• Yukni muvozanatlash: oddiy va izchil, xeshlarga asoslangan;
• Yiqilishdan keyin tiklanish: vaqt tugashi, qayta urinishlar, o'chirgichlar;
• Xatolarni kiritish: kechikishlar, so'rovlarning uzilishi va boshqalar.

Maqola davom etar ekan, ushbu funksiyalar tanlangan ilova yordamida namuna sifatida namoyish etiladi va yo'lda yangi tushunchalar kiritiladi. Birinchi bunday kontseptsiya bo'ladi DestinationRules (ya'ni, trafik / so'rovlarni qabul qiluvchi to'g'risidagi qoidalar - taxminan tarjimasi), uning yordamida biz A / B testini faollashtiramiz.

A/B testi: Amaliyotdagi Destination Rules

A/B testi ilovaning ikkita versiyasi mavjud bo'lganda qo'llaniladi (odatda ular vizual ravishda farqlanadi) va qaysi biri foydalanuvchi tajribasini yaxshilashiga 100% ishonchimiz komil emas. Shuning uchun biz bir vaqtning o'zida ikkala versiyani ishga tushiramiz va ko'rsatkichlarni yig'amiz.

A/B test demosi uchun zarur bo'lgan frontendning ikkinchi versiyasini o'rnatish uchun quyidagi buyruqni bajaring:

$ kubectl apply -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions/sa-frontend-green created

"Yashil versiya" uchun joylashtirish manifestida ikki joyda farqlanadi:

1. Rasm boshqa tegga asoslangan - istio-green,
2. Podlarning yorlig'i bor version: green.

Chunki ikkala joylashtirishda ham yorliq mavjud app: sa-frontend, virtual xizmat tomonidan yo'naltirilgan so'rovlar sa-external-services xizmat uchun sa-frontend, uning barcha nusxalariga yo'naltiriladi va yuk tomonidan taqsimlanadi dumaloq robin algoritmi, bu quyidagi holatga olib keladi:

Soʻralgan fayllar topilmadi

Ushbu fayllar ilovaning turli versiyalarida turlicha nomlanganligi sababli topilmadi. Keling, buni tekshirib ko'ramiz:

$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.c7071b22.css
/static/js/main.059f8e9c.js
$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.f87cd8c9.css
/static/js/main.f7659dbb.js

Bu degani index.htmlstatik fayllarning bitta versiyasini so'rash yuk balanslagichi tomonidan boshqa versiyaga ega bo'lgan podlarga yuborilishi mumkin, bu erda aniq sabablarga ko'ra bunday fayllar mavjud emas. Shuning uchun, dastur ishlashi uchun biz cheklov qo'yishimiz kerak: "index.html-ni qaytargan dasturning bir xil versiyasi keyingi so'rovlarga xizmat qilishi kerak".

Biz maqsadimizga hashga asoslangan izchil yuk balansi orqali erishamiz (Izchil xash yukini muvozanatlash)... Ushbu holatda bir mijozdan so'rovlar bir xil backend instansiyasiga yuboriladi, buning uchun oldindan belgilangan xususiyat ishlatiladi - masalan, HTTP sarlavhasi. DestinationRules yordamida amalga oshirilgan.

Destination qoidalari

so'ng Virtual xizmat Istalgan xizmatga so'rov yuborilgan bo'lsa, DestinationRules-dan foydalanib, biz ushbu xizmat misollari uchun mo'ljallangan trafikka qo'llaniladigan siyosatlarni aniqlashimiz mumkin:

Istio resurslari bilan trafikni boshqarish

nota: Istio resurslarining tarmoq trafigiga ta'siri bu yerda tushunish uchun soddalashtirilgan shaklda keltirilgan. Aniqroq qilib aytadigan bo'lsak, so'rovni qaysi instansiyaga yuborish to'g'risida qaror CRD da sozlangan kirish shlyuzida Elchi tomonidan qabul qilinadi.

Destination Rules yordamida biz izchil xeshlardan foydalanish va bir xil xizmat namunasi bir xil foydalanuvchiga javob berishini ta'minlash uchun yuk balansini sozlashimiz mumkin. Quyidagi konfiguratsiya bunga erishadi (destinationrule-sa-frontend.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-frontend
spec:
  host: sa-frontend
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpHeaderName: version   # 1

1 - xesh HTTP sarlavhasi mazmuni asosida yaratiladi version.

Quyidagi buyruq bilan konfiguratsiyani qo'llang:

$ kubectl apply -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io/sa-frontend created

Endi quyidagi buyruqni bajaring va sarlavhani ko'rsatganingizda to'g'ri fayllarni olishingizga ishonch hosil qiling version:

$ curl --silent -H "version: yogo" http://$EXTERNAL_IP/ | tr '"' 'n' | grep main

nota: Sarlavhaga turli qiymatlarni qo'shish va natijalarni to'g'ridan-to'g'ri brauzerda sinab ko'rish uchun siz foydalanishingiz mumkin bu kengaytma Chrome uchun (yoki bu bilan Firefox uchun - taxminan. tarjima.).

Umuman olganda, DestinationRules yuklarni muvozanatlash sohasida ko'proq xususiyatlarga ega - tafsilotlarni tekshiring rasmiy hujjatlar.

VirtualService-ni qo'shimcha o'rganishdan oldin, keling, quyidagi buyruqlarni bajarish orqali ilovaning "yashil versiyasini" va trafik yo'nalishi uchun tegishli qoidani olib tashlaymiz:

$ kubectl delete -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions “sa-frontend-green” deleted
$ kubectl delete -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io “sa-frontend” deleted

Mirroring: Amalda virtual xizmatlar

Soya qilish ("qalqon") yoki Mirroring ("ko'zgu") oxirgi foydalanuvchilarga ta'sir qilmasdan ishlab chiqarishdagi o'zgarishlarni sinab ko'rmoqchi bo'lgan holatlarda qo'llaniladi: buning uchun biz kerakli o'zgarishlar kiritilgan ikkinchi instansiyaga so'rovlarni takrorlaymiz ("oyna") va oqibatlarini ko'rib chiqamiz. Oddiy qilib aytganda, sizning hamkasbingiz eng muhim masalani tanlaganida va shu qadar katta axloqsizlik ichida tortib olish so'rovini qilganida, uni hech kim ko'rib chiqa olmaydi.

Ushbu stsenariyni amalda sinab ko'rish uchun xatolar bilan SA-Logic ning ikkinchi nusxasini yarataylik (buggy) quyidagi buyruqni ishga tushirish orqali:

$ kubectl apply -f resource-manifests/kube/shadowing/sa-logic-service-buggy.yaml
deployment.extensions/sa-logic-buggy created

Va endi barcha misollar mavjudligiga ishonch hosil qilish uchun buyruqni bajaramiz app=sa-logic Shuningdek, ular tegishli versiyalari bilan yorliqlarga ega:

$ kubectl get pods -l app=sa-logic --show-labels
NAME                              READY   LABELS
sa-logic-568498cb4d-2sjwj         2/2     app=sa-logic,version=v1
sa-logic-568498cb4d-p4f8c         2/2     app=sa-logic,version=v1
sa-logic-buggy-76dff55847-2fl66   2/2     app=sa-logic,version=v2
sa-logic-buggy-76dff55847-kx8zz   2/2     app=sa-logic,version=v2

xizmat sa-logic yorlig'i bilan podlarni nishonga oladi app=sa-logic, shuning uchun barcha so'rovlar barcha misollar orasida taqsimlanadi:

… lekin biz so‘rovlar v1 nusxalariga yo‘naltirilishini va v2 misollariga aks ettirilishini istaymiz:

Biz bunga VirtualXizmat orqali DestinationRule bilan birgalikda erishamiz, bu erda qoidalar VirtualServicening ma'lum bir kichik to'plamga quyi to'plamlari va marshrutlarini belgilaydi.

Destination qoidalarida kichik to'plamlarni aniqlash

Kichik to'plamlar (quyi to'plamlar) quyidagi konfiguratsiya bilan belgilanadi (sa-logic-subsets-destination Rule.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-logic
spec:
  host: sa-logic    # 1
  subsets:
  - name: v1        # 2
    labels:
      version: v1   # 3
  - name: v2
    labels:
      version: v2

1. Xost (host) ushbu qoida faqat marshrut xizmat tomon ketadigan holatlarga nisbatan qo'llanilishini belgilaydi sa-logic;
2. Ismlar (name) kichik to'plamlar to'plam misollariga yo'naltirishda ishlatiladi;
3. Yorliq (label) kichik to'plamning bir qismi bo'lish uchun misollar mos kelishi kerak bo'lgan kalit-qiymat juftliklarini belgilaydi.

Quyidagi buyruq bilan konfiguratsiyani qo'llang:

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-destinationrule.yaml
destinationrule.networking.istio.io/sa-logic created

Endi quyi to'plamlar aniqlangandan so'ng, biz davom etishimiz va VirtualServiceni sa-logic so'rovlariga qoidalarni qo'llash uchun sozlashimiz mumkin, shunda ular:

1. Kichik toʻplamga yoʻnaltirilgan v1,
2. Kichik to‘plamga aks ettirilgan v2.

Quyidagi manifest maqsadlaringizga erishishga imkon beradi (sa-logic-subsets-shadowing-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic          
  http:
  - route:
    - destination:
        host: sa-logic  
        subset: v1      
    mirror:             
      host: sa-logic     
      subset: v2

Bu erda tushuntirish kerak emas, shuning uchun uni amalda ko'rib chiqaylik:

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-shadowing-vs.yaml
virtualservice.networking.istio.io/sa-logic created

Quyidagi buyruqni chaqirish orqali yukni qo'shamiz:

$ while true; do curl -v http://$EXTERNAL_IP/sentiment 
    -H "Content-type: application/json" 
    -d '{"sentence": "I love yogobella"}'; 
    sleep .8; done

Keling, Grafana-dagi natijalarni ko'rib chiqaylik, u erda xatoliklar bo'lgan versiyani ko'rishingiz mumkin (buggy) soʻrovlarning ~60% uchun bajarilmaydi, lekin bu xatoliklarning hech biri oxirgi foydalanuvchilarga taʼsir qilmaydi, chunki ular ishlaydigan xizmat tomonidan javob beradi.

Sa-logic xizmatining turli versiyalarining javoblari muvaffaqiyati

Bu yerda biz VirtualService elchilar xizmatimizga qanday qo‘llanilishini birinchi marta ko‘rdik: qachon sa-web-app ga murojaat qiladi sa-logic, u VirtualService orqali so'rovni v1 quyi to'plamiga yo'naltirish va so'rovni xizmatning v2 kichik to'plamiga aks ettirish uchun sozlangan yordamchi elchi orqali o'tadi. sa-logic.

Bilaman: siz allaqachon Virtual xizmatlar oddiy deb o'ylashga vaqtingiz bor edi. Keyingi bo'limda ular ham chinakam buyuk ekanligini aytib, bu fikrni kengaytiramiz.

Kanareykalarni tarqatish

Canary Deployment - bu kam sonli foydalanuvchilarga ilovaning yangi versiyasini chiqarish jarayoni. Chiqarishda hech qanday muammo yo'qligiga ishonch hosil qilish uchun foydalaniladi va shundan keyingina uning etarli (chiqarish) sifatiga ishonch hosil qilib, uni tarqating.оkattaroq auditoriya.

Kanareykalarni namoyish qilish uchun biz kichik to'plam bilan davom etamiz buggy у sa-logic.

Keling, arzimas narsalarga vaqt sarflamaylik va darhol foydalanuvchilarning 20 foizini xatosi bo'lgan versiyaga yuboramiz (bu bizning kanareykalarimizni namoyish etadi), qolgan 80 foizi esa oddiy xizmatga. Buning uchun quyidagi VirtualService (sa-logic-subsets-canary-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic    
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 80         # 1
    - destination: 
        host: sa-logic
        subset: v2
      weight: 20 # 1

1 - og'irlik (weight) qabul qiluvchiga yoki qabul qiluvchining bir qismiga yuboriladigan so'rovlar foizini belgilaydi.

Oldingi VirtualService konfiguratsiyasini yangilang sa-logic quyidagi buyruq bilan:

$ kubectl apply -f resource-manifests/istio/canary/sa-logic-subsets-canary-vs.yaml
virtualservice.networking.istio.io/sa-logic configured

... va biz darhol ba'zi so'rovlar muvaffaqiyatsizlikka olib kelishini ko'ramiz:

$ while true; do 
   curl -i http://$EXTERNAL_IP/sentiment 
   -H "Content-type: application/json" 
   -d '{"sentence": "I love yogobella"}' 
   --silent -w "Time: %{time_total}s t Status: %{http_code}n" 
   -o /dev/null; sleep .1; done
Time: 0.153075s Status: 200
Time: 0.137581s Status: 200
Time: 0.139345s Status: 200
Time: 30.291806s Status: 500

VirtualServices kanareykalarni ishga tushiradi: bu holda biz muammolarning mumkin bo'lgan ta'sirini foydalanuvchi bazasining 20 foizigacha qisqartirdik. Ajoyib! Endi, har qanday holatda, biz kodimizga ishonchimiz komil bo'lmaganda (boshqacha qilib aytganda, har doim ...), biz aks ettirish va kanareykalardan foydalanishimiz mumkin.

Tanaffuslar va qayta urinishlar

Ammo xatolar har doim ham kodda tugamaydi. dan ro'yxatdaTaqsimlangan hisoblashda 8 ta noto'g'ri tushuncha” birinchi o'rinda "tarmoq ishonchli" degan noto'g'ri fikr. Aslida tarmoq yo'q ishonchli va shu sababli bizga taym-autlar kerak (taym-aut) va qayta urinib ko'ring (qayta urinish).

Namoyish uchun biz bir xil muammoli versiyadan foydalanishda davom etamiz sa-logic (buggy) va tarmoqning ishonchsizligi tasodifiy nosozliklar bilan simulyatsiya qilinadi.

Xatolar bilan xizmatimizga 1/3 qismi juda uzoq vaqt javob berish, 1/3 qismi ichki server xatosi bilan tugash va 1/3 qismi sahifani muvaffaqiyatli ko‘rsatish imkoniyatiga ega bo‘lsin.

Ushbu muammolarni yumshatish va foydalanuvchilarimiz hayotini yaxshilash uchun biz:

1. agar xizmat 8 soniyadan ko'proq javob bersa, kutish vaqti qo'shing,
2. agar so'rov bajarilmasa, qayta urinib ko'ring.

Amalga oshirish uchun biz quyidagi manba ta'rifidan foydalanamiz (sa-logic-reries-timeouts-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 50
    - destination: 
        host: sa-logic
        subset: v2
      weight: 50
    timeout: 8s           # 1
    retries:
      attempts: 3         # 2
      perTryTimeout: 3s # 3

1. So'rov uchun kutish vaqti 8 soniyaga o'rnatiladi;
2. So'rovlar 3 marta qayta ko'rib chiqiladi;
3. Va agar javob vaqti 3 soniyadan oshsa, har bir urinish muvaffaqiyatsiz deb hisoblanadi.

Bu optimallashtirishdir, chunki foydalanuvchi 8 soniyadan ko'proq kutishi shart emas va biz muvaffaqiyatsizlikka uchragan taqdirda javob olish uchun uchta yangi urinish qilamiz, bu esa muvaffaqiyatli javob berish imkoniyatini oshiradi.

Yangilangan konfiguratsiyani quyidagi buyruq bilan qo'llang:

$ kubectl apply -f resource-manifests/istio/retries/sa-logic-retries-timeouts-vs.yaml
virtualservice.networking.istio.io/sa-logic configured

Muvaffaqiyatli javoblar soni tugaganligini Grafana jadvallarida tekshiring:

Muvaffaqiyat statistikasidagi yaxshilanishlar vaqt-autlari va qayta urinishlarni qo'shgandan keyin

Keyingi bo'limga o'tishdan oldin (aniqrog'i - maqolaning keyingi qismiga, chunki bu amaliy tajribalarda boshqa bo'lmaydi - taxminan. tarjimasi.), oʻchirish sa-logic-buggy va VirtualService quyidagi buyruqlarni ishga tushirish orqali:

$ kubectl delete deployment sa-logic-buggy
deployment.extensions “sa-logic-buggy” deleted
$ kubectl delete virtualservice sa-logic
virtualservice.networking.istio.io “sa-logic” deleted

O'chirish to'xtatuvchisi va o'tkazgich naqshlari

Biz mikroservis arxitekturasida o'z-o'zini tiklashga erishishga imkon beradigan ikkita muhim naqsh haqida gapiramiz. (o'z-o'zini davolash) xizmatlar.

O'chirish to'xtatuvchisi ("o'chirgich") nosog'lom deb hisoblangan xizmat ko'rsatish instantsiyasiga keladigan so'rovlarni to'xtatish va mijoz so'rovlari ushbu xizmatning sog'lom nusxalariga yo'naltirilganda (bu muvaffaqiyat darajasini oshiradi) uni tiklash uchun ishlatiladi. (Tarjima. Eslatma: Naqshning batafsil tavsifini topish mumkin, masalan, shu yerda.)

To'siq ("bo'lim") xizmatlardagi nosozliklarni butun tizimning mag'lubiyatidan ajratib turadi. Misol uchun, B xizmati buzilgan va boshqa xizmat (B xizmati mijozi) B xizmatiga so'rov yuboradi, bu esa u o'zining iplar pulidan foydalanishiga va boshqa so'rovlarga (hatto ular xizmatga tegishli bo'lmasa ham) xizmat qila olmasligiga olib keladi. B). (Tarjima. Eslatma: Naqshning batafsil tavsifini topish mumkin, masalan, shu yerda.)

Men ushbu naqshlarni amalga oshirish tafsilotlarini o'tkazib yuboraman, chunki ularni topish oson rasmiy hujjatlar, va men haqiqatan ham maqolaning keyingi qismida muhokama qilinadigan autentifikatsiya va avtorizatsiyani ko'rsatishni xohlayman.

Tarjimondan PS

Shuningdek, bizning blogimizda o'qing:

• "Istio bilan mikroservislarga qaytish": 1-qism (asosiy xususiyatlar bilan tanishish), 3-qism (autentifikatsiya va avtorizatsiya);
• «Conduit - Kubernetes uchun engil xizmat ko'rsatish tarmog'i";
• «Xizmat tarmog'i nima va u menga nima uchun kerak [mikroservislar bilan bulutli ilova uchun]?".

Manba: www.habr.com