Svētki ir beigušies, un mēs esam atpakaļ ar savu otro ierakstu Istio Service Mesh sērijā.
Šodienas tēma ir ķēdes pārtraucējs, kas krievu valodā nozīmē "automātiskais slēdzis" vai, sarunvalodā, "ķēdes pārtraucējs". Tomēr istio valodā šis ķēdes pārtraucējs atvieno bojātus konteinerus, nevis īsslēgtas vai pārslogotas ķēdes.
Kā tam ideālā gadījumā vajadzētu darboties
Kad mikropakalpojumus pārvalda Kubernetes, piemēram, OpenShift platformā, tie automātiski tiek mērogoti uz augšu un uz leju atkarībā no slodzes. Tā kā mikropakalpojumi darbojas podos, vienā galapunktā var darboties vairāki konteinerizēta mikropakalpojuma gadījumi, un Kubernetes maršrutēs pieprasījumus un līdzsvaros slodzi starp tiem. Un ideālā gadījumā visam tam vajadzētu darboties nevainojami.
Mēs atceramies, ka mikropakalpojumi ir mazi un īslaicīgi. Īslaicīgums, kas šeit attiecas uz parādīšanās un izzušanas vieglumu, bieži tiek nepietiekami novērtēts. Vēl viena mikropakalpojuma instances dzimšana un nāve podā ir pilnībā paredzama; OpenShift un Kubernetes ar to tiek galā labi, un viss darbojas lieliski, bet atkal, tas ir tikai teorētiski.
Kā tas patiesībā darbojas
Tagad iedomājieties, ka konkrēta mikropakalpojuma instance jeb konteiners ir kļuvis nelietojams: vai nu tas nereaģē (kļūda 503), vai, vēl ļaunāk, tas reaģē, bet pārāk lēni. Citiem vārdiem sakot, tas darbojas ar kļūmi vai nereaģē, bet netiek automātiski noņemts no pūla. Ko šādā gadījumā darīt? Mēģināt vēlreiz? Noņemt to no maršrutēšanas? Un ko nozīmē "pārāk lēns"? Cik tas ir, un kas to nosaka? Varbūt jums vienkārši vajadzētu dot tam pārtraukumu un mēģināt vēlreiz vēlāk? Ja tā, cik ilgi?
Kas ir baseina izmešana Istio?
Šeit noder Istio ar saviem ķēdes pārtraucēja aizsardzības mehānismiem, kas īslaicīgi noņem bojātus konteinerus no maršrutēšanas un slodzes līdzsvarošanas resursu kopas, ieviešot kopas izmešanas procedūru.
Izmantojot noviržu noteikšanas stratēģiju, Istio nosaka nesinhronizētus podus un uz noteiktu laiku, ko sauc par miega logu, noņem tos no resursu kopas.
Lai parādītu, kā tas darbojas Kubernetes platformā OpenShift, sāksim ar parasti darbojošos mikropakalpojumu ekrānuzņēmumu no piemēra repozitorija. Šeit mums ir divi podi, v1 un v2, katrs darbina vienu konteineru. Ja netiek izmantoti Istio maršrutēšanas noteikumi, Kubernetes pēc noklusējuma izmanto vienmērīgi līdzsvarotu apļveida maršrutēšanu:
Gatavošanās neveiksmei
Pirms Pool Ejection veikšanas mums ir jāizveido Istio maršrutēšanas noteikums. Pieņemsim, ka vēlamies sadalīt pieprasījumus starp podiem 50/50. Mēs arī palielināsim v2 konteineru skaitu no viena uz diviem, šādi:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
Tagad mēs iestatām maršrutēšanas noteikumu tā, lai datplūsma starp podiem tiktu sadalīta proporcijā 50/50.
Un lūk, kā izskatās šī noteikuma rezultāts:
Varētu iebilst, ka šis ekrāns nav 50/50, bet gan 14:9, taču situācija laika gaitā uzlabosies.
Mēs izraisām kļūmi
Tagad atspējosim vienu no diviem v2 konteineriem, lai mums būtu viens veselīgs v1 konteiners, viens veselīgs v2 konteiners un viens bojāts v2 konteiners:
Mēs risinām problēmu
Tātad, mums ir konteiners ar kļūmi, un ir pienācis laiks pūla izmešanai (Pool Ejection). Izmantojot ļoti vienkāršu konfigurāciju, mēs uz 15 sekundēm izslēgsim šo konteineru ar kļūmi no visas maršrutēšanas, cerot, ka tas pats atjaunosies (vai nu restartējot, vai atjaunojot veiktspēju). Lūk, kā izskatās šī konfigurācija un kādi ir tās rezultāti:
Kā redzat, bojātais v2 konteiners vairs netiek izmantots pieprasījumu maršrutēšanai, jo tas ir noņemts no pūla. Tomēr pēc 15 sekundēm tas automātiski atgriezīsies pūlā. Patiesībā mēs tikko parādījām, kā darbojas pūla izmešana.
Sāksim veidot arhitektūru
Pool Ejection apvienojumā ar Istio uzraudzības iespējām ļauj sākt veidot sistēmu neizdevušos konteineru automātiskai aizstāšanai, lai samazinātu, ja ne pilnībā novērstu, dīkstāves laiku un kļūmes.
NASA ir viens skaļš moto — neveiksme nav risinājums, kura autors tiek uzskatīts par lidojuma direktoru. Krievu valodā to var tulkot kā "Neveiksme nav risinājums", un ideja ir tāda, ka ar pietiekamu gribasspēku var panākt, lai viss izdotos. Tomēr reālajā dzīvē neveiksmes nenotiek tāpat vien; tās ir neizbēgamas visur un it visā. Tātad, kā ar tām tikt galā mikropakalpojumu gadījumā? Mūsuprāt, labāk paļauties nevis uz gribasspēku, bet gan uz konteineru iespējām. , Un .
Kā jau minējām, Istio ievieš fiziskajā pasaulē labi izveidoto ķēdes pārtraucēju koncepciju. Tāpat kā elektriskais ķēdes pārtraucējs atvieno problemātisku ķēdes posmu, Istio programmatūras ķēdes pārtraucējs atvieno savienojumu starp pieprasījumu plūsmu un problemātisko konteineru, ja kaut kas noiet greizi ar galapunktu, piemēram, serveris avarē vai kļūst lēns.
Turklāt otrajā gadījumā problēmas tikai pieaug, jo viena konteinera palēnināšanās ne tikai izraisa virkni kavējumu pakalpojumos, kas tam piekļūst, un rezultātā samazina visas sistēmas veiktspēju, bet arī ģenerē atkārtotus pieprasījumus jau tā lēnam pakalpojumam, kas situāciju tikai pasliktina.
Ķēdes pārtraucējs teorijā
Ķēdes pārtraucējs ir starpniekserveris, kas kontrolē pieprasījumu plūsmu uz galapunktu. Kad šis galapunkts pārstāj darboties vai, atkarībā no konfigurētajiem iestatījumiem, sāk palēnināties, starpniekserveris atvieno savienojumu ar konteineru. Pēc tam datplūsma tiek novirzīta uz citiem konteineriem, vienkārši slodzes līdzsvarošanas nolūkos. Savienojums paliek atvērts noteiktu miega logu, piemēram, divas minūtes, un pēc tam tiek uzskatīts par daļēji atvērtu. Mēģinājums nosūtīt nākamo pieprasījumu nosaka savienojuma turpmāko stāvokli. Ja pakalpojums ir kārtībā, savienojums atgriežas darba stāvoklī un atkal tiek slēgts. Ja pakalpojums joprojām neizdodas, savienojums tiek atvienots un miega logs tiek atkārtoti iespējots. Šeit ir vienkāršota ķēdes pārtraucēja stāvokļa pārejas diagramma:
Ir svarīgi atzīmēt, ka tas viss notiek sistēmas arhitektūras līmenī, tā teikt. Tāpēc kādā brīdī jums būs jāiemāca savas lietojumprogrammas strādāt ar Circuit Breaker, piemēram, atbildē norādot noklusējuma vērtību vai, ja iespējams, ignorējot pakalpojuma esamību. Tas tiek panākts, izmantojot starpsienu modeli, taču tas neietilpst šī raksta tvērumā.
Ķēdes pārtraucējs praksē
Šajā piemērā mēs OpenShift platformā palaidīsim divas mūsu ieteikumu mikropakalpojuma versijas. 1. versija darbosies normāli, bet 2. versijā mēs pievienosim aizkavi, lai simulētu servera aizkavi. Lai skatītu rezultātus, izmantojiet rīku. :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
Viss šķietami darbojas, bet par kādu cenu? No pirmā acu uzmetiena mums ir 100% pieejamība, bet, ieskatoties rūpīgāk, maksimālais transakcijas ilgums ir veselas 12 sekundes. Tā nepārprotami ir vājā vieta, un tā ir jārisina.
Lai to paveiktu, mēs izmantosim Istio, lai novērstu izsaukumus uz lēniem konteineriem. Lūk, kā izskatās atbilstošā konfigurācija, izmantojot Circuit Breaker:
Pēdējā rinda ar parametru httpMaxRequestsPerConnection norāda, ka savienojums ir jāaizver, mēģinot izveidot otru savienojumu papildus esošajam. Tā kā mūsu konteiners simulē lēnu pakalpojumu, šādas situācijas periodiski radīsies, un tad Istio atgriezīs 503 kļūdu, un lūk, ko parādīs Siege:
Labi, mums ir ķēdes pārtraucējs, kas tālāk?
Tātad, mēs esam ieviesuši automātisku izslēgšanu, nepieskaroties pašu pakalpojumu pirmkodam. Izmantojot iepriekš aprakstīto Circuit Breaker un Pool Ejection procedūru, mēs varam noņemt lēnus konteinerus no resursu kopas, līdz tie atgriežas normālā stāvoklī, un pārbaudīt to statusu noteiktā intervālā — mūsu piemērā ik pēc divām minūtēm (sleepWindow parametrs).
Lūdzu, ņemiet vērā, ka lietojumprogrammas spēja reaģēt uz 503 kļūdu joprojām ir definēta pirmkoda līmenī. Atkarībā no situācijas ir pieejamas dažādas stratēģijas, kā rīkoties ar ķēdes pārtraucēju.
Nākamajā ierakstā: Mēs apskatīsim izsekošanu un uzraudzību, kas ir iebūvētas Istio vai viegli pievienojamas, kā arī to, kā apzināti ieviest sistēmā kļūdas.
Avots: www.habr.com
