Alustame postituste seeriat, kus demonstreerime mitmeid Istio Service Meshi võimalusi koos Red Hat OpenShifti ja Kubernetesega.
Esimene osa, täna:
- Selgitame Kubernetes'e sidecar konteinerite kontseptsiooni ja sõnastame selle postituste seeria teema: „teile ei ole mitte midagi vaja oma koodis muuta“.
- Tutvustame Istio põhipunkti – marsruutimise reegleid. Need on kõikide Istio teiste võimaluste aluseks, kuna reeglid suunavad liiklust mikroteenustele, kasutades selleks koodist sõltumatuid YAML-faili konfiguratsioone. Samuti käsitleme Canary Deployment'i mudelit. Uue aasta kingitus – 10 interaktiivset tundi Istio kohta.
Teine osa, mis varsti ilmub, räägib teile:
- Kuidas Istio rakendab Pool Ejection'i koos Circuit Breaker'iga ning demonstreerib, kuidas Istio võimaldab kehvasti toimiva või mitte töötava pod'i tasakaalustamisest välja jätta.
- Käsitleme ka Circuit Breaker'i teemat esimeses postituses, et näidata, kuidas siin saab Istio't rakendada. Näitame, kuidas suunata liiklust ja hallata võrgu vigu YAML-konfiguratsiooni failide ja terminali käskudega, muutmata koodis midagi.
Kolmas osa:
- Jutt jälgimisest ja monitooringust, mis on juba sisse ehitatud või kergesti lisatav Istio'sse. Näitame, kuidas kasutada selliseid tööriistu nagu Prometheus, Jaeger ja Grafana koos OpenShift'i skaleerimisega, et hallata mikroteenuste arhitektuuri vaevata.
- Liigume monitoorimisest ja vigade töötlemisest sellele, et tuua need süsteemi sihilikult sisse. Teisisõnu, õpime tegema fault injection'i koodi muutmata, mis on testimise seisukohalt väga oluline – kuna kui selleks koodi muuta, on oht sisse tuua täiendavaid vigu.
Lõpuks, Istio Service Mesh'i viimasel postitusel:
- Liigume Tumedale Poole. Täpsemalt, õpime kasutama Dark Launch'i skeemi, kus kood on juurutatud ja testitud otse tootmisandmete peal, kuid ei mõjuta süsteemi toimimist. Siin tuleb hästi kasuks Istio oskus liiklust jagada. Ja võimalus testida elavad tootmisandmeid, mõjutamata samal ajal tootmisse süsteemi, on kõige veenvam viis kontrollimiseks.
- Võttes aluseks Dark Launch, näitame, kuidas kasutada Canary Deployment mudelit, et vähendada riske ja lihtsustada uue koodi juurutamist. Canary Deployment iseenesest pole uus, kuid Istio võimaldab seda rakendada vaid lihtsate YAML-failide abil.
- Kokkuvõttes näitame, kuidas kasutada Istio Egress, et anda juurdepääs teenustele neile, kes asuvad teie klastri välispindadel, et kasutada Istio võimalusi internetis töötamisel.
Nii, hakkasime minema…
Istio jälgimise ja haldamise tööriistakast – kõik vajalik mikroteenuste koordineerimiseks teenuste võrgus. .
Mis on Istio teenuste võrk
Teenuste võrk rakendab grupile teenustele selliseid funktsioone nagu liikluse jälgimine, juurdepääsukontroll, avastamine, turvalisus, töökindlus ja palju muud kasulikku. Istio võimaldab seda kõike teha ilma, et teenuste koodis peaks olema mingeid muudatusi. Mis on maagiatrikk? Istio liidab iga teenusega oma proksi sidecar-konteinerina (sidecar – mootorratta külgkäru), pärast mida läheb kogu liiklus selle teenuse juurde läbi proksi, mis vastavalt määratud poliitikatele otsustab, kuidas, millal ja kas see liiklus peab teenuseni jõudma. Istio pakub ka võimalust rakendada arenenud DevOpsi tehnikaid, nagu canary deployments, circuit breakers, fault injection ja palju muud.
Kuidas Istio töötab konteinerite ja Kubernetesega
Istio teenuste võrk on sidecar-implementatsioon kõikidest vajalikest funktsioonidest mikroteenuste loomiseks ja haldamiseks: jälgimine, jälgimine, circuit breakers, marsruutimine, koormuse tasakaalustamine, fault injection, kordused, ajatuled, peegeldamine, juurdepääsukontroll, kiiruspiirang ja palju muud. Ja kuigi täna on palju raamatukogusid, et neid funktsioone otse koodis rakendada, saad sa Istio abil kõik need funktsioonid, ilma et peaksid oma koodi muutma.
Sidecar-mudeli kohaselt käitab Istio Linuxi konteineris, mis asub ühes -podis kontrollitava teenusega, ning sisestab (inject) ja väljavõtab (extract) funktsionaalsust ning teavet vastavalt määratud konfiguratsioonile. Alati rõhutame, et see on teie enda konfiguratsioon ja see elab väljaspool teie koodi. Seetõttu muutub kood oluliselt lihtsamaks ja lühemaks.
Mis on veel oluline, et mikroteenuste operatiivkomponent ei ole mingil viisil seotud koodiga, mis tähendab, et nende haldamise võib usaldada IT-spetsialistidele. Tõepoolest, miks peaks arendaja vastutama circuit breaker'ite ja fault injection'i eest? Reageerimine – jah, aga nende haldamine ja loomine? Kui kogu see asi koodist välja jätta, saavad programmeerijad täielikult keskenduda rakendusfunktsionaalsusele. Ja ka kood muutub lühemaks ja lihtsamaks.
Teenuste võrk
Istio, mis pakub mikroteenuste haldamise funktsioone väljaspool nende koodi – see ongi teenuste võrgu kontseptsioon Service Mesh. Teisisõnu, see on koordineeritud rühm ühest või mitmest binaarsest failist, mis moodustavad võrgufunktsioonide võrgu.
Kuidas Istio töötab mikroteenustega
Nii näeb välja sidecar-konteinerite töö seoses ja lindude kõrguselt: käivitate Minishifti instantsi, loote projekti Istio jaoks (nimetame seda 'istio-system'), installite ja käivitate kõik Istio komponentidega seotud osad. Seejärel, kui loote projekte ja pod'e, lisate konfiguratsiooniteavet oma deployment'idesse ning teie pod'id hakkavad kasutama Istio. Lihtsustatud diagramm näeb välja nii:
Nüüd on võimalik muuta Istio seadeid, et näiteks korraldada fault injection'i, toetada või muid Istio funktsioone – ja kõik see, ilma et peaksite puudutama rakenduste koodi. Oletame, et soovite suunata kogu veebiliikluse oma suurima kliendi (Foo Corporation) kasutajatelt uue versiooni veebisaidile. Selleks on piisav luua Istio suunamisreegel, mis otsib @foocorporation.com kasutajatunnusest ja rakendab vastava suunamise. Kõikide teiste kasutajate jaoks ei muutu miski. Te samal ajal saate rahulikult testida uue versiooni veebisaiti. Ja pidage meeles, et selleks ei ole arendajaid vajaka.
Ja peab selle eest kallilt maksma?
Kaugel sellest. Istio töötab üsna kiiresti, see on kirjutatud ja loob väga väikese ülekaalu. Lisaks kompenseeritakse võimalikud kaotused veebitootlikkuses arendajate tootlikkuse kasvu kaudu. Siiski teoorias: ärge unustage, et arendajate aeg on kallis. Mis puutub tarkvarakustesse, siis Istio on avatud lähtekoodiga tarkvara, seega on selle hankimine ja kasutamine tasuta.
Omnya ise
Red Hat Developer Experience Team on välja töötanud põhjaliku praktilise Istio kohta (inglise keeles). See töötab Linuxi, MacOS-i ja Windowsi all, ning kood on saadaval Java ja Node.js versioonides.
10 interaktiivset istungit Istio kohta
Blokk 1 – Algajatele
Sissejuhatus Istiosse
30 minutit
Tutvume Service Meshiga, õpime Istio installima OpenShift Kubernetes klastrisse.
Mikroteenuste juurutamine Istios
30 minutit
Kasutame Istiot, et juurutada kolme mikroteenust Spring Booti ja Vert.xi abil.
Blokk 2 – Kesktase
Monitorimine ja jälgimine Istios
60 minutit
Uurime Istio sisseehitatud jälgimisvahendeid, konfigureeritavaid mõõdikuid ning OpenTracingut Prometheuse ja Grafana kaudu.
Lihtne marsruutimine Istios
60 minutit
Õpime Istios marsruutimist hallama lihtsate reeglite abil.
Täiendavad marsruutimisreeglid
60 minutit
Tutvume Istios nutika marsruutimise, juurdepääsu haldamise, koormuse tasakaalu ja määrangute piiramisiga.
Blokk 3 – Kogenud kasutaja
Fault Injection Istios
60 minutit
Uurime tõrkehalduse stsenaariume jaotatud rakendustes, luues HTTP vigu ja võrgu viivitusi, õppime rakendama kaostehnikat keskkonna taastamiseks.
Circuit Breaker Istios
30 minutit
Paigaldame Siege'i veebisaitide stressitestimiseks ja õpime tagama taustteenuse tõrketaluvust kordusvõimetuse, circuit breaker'i ja devpool'e kaudu.
Egress ja Istio
10 minutit
Kasuta Egressi marsruute, et luua reeglid sisemiste teenuste ja välist API-de ja teenuste vahel.
Istio ja Kiali
15 minutit
Õpime, kuidas kasutada Kialit, et saada üldine ülevaade teenuse võrku ja uuringute päringute ning andmete voogudest.
Mutual TLS Istios
15 minutit
Loome Istio Gateway ja VirtualService, seejärel uurime põhjalikult omavahelist TLS-i (mTLS) ja selle seadistusi.
Blokk 3.1 – Süvitsi minek: Istio Service Mesh mikroteenustele
Millest raamat räägib:
- Mis on teenuse võrgu service mesh.
- Istio süsteem ja selle roll mikroteenuste arhitektuuris.
- Istio kasutamine järgmiste probleemide lahendamisel:
- Veakindlus;
- Marsruutimine;
- Kaostestimine;
- Turvalisus;
- Telemeetriakogumine jälgimise, mõõdikutega ja Grafana abil.
Artiklite seeria teenusvõrkude ja Istio kohta
Proovige ise
See postituste seeria ei püüa anda sügavat sukeldumist Istio maailma. Soovime lihtsalt tutvustada teid selle mõistega ja võib-olla innustada teid ise Istiot proovima. Seda on võimalik teha täiesti tasuta, ja Red Hat pakub kõik vajalikud tööriistad, et alustada OpenShift'i, Kubernetes'i, Linuxi konteinerite ja Istio õppimist, nimelt: , ja teised ressursid meie . Ära oota, alusta juba täna!
Istio suunamisreeglid: suuname teenusettevõtte päringud sinna, kuhu need kuuluvad
ja teenindavad suurepäraselt päringud suunatakse õigetele pod'idele. See on üks Kubernetes'e eksisteerimise eesmärke – marsruutimine ja koormuse tasakaalustamine. Ent mis juhtub, kui vajate peenemat ja rafineeritumat marsruutimist? Näiteks kui soovite korraga kasutada kahte mikroteenuse versiooni. Kuidas aitavad siin Istio suunamisreeglid?
Suunamisreeglid on reeglid, mis tegelikult määravad marsruudi valiku. Ükskõik kui keeruline süsteem on, jääb nende reeglite töö põhimõte lihtsaks: päringud marsruutimise aluseks on määratletud parameetrid ja HTTP pealdiste väärtused.
Vaadakem näidete kaudu:
Kubernetes vaikesäte: triviaalne “50-50” jaotus
Oma näites näitame, kuidas kasutada OpenShift'is korraga kahte versiooni mikroteenusest, nimetame neid v1 ja v2. Iga versioon käivitub oma Kubernetes'e pod'is ning vaikimisi töötab siin ühtlaselt jaotatud ringjoone marsruutimine (evenly balanced round robin routing). Iga pod saab oma osa päringutest vastavalt tema mikroteenuse eksemplaride arvule, teisisõnu, replikatele. Istio võimaldab siiski selle tasakaalu käsitsi muuta.
Oletame, et oleme OpenShift'is juurutanud kaks meie soovitusteenuse versiooni, recommendation-v1 ja recommendation-v2.
Kujutisel 1 on näha, et kui iga teenus on esindatud ühes eksemplaris, siis päringud vahelduvad ühtlaselt nende vahel: 1-2-1-2-... Just nii töötab Kubernetes'e marsruutimine vaikimisi:
Kaaluge jaotumist versioonide vahel
Joonisel 2 on näidatud, mis juhtub, kui suurendada teenuse v2 koopiate arvu ühest kahele (see toimub käsu oc scale —replicas=2 deployment/recommendation-v2 abil). Nagu näeme, jagunevad päringud v1 ja v2 nüüd suhtega "üks kuni kolm": 1-2-2-1-2-2-…:
Versiooni ignoreerimine Istio abil
Istio võimaldab hõlpsasti muuta päringute jaotust soovitud viisil. Näiteks saame suunata kogu liikluse ainult recommendation-v1-le järgmise Istio yaml-failiga:
Siin tuleb tähelepanu pöörata sellele: pod'id valitakse vastavalt märkidele. Meie näites kasutatakse märki v1. Parameeter "weight: 100" tähendab, et 100% liiklusest suunatakse kõikidele pod'idele, millel on märk v1.
Diktee jaotamine versioonide vahel (Canary Deployment)
Edasi, kasutades parameetrit weight, saab liiklust suunata mõlema pod'i poole, ignoreerides mikroteenuste koopiaid, mis on igaühes jooksutatud. Näiteks suuname siin diktiivselt 90% liiklusest v1-le ja 10% - v2-le:
Eraldi marsruutimine mobiilsete kasutajate jaoks
Kokkuvõtteks näitame, kuidas sundida mobiilsete kasutajate liiklust suunama teenusele v2 ja kõik ülejäänud - v1-le. Selleks analüüsime regulaaravaldiste abil user-agent väärtust päringupealkirjas:
Nüüd on teie kord
Regulaaravaldiste näide pealkirjade analüüsimiseks peaks motiveerima teid otsima oma võimalusi Istio marsruutimisreeglite rakendamiseks. Eriti, kuna võimalused on siin ulatuslikud, kuna pealkirjade väärtusi saab luua rakenduste lähtekoodis.
Ja pidage meeles, et Ops, mitte Dev
Kõik, mida me ülaltoodud näidetes näitasime, toimub ilma vähimalgi muutmiseta lähtekoodis, välja arvatud juhtudel, kui tuleb luua erilisi päringupealkirju. Istio on kasulik nii arendajatele, kes saavad seda kasutada näiteks testimise etapis, kui ka IT-süsteemide halduritele, kellele see aitab oluliselt tootmises.
Nii et kordame selle postitustes seeria motiivi: teile ei pea oma koodis midagi muutma. Uute piltide kogumine või uute konteinerite käivitamine ei ole vajalik. Kõik see viiakse ellu väljaspool koodi.
Käitage oma kujutlusvõimet
Kujutage ette, millised võimalused avanevad pealkirjade analüüsimisel regulaaravaldiste abil. Kas soovite suunata oma suurima kliendi spetsiaalsele versioonile? ? Легко! Нужна отдельная версия для браузера Chrome? Не проблема! Вы можете маршрутизировать трафик практически по любой его характеристике.
Proovige ise
Istio, Kubernetes ja OpenShift'i kohta lugemine on üks asi, aga miks mitte kõike ise kätega proovida? Meeskond valmistab ette põhjalikku juhendit (inglise keeles), mis aitab teil neid tehnoloogiaid võimalikult kiiresti omandada. Juhend on samuti 100% avatud lähtekoodiga, seega on see kergesti kättesaadav. Fail töötab macOS, Linuxi ja Windowsi peal ning lähtekood on saadaval Java ja node.js variantides (varsti tuleb versioone ka teistes keeltes). Avage lihtsalt oma brauseris vastav git-repositorium. .
Järgmises postituses: lahendame probleeme kenasti.
Täna nägite, milleks Istio marsruutimisreeglid võimelised on. Ja nüüd kujutage ette sama, kuid vigade käsitlemise kontekstis. Just sellest me räägime järgmises postituses.
Allikas: habr.com
