Tere kõigile! Minu nimi on Pavel Agaletsky. Töötan meeskonnajuhina meeskonnas, mis arendab Lamoda tarnesüsteemi. 2018. aastal esinesin HighLoad++ konverentsil ja täna tahaksin esitada oma raporti ärakirja.

Minu teema on pühendatud meie ettevõtte kogemustele süsteemide ja teenuste juurutamisel erinevates keskkondades. Alates meie eelajaloolistest aegadest, mil juurutasime kõik süsteemid tavalistesse virtuaalserveritesse, lõpetades järkjärgulise üleminekuga Nomadilt Kubernetes juurutamisele. Ma ütlen teile, miks me seda tegime ja millised probleemid meil selle käigus tekkisid.

Rakenduste juurutamine VM-is

Alustame sellest, et 3 aastat tagasi olid kõik ettevõtte süsteemid ja teenused juurutatud tavalistele virtuaalserveritele. Tehniliselt oli see korraldatud nii, et kogu meie süsteemide kood salvestati ja monteeriti automaatsete koostetööriistade abil, kasutades jenkineid. Ansible abil viidi see meie versioonikontrollisüsteemist välja virtuaalserveritesse. Lisaks oli iga meie ettevõtte süsteem juurutatud vähemalt kahele serverile: üks neist peas, teine ​​​​sabas. Need kaks süsteemi olid üksteisega absoluutselt identsed kõigis seadetes, võimsuses, konfiguratsioonis jne. Ainus erinevus nende vahel oli see, et pea sai kasutaja liiklust, samas kui saba ei saanud kunagi kasutaja liiklust.

Miks seda tehti?

Rakenduse uute versioonide juurutamisel soovisime tagada sujuva leviku, st ilma märgatavate tagajärgedeta kasutajatele. See saavutati tänu sellele, et järgmine Ansible'i abil koostatud väljalase veeretati sabani. Seal said juurutamisega seotud inimesed kontrollida ja veenduda, et kõik on korras: kõik mõõdikud, jaotised ja rakendused töötasid; käivitatakse vajalikud skriptid. Alles pärast seda, kui nad olid veendunud, et kõik on korras, lülitati liiklus ümber. See hakkas minema serverisse, mis oli varem saba. Ja see, mis oli varem pea, jäi ilma kasutajaliikluseta, kuid sellel oli endiselt meie rakenduse eelmine versioon.

Nii et see oli kasutajate jaoks sujuv. Kuna lüliti on hetkeline, kuna see on lihtsalt tasakaalustuslüliti. Saate väga lihtsalt tagasi eelmisele versioonile tagasi pöörduda, lülitades lihtsalt tasakaalustaja tagasi. Samuti saime kontrollida, kas rakendus oli tootmisvõimeline juba enne kasutajaliikluse saamist, mis oli üsna mugav.

Milliseid eeliseid me selles kõiges nägime?

1. Esiteks piisab see lihtsalt töötab. Kõik saavad aru, kuidas selline juurutusskeem töötab, sest enamik inimesi on kunagi juurutanud tavalistesse virtuaalserveritesse.
2. Sellest piisab usaldusväärselt, kuna juurutamise tehnoloogia on lihtne ja seda on testinud tuhanded ettevõtted. Sel viisil juurutatakse miljoneid servereid. Midagi on raske murda.
3. Ja lõpuks saime aatomite kasutuselevõtt. Juurutused, mis toimuvad kasutajatele üheaegselt, ilma märgatava üleminekueta vana ja uue versiooni vahel.

Kuid me nägime selles kõiges ka mitmeid puudusi:

