Sveiki visi! Mano vardas Pavelas Agaletskis. Dirbu kaip komandos vadovas komandoje, kuri kuria Lamoda pristatymo sistemą. 2018 metais kalbėjau HighLoad++ konferencijoje, o šiandien noriu pristatyti savo pranešimo stenogramą.

Mano tema skirta mūsų įmonės patirčiai diegiant sistemas ir paslaugas įvairiose aplinkose. Pradedant nuo priešistorinių laikų, kai visas sistemas diegėme į paprastus virtualius serverius, baigiant laipsnišku perėjimu nuo Nomad prie diegimo Kubernetes. Papasakosiu, kodėl tai padarėme ir kokių problemų kilo.

Programų diegimas VM

Pradėkime nuo to, kad prieš 3 metus visos įmonės sistemos ir paslaugos buvo įdiegtos į įprastus virtualius serverius. Techniškai jis buvo organizuotas taip, kad visas mūsų sistemų kodas buvo saugomas ir surinktas naudojant automatinius surinkimo įrankius, naudojant jenkinus. Naudojant Ansible, ji buvo įdiegta iš mūsų versijų valdymo sistemos į virtualius serverius. Be to, kiekviena sistema, kurią turėjo mūsų įmonė, buvo dislokuota mažiausiai 2 serveriuose: vienas iš jų ant galvos, antrasis ant uodegos. Šios dvi sistemos buvo visiškai identiškos viena kitai visais nustatymais, galia, konfigūracija ir kt. Vienintelis skirtumas tarp jų buvo tas, kad galva sulaukė vartotojų srauto, o uodega niekada nesulaukė vartotojų srauto.

Kodėl tai buvo padaryta?

Diegdami naujus programos leidimus norėjome užtikrinti sklandų diegimą, ty be pastebimų pasekmių vartotojams. Tai buvo pasiekta dėl to, kad kita kompiliuota versija naudojant Ansible buvo išleista iki galo. Ten žmonės, kurie dalyvavo diegime, galėjo pasitikrinti ir įsitikinti, kad viskas gerai: veikia visos metrikos, skyriai ir programos; paleidžiami reikiami scenarijai. Tik įsitikinus, kad viskas gerai, eismas buvo perjungtas. Jis pradėjo eiti į serverį, kuris anksčiau buvo uodega. Ir ta, kuri anksčiau buvo pagrindinė, liko be vartotojų srauto, tačiau joje vis dar buvo ankstesnė mūsų programos versija.

Taigi vartotojams tai buvo sklandu. Kadangi perjungimas vyksta akimirksniu, nes tai tiesiog perjungiamas balansuotojas. Galite labai lengvai grįžti prie ankstesnės versijos, tiesiog perjungę balansyrą atgal. Taip pat galėjome patikrinti, ar programa buvo sukurta dar prieš sulaukiant vartotojų srauto, o tai buvo gana patogu.

Kokius privalumus visa tai įžvelgėme?

1. Visų pirma, užtenka tai tiesiog veikia. Visi supranta, kaip veikia tokia diegimo schema, nes dauguma žmonių kada nors yra įdiegę įprastus virtualius serverius.
2. Šito pakaks patikimai, nes diegimo technologija yra paprasta, ją išbandė tūkstančiai įmonių. Tokiu būdu yra dislokuoti milijonai serverių. Sunku ką nors sulaužyti.
3. Ir pagaliau galėjome gauti atominių dislokacijų. Diegimai, kurie vartotojams atliekami vienu metu, be pastebimo perjungimo tarp senosios versijos į naująją etapo.

Tačiau visa tai taip pat pastebėjome keletą trūkumų:

