Qeyd. tərcümə.: bu sikl İstionun imkanları ilə tanış olmağa və onları fəaliyyətdə nümayiş etdirməyə həsr olunmuşdu. İndi biz bu xidmət şəbəkəsinin konfiqurasiyası və istifadəsinin daha mürəkkəb aspektləri, xüsusən də dəqiq tənzimlənmiş marşrutlaşdırma və şəbəkə trafikinin idarə edilməsi haqqında danışacağıq.
Həm də xatırladırıq ki, məqalədə anbardan konfiqurasiyalardan (Kubernetes və Istio üçün manifestlər) istifadə olunur. .
trafikin idarə edilməsi
Istio ilə, təmin etmək üçün klasterə yeni xüsusiyyətlər əlavə olunur:
- Dinamik sorğu yönləndirməsi: canary rollouts, A/B testi;
- Yük balansı: sadə və ardıcıl, hashlərə əsaslanan;
- Düşdükdən sonra bərpa: fasilələr, təkrar cəhdlər, elektrik açarları;
- Qüsurların təqdimatı: gecikmələr, sorğuların kəsilməsi və s.
Məqalə davam etdikcə bu xüsusiyyətlər seçilmiş tətbiqdən nümunə kimi istifadə edilərək nümayiş etdiriləcək və yol boyu yeni anlayışlar təqdim ediləcək. İlk belə konsepsiya olacaq DestinationRules (yəni trafikin/sorğuların alıcısı haqqında qaydalar - təqribən tərcümə), onunla A / B testini aktivləşdiririk.
A/B Testi: Təcrübədə Təyinat Qaydaları
A/B testi tətbiqin iki versiyası olduqda istifadə olunur (adətən onlar vizual olaraq fərqlidirlər) və hansının istifadəçi təcrübəsini yaxşılaşdıracağına 100% əmin deyilik. Buna görə də biz eyni vaxtda hər iki versiyanı işə salırıq və ölçüləri toplayırıq.
A/B test demosu üçün tələb olunan frontendin ikinci versiyasını yerləşdirmək üçün aşağıdakı əmri yerinə yetirin:
$ kubectl apply -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions/sa-frontend-green created"Yaşıl versiya" üçün yerləşdirmə manifestləri iki yerdə fərqlənir:
- Şəkil fərqli etiketə əsaslanır -
istio-green, - Podların etiketi var
version: green.
Çünki hər iki yerləşdirmənin etiketi var app: sa-frontend, virtual xidmət tərəfindən yönləndirilən sorğular sa-external-services xidmət üçün sa-frontend, bütün nümunələrinə yönləndiriləcək və yük tərəfindən paylanacaq , bu, aşağıdakı vəziyyətə gətirib çıxaracaq:
Tələb olunan fayllar tapılmadı
Tətbiqin müxtəlif versiyalarında fərqli adlandırıldığı üçün bu fayllar tapılmadı. Gəlin yoxlayaq:
$ 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 da deməkdir index.htmlstatik faylların bir versiyasını tələb etmək, yük balanslaşdırıcısı tərəfindən açıq-aşkar səbəblərə görə belə faylların mövcud olmadığı fərqli versiyaya malik podlara göndərilə bilər. Buna görə də, tətbiqin işləməsi üçün bir məhdudiyyət qoymalıyıq: "index.html-i qaytaran tətbiqin eyni versiyası sonrakı sorğulara xidmət etməlidir.
Həş-əsaslı ardıcıl yük balansı ilə məqsədimizə nail olacağıq. (Ardıcıl Hash Load Balancing). Bu vəziyyətdə eyni müştəridən sorğular eyni backend instansiyasına göndərilir, bunun üçün əvvəlcədən təyin edilmiş xüsusiyyət istifadə olunur - məsələn, HTTP başlığı. DestinationRules istifadə edərək həyata keçirilir.
Təyinat Qaydaları
Sonra Virtual Xidmət İstənilən xidmətə sorğu göndərdikdə, DestinationRules-dən istifadə edərək biz bu xidmətin nümunələri üçün nəzərdə tutulan trafikə tətbiq olunacaq siyasətləri müəyyən edə bilərik:
Istio resursları ilə trafikin idarə edilməsi
Qeyd: Istio resurslarının şəbəkə trafikinə təsiri burada başa düşmək üçün sadələşdirilmiş formada təqdim olunur. Dəqiq desək, sorğunun hansı instansiyaya göndərilməsi barədə qərar CRD-də konfiqurasiya edilmiş Giriş Şlüzəsində Elçi tərəfindən verilir.
Təyinat Qaydaları ilə biz ardıcıl hashlərdən istifadə etmək və eyni xidmət nümunəsinin eyni istifadəçiyə cavab verməsini təmin etmək üçün yük balansını qura bilərik. Aşağıdakı konfiqurasiya buna nail olur ():
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: sa-frontend
spec:
host: sa-frontend
trafficPolicy:
loadBalancer:
consistentHash:
httpHeaderName: version # 1
1 - hash HTTP başlığının məzmunu əsasında yaradılacaq version.
Konfiqurasiyanı aşağıdakı əmrlə tətbiq edin:
$ kubectl apply -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io/sa-frontend created
İndi aşağıdakı əmri yerinə yetirin və başlığı təyin edərkən düzgün faylları əldə etdiyinizə əmin olun version:
$ curl --silent -H "version: yogo" http://$EXTERNAL_IP/ | tr '"' 'n' | grep mainQeyd: Başlığa müxtəlif dəyərlər əlavə etmək və nəticələri birbaşa brauzerdə yoxlamaq üçün istifadə edə bilərsiniz Chrome-a (Və ya Firefox üçün - təqribən. tərcümə.).
Ümumiyyətlə, DestinationRules yük balansı sahəsində daha çox xüsusiyyətə malikdir - təfərrüatları yoxlayın .
VirtualService-i daha çox araşdırmadan əvvəl, aşağıdakı əmrləri yerinə yetirərək tətbiqin "yaşıl versiyasını" və trafikin istiqaməti üçün müvafiq qaydanı çıxaraq:
$ 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” deletedYansıtma: Təcrübədə Virtual Xidmətlər
Shadowing ("ekran") və ya Yansıtma ("güzgü") son istifadəçilərə təsir etmədən istehsaldakı dəyişikliyi sınaqdan keçirmək istədiyimiz hallarda istifadə olunur: bunun üçün biz lazımi dəyişikliklərin edildiyi ikinci instansiyaya sorğuları dublikat edirik (“güzgü”) və nəticələrinə baxırıq. Sadə dillə desək, həmkarınız ən kritik məsələni seçdikdə və o qədər böyük bir kir topu şəklində çəkmə tələbi etdikdə, heç kim onu nəzərdən keçirə bilməz.
Bu ssenarini hərəkətdə sınamaq üçün səhvlərlə SA-Logic-in ikinci nümunəsini yaradaq (buggy) aşağıdakı əmri işlətməklə:
$ kubectl apply -f resource-manifests/kube/shadowing/sa-logic-service-buggy.yaml
deployment.extensions/sa-logic-buggy created
İndi isə bütün instansiyalardan əmin olmaq üçün əmr işlədək app=sa-logic onların müvafiq versiyaları olan etiketləri də var:
$ 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
Xidmət sa-logic etiketli podları hədəfləyir app=sa-logic, beləliklə, bütün sorğular bütün instansiyalar arasında paylanacaq:
… lakin biz sorğuların v1 nümunələrinə yönləndirilməsini və v2 instansiyalarına əks olunmasını istəyirik:
Biz buna VirtualService vasitəsilə DestinationRule ilə birlikdə nail oluruq, burada qaydalar VirtualXidmətin alt dəstlərini və müəyyən alt qrupa marşrutlarını müəyyən edir.
Təyinat Qaydalarında alt çoxluqların müəyyən edilməsi
Alt çoxluqlar (alt çoxluqlar) aşağıdakı konfiqurasiya ilə müəyyən edilir ():
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- Ev sahibi (
host) müəyyən edir ki, bu qayda yalnız marşrutun xidmətə doğru getdiyi hallara şamil edilirsa-logic; - adlar (
name) alt çoxluqlar alt çoxluq nümunələrinə marşrutlaşdırarkən istifadə olunur; - etiket (
label) alt çoxluğun bir hissəsi olmaq üçün nümunələrin uyğun gəlməli olduğu açar-dəyər cütlərini müəyyən edir.
Konfiqurasiyanı aşağıdakı əmrlə tətbiq edin:
$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-destinationrule.yaml
destinationrule.networking.istio.io/sa-logic createdİndi alt çoxluqlar müəyyən edildikdən sonra biz davam edə və VirtualService-i sa-məntiqə sorğulara qaydaları tətbiq etmək üçün konfiqurasiya edə bilərik ki, onlar:
- Alt qrupa yönləndirildi
v1, - Alt qrupa əks olunub
v2.
Aşağıdakı manifest sizə məqsədlərinizə çatmağa imkan verir ():
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: v2Burada izaha ehtiyac yoxdur, ona görə də gəlin bunu hərəkətdə görək:
$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-shadowing-vs.yaml
virtualservice.networking.istio.io/sa-logic createdAşağıdakı əmri çağıraraq bir yük əlavə edək:
$ while true; do curl -v http://$EXTERNAL_IP/sentiment
-H "Content-type: application/json"
-d '{"sentence": "I love yogobella"}';
sleep .8; done
Gəlin Grafana-da nəticələrə baxaq, burada səhvləri olan versiyanın (buggy) sorğuların ~60%-i üçün uğursuz olur, lakin bu uğursuzluqların heç biri çalışan xidmət tərəfindən cavablandırıldığı üçün son istifadəçilərə təsir etmir.
sa-logic xidmətinin müxtəlif versiyalarının cavablarının uğuru
VirtualService-in Envoys xidmətimizə necə tətbiq edildiyini ilk dəfə burada gördük: nə vaxt sa-web-app müraciət edir sa-logic, o, VirtualService vasitəsilə sorğunu v1 alt dəstinə yönləndirmək və sorğunu xidmətin v2 alt dəstinə əks etdirmək üçün konfiqurasiya edilən yan vaqon Elçisindən keçir. sa-logic.
Bilirəm: Virtual Xidmətlərin sadə olduğunu düşünməyə artıq vaxtınız olub. Növbəti bölmədə onların da həqiqətən böyük olduğunu söyləməklə bu fikri genişləndirəcəyik.
Canary Rollouts
Canary Deployment proqramın yeni versiyasının az sayda istifadəçi üçün yayılması prosesidir. Buraxılışda heç bir problem olmadığına əmin olmaq üçün istifadə olunur və yalnız bundan sonra onun kifayət qədər (buraxılış) keyfiyyətinə əmin olduqdan sonra onu paylayın.оdaha böyük auditoriya.
Kanareykaların təqdimatını nümayiş etdirmək üçün alt dəstlə davam edəcəyik buggy у sa-logic.
Gəlin xırda-xırda vaxt itirməyək və dərhal istifadəçilərin 20%-ni səhvləri olan versiyaya göndərək (bu, bizim kanareykamızı təqdim edəcək), qalan 80%-ni isə normal xidmətə göndərək. Bunu etmək üçün aşağıdakı VirtualService tətbiq edin ():
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 çəkidir (weight) alıcıya və ya alıcının alt çoxluğuna yönəldiləcək sorğuların faizini müəyyən edir.
üçün əvvəlki VirtualService konfiqurasiyasını yeniləyin sa-logic aşağıdakı əmrlə:
$ kubectl apply -f resource-manifests/istio/canary/sa-logic-subsets-canary-vs.yaml
virtualservice.networking.istio.io/sa-logic configured... və biz dərhal görəcəyik ki, bəzi sorğular uğursuzluğa səbəb olur:
$ 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: 500VirtualServices canary rollouts-u işə salır: bu halda, biz problemlərin potensial təsirini istifadəçi bazasının 20%-nə qədər daraltmışıq. Əla! İndi, kodumuzdan əmin olmadığımız hər bir vəziyyətdə (başqa sözlə, həmişə ...), biz aynalama və kanareykadan istifadə edə bilərik.
Zaman aşımı və təkrar cəhdlər
Lakin səhvlər həmişə kodda bitmir. Siyahıda” ilk növbədə “şəbəkə etibarlıdır” kimi yanlış fikirdir. Əslində şəbəkə heç bir etibarlıdır və bu səbəbdən bizə fasilələr lazımdır (fayllar) və yenidən cəhd edir (yenidən cəhd).
Nümayiş üçün biz eyni problemli versiyadan istifadə etməyə davam edəcəyik sa-logic (buggy) və şəbəkənin etibarsızlığı təsadüfi uğursuzluqlarla simulyasiya ediləcək.
Səhvləri olan xidmətimizin 1/3-ə çox uzun müddət cavab vermək, 1/3-ü Daxili Server Xətası ilə bitmək və 1/3-ü səhifəni uğurla göstərmək şansına malik olsun.
Bu problemlərin təsirini azaltmaq və istifadəçilərimizin həyatını yaxşılaşdırmaq üçün biz:
- xidmət 8 saniyədən çox cavab verirsə, fasilə əlavə edin,
- sorğu uğursuz olarsa, yenidən cəhd edin.
Həyata keçirmək üçün aşağıdakı resurs tərifindən istifadə edirik ():
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- Sorğu üçün fasilə 8 saniyəyə təyin edilib;
- Sorğulara 3 dəfə yenidən baxılır;
- Cavab müddəti 3 saniyədən çox olarsa, hər bir cəhd uğursuz sayılır.
Bu, optimallaşdırmadır, çünki istifadəçi 8 saniyədən çox gözləməli deyil və biz uğursuzluq halında cavab almaq üçün üç yeni cəhd edəcəyik və uğurlu cavab şansını artıracağıq.
Yenilənmiş konfiqurasiyanı aşağıdakı əmrlə tətbiq edin:
$ kubectl apply -f resource-manifests/istio/retries/sa-logic-retries-timeouts-vs.yaml
virtualservice.networking.istio.io/sa-logic configuredVə Grafana qrafiklərində uğurlu cavabların sayının bitdiyini yoxlayın:
Taymoutlar və təkrar cəhdlər əlavə edildikdən sonra müvəffəqiyyət statistikasında təkmilləşdirmələr
Növbəti hissəyə keçməzdən əvvəl (daha doğrusu, məqalənin növbəti hissəsinə, çünki bu hissədə daha praktik təcrübələr olmayacaq - təqribən tərcümə.), silin sa-logic-buggy və aşağıdakı əmrləri işlətməklə VirtualService:
$ kubectl delete deployment sa-logic-buggy
deployment.extensions “sa-logic-buggy” deleted
$ kubectl delete virtualservice sa-logic
virtualservice.networking.istio.io “sa-logic” deletedCircuit Breaker və Bölmə Nümunələri
Söhbət mikroservis arxitekturasında özünü bərpa etməyə imkan verən iki mühüm nümunədən gedir. (özünü müalicə) xidmətlər.
Circuit Breaker ("Dövrə açarı") qeyri-sağlam hesab edilən xidmət instansiyasına daxil olan sorğuları dayandırmaq və müştəri sorğuları həmin xidmətin sağlam nümunələrinə yönləndirilərkən (bu müvəffəqiyyət dərəcəsini artırır) onu bərpa etmək üçün istifadə olunur. (Tərcümə qeydi: Nümunənin daha ətraflı təsviri tapıla bilər, məsələn, .)
Qabar ("bölmə") xidmətlərdəki uğursuzluqları bütün sistemin məğlubiyyətindən təcrid edir. Məsələn, B xidməti pozulub və başqa bir xidmət (B xidmətinin müştərisi) B xidmətinə sorğu göndərir, bu da onun öz iplik hovuzunu istifadə etməsinə və digər sorğulara (hətta xidmətə aid olmasa belə) xidmət göstərə bilməməsinə səbəb olur. B). (Tərcümə qeydi: Nümunənin daha ətraflı təsviri tapıla bilər, məsələn, .)
Bu nümunələrin icra təfərrüatlarını buraxacağam, çünki onları tapmaq asandır , və mən də həqiqətən məqalənin növbəti hissəsində müzakirə olunacaq autentifikasiya və icazəni göstərmək istəyirəm.
Tərcüməçidən PS
Bloqumuzda da oxuyun:
- "Istio ilə mikro xidmətlərə qayıdın": , ;
- «";
- «.
Mənbə: www.habr.com