1. Lisaks tootmiskeskkonnale, arenduskeskkonnale on ka teisi keskkondi. Näiteks qa ja eelproduktsioon. Sel ajal oli meil palju servereid ja umbes 60 teenust. Sel põhjusel oli see vajalik säilitage iga teenuse jaoks selle uusim versioon Virtuaalne masin. Veelgi enam, kui soovite värskendada teeke või installida uusi sõltuvusi, peate seda tegema kõigis keskkondades. Samuti pidite sünkroonima rakenduse järgmise uue versiooni juurutamise aja ajaga, mil devops teeb vajalikud keskkonnasätted. Sel juhul on lihtne sattuda olukorda, kus meie keskkond on kõigis keskkondades korraga mõnevõrra erinev. Näiteks QA keskkonnas on mõned teekide versioonid ja tootmiskeskkonnas erinevad, mis toob kaasa probleeme.
2. Raskused sõltuvuste värskendamisel teie rakendus. See ei sõltu sinust, vaid teisest meeskonnast. Nimelt devopsi tiimilt, kes servereid hooldab. Peate andma neile sobiva ülesande ja kirjelduse, mida soovite teha.
3. Tahtsime toona jagada ka meie käsutuses olevad suured monoliidid eraldi väikesteks teenusteks, kuna saime aru, et neid tuleb aina juurde. Sel ajal oli neid meil juba üle 100. Iga uue teenuse jaoks oli vaja luua eraldi uus virtuaalmasin, mida oli vaja ka hooldada ja juurutada. Lisaks pole vaja ühte autot, vaid vähemalt kahte. Kõigele sellele lisandub QA keskkond. See põhjustab probleeme ja muudab uute süsteemide loomise ja käitamise keerulisemaks. keeruline, kallis ja pikk protsess.

Seetõttu otsustasime, et mugavam oleks liikuda tavaliste virtuaalmasinate juurutamiselt oma rakenduste juurutamisele dokkeri konteineris. Kui teil on dokk, vajate süsteemi, mis suudab rakendust klastris käivitada, kuna konteinerit ei saa lihtsalt tõsta. Tavaliselt tahetakse jälgida, kui palju konteinereid tõstetakse, et need tõuseksid automaatselt. Sel põhjusel pidime valima juhtimissüsteemi.

Mõtlesime tükk aega, kumma võiks võtta. Fakt on see, et sel ajal oli tavalistes virtuaalserverites see juurutamise virn mõnevõrra vananenud, kuna neil polnud operatsioonisüsteemide uusimaid versioone. Mingil hetkel oli isegi FreeBSD, mida polnud eriti mugav toetada. Saime aru, et peame võimalikult kiiresti dokkerisse üle minema. Meie devops vaatas oma olemasolevaid kogemusi erinevate lahendustega ja valis sellise süsteemi nagu Nomad.

Lülitu Nomadile

Nomad on HashiCorpi toode. Nad on tuntud ka oma muude lahenduste poolest:

"konsul" on tööriist teenuse leidmiseks.

"Terraform" - serverite haldamise süsteem, mis võimaldab teil neid konfiguratsiooni kaudu konfigureerida, nn infrastruktuuri-koodina.

"rändur" võimaldab juurutada virtuaalmasinaid kohapeal või pilves kindlate konfiguratsioonifailide kaudu.

Nomad tundus tol ajal üsna lihtne lahendus, millele sai kiiresti üle minna ilma kogu taristut muutmata. Lisaks on seda üsna lihtne õppida. Seetõttu valisime selle oma konteineri filtreerimissüsteemiks.

Mida on vaja süsteemi Nomadi juurutamiseks?

1. Kõigepealt vajate dokkeri pilt teie rakendus. Peate selle ehitama ja paigutama dockeri pildihoidlasse. Meie puhul on see artefaktuur - süsteem, mis võimaldab teil sellesse suruda mitmesuguseid erinevat tüüpi artefakte. See võib salvestada arhiive, dokkimispilte, helilooja PHP-pakette, NPM-pakette ja nii edasi.
2. Vajalik ka konfiguratsioonifail, mis ütleb Nomadile, mida, kus ja millises koguses soovite juurutada.

Kui me räägime Nomadist, kasutab see teabefaili vorminguna HCL-keelt, mis tähistab HashiCorpi konfiguratsioonikeel. See on Yamli superkomplekt, mis võimaldab teil kirjeldada oma teenust nomadi terminites.

See võimaldab teil öelda, mitu konteinerit soovite juurutada, millistest piltidest neile juurutamise ajal erinevaid parameetreid edastada. Seega toidate selle faili Nomadile ja see käivitab selle järgi konteinerid tootmisse.

Meie puhul mõistsime, et lihtsalt iga teenuse jaoks absoluutselt identsete HCL-failide kirjutamine poleks eriti mugav, kuna teenuseid on palju ja mõnikord soovite neid värskendada. Juhtub, et ühte teenust juurutatakse mitte ühel, vaid mitmel erineval juhul. Näiteks ühes meie tootmises kasutatavatest süsteemidest on tootmises üle 100 eksemplari. Need töötavad samadest piltidest, kuid erinevad konfiguratsiooniseadete ja konfiguratsioonifailide poolest.

