Alustame postituste seeriat, kus demonstreerime mitmeid Istio Service Mesh teenusevõrgu võimalusi koos Red Hat OpenShift ja Kubernetes'iga.
Esimene osa, täna:
- Selgitame Kubernetes'e sidecar konteinerite kontseptsiooni ja formuleerime selle postituste seeria teemaks: «teil pole vaja oma koodis midagi muuta».
- Tutvustame Istio ühte põhielementi – marsruutimise reegleid. Need reeglid moodustavad kõikide teiste Istio võimaluste aluse, kuna just need reeglid võimaldavad suunata liiklust mikroteenustele, kasutades selleks teenuse YAML-faile, mis on koodist eraldi. Samuti vaatame üle Canary Deployment'i juurutamise skeemi. Aasta alguse boonus – 10 interaktiivset õppimist Istio kohta.
Teine osa, mis varsti ilmub, räägib teile:
- Kuidas Istio rakendab Pool Ejection'i koos Circuit Breaker'iga ja näitab, kuidas Istio võimaldab tasakaalustamisest eemaldada mittefunktsionaalsed või halvasti töötavad pod'id.
- Ja käsitleme samuti Circuit Breaker'i teemat esimesest postitusest, uurides, kuidas siin saab kasutada Istio't. Näitame, kuidas ilma koodimuudatusteta suunata liiklust ja hallata võrguvigu YAML konfiguratsioonifailide ja terminali käskude abil.
Kolmas osa:
- Juttu tulemustest ja jälgimisest, mis on juba sisseehitatud või kergesti lisatavad Istio'sse. Näitame, kuidas kasutada selliseid tööriistu nagu Prometheus, Jaeger ja Grafana koos OpenShifti skaleerimisega, et hallata mikroteenuste arhitektuuri vaevata.
- Käime läbi, kuidas liikuda vigade jälgimiselt ja käsitlemiselt nende tahtlikku süstimise suunas. Teisisõnu, õpime, kuidas teha fault injection'i ilma lähtekoodi muutmata, mis on testimise seisukohalt väga oluline — sest kui selleks koodi muuta, on oht lisada uusi vigu.
Lõpuks, viimases postituses Istio Service Mesh'ist:
- Liigume Tumeda Poole juurde. Täpsemalt, õppime kasutama Dark Launch mudelit, kus kood suletakse ja testitakse otse tootmisandmetel, ilma et see mõjutaks süsteemi tööd. Siin tuleb kasuks Istio oskus liiklust jagada. Ja võimalus testida elavaid tootmisandmeid, mõjutamata samal ajal tootmise süsteemi, on kõige veenvam meetod kontrollimiseks.
- Tuginedes Dark Launch'ile, näitame, kuidas kasutada Canary Deploymeni mudelit, et vähendada riske ja lihtsustada uue koodi juurutamist. Canary Deployment ise ei ole midagi uut, kuid Istio võimaldab selle mudeli rakendada vaid lihtsate YAML-failide abil.
- Lõpetuseks näitame, kuidas Istio Egress'i abil anda juurdepääs teenustele neile, kes asuvad teie klastritest väljaspool, et kasutada Istio võimalusi internetis töötades.
Nii et, alaldame…
Istio jälgimise ja haldamise tööriistad – kõik vajalik mikroteenuste koordineerimiseks teenusete võrgus. .
Mis on Istio teenusete võrk?
Teenusevõrk pakub teenuste rühmale selliseid funktsioone nagu liikluse jälgimine, juurdepääsu kontroll, avastamine, turvalisus, tõrke taluvus ja palju muud kasulikku. Istio võimaldab seda kõike teha ilma teenuste enda koodi vähimagi muutmiseta. Mis on selle maagia saladus? Istio kinnitab igale teenusele oma proxyd sidecar-konteineri kujul (sidecar – mootorratta kõrvalkäru), mille järel kogu liiklus sellele teenusele suundub läbi proxy, mis, järgides määratud poliitikaid, otsustab, kuidas, millal ja kas see liiklus üldse teenuseni jõuab. Istio võimaldab ka rakendada edasijõudnud DevOpsi tehnikaid, nagu kanarbikutootmine, ringluste katkestajad, vea sissejõudmine ja paljud teised.
Kuidas Istio töötab konteinerite ja Kubernetesega
Istio teenusesüsteem on sidecar'i rakendus, mis pakub kõiki vajalikke funktsioone mikroteenuste loomiseks ja haldamiseks: monitooring, jälgimine, circuit breakers, suunamine, koormuse tasakaalustamine, viga süstimine, kordused, ajoutsid, peegeldamine, juurdepääsukontroll, ribatai piiramine ja palju muud. Kuigi täna on olemas palju raamatukogusid, mis võimaldavad neid funktsioone otse koodis rakendada, saate Istio abil kõik need funktsioonid ilma oma koodi muutmata.
Sidecar'i mudeli järgi töötab Istio Linuxi konteineris, mis asub ühes -pod'is kontrollitava teenusega ning lisab (inject) ja ekstraheerib (extract) funktsioone ja teavet vastavalt määratud konfiguratsioonile. Oluline on rõhutada, et see on teie enda konfiguratsioon ja see elab väljaspool teie koodi. Seetõttu muutub kood palju lihtsamaks ja lühemaks.
Oluline on, et mikroteenuste operatiivne komponent ei ole seotud koodiga, mistõttu saab nende haldamise mugavalt usaldada IT-spetsialistidele. Tõepoolest, miks peaks arendaja vastutama circuit breakerite ja fault injectioni eest? Reageerida – jah, aga hallata neid ja luua? Kui kõik see koodist eemaldada, saavad arendajad täielikult keskenduda rakendusfunktsionaalsusele. Ja kood ise muutub lühemaks ja lihtsamaks.
Teenuste võrk
Istio, mis rakendab mikroteenuste haldamise funktsioone nende koodist väljaspool – see ongi teenuste võrgu kontseptsioon Service Mesh. Teisisõnu, see on koordineeritud grupp ühes või mitmes binaris, mis moodustavad võrgufunktsioonide võrgu.
Kuidas Istio töötab mikroteenustega
Nii näeb välja sidecar-konteinerite töö seoses ja lintud vaatega: käivitate Minishifti eksemplari, loote Istio jaoks projekti (nimetame seda „istio-system”), installite ja käivitate kõik Istio seotud komponendid. Siis, kui loote projekte ja pod'e, lisate konfiguratsiooniteavet oma deployment'idesse ning teie pod'id hakkavad kasutama Istio'd. Lihtsustatud diagramm näeb välja järgmine:
Nüüd on võimalik muuta Istio seadeid, et näiteks korraldada fault injection, toetada või muid Istio võimalusi – ja kõik see ilma, et peaks kodeerimisega tegelema. Oletame, et soovite suunata kogu veebiliiklust oma suurima kliendi (Foo Corporation) kasutajatelt uue veebiversiooni suunas. Selleks piisab, kui luua Istio marsruutimisse reegel, mis otsib @foocorporation.com kasutaja ID-st ja viib läbi vastava suunamise. Kõikide teiste kasutajate jaoks ei muutu midagi. Ja samal ajal saate rahulikult uut veebiversiooni testida. Ja olge tähelepanelik, et selleks ei pea arendajaid kaasama.
Kas selle eest tuleb kallis hind maksta?
Kaugel sellest. Istio töötab väga kiiresti, see on kirjutatud ja loob väga väikese ülekande. Lisaks kompenseerib võimalik kahjum veebitootlikkuses arendajate töö tulemuslikkuse kasvu. Vähemalt teoorias: ärge unustage, et arendajate aeg on kallis. Mis puutub tarkvara kuludesse, siis Istio on avatud lähtekoodiga, seega on selle hankimine ja kasutamine tasuta.
Õppige ise
Red Hat Developer Experience Team on välja töötanud süvitsi mineva praktilise juhendi Istio kohta (inglise keeles). See töötab Linuxil, MacOS-il ja Windowsil ning kood on saadaval Java ja Node.js variantides.
10 interaktiivset Istio kursust
Blokk 1 – Algajad
Sissejuhatus Istiosse
30 minutit
Tutvume Service Mesh'iga, õpime installima Istio OpenShift'i Kubernetes klastrisse.
Mikroteenuste juurutamine Istios
30 minutit
Kasutame Istiot kolme mikroteenuse juurutamiseks Spring Booti ja Vert.x-i abil.
Blokk 2 – Kesktase
Monitooring ja jälgimine Istios
60 minutit
Uurime Istio sisseehitatud monitooringuvahendeid, kohandatavaid mõõdikuid ning OpenTracing'i läbi Prometheuse ja Grafana.
Lihtne marsruutimine Istios
60 minutit
Õpime hallama marsruute Istios lihtsate reeglite abil.
Täiendavad marsruutimise reeglid
60 minutit
Tutvume Istio nutika marsruutimise, juurdepääsu haldamise, koormuse tasakaalustamise ja kiiruspiirangute üle.
Blokk 3 – kogenud kasutaja
Vea süstimine Istios
60 minutit
Uurime tõrke käitlemise stsenaariume hajutatud rakendustes, luues HTTP vigu ja võrgu viivitusi, ning õpime rakendama kaosetehnikaid keskkonna taastamiseks.
Circuit Breaker Istios
30 minutit
Paigaldame Siege'i saitide stressitestimiseks ja õpime tagama tagasivoolu vastupidavust korduste, circuit breakeri ja basseinide väljajätmise abil.
Egress ja Istio
10 minutit
Kasutame Egress marsroute, et luua reegleid siseteenuste suhtlemiseks väliste API-de ja teenustega.
Istio ja Kiali
15 minutit
Õpime kasutama Kiali, et saada ülevaade teenuste võrgust ja uurida päringute ja andmete vooge.
Kaasne TLS Istios
15 minutit
Loome Istio Gateway ja VirtualService, seejärel uurime põhjalikult kaasnevat TLS-i (mTLS) ja selle seadeid.
Blokk 3.1 – Sügav sukeldumine: Istio teenuste võrk mikroteenustele
Raamatu teema:
- Mis on teenuste võrk (service mesh).
- Istio süsteem ja selle roll mikroteenuste arhitektuuris.
- Istio kasutamine järgmiste probleemide lahendamisel:
- Vea taluvus;
- Marsruutimine;
- Kaostestimine;
- Turvalisus;
- Teabeuruumi kogumine jälgimis-, mõõtmis- ja Grafana vahendite kaudu.
Artiklite seeria teenusvõrkudest ja Istio'st
Proovige ise
See postituste seeria ei püüa pakkuda sügavat tutvustust Istio maailma. Me tahame lihtsalt tutvustada teid selle kontseptsiooniga ja ehk inspireerida teid proovida Istio ise. Seda saab teha täiesti tasuta ning Red Hat pakub kõiki vajalikke tööriistu OpenShifti, Kubernetes, Linuxi konteineritega ja Istio kasutamiseks, sealhulgas: , ja muid ressursse meie . Ära oota, alusta juba täna!
Istio marsruutimise reeglid: suuname teenusettekanded õigesse kohta
ja suurepäraselt töötavad teenuste kõnede suunamisel suunati õigele pod'ile. See on üks Kubernetes'e eesmärke – marsruutimine ja koormuse jaotamine. Ent mis juhtub, kui vajate peenemat ja rafineeritumat marsruutimist? Näiteks kui soovite samaaegselt kasutada kahte versiooni mikroteenusest. Kuidas saavad aidata Istio marsruutimise reeglid?
Marsruutimisreeglid on reeglid, mis määravad marsruudi valiku. Süsteemi keerukusest sõltumata jääb nende reeglite töö üldine põhimõte lihtsaks: päringud suunatakse kindlate parameetrite ja HTTP päiste väärtuste alusel.
Vaadakem näiteid:
Kubernetes vaikimisi: triviaalne "50 kahe"
Meie näites näitame, kuidas OpenShiftis samaaegselt kasutada kahte versiooni mikroteenusest, nimetame need v1 ja v2. Iga versioon töötab oma Kubernetesi pod'is ning vaikimisi toimub siin ühtlaselt tasakaalustatud ringmarsruutimine (evenly balanced round robin routing). Igal pod'il on oma osa päringutest, sõltuvalt mikroteenuse eksemplaride arvust, teisisõnu, replikatest. Istio võimaldab seda tasakaalu käsitsi muuta.
Oletame, et oleme oma soovitusteenuse, recommendation-v1 ja recommendation-v2, OpenShiftis rakendanud kahes versioonis.
Joonisel 1 on näha, et kui iga teenus on esindatud ühes eksemplaris, vahelduvad päringud nende vahel ühtlaselt: 1-2-1-2-… Just nii töötab Kubernetes'i marsruutimine vaikimisi:
Kaalu järgi jaotamine versioonide vahel
Kujutisel 2 on näidatud, mis juhtub, kui suurendada teenuse v2 koopiate arvu ühest kahele (seda teeb käsk oc scale —replicas=2 deployment/recommendation-v2). Nagu näeme, jagunevad päringud v1 ja v2 nüüd suhtega «üks kolmest»: 1-2-2-1-2-2-…:
Versiooni ignoreerimine Istio abil
Istio võimaldab hõlpsasti muuta päringute jaotust soovitud viisil. Näiteks suunata kogu liiklus ainult recommendation-v1 juurde järgmise Istio yaml-failiga:
Siin tuleb tähelepanu pöörata sellele: pod'id valitakse sildistamise järgi. Meie näites kasutatakse silti v1. Parameeter „weight: 100” tähendab, et 100% liiklusest suunatakse kõigile pod'idele, millel on silt v1.
Suunatud jaotamine versioonide vahel (Canary Deployment)
Edasi liikudes saame kasutada parameetrit weight, et suunata liiklust mõlemasse pod'i, ignoreerides igaühesse neist käivitatud mikroteenuste arvu. Näiteks siin suuname 90% liiklusest v1-le ja 10% v2-le:
Eraldi mobiilikasutajate marsruutimine
Kokkuvõtteks näitame, kuidas sunniviisiliselt marsruutida mobiilikasutajate liiklust teenusele v2, samas kui kõik teised suunatakse v1-le. Selleks analüüsime regulaarsustega user-agent'i väärtust päringu päises:
Nüüd on teie kord
Regulaarsuste näide päiste analüüsimiseks peaks motiveerima teid otsima oma lahendusi Istio marsruutimisreeglite rakendamiseks. Eriti kuna võimalused on siin väga avardunud, kuna päiste väärtusi saab luua rakenduste lähtekoodis.
Ja pidage meeles, et Ops, mitte Dev
Kõik, mida me eespool näidatud näidetes tegime, toimub ilma vähimagi muudatuseta lähtekoodis, välja arvatud juhtudel, kui on vajalik luua erilisi päringupealkirju. Istio on kasulik nii arendajatele, kes saavad seda näiteks testimise etapis kasutada, kui ka IT-süsteemide halduritele, kellele see aitab oluliselt tootmises.
Nii et korratakse selle postituste seeria teemat: te ei pea oma koodis midagi muutma. Uute piltide kogumine või uute konteinerite käivitamine ei ole vajalik. Kõik see toimub väljaspool koodi.
Käivitage kujutlusvõime
Kujutage ette, millised võimalused avanevad päiste analüüsimisel regulaaravaldiste abil. Kas soovite suunata oma suurima kliendi spetsiaalsele versioonile oma ? Легко! Нужна отдельная версия для браузера Chrome? Не проблема! Вы можете маршрутизировать трафик практически по любой его характеристике.
Proovige ise
Istio, Kubernetes ja OpenShift'i lugemine on üks asi, aga miks mitte proovida kõike ise teha? Meeskond oleme valmistanud põhjaliku juhendi (inglise keeles), mis aitab teil neid tehnoloogiaid kiiresti omandada. Juhend on samuti 100% avatud lähtekoodiga, seetõttu on see avalikult kättesaadav. Fail töötab macOS, Linuxi ja Windowsi süsteemides, samas kui allikakood on saadaval Java ja node.js versioonides (varsti tulevad ka versioonid teistes keeltes). Lihtsalt avage oma brauseris vastav git-repositoorium .
Järgmisel postitusel: lahendame probleeme elegantselt
Täna nägite, milleks Istio marsruutingureeglid on võimelised. Kujutage nüüd ette, et kõik see kehtib ka vigade töötlemise kohta. Just sellest räägimegi järgmises postituses.
Allikas: habr.com