1. Be gamybos aplinkos, kūrimo aplinkos, yra ir kitų aplinkų. Pavyzdžiui, qa ir preprodukcija. Tuo metu turėjome daug serverių ir apie 60 paslaugų. Dėl šios priežasties tai buvo būtina kiekvienai paslaugai palaikykite naujausią jos versiją Virtuali mašina. Be to, jei norite atnaujinti bibliotekas arba įdiegti naujas priklausomybes, tai turite padaryti visose aplinkose. Taip pat reikėjo sinchronizuoti laiką, kada ketinate diegti kitą naują programos versiją, su laiku, kai devops atlieka būtinus aplinkos nustatymus. Tokiu atveju nesunku patekti į situaciją, kai visose aplinkose vienu metu mūsų aplinka bus kiek skirtinga. Pavyzdžiui, kokybės užtikrinimo aplinkoje bus vienos bibliotekų versijos, o gamybinėje – skirtingos, todėl kils problemų.
2. Sunkumai atnaujinant priklausomybes jūsų paraiška. Tai priklauso ne nuo jūsų, o nuo kitos komandos. Būtent iš devops komandos, kuri prižiūri serverius. Turite duoti jiems tinkamą užduotį ir apibūdinti, ką norite daryti.
3. Tuo metu turėjome didelius didelius monolitus irgi norėjome padalinti į atskiras mažas tarnybas, nes supratome, kad jų bus vis daugiau. Tuo metu jų jau turėjome daugiau nei 100. Kiekvienai naujai paslaugai reikėjo sukurti atskirą naują virtualią mašiną, kurią taip pat reikėjo prižiūrėti ir diegti. Be to, reikia ne vieno automobilio, o bent dviejų. Prie viso to pridedama QA aplinka. Tai sukelia problemų ir apsunkina naujų sistemų kūrimą ir paleidimą. sudėtingas, brangus ir ilgas procesas.

Todėl nusprendėme, kad patogiau būtų pereiti nuo įprastų virtualių mašinų diegimo prie programų diegimo docker konteineryje. Jei turite doką, jums reikia sistemos, kuri galėtų paleisti programą klasteryje, nes negalite tiesiog pakelti konteinerio. Paprastai norima sekti, kiek konteinerių pakeliama, kad jie kiltų automatiškai. Dėl šios priežasties turėjome pasirinkti valdymo sistemą.

Ilgai galvojome, kurį galėtume paimti. Faktas yra tas, kad tuo metu šis diegimo krūvas įprastuose virtualiuose serveriuose buvo šiek tiek pasenęs, nes jie neturėjo naujausių operacinių sistemų versijų. Kažkuriuo metu buvo net FreeBSD, kurią nebuvo labai patogu palaikyti. Supratome, kad turime kuo greičiau pereiti prie dokerio. Mūsų kūrėjai peržiūrėjo savo turimą įvairių sprendimų patirtį ir pasirinko tokią sistemą kaip Nomad.

Perjungti į Nomad

Nomad yra HashiCorp produktas. Jie taip pat žinomi dėl kitų sprendimų:

"konsulas" yra paslaugų atradimo įrankis.

"Terraforma" - serverių valdymo sistema, leidžianti juos konfigūruoti per konfigūraciją, vadinamąją infrastruktūrą kaip kodą.

"Valkata" leidžia įdiegti virtualias mašinas vietoje arba debesyje naudojant konkrečius konfigūracijos failus.

„Nomad“ tuo metu atrodė gana paprastas sprendimas, prie kurio galima greitai pereiti nekeičiant visos infrastruktūros. Be to, tai gana lengva išmokti. Štai kodėl mes pasirinkome ją kaip savo konteinerio filtravimo sistemą.

Ko reikia norint įdiegti sistemą Nomad?

1. Pirmiausia reikia dokerio vaizdas jūsų paraiška. Turite jį sukurti ir įdėti į „Docker“ vaizdų saugyklą. Mūsų atveju tai yra artefaktūra – sistema, leidžianti į ją įstumti įvairius skirtingų tipų artefaktus. Jame gali būti saugomi archyvai, dokerių vaizdai, kompozitoriaus PHP paketai, NPM paketai ir pan.
2. Taip pat reikalingas konfigūracijos failą, kuri pasakys Nomadui, ką, kur ir kokiu kiekiu norite dislokuoti.