Seetõttu otsustasime, et meil oleks mugav salvestada kõik oma konfiguratsioonifailid juurutamiseks ühte ühisesse hoidlasse. Nii olid need nähtavad: neid oli lihtne hooldada ja saime näha, millised süsteemid meil on. Vajadusel on lihtne ka midagi uuendada või muuta. Uue süsteemi lisamine pole samuti keeruline - peate lihtsalt looma uude kataloogi konfiguratsioonifaili. Selle sees on järgmised failid: service.hcl, mis sisaldab meie teenuse kirjeldust, ja mõned env-failid, mis võimaldavad konfigureerida just seda tootmisprotsessis juurutatud teenust.

Mõned meie süsteemid on aga tootmises kasutusele võetud mitte ühes eksemplaris, vaid mitmes korraga. Seetõttu otsustasime, et meil oleks mugav salvestada konfiguratsioonid mitte puhtal kujul, vaid malli kujul. Ja me valisime jinja 2. Selles vormingus salvestame nii teenuse enda konfiguratsioonid kui ka selle jaoks vajalikud env-failid.

Lisaks oleme hoidlasse paigutanud kõikidele projektidele ühise juurutusskripti, mis võimaldab käivitada ja juurutada oma teenus tootmisse, soovitud keskkonda, soovitud sihtpunkti. Juhul, kui muutsime oma HCL-i konfiguratsiooni malliks, hakkas HCL-fail, mis varem oli tavaline Nomadi konfiguratsioon, antud juhul veidi teistsugune välja nägema.

See tähendab, et asendasime mõned konfiguratsiooni asukohamuutujad sisestatud muutujatega, mis on võetud env-failidest või muudest allikatest. Lisaks saime võimaluse koguda HCL-faile dünaamiliselt, see tähendab, et saame kasutada mitte ainult tavalisi muutujate sisestusi. Kuna jinja toetab silmuseid ja tingimusi, saate seal luua ka konfiguratsioonifaile, mis muutuvad olenevalt sellest, kus te oma rakendusi täpselt juurutate.

Näiteks soovite oma teenust juurutada eeltootmises ja tootmises. Oletame, et eeltootmise ajal ei taha te cron-skripte käivitada, vaid soovite lihtsalt näha teenust eraldi domeenis, et veenduda selle toimimises. Kõigile, kes teenuse juurutavad, tundub protsess väga lihtne ja läbipaistev. Kõik, mida pead tegema, on käivitada fail deploy.sh, määrata, millist teenust soovite juurutada ja millisele sihtmärgile. Näiteks soovite teatud süsteemi juurutada Venemaale, Valgevenesse või Kasahstani. Selleks muutke lihtsalt ühte parameetritest ja teil on õige konfiguratsioonifail.

Kui teenus Nomad on teie klastris juba juurutatud, näeb see välja selline.

Esiteks on väljas vaja mingit tasakaalustajat, mis kogu kasutajaliikluse vastu võtab. See töötab koos Consuliga ja uurib sealt välja, kus, millisel sõlmel, mis IP-aadressil asub konkreetne teenus, mis vastab konkreetsele domeeninimele. Konsuli teenused tulevad Nomadilt endalt. Kuna tegemist on sama firma toodetega, on need omavahel üsna seotud. Võime öelda, et Nomad saab kastist väljas registreerida kõik selles käivitatud teenused Consuli sees.

Kui teie esiotsa koormuse tasakaalustaja teab, millisele teenusele liiklust saata, edastab see selle sobivasse konteinerisse või mitmesse konteinerisse, mis vastavad teie rakendusele. Loomulikult tuleb mõelda ka ohutusele. Kuigi kõik teenused töötavad samades virtuaalmasinates konteinerites, nõuab see tavaliselt mis tahes teenuse tasuta juurdepääsu takistamist teistele. Selle saavutasime segmenteerimise kaudu. Iga teenus käivitati oma virtuaalses võrgus, kus olid ette nähtud marsruutimise reeglid ja teistele süsteemidele ja teenustele juurdepääsu lubamise/keelamise reeglid. Need võivad asuda nii selle klastri sees kui ka väljaspool seda. Näiteks kui soovite takistada teenusel konkreetse andmebaasiga ühenduse loomist, saate seda teha võrgutaseme segmenteerimise kaudu. See tähendab, et isegi kogemata ei saa te katsekeskkonnast kogemata ühendust oma tootmisandmebaasiga.

