Istio Circuit Breaker: nasaz konteynerləri söndürmək

Tətil bitdi və biz Istio Service Mesh seriyasındakı ikinci postumuzla geri döndük.

Istio Circuit Breaker: nasaz konteynerləri söndürmək

Bu günün mövzusu Circuit Breakerdir ki, bu da rus elektrik mühəndisliyindən tərcümədə "dövrə kəsici", ümumi dildə - "circuit breaker" deməkdir. Yalnız İstioda bu maşın qısaqapanmış və ya həddindən artıq yüklənmiş dövrəni deyil, nasaz konteynerləri ayırır.

Bu ideal şəkildə necə işləməlidir

Mikroservislər, məsələn, OpenShift platforması daxilində Kubernetes tərəfindən idarə edildikdə, yükdən asılı olaraq avtomatik olaraq böyüyür və azaldır. Mikroservislər qovşaqlarda işlədiyi üçün bir son nöqtədə konteynerləşdirilmiş mikroxidmətin çoxsaylı nümunələri ola bilər və Kubernetes sorğuları yönləndirəcək və onlar arasında balans yükləyəcək. Və - ideal olaraq - bütün bunlar mükəmməl işləməlidir.

Mikroservislərin kiçik və efemer olduğunu xatırlayırıq. Burada görünmək və yox olmaq asanlığı mənasını verən efemerlik çox vaxt lazımınca qiymətləndirilmir. Podda başqa bir mikroservis nümunəsinin doğulması və ölümü gözlənilən şeylərdir, OpenShift və Kubernetes bunu yaxşı idarə edir və hər şey əla işləyir - amma yenə də nəzəri cəhətdən.

Əslində necə işləyir

İndi təsəvvür edin ki, mikroservisin konkret nümunəsi, yəni konteyner yararsız hala düşüb: ya cavab vermir (səhv 503), ya da daha xoşagəlməz odur ki, cavab verir, lakin çox yavaş. Başqa sözlə, o, qeyri-sabit olur və ya sorğulara cavab vermir, lakin avtomatik olaraq hovuzdan silinmir. Bu halda nə etmək lazımdır? Yenidən cəhd etmək? Onu marşrutlaşdırma sxemindən silməliyəm? Və "çox yavaş" nə deməkdir - rəqəmlərdə neçədir və onları kim müəyyənləşdirir? Bəlkə bir ara verin və sonra yenidən cəhd edin? Əgər belədirsə, nə qədər sonra?

Istio-da Pool Ejection nədir

Və burada Istio, Pool Ejection prosedurunu həyata keçirərək, nasaz konteynerləri marşrutlaşdırma və yük balanslaşdırma resurs hovuzundan müvəqqəti olaraq çıxaran Circuit Breaker mühafizə maşınları ilə xilasetmə işinə gəlir.

Kənarların aşkarlanması strategiyasından istifadə edərək, Istio xəttdən kənar əyri podları aşkar edir və onları yuxu pəncərəsi adlanan müəyyən müddət ərzində resurs hovuzundan silir.

Bunun OpenShift platformasında Kubernetes-də necə işlədiyini göstərmək üçün depodakı nümunədən normal işləyən mikroxidmətlərin ekran görüntüsü ilə başlayaq. Red Hat Developer Demoları. Burada hər biri bir konteynerlə işləyən v1 və v2 olan iki podsumuz var. Istio marşrutlaşdırma qaydaları istifadə edilmədikdə, Kubernetes defolt olaraq bərabər balanslaşdırılmış dairəvi marşrutlaşdırmaya keçir:

Istio Circuit Breaker: nasaz konteynerləri söndürmək

Uğursuzluğa hazırlaşır

Pool Ejection etməzdən əvvəl Istio marşrutlaşdırma qaydası yaratmalısınız. Deyək ki, sorğuları podlar arasında 50/50 nisbətində paylamaq istəyirik. Əlavə olaraq, v2 konteynerlərinin sayını birdən ikiyə qədər artıracağıq, məsələn:

oc scale deployment recommendation-v2 --replicas=2 -n tutorial

İndi biz marşrutlaşdırma qaydasını təyin etdik ki, trafik 50/50 nisbətində podlar arasında paylansın.