Kai kalbame apie Nomad, jis naudoja HCL kalbą kaip informacijos failo formatą, kuris reiškia HashiCorp konfigūravimo kalba. Tai yra „Yaml“ superrinkinys, leidžiantis apibūdinti savo paslaugą nomadiškai.

Tai leidžia pasakyti, kiek konteinerių norite įdiegti, iš kurių vaizdų diegimo metu jiems perduoti įvairius parametrus. Taigi jūs pateikiate šį failą „Nomad“, o jis pagal jį paleidžia konteinerius į gamybą.

Mūsų atveju supratome, kad tiesiog rašyti absoliučiai identiškus HCL failus kiekvienai paslaugai nebūtų labai patogu, nes paslaugų yra labai daug ir kartais norisi jas atnaujinti. Pasitaiko, kad viena paslauga diegiama ne vienu atveju, o įvairiuose. Pavyzdžiui, vienoje iš mūsų gaminamų sistemų yra daugiau nei 100 gamybos egzempliorių. Jie veikia iš tų pačių vaizdų, tačiau skiriasi konfigūracijos nustatymais ir konfigūracijos failais.

Todėl nusprendėme, kad mums būtų patogu visus savo konfigūracijos failus, skirtus diegti, saugoti vienoje bendroje saugykloje. Taip jos buvo matomos: jas lengva prižiūrėti, matėme, kokias sistemas turime. Jei reikia, taip pat nesunku ką nors atnaujinti ar pakeisti. Pridėti naują sistemą taip pat nėra sunku – tereikia naujame kataloge sukurti konfigūracijos failą. Jo viduje yra šie failai: service.hcl, kuriame yra mūsų paslaugos aprašymas, ir kai kurie env failai, leidžiantys konfigūruoti šią gamyboje įdiegtą paslaugą.

Tačiau kai kurios mūsų sistemos gamyboje diegiamos ne viena kopija, o kelios iš karto. Todėl nusprendėme, kad mums patogu būtų saugoti ne gryną konfigūraciją, o šabloninę formą. Ir mes pasirinkome jinja 2. Šiame formate saugome ir pačios paslaugos konfigūracijas, ir jai reikalingus env failus.

Be to, saugykloje patalpinome visiems projektams bendrą diegimo scenarijų, leidžiantį paleisti ir įdiegti paslaugą į gamybą, į norimą aplinką, į norimą tikslą. Tuo atveju, kai HCL konfigūraciją pavertėme šablonu, HCL failas, kuris anksčiau buvo įprasta Nomad konfigūracija, šiuo atveju pradėjo atrodyti šiek tiek kitaip.

Tai reiškia, kad kai kuriuos konfigūracijos vietos kintamuosius pakeitėme kintamųjų įdėklais, paimtais iš env failų ar kitų šaltinių. Be to, gavome galimybę dinamiškai rinkti HCL failus, tai yra, galime naudoti ne tik įprastus kintamųjų įterpimus. Kadangi „jinja“ palaiko kilpas ir sąlygas, ten taip pat galite kurti konfigūracijos failus, kurie keičiasi priklausomai nuo to, kur tiksliai diegiate savo programas.

Pavyzdžiui, norite pritaikyti paslaugą iki gamybos ir gamybos. Tarkime, kad prieš gaminant nenorite paleisti cron scenarijų, o tiesiog norite matyti paslaugą atskirame domene, kad įsitikintumėte, ar ji veikia. Visiems, kurie diegia paslaugą, procesas atrodo labai paprastas ir skaidrus. Viskas, ką jums reikia padaryti, tai paleisti deploy.sh failą, nurodyti, kurią paslaugą norite įdiegti ir kokiam tikslui. Pavyzdžiui, norite dislokuoti tam tikrą sistemą Rusijoje, Baltarusijoje ar Kazachstane. Norėdami tai padaryti, tiesiog pakeiskite vieną iš parametrų ir turėsite tinkamą konfigūracijos failą.

Kai „Nomad“ paslauga jau įdiegta jūsų klasteryje, atrodo taip.