Kui palju läks meile üleminek inimressursside osas maksma?

Kogu ettevõtte üleminek Nomadile kestis orienteeruvalt 5-6 kuud. Liikusime teenuste kaupa, kuid üsna kiires tempos. Iga meeskond pidi teenuste jaoks looma oma konteinerid.

Oleme võtnud kasutusele sellise lähenemisviisi, et iga meeskond vastutab oma süsteemide dokipiltide eest iseseisvalt. DevOps pakub juurutamiseks vajalikku üldist infrastruktuuri, st tuge klastrile endale, CI-süsteemi tuge jne. Ja sel ajal oli meil Nomadile kolitud üle 60 süsteemi, mis moodustas umbes 2 tuhat konteinerit.

Devops vastutab kõige juurutamise ja serveritega seotud üldise infrastruktuuri eest. Ja iga arendusmeeskond vastutab omakorda oma konkreetse süsteemi konteinerite juurutamise eest, kuna just meeskond teab, mida ta konkreetses konteineris üldiselt vajab.

Nomadi hülgamise põhjused

Milliseid eeliseid saime muuhulgas Nomadi ja dockeri abil juurutamisele üleminekust?

1. Me andis võrdsed tingimused kõigi keskkondade jaoks. Arenduses, QA keskkonnas, eeltootmises, tootmises kasutatakse samu konteineripilte, samade sõltuvustega. Seetõttu pole teil praktiliselt mingit võimalust, et see, mis tootmisse jõuab, pole see, mida olete varem kohapeal või oma testkeskkonnas testinud.
2. Leidsime ka, et sellest piisab lihtne lisada uut teenust. Kasutuselevõtu seisukohalt käivitatakse kõik uued süsteemid väga lihtsalt. Lihtsalt minge hoidlasse, mis salvestab seadistusi, lisage sinna oma süsteemi jaoks veel üks konfiguratsioon ja oletegi valmis. Saate oma süsteemi tootmisse juurutada ilma arendajate täiendavate pingutusteta.
3. Kõik konfiguratsioonifailid ühes ühises hoidlas osutus ülevaatamisel olevaks. Ajal, mil me oma süsteemid virtuaalserverite abil juurutasime, kasutasime Ansible'i, mille konfiguratsioonid olid samas hoidlas. Enamiku arendajate jaoks oli see aga pisut keerulisem. Siin on teenuse juurutamiseks lisatavate konfiguratsioonide ja koodide maht muutunud palju väiksemaks. Lisaks on devoppidel seda väga lihtne parandada või muuta. Näiteks Nomadi uuele versioonile ülemineku korral saavad nad hulgi värskendada kõiki samas kohas asuvaid tööfaile.

Kuid puutusime kokku ka mitmete puudustega:

Selgus, et meie ei suutnud sujuvat kasutuselevõttu saavutada Nomadi puhul. Konteinerite väljarullimisel erinevates tingimustes võib see osutuda töötavaks ja Nomad tajus seda kui konteinerit, mis on valmis liiklust vastu võtma. See juhtus enne, kui selle sees olev rakendus sai isegi käivituda. Sel põhjusel hakkas süsteem lühikese aja jooksul tootma 500 viga, sest liiklus hakkas liikuma konteinerisse, mis polnud veel valmis seda vastu võtma.

Kohtasime mõnda rabade poolt. Kõige olulisem viga on see, et Nomad ei käsitle suurt klastrit kuigi hästi, kui teil on palju süsteeme ja konteinereid. Kui soovite mõnda Nomad klastris sisalduvat serverit hoolduseks välja võtta, on üsna suur tõenäosus, et klaster ei tunne end eriti hästi ja laguneb. Mõned konteinerid võivad näiteks kukkuda ja mitte tõusta – see läheb teile hiljem väga palju maksma, kui kõik teie tootmissüsteemid asuvad Nomadi hallatavas klastris.

Seega otsustasime mõelda, kuhu edasi minna. Sel hetkel saime palju teadlikumaks sellest, mida tahame saavutada. Nimelt: me tahame töökindlust, natuke rohkem funktsioone kui Nomad pakub ja küpsemat, stabiilsemat süsteemi.