Istio Circuit Breaker: nasaz konteynerləri söndürmək
Bu qaydanın nəticəsi belə görünür:

Istio Circuit Breaker: nasaz konteynerləri söndürmək
Bu ekranın 50/50 yox, 14:9 olmasında günah tapa bilərsiniz, amma zaman keçdikcə vəziyyət düzələcək.

Bir səhv etmək

İndi iki v2 konteynerindən birini deaktiv edək ki, bir sağlam v1 konteynerimiz, bir sağlam v2 konteynerimiz və bir səhv v2 konteynerimiz olsun:

Istio Circuit Breaker: nasaz konteynerləri söndürmək

Xəttin düzəldilməsi

Beləliklə, nasaz konteynerimiz var və Pool Ejection zamanıdır. Çox sadə konfiqurasiyadan istifadə edərək, bu uğursuz konteyneri sağlam vəziyyətə qaytaracağı ümidi ilə 15 saniyə ərzində hər hansı marşrutlaşdırma sxemlərindən kənarlaşdıracağıq (ya yenidən başladın, ya da performansını bərpa edin). Bu konfiqurasiya və işinin nəticələri belə görünür:

Istio Circuit Breaker: nasaz konteynerləri söndürmək
Istio Circuit Breaker: nasaz konteynerləri söndürmək
Gördüyünüz kimi, uğursuz v2 konteyneri hovuzdan silindiyi üçün artıq marşrutlaşdırma sorğuları üçün istifadə edilmir. Amma 15 saniyədən sonra avtomatik olaraq hovuza qayıdacaq. Əslində, biz sadəcə Pool Ejection-ın necə işlədiyini göstərdik.

Memarlıq qurmağa başlayaq

Pool Ejection, Istio-nun monitorinq imkanları ilə birlikdə, dayanma müddətini və nasazlıqları aradan qaldırmaq deyilsə, azaltmaq üçün nasaz konteynerlərin avtomatik dəyişdirilməsi üçün çərçivə qurmağa başlamağa imkan verir.

NASA-nın bir yüksək şüarı var - Uğursuzluq bir seçim deyil, müəllifi uçuş direktoru hesab olunur Gene Kranz. Bunu rus dilinə "Uğursuzluq variant deyil" kimi tərcümə etmək olar və buradakı məna odur ki, kifayət qədər iradəniz varsa, hər şeyi işə salmaq olar. Ancaq real həyatda uğursuzluqlar öz-özünə baş vermir, hər yerdə və hər şeydə qaçılmazdır. Mikroservislər vəziyyətində onlarla necə məşğul olmaq olar? Fikrimizcə, iradəyə deyil, konteynerlərin imkanlarına güvənmək daha yaxşıdır, Kubernetes, Red Hat OpenShiftİstio.

Istio, yuxarıda yazdığımız kimi, fiziki dünyada özünü yaxşı sübut edən elektrik açarları konsepsiyasını həyata keçirir. Elektrik açarı dövrənin problemli hissəsini söndürdüyü kimi, Istio-nun proqram təminatı Circuit Breaker son nöqtədə nəsə səhv olduqda, məsələn, server qəzaya uğradıqda və ya işləməyə başlayanda sorğular axını ilə problem konteyneri arasındakı əlaqəni açır. yavaşlatmaq.

Üstəlik, ikinci halda, yalnız daha çox problemlər var, çünki bir konteynerin əyləcləri ona daxil olan xidmətlərdə nəinki gecikmələr kaskadına səbəb olur və nəticədə bütövlükdə sistemin işini azaldır, həm də təkrarlanan yüklər yaradır. onsuz da yavaş işləyən xidmətə müraciət edir ki, bu da vəziyyəti daha da ağırlaşdırır.

Nəzəri olaraq Circuit Breaker