Pirma, lauke reikia kažkokio balansyro, kuris priims visą vartotojų srautą. Jis dirbs kartu su Consul ir iš jo išsiaiškins, kur, kokiame mazge, kokiu IP adresu yra konkreti paslauga, atitinkanti konkretų domeno pavadinimą. Consul paslaugas teikia pats Nomadas. Kadangi tai yra tos pačios įmonės produktai, jie yra gana susiję vienas su kitu. Galima sakyti, kad „Nomad out of the box“ gali užregistruoti visas jame pradėtas paslaugas Consul viduje.

Kai jūsų priekinio galo apkrovos balansavimo priemonė žino, į kurią paslaugą siųsti srautą, jis persiunčia jį į atitinkamą konteinerį arba kelis konteinerius, atitinkančius jūsų programą. Natūralu, kad reikia galvoti ir apie saugumą. Nors visos paslaugos veikia tose pačiose virtualiosiose mašinose konteineriuose, paprastai reikia užkirsti kelią laisvai prieigai iš bet kurios kitos paslaugos. Tai pasiekėme segmentuodami. Kiekviena paslauga buvo paleista savo virtualiame tinkle, kuriame buvo nustatytos maršruto parinkimo taisyklės ir prieigos prie kitų sistemų ir paslaugų leidimo / uždraudimo taisyklės. Jie gali būti tiek šio klasterio viduje, tiek už jo ribų. Pavyzdžiui, jei norite neleisti paslaugai prisijungti prie konkrečios duomenų bazės, tai galima padaryti naudojant tinklo lygio segmentavimą. Tai reiškia, kad net per klaidą negalite netyčia prisijungti iš bandomosios aplinkos prie savo gamybos duomenų bazės.

Kiek perėjimas mums kainavo žmogiškųjų išteklių atžvilgiu?

Visos įmonės perėjimas prie Nomad užtruko maždaug 5-6 mėnesius. Judėjome pagal paslaugą, bet gana sparčiu tempu. Kiekviena komanda paslaugoms turėjo susikurti savo konteinerius.

Taikome tokį metodą, kad kiekviena komanda yra atsakinga už savo sistemų doko vaizdus atskirai. „DevOps“ teikia bendrą diegimui reikalingą infrastruktūrą, tai yra palaikymą pačiam klasteriui, CI sistemos palaikymui ir pan. O tuo metu į Nomadą turėjome perkelta daugiau nei 60 sistemų, kurios sudarė apie 2 tūkst. konteinerių.

Devops yra atsakingas už bendrą infrastruktūrą visko, kas susiję su diegimu ir serveriais. Ir kiekviena kūrimo komanda savo ruožtu yra atsakinga už konteinerių įdiegimą konkrečioje sistemoje, nes būtent komanda žino, ko jai paprastai reikia konkrečiame konteineryje.

Priežastys, kodėl paliko Nomadą

Kokių pranašumų gavome perėję prie diegimo naudodami Nomad ir docker, be kita ko?

1. Mes suteiktos vienodos sąlygos visoms aplinkoms. Kuriant kokybės užtikrinimo aplinką, išankstinę gamybą, gamybą, naudojami tie patys konteinerio vaizdai su tomis pačiomis priklausomybėmis. Atitinkamai, jūs beveik neturite šansų, kad gamyboje bus ne tai, ką anksčiau išbandėte vietoje arba savo bandomojoje aplinkoje.
2. Taip pat pastebėjome, kad užtenka lengva pridėti naują paslaugą. Diegimo požiūriu visos naujos sistemos paleidžiamos labai paprastai. Tiesiog eikite į saugyklą, kurioje saugomos konfigūracijos, pridėkite kitą savo sistemos konfigūraciją ir viskas. Galite įdiegti savo sistemą gamybinėje versijoje be jokių papildomų devops pastangų.
3. visi konfigūracijos failus vienoje bendroje saugykloje pasirodė esąs peržiūrimas. Tuo metu, kai diegėme savo sistemas naudodami virtualius serverius, naudojome Ansible, kurios konfigūracijos buvo toje pačioje saugykloje. Tačiau daugumai kūrėjų tai buvo šiek tiek sunkiau dirbti. Čia konfigūracijų ir kodų, kuriuos reikia pridėti norint įdiegti paslaugą, kiekis tapo daug mažesnis. Be to, devops labai lengva tai pataisyti ar pakeisti. Pavyzdžiui, pereinant prie naujos „Nomad“ versijos, jie gali paimti ir masiškai atnaujinti visus toje pačioje vietoje esančius veikiančius failus.