Sellega seoses langes meie valik Kubernetesele kui kõige populaarsemale platvormile klastrite käivitamiseks. Eriti arvestades, et meie konteinerite suurus ja arv oli piisavalt suur. Sellistel eesmärkidel tundus Kubernetes olevat kõige sobivam süsteem, mida võiksime vaadata.

Üleminek Kubernetesesse

Ma räägin teile veidi Kubernetese põhikontseptsioonidest ja nende erinevusest Nomadist.

Esiteks on Kubernetese kõige elementaarsem kontseptsioon kauna mõiste. Kaun on rühm ühest või mitmest konteinerist, mis jooksevad alati koos. Ja need töötavad alati justkui rangelt ühes virtuaalmasinas. Need on üksteisele juurdepääsetavad IP 127.0.0.1 kaudu erinevates portides.

Oletame, et teil on PHP-rakendus, mis koosneb nginxist ja php-fpm-st - klassikalisest skeemist. Tõenäoliselt soovite nii nginxi kui ka php-fpm konteinereid kogu aeg koos hoida. Kubernetes võimaldab teil seda saavutada, kirjeldades neid ühe ühise kaunana. See on täpselt see, mida me Nomadiga ei saanud.

Teine kontseptsioon on kasutuselevõtu. Fakt on see, et kaun ise on efemeerne asi, see algab ja kaob. Kas soovite kõigepealt hävitada kõik oma eelmised konteinerid ja seejärel käivitada korraga uued versioonid või soovite need järk-järgult levitada? See on protsess, mille eest vastutab juurutamise kontseptsioon. See kirjeldab, kuidas oma kaunasid juurutada, millises koguses ja kuidas neid värskendada.

Kolmas kontseptsioon on teenus. Teie teenus on tegelikult teie süsteem, mis võtab vastu teatud liiklust ja edastab selle siis ühte või mitmesse teie teenusele vastavasse kausta. See tähendab, et see võimaldab teil öelda, et kogu sellise ja sellise nimega teenuse sissetulev liiklus tuleb saata nendesse konkreetsetesse kaustadesse. Ja samal ajal pakub see teile liikluse tasakaalustamist. See tähendab, et saate käivitada kaks oma rakenduse kausta ja kogu sissetulev liiklus on selle teenusega seotud kaustade vahel ühtlaselt tasakaalustatud.

Ja neljas põhikontseptsioon on Ingress. See on teenus, mis töötab Kubernetese klastris. See toimib välise koormuse tasakaalustajana, mis võtab üle kõik taotlused. Kubernetes API abil saab Ingress määrata, kuhu need päringud saata. Pealegi teeb ta seda väga paindlikult. Võite öelda, et kõik päringud sellele hostile ja niisugusele URL-ile saadetakse sellele teenusele. Ja need päringud, mis tulevad sellele hostile ja teisele URL-ile, saadetakse teisele teenusele.

Rakenduse arendaja seisukohalt on kõige lahedam see, et sa saad seda kõike ise hallata. Seadistades Ingressi konfiguratsiooni, saad kogu sellisele ja sellisele API-le tuleva liikluse saata eraldi konteineritesse, mis on kirjutatud näiteks Go-s. Kuid see liiklus, mis tuleb samale domeenile, kuid teisele URL-ile, tuleks saata PHP-s kirjutatud konteineritesse, kus on palju loogikat, kuid need ei ole väga kiired.

Kui võrrelda kõiki neid mõisteid Nomadiga, võib öelda, et kolm esimest mõistet on kõik koos Teenus. Ja viimane mõiste puudub Nomadil endal. Kasutasime välist tasakaalustajat: see võib olla haproxy, nginx, nginx+ ja nii edasi. Kuubi puhul ei pea seda lisakontseptsiooni eraldi tutvustama. Kui aga vaadata Ingressi sisemiselt, on see kas nginx, haproxy või traefik, kuid omamoodi Kubernetesesse sisse ehitatud.

Kõik minu kirjeldatud mõisted on tegelikult ressursid, mis eksisteerivad Kubernetese klastris. Nende kirjeldamiseks kuubis kasutatakse yaml-vormingut, mis on Nomadi puhul loetavam ja tuttavam kui HCL-failid. Kuid struktuuriliselt kirjeldavad nad sama asja näiteks kauna puhul. Nad ütlevad - ma tahan selliseid ja selliseid kaunasid sinna juurutada, selliste ja selliste piltidega, sellistes ja sellistes kogustes.