Circuit Breaker, son nöqtəyə sorğu axınına nəzarət edən bir proxydir. Bu nöqtə işləməyi dayandırdıqda və ya göstərilən parametrlərdən asılı olaraq yavaşlamağa başlayanda, proxy konteyner ilə əlaqəni kəsir. Trafik daha sonra sadəcə yük balansına görə başqa konteynerlərə yönləndirilir. Bağlantı müəyyən bir yuxu pəncərəsi üçün açıq qalır, məsələn, iki dəqiqə və sonra yarı açıq hesab olunur. Növbəti sorğunu göndərmək cəhdi əlaqənin sonrakı vəziyyətini müəyyənləşdirir. Xidmətdə hər şey qaydasındadırsa, əlaqə işlək vəziyyətə qayıdır və yenidən bağlanır. Xidmətdə hələ də nasazlıq varsa, əlaqə kəsilir və yuxu pəncərəsi yenidən işə salınır. Sadələşdirilmiş Circuit Breaker dövlət diaqramı belə görünür:

Istio Circuit Breaker: nasaz konteynerləri söndürmək
Burada qeyd etmək lazımdır ki, bütün bunlar, belə demək mümkünsə, sistem arxitekturası səviyyəsində baş verir. Beləliklə, bir nöqtədə siz proqramlarınıza Circuit Breaker ilə işləməyi öyrətməli olacaqsınız, məsələn, cavab olaraq defolt dəyəri təqdim etmək və ya mümkünsə xidmətin mövcudluğuna məhəl qoymamaq. Bunun üçün aralıq nümunəsi istifadə olunur, lakin bu məqalənin əhatə dairəsi xaricindədir.

Təcrübədə Circuit Breaker

Məsələn, OpenShift-də tövsiyə etdiyimiz mikroservisimizin iki versiyasını işlədəcəyik. Versiya 1 yaxşı işləyəcək, lakin v2-də serverdə yavaşlamaları simulyasiya etmək üçün gecikmə ilə quracağıq. Nəticələrə baxmaq üçün alətdən istifadə edin mühasirə:

siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io

Istio Circuit Breaker: nasaz konteynerləri söndürmək
Hər şey işləyir, amma nəyin bahasına? İlk baxışdan 100% əlçatanlığımız var, lakin daha yaxından nəzər salaq - əməliyyatın maksimal müddəti 12 saniyəyə qədərdir. Bu, açıq şəkildə darboğazdır və genişləndirilməlidir.

Bunu etmək üçün yavaş konteynerlərə edilən zəngləri aradan qaldırmaq üçün Istio-dan istifadə edəcəyik. Circuit Breaker istifadə edərək müvafiq konfiqurasiya belə görünür:

Istio Circuit Breaker: nasaz konteynerləri söndürmək
HttpMaxRequestsPerConnection parametri ilə sonuncu sətir mövcud olana əlavə olaraq başqa - ikinci - əlaqə yaratmağa çalışarkən əlaqənin kəsilməli olduğunu bildirir. Konteynerimiz yavaş bir xidməti simulyasiya etdiyindən, belə hallar vaxtaşırı yaranacaq və sonra Istio 503 səhvini qaytaracaq, lakin mühasirə bunu göstərəcək:

Istio Circuit Breaker: nasaz konteynerləri söndürmək

Yaxşı, bizdə Circuit Breaker var, növbəti nə olacaq?

Beləliklə, biz ümumiyyətlə xidmətlərin mənbə koduna toxunmadan avtomatik bağlanma tətbiq etdik. Yuxarıda təsvir edilən Circuit Breaker və Pool Ejection prosedurundan istifadə edərək, biz əyləc konteynerlərini normal vəziyyətə qayıdana qədər resurs hovuzundan çıxara və onların vəziyyətini müəyyən edilmiş tezlikdə yoxlaya bilərik - bizim nümunəmizdə bu, iki dəqiqədir (sleepWindow parametri).

Nəzərə alın ki, tətbiqin 503 səhvinə cavab vermək qabiliyyəti hələ də mənbə kodu səviyyəsində təyin olunur. Vəziyyətdən asılı olaraq Circuit Breaker-dən istifadə etmək üçün bir çox strategiya var.

Növbəti yazıda: Artıq quraşdırılmış və ya asanlıqla Istio-ya əlavə edilən izləmə və monitorinq, həmçinin səhvləri sistemə qəsdən necə daxil etmək barədə danışacağıq.

Mənbə: www.habr.com

Добавить комментарий