Tačiau susidūrėme ir su keliais trūkumais:

Paaiškėjo, kad mes negalėjo pasiekti sklandaus diegimo Nomad atveju. Išriedėjus konteinerius skirtingomis sąlygomis, gali pasirodyti, kad jis veikia, o Nomadas jį suvokė kaip konteinerį, paruoštą priimti srautą. Tai atsitiko dar prieš tai, kai joje esanti programa net turėjo galimybę paleisti. Dėl šios priežasties sistema per trumpą laiką pradėjo gaminti 500 klaidų, nes srautas pradėjo eiti į konteinerį, kuris dar nebuvo pasiruošęs jo priimti.

Susidūrėme su kai kuriais prie pelkių. Svarbiausia klaida yra ta, kad „Nomad“ nelabai gerai valdo didelę grupę, jei turite daug sistemų ir konteinerių. Kai norite išimti vieną iš serverių, kurie yra įtraukti į Nomad klasterį priežiūrai, yra gana didelė tikimybė, kad klasteris nesijaus labai gerai ir subyrės. Pavyzdžiui, kai kurie konteineriai gali nukristi ir nepakilti – vėliau tai jums labai brangiai kainuos, jei visos jūsų gamybos sistemos bus „Nomad“ valdomame klasteryje.

Taigi nusprendėme pagalvoti, kur eiti toliau. Tuo metu mes daug geriau suvokėme, ko norime pasiekti. Būtent: norime patikimumo, šiek tiek daugiau funkcijų, nei suteikia Nomad, ir brandesnės, stabilesnės sistemos.

Šiuo atžvilgiu mūsų pasirinkimas krito į Kubernetes kaip populiariausią klasterių paleidimo platformą. Ypač atsižvelgiant į tai, kad mūsų konteinerių dydis ir skaičius buvo pakankamai dideli. Tokiems tikslams „Kubernetes“ atrodė tinkamiausia sistema, kurią galėtume pažvelgti.

Perėjimas prie Kubernetes

Aš jums šiek tiek papasakosiu apie pagrindines „Kubernetes“ sąvokas ir kuo jos skiriasi nuo „Nomad“.

Visų pirma, pati pagrindinė Kubernetes sąvoka yra ankšties sąvoka. Ankštis yra vieno ar kelių konteinerių, kurie visada veikia kartu, grupė. Ir jie visada veikia tarsi griežtai vienoje virtualioje mašinoje. Jie yra prieinami vienas kitam per IP 127.0.0.1 skirtinguose prievaduose.

Tarkime, kad turite PHP programą, kurią sudaro nginx ir php-fpm – klasikinė schema. Greičiausiai norėsite visą laiką laikyti kartu ir nginx, ir php-fpm konteinerius. „Kubernetes“ leidžia tai pasiekti, apibūdinant juos kaip vieną bendrą rinkinį. Būtent to mes negalėjome gauti su Nomadu.

Antroji koncepcija yra diegimas. Faktas yra tas, kad pati ankštis yra trumpalaikis dalykas, jis prasideda ir išnyksta. Ar pirmiausia norite sunaikinti visus ankstesnius sudėtinius rodinius, o tada iš karto paleisti naujas versijas, ar norite jas išleisti palaipsniui? Tai procesas, už kurį atsakinga diegimo koncepcija. Jame aprašoma, kaip diegiate ankštis, kokiu kiekiu ir kaip jas atnaujinti.