Lisaks mõistsime, et me ei soovi käsitsi luua iga üksikut ressurssi: juurutus, teenused, Ingress jne. Selle asemel soovisime juurutamise ajal kirjeldada iga oma süsteemi Kubernetese kaudu, et me ei peaks kõiki vajalikke ressursisõltuvusi käsitsi õiges järjekorras uuesti looma. Helm valiti süsteemiks, mis võimaldas meil seda teha.

Põhimõisted Helmis

Helm on paketihaldur Kubernetese jaoks. See on väga sarnane programmeerimiskeelte paketihaldurite tööga. Need võimaldavad teil salvestada teenust, mis koosneb näiteks juurutusest nginx, juurutamise php-fpm, sissepääsu konfiguratsioonist, konfiguratsioonikaartidest (see on üksus, mis võimaldab teil määrata süsteemi env ja muid parameetreid) kujul. nimetatakse diagrammideks. Samal ajal Helm jookseb Kubernetese peal. See tähendab, et see pole mingisugune kõrvalejääv süsteem, vaid lihtsalt üks kuubiku sees käivitatud teenus. Saate sellega suhelda selle API kaudu konsoolikäsu kaudu. Selle mugavus ja ilu seisneb selles, et isegi kui rool läheb katki või eemaldate selle klastrist, ei kao teie teenused kuhugi, kuna rool toimib sisuliselt ainult süsteemi käivitamiseks. Seejärel vastutab Kubernetes ise teenuste toimivuse ja oleku eest.

Sellest saime ka aru mallistamine, mida olime varem sunnitud ise tegema, lisades oma konfiguratsioonidesse jinja, on üks tüüri põhiomadusi. Kõik konfiguratsioonid, mille oma süsteemide jaoks loote, salvestatakse tüüridesse mallide kujul, mis on pisut sarnased Jinjaga, kuid tegelikult kasutatakse Go-keele malli, milles helm on kirjutatud, nagu Kubernetes.

Helm lisab meie jaoks veel mõned mõisted.

Joonis - see on teie teenuse kirjeldus. Teistes paketihaldurites nimetatakse seda paketiks, komplektiks või millekski sarnaseks. Siin nimetatakse seda diagrammiks.

Väärtused on muutujad, mida soovite mallide põhjal oma konfiguratsioonide koostamiseks kasutada.

Vabastage. Iga kord, kui tüüri abil juurutatud teenus saab väljalaske järkjärgulise versiooni. Helm mäletab, milline oli teenuse konfiguratsioon eelmises versioonis, enne seda väljalaske jne. Seetõttu, kui teil on vaja tagasipööramist, käivitage lihtsalt tüüri tagasikutsumise käsk, suunates selle eelmisele versioonile. Isegi kui vastav konfiguratsioon teie hoidlas pole tagasipööramise ajal saadaval, jätab juht siiski meelde, mis see oli, ja taastab teie süsteemi olekusse, milles see oli eelmises versioonis.

Helmi kasutamisel muutuvad Kubernetese tavalised konfiguratsioonid ka mallideks, milles on võimalik kasutada muutujaid, funktsioone ja rakendada tingimuslauseid. Nii saate koguda oma teenuse konfiguratsiooni sõltuvalt keskkonnast.

Praktikas otsustasime teha asju natuke teisiti kui Nomadiga. Kui Nomadis olid nii juurutamise konfiguratsioonid kui ka meie teenuse juurutamiseks vajalikud n-muutujad salvestatud ühte hoidlasse, siis siin otsustasime need jagada kaheks eraldi hoidlaks. „Juurutus” hoidla salvestab ainult juurutamiseks vajalikke n-muutujaid ja „helm” hoidla salvestab konfiguratsioonid või diagrammid.

Mida see meile andis?

Hoolimata asjaolust, et me ei salvesta konfiguratsioonifailides endas mingeid tõeliselt tundlikke andmeid. Näiteks andmebaaside paroolid. Need on Kuberneteses saladustena talletatud, kuid sellegipoolest on seal siiski teatud asju, millele me ei taha kõigile ligipääsu anda. Seetõttu on juurdepääs „juurutamise” hoidlale piiratum ja „juhi” hoidla sisaldab lihtsalt teenuse kirjeldust. Sel põhjusel pääseb sellele turvaliselt juurde laiem hulk inimesi.