Trečioji sąvoka yra tarnyba. Jūsų paslauga iš tikrųjų yra jūsų sistema, kuri gauna tam tikrą srautą ir persiunčia jį į vieną ar kelis jūsų paslaugą atitinkančius blokus. Tai yra, tai leidžia sakyti, kad visas įeinantis srautas į tokią ir tokią paslaugą tokiu ir tokiu pavadinimu turi būti siunčiamas į šiuos konkrečius blokus. Ir tuo pat metu jis suteikia jums srauto balansavimą. Tai reiškia, kad galite paleisti du savo programos paketus ir visas gaunamas srautas bus tolygiai subalansuotas tarp su šia paslauga susijusių grupių.

Ir ketvirta pagrindinė koncepcija yra Įėjimas. Tai paslauga, kuri veikia Kubernetes klasteryje. Jis veikia kaip išorinis apkrovos balansavimo įrankis, kuris perima visas užklausas. Naudodama Kubernetes API, Ingress gali nustatyti, kur turėtų būti siunčiamos šios užklausos. Be to, jis tai daro labai lanksčiai. Galima sakyti, kad visos užklausos šiai prieglobai ir toks ir toks URL yra siunčiamos šiai paslaugai. Ir šios užklausos, ateinančios į šį pagrindinį kompiuterį ir kitą URL, siunčiamos į kitą paslaugą.

Pats šauniausias dalykas žmogaus, kuris kuria programą, požiūriu yra tai, kad jūs galite patys viską valdyti. Nustačius Ingress konfigūraciją, visą srautą, ateinantį į tokią ir tokią API, galite siųsti į atskirus konteinerius, parašytus, pavyzdžiui, Go. Bet šis srautas, ateinantis į tą patį domeną, bet į kitą URL, turėtų būti siunčiamas į PHP parašytus konteinerius, kuriuose yra daug logikos, bet jie nėra labai greiti.

Jei visas šias sąvokas palygintume su Nomadu, galime pasakyti, kad pirmosios trys sąvokos kartu yra Paslauga. Ir paskutinės sąvokos pačiame Nomad nėra. Mes naudojome išorinį balansavimo įrenginį: tai gali būti haproxy, nginx, nginx+ ir pan. Jei tai yra kubas, šios papildomos sąvokos atskirai pristatyti nereikia. Tačiau, jei pažvelgsite į „Ingress“ viduje, tai yra „nginx“, „haproxy“ arba „traefik“, bet tarsi integruotas į „Kubernetes“.

Visos mano aprašytos sąvokos iš tikrųjų yra ištekliai, esantys Kubernetes klasteryje. Norint juos apibūdinti kube, naudojamas yaml formatas, kuris yra labiau skaitomas ir pažįstamas nei HCL failai Nomad atveju. Tačiau struktūriškai jie apibūdina tą patį, pavyzdžiui, ankšties atveju. Sako – noriu ten dislokuoti tokias ir tokias ankštis, su tokiais ir tokiais vaizdais, tokiais ir tokiais kiekiais.

Be to, supratome, kad nenorime rankomis kurti kiekvieno atskiro resurso: diegimo, paslaugų, „Ingress“ ir kt. Vietoj to norėjome apibūdinti kiekvieną savo sistemą kaip „Kubernetes“ diegimo metu, kad nereikėtų rankiniu būdu atkurti visų būtinų išteklių priklausomybių tinkama tvarka. Helmas buvo pasirinktas kaip sistema, kuri leido mums tai padaryti.

Pagrindinės Helmo sąvokos