Kuna meil pole mitte ainult tootmist, vaid ka muid keskkondi, saame tänu sellele eraldamisele taaskasutada oma tüürikaarte teenuste juurutamiseks mitte ainult tootmises, vaid ka näiteks QA keskkonda. Isegi nende kasutamiseks kohapeal Minikube - see on mõeldud Kubernetese kohalikuks käitamiseks.

Igas hoidlas jätsime iga teenuse jaoks jaotuse eraldi kataloogidesse. See tähendab, et igas kataloogis on mallid, mis on seotud vastava diagrammiga ja kirjeldavad ressursse, mida tuleb meie süsteemi käitamiseks kasutada. Jätsime juurutamise hoidlasse ainult envsid. Antud juhul me ei kasutanud mallimist jinja abil, sest helm ise tagab mallimise karbist välja – see on üks selle peamisi funktsioone.

Jätsime juurutusskripti - deploy.sh, mis lihtsustab ja standardiseerib käivitamist tüüri abil juurutamiseks. Seega kõigile, kes soovivad juurutada, näeb juurutamisliides välja täpselt samasugune nagu Nomadi kaudu juurutamisel. Sama deploy.sh, teie teenuse nimi ja koht, kus soovite selle juurutada. See põhjustab rooli käivitumise sisemiselt. See omakorda kogub mallidest konfiguratsioonid, lisab neisse vajalikud väärtuste failid, seejärel juurutab need, käivitades need Kubernetesesse.

Järeldused

Kubernetese teenus näib olevat keerulisem kui Nomad.

Siin tuleb väljaminev liiklus Ingressi. See on lihtsalt eesmine kontroller, mis võtab üle kõik päringud ja saadab need seejärel päringuandmetele vastavatele teenustele. See määrab need konfiguratsioonide põhjal, mis on osa teie rakenduse kirjeldusest ja mille arendajad ise määravad. Teenus saadab päringud oma kaustadesse, st konkreetsetesse konteineritesse, tasakaalustades sissetulevat liiklust kõigi sellesse teenusesse kuuluvate konteinerite vahel. Ja loomulikult ei tohiks me unustada, et me ei tohiks võrgutasemel turvalisusest kuhugi minna. Seetõttu toimib segmenteerimine Kubernetese klastris, mis põhineb sildistamisel. Kõigil teenustel on teatud sildid, millega on seotud teenuste juurdepääsuõigused teatud välistele/sisemistele ressurssidele klastris või väljaspool.

Üleminekut tehes nägime, et Kubernetes on olemas kõik Nomadi võimalused, mida olime varem kasutanud, ja lisaks lisati palju uut. Seda saab laiendada pistikprogrammide ja tegelikult kohandatud ressursitüüpide kaudu. See tähendab, et teil on võimalus mitte ainult kasutada midagi, mis on Kubernetesiga kaasas, vaid luua oma ressurss ja teenus, mis teie ressurssi loeb. See annab teile lisavõimalusi süsteemi laiendamiseks ilma Kubernetese uuesti installimise ja muutmist nõudmata.

Sellise kasutuse näide on Prometheus, mis töötab meie Kubernetese klastris. Selleks, et see hakkaks konkreetselt teenuselt mõõdikuid koguma, peame teenuse kirjeldusse lisama täiendavat tüüpi ressursi, nn teenusemonitori. Kuna Prometheus suudab Kubernetesis käivitamisel lugeda kohandatud ressursitüüpi, hakkab see automaatselt uuest süsteemist mõõdikuid koguma. See on üsna mugav.

Esimene kasutuselevõtt Kubernetesesse toimus 2018. aasta märtsis. Ja selle aja jooksul ei kogenud me sellega kordagi probleeme. See töötab üsna stabiilselt ilma oluliste vigadeta. Lisaks saame seda veelgi laiendada. Tänaseks on meil piisavalt selle võimalusi ja Kubernetese arengutempo meeldib meile väga. Praegu on Kubernetesis üle 3000 konteineri. Klaster hõlmab mitut sõlme. Samal ajal on see hooldatav, stabiilne ja väga juhitav.

Allikas: www.habr.com