Vairas yra paketo valdytojas už Kubernetes. Tai labai panašu į tai, kaip veikia paketų tvarkyklės programavimo kalbomis. Jie leidžia saugoti paslaugą, kurią sudaro, pavyzdžiui, diegimo nginx, diegimo php-fpm, įėjimo konfigūracijos, konfigūracijos žemėlapiai (tai objektas, leidžiantis nustatyti env ir kitus jūsų sistemos parametrus) tokia forma. vadinami diagramomis. Tuo pačiu metu Helmas bėga ant Kubernetes. Tai yra, tai nėra kažkokia nuošalyje stovinti sistema, o tik dar viena paslauga, paleista kubo viduje. Jūs sąveikaujate su juo per jo API naudodami konsolės komandą. Jo patogumas ir grožis yra tai, kad net jei vairas sulūžtų ar pašalintumėte jį iš klasterio, jūsų paslaugos nedings, nes vairas iš esmės yra skirtas tik sistemos paleidimui. Tada pati Kubernetes yra atsakinga už paslaugų veikimą ir būklę.

Tą supratome ir mes šabloniškumas, kurį anksčiau buvome priversti daryti patys, į savo konfigūracijas įtraukdami jinja, yra viena iš pagrindinių vairo savybių. Visos konfigūracijos, kurias sukuriate savo sistemoms, yra saugomos „helm“ šablonų pavidalu, šiek tiek panašių į „jinja“, bet iš tikrųjų naudojant „Go“ kalbos šabloną, kuriame parašyta „helm“, kaip „Kubernetes“.

Helmas prideda mums dar keletą sąvokų.

schema – tai jūsų paslaugos aprašymas. Kitose paketų tvarkyklėse tai būtų vadinama paketu, paketu ar panašiai. Čia jis vadinamas diagrama.

Vertybės yra kintamieji, kuriuos norite naudoti kurdami konfigūracijas iš šablonų.

Atleiskite. Kiekvieną kartą, kai paslauga, kuri įdiegta naudojant vairą, gauna laipsnišką leidimo versiją. Helmas prisimena, kokia buvo paslaugos konfigūracija ankstesniame leidime, leidime prieš tai ir pan. Todėl, jei reikia atšaukti, tiesiog paleiskite vairo iškvietimo komandą, nukreipdami ją į ankstesnę versiją. Net jei atitinkama konfigūracija jūsų saugykloje nepasiekiama atkūrimo metu, vairas vis tiek atsimins, kas tai buvo, ir grąžins jūsų sistemą į būseną, kuri buvo ankstesniame leidime.

Tuo atveju, kai naudojame helm, įprastos Kubernetes konfigūracijos taip pat virsta šablonais, kuriuose galima naudoti kintamuosius, funkcijas ir taikyti sąlyginius sakinius. Tokiu būdu galite rinkti savo paslaugų konfigūraciją priklausomai nuo aplinkos.

Praktiškai nusprendėme viską daryti šiek tiek kitaip nei su Nomadu. Jei „Nomad“ ir diegimo konfigūracijos, ir n-kintamieji, kurių reikėjo mūsų paslaugai įdiegti, buvo saugomi vienoje saugykloje, čia nusprendėme juos padalyti į dvi atskiras saugyklas. „Diegimo“ saugykloje saugomi tik diegimui reikalingi n kintamieji, o „vairo“ saugykloje saugomos konfigūracijos arba diagramos.

Ką tai mums davė?

Nepaisant to, kad pačiuose konfigūracijos failuose nesaugome jokių tikrai jautrių duomenų. Pavyzdžiui, duomenų bazių slaptažodžiai. Jie saugomi kaip paslaptys „Kubernetes“, tačiau vis tiek yra tam tikrų dalykų, prie kurių nenorime visiems suteikti prieigos. Todėl prieiga prie „diegimo“ saugyklos yra labiau ribota, o „vairo“ saugykloje yra tiesiog paslaugos aprašymas. Dėl šios priežasties jį saugiai gali pasiekti platesnis žmonių skaičius.

Kadangi turime ne tik gamybinę, bet ir kitas aplinkas, dėl šio atskyrimo galime pakartotinai naudoti savo vairo diagramas, kad galėtume diegti paslaugas ne tik gamyboje, bet ir, pavyzdžiui, kokybės užtikrinimo aplinkoje. Net ir įdiegti juos vietoje Minikubas - tai yra „Kubernetes“ paleidimas vietoje.

Kiekvienoje saugykloje palikome suskirstymą į atskirus kiekvienos paslaugos katalogus. Tai reiškia, kad kiekviename kataloge yra šablonai, susiję su atitinkama diagrama ir aprašantys išteklius, kuriuos reikia panaudoti norint paleisti mūsų sistemą. „Deploy“ saugykloje palikome tik envs. Šiuo atveju mes nenaudojome šablonų naudodami Jinja, nes pats vairas suteikia šabloną iš dėžutės - tai yra viena iš pagrindinių jo funkcijų.

Mes palikome diegimo scenarijų - deploy.sh, kuris supaprastina ir standartizuoja diegimo paleidimą naudojant vairą. Taigi visiems, kurie nori įdiegti, diegimo sąsaja atrodo lygiai taip pat, kaip ir diegiant per Nomad. Tas pats deploy.sh, jūsų paslaugos pavadinimas ir vieta, kur norite ją įdiegti. Dėl to vairas įsijungia viduje. Jis, savo ruožtu, renka konfigūracijas iš šablonų, įterpia į juos reikalingus reikšmių failus, tada juos diegia ir paleidžia į Kubernetes.

išvados

„Kubernetes“ paslauga atrodo sudėtingesnė nei „Nomad“.

Čia išeinantis srautas patenka į Ingress. Tai tik priekinis valdiklis, kuris perima visas užklausas ir vėliau siunčia jas tarnyboms, atitinkančioms užklausos duomenis. Jis nustato juos pagal konfigūracijas, kurios yra jūsų programos aprašymo dalis ir kurias kūrėjai nustato patys. Paslauga siunčia užklausas į savo blokus, tai yra, konkrečius konteinerius, subalansuodama gaunamą srautą tarp visų šiai paslaugai priklausančių konteinerių. Ir, žinoma, neturėtume pamiršti, kad neturėtume niekur eiti nuo saugumo tinklo lygiu. Todėl segmentavimas veikia Kubernetes klasteryje, kuris pagrįstas žymėjimu. Visos paslaugos turi tam tikras žymas, su kuriomis yra susietos paslaugų prieigos prie tam tikrų išorinių / vidinių išteklių klasteryje arba už jos ribų.

Atlikdami perėjimą pamatėme, kad „Kubernetes“ turi visas „Nomad“ galimybes, kurias naudojome anksčiau, taip pat pridėjome daug naujų dalykų. Jį galima išplėsti naudojant papildinius ir iš tikrųjų naudojant pasirinktinius išteklių tipus. Tai reiškia, kad turite galimybę ne tik naudoti ką nors, kas pateikiama kartu su Kubernetes, bet ir sukurti savo šaltinį ir paslaugą, kuri skaitys jūsų išteklius. Tai suteikia papildomų galimybių išplėsti sistemą, nereikia iš naujo įdiegti Kubernetes ir nereikalaujant pakeitimų.

Tokio naudojimo pavyzdys yra „Prometheus“, kuris veikia mūsų „Kubernetes“ klasteryje. Tam, kad ji pradėtų rinkti tam tikros paslaugos metrikas, prie paslaugos aprašymo turime įtraukti papildomą išteklių tipą, vadinamąjį paslaugų monitorių. Dėl to, kad „Prometheus“ gali nuskaityti pasirinktinį išteklių tipą, kai paleista „Kubernetes“, automatiškai pradeda rinkti metrikas iš naujos sistemos. Tai gana patogu.

Pirmą kartą „Kubernetes“ įdiegėme 2018 m. kovo mėn. Ir per tą laiką niekada nepatyrėme jokių problemų. Jis veikia gana stabiliai, be didelių klaidų. Be to, galime ją dar išplėsti. Šiandien turime pakankamai galimybių, kurias ji turi, ir mums labai patinka „Kubernetes“ plėtros tempai. Šiuo metu Kubernetes yra daugiau nei 3000 konteinerių. Klasteris užima kelis mazgus. Tuo pačiu metu jis yra tinkamas naudoti, stabilus ir labai valdomas.

Šaltinis: www.habr.com