Tere kõigile! Minu nimi on Pavel Agaletckiy. Olen tiimi juht, mis arendab Lamoda tarnesüsteemi. Aastal 2018 esinesin konverentsil HighLoad++, ja täna soovin tutvustada oma ettekande transkripti.

Minu teema on pühendatud meie ettevõtte kogemusele süsteemide ja teenuste juurutamisel erinevates keskkondades. Alustame meie eelajaloolistest aegadest, kui juurutati kõik süsteemid tavapärastel virtuaalserveritel, ning liigume järk-järgult üle Nomadilt Kubernetesesse juurutamisele. Räägin, miks me seda tegime ja millised probleemid meil protsessi käigus olid.

Rakenduste juurutamine VM-idele

Alustame sellest, et 3 aastat tagasi juurutati kõik ettevõtte süsteemid ja teenused tavapärastel virtuaalserveritel. Tehniliselt oli see korraldatud nii, et kogu meie süsteemide kood olid kogutud automatiseeritud koostamise vahendite abil Jenkins'i kaudu. Ansible'i abil laaditi see meie versioonihaldussüsteemist juba virtuaalserveritesse. Igal süsteemil, mis meie ettevõttes oli, juurutati vähemalt kahte serverisse: üks neist oli head, teine tail. Need kaks süsteemi olid omavahel täiesti identsed kõiki seadistuste, jõudluse, konfiguratsiooni ja muude omaduste osas. Erinevus nende vahel oli vaid see, et head sai kasutaja liiklust, samas kui tail ei saanud kunagi kasutaja liiklust.

Miks see nii tehti?

Kui me juurutame uusi versioone meie rakendusest, soovisime tagada sujuva juurutamise võimaluse, see tähendab, et ilma kasutajatele märgatavate tagajärgedeta. See saavutati sellega, et järgmine koostatud versioon jagati Ansible'i kaudu tail'ile. Seal said juurutamisega tegelejad kontrollida ja veenduda, et kõik on korras: kõik mõõdikud, osad ja rakendused töötavad; vajalikud skriptid käivitatakse. Alles pärast seda, kui nad veendusid, et kõik on hästi, suunati liiklus. See hakkas minema serverile, mis oli varem olnud tail. Ja see, mis oli varem olnud head, jäi ilma kasutajaliikluseta, samas kui sellel oli eelmine versioon meie rakendusest.

Seega oli see kasutajatele läbipaistev. Kuna vahetus toimub hetkega, kuna see on lihtsalt koormuse tasakaalustaja vahetamine. Eelmine versioon on väga lihtne tagasi võtta, lihtsalt vahetades koormuse tasakaalustajat tagasi. Samuti saime veenduda rakenduse võimes tootmises veel enne, kui kasutajate liiklus sellele suundub, mis oli väga mugav.

Milliseid eeliseid me kõik selle juures nägime?

1. Esiteks, see on piisavalt lihtsalt toimiv. Kõigile on selge, kuidas selline juurutusmehhanism töötab, sest enamik inimesi on kunagi juurutanud tavaliselt virtuaalsetele serveritele.
2. See on piisavalt usaldusväärne, kuna juurutustehnoloogia on lihtne ja testitud tuhandeid ettevõtteid. Miljonid serverid juurutatakse just nii. Midagi on keeruline katki teha.
3. Ja lõpuks saime aatomse juurutuse. Juurutused toimuvad kasutajatele momentaalselt, ilma märgatava etapita vana ja uue versiooni vahel.

Kuid kogu selle juures nägime ka mõningaid puuduseid:

1. Lisaks tootmisüsteemile, arendussüsteemile, on olemas ka teised keskkonnad. Näiteks qa ja eeltoodang. Sellel hetkel oli meil palju servereid ja umbes 60 teenust. Sel põhjusel oli vajalik iga teenuse jaoks hoida selle jaoks asjakohast versiooni virtuaalsest masinast. Ja kui soovite uuendada teeke või installida uusi sõltuvusi, peate seda tegema kõikides keskkondades. Samuti pidi sünkroniseerima aja, mil kavatsete juurutada järgmise uue versiooni oma rakendusest, ajaga, mil devops teostab keskkonna vajalikud konfiguratsioonid. Sellisel juhul on lihtne sattuda olukorda, kus keskkondade vahel on koos erinevusi järjestikku. Näiteks qa keskkonnas on teised teekide versioonid ja tootmises teised, mis toob kaasa probleeme.
2. Sõltuvuste uuendamise keerukus teie rakenduses. See ei sõltu teist, vaid teisest meeskonnast. Nimelt, devops meeskonnast, kes toetab servereid. Peate neile esitama vastava ülesande ja kirjeldama, mida soovite teha.
3. Sellest ajast alates soovisime jagada suured monoliidid väiksemateks teenusteks, kuna mõistsime, et neid hakkab järjest rohkem olema. Tol hetkel oli neid juba üle 100. Iga uue teenuse jaoks oli vajalik luua eraldi uus virtuaalmasin, mida tuli samuti hallata ja juurutada. Lisaks sellele ei piisanud ühest masinast, vaid vähemalt kahest. Kõigile nendele lisandus QA-keskkond. See tekitab probleeme ja muudab teie uute süsteemide loomise ja käivitamise keerukaks, kulukaks ja ajamahukaks protsessiks.

Seetõttu otsustasime, et oleks mugavam liikuda tavalisest virtuaalmasinate juurutamisest oma rakenduste juurutamisele Dockeris. Dockeri olemasolul on vajalik süsteem, mis suudab rakenduse klastris käivitada, kuna te ei saa lihtsalt konteinerit üles tõsta. Tavaliselt soovitakse jälgida, kui palju konteinerite on üles tõstetud, et need automaatselt käivituksid. Seetõttu pidi meil valima juhtimissüsteemi.

Me mõtlesime pikalt, millist neist võiks kasutada. Probleemiks oli see, et tol hetkel oli meie tavapäraste virtuaalserverite juurutamistehnoloogia pisut aegunud, kuna seal olid vanad operatsioonisüsteemide versioonid. Ühel hetkel oli seal isegi FreeBSD, mida ei olnud just mugav hallata. Me mõistsime, et peame Dockerisse võimalikult kiiresti migreerima. Meie devopsid vaatasid oma olemasolevat kogemust erinevate lahendustega ja valisid süsteemi nimega Nomad.

Üleminek Nomadile

Nomad on ettevõtte “HashiCorp” toode. Nad on tuntud ka teiste oma lahenduste poolest:

«Consul» — teenuste avastamiseks mõeldud tööriist.

«Terraform» — serverihalduse süsteem, mis võimaldab teil neid konfigureerida infrastruktuuri koodina.

«Vagrant» — võimaldab teil hankida virtuaalmasinaid kohapeal või pilves, kasutades teatud konfigureerimisfaile.

Tol hetkel tundus Nomad piisavalt lihtne lahendus, kuhu saaks kiiresti üle minna, ilma kogu infrastruktuuri muutmata. Lisaks sellele on seda lihtne õppida. Seetõttu valisimegi selle meie konteineri filtreerimise süsteemiks.

Mida on üldse vaja, et teie süsteemi Nomadis juurutada?

1. Esiteks on vajalik docker image teie rakendust. Tuleb see koguda ning paigutada docker'i piltide hoidlasse. Meie puhul on selleks artifactory — selline süsteem, mis võimaldab erinevaid artefakte erinevat tüüpi sinna saata. See suudab hoida arhiive, docker'i pilte, PHP composer pakette, NPM pakette jms.
2. Samuti on vajalik konfiguratsioonifail, mis ütleb Nomadile, mida, kuhu ja kui palju soovite juurutada.

Kui räägime Nomadist, kasutab see informatiivse faili formaadina HCL keelt, mis tähistab HashiCorp Configuration Language. See on Yaml'i ülehulk, mis võimaldab teil oma teenust Nomadi terminoloogias kirjeldada.

See võimaldab teil öelda, kui palju konteinerite soovite juurutada, millistest piltidest nendele erinevaid parameetreid juurutamisel anda. Nii toidate selle faili Nomadile ja see käivitab vastavalt sellele konteinerid tootmises.

Meie puhul mõistsime, et lihtsalt iga teenuse jaoks täiesti identsete HCL-failide kirjutamine poleks väga mugav, kuna teenuseid on palju ja neid tahaks vahel uuendada. On juhtumeid, kui üks teenus ei ole juurutatud ühes eksemplaris, vaid mitmetes erinevates. Näiteks on üks meie tootmises olevatest süsteemidest rohkem kui 100 instantsi tootmises. Need käivitatakse samadest piltidest, kuid erinevad konfiguratsiooni seadetest ja konfiguratsioonifailidest.

Seetõttu otsustasime, et meil oleks mugav hoida kõiki meie juurutamise konfiguratsioonifaile ühes ühises hoidlas. Nii muutuvad need läbipaistvaks: neid on lihtne hallata ja näha, millised süsteemid meil on. Vajadusel ei ole ka raske midagi uuendada või muuta. Uue süsteemi lisamine ei valmista samuti raskusi — piisab lihtsalt, kui luua konfiguratsioonifail uue kausta sisse. Selles kaustas on failid: service.hcl, mis sisaldab meie teenuse kirjeldust, ja mõned env-failid, mis võimaldavad seda teenust, olles tootmises juurutatud, seadistada.

Kuid mõned meie süsteemidest on tootmises juurutatud mitte ühes, vaid mitmes eksemplaris korraga. Seega otsustasime, et meile oleks mugav hoida mitte puhtaid konfiguratsioonifaile, vaid nende mallitud kujul. Ja mallimise keeleks valisime jinja 2. Sellise vormingu abil salvestame nii teenuse konfiguratsioonid kui ka selleks vajalikud env-failid.

Lisaks oleme paigutanud projektide ühisesse hoidlasse üldise skripti, mis võimaldab teie teenust käivitada ja tootmisse paigaldada sobivasse keskkonda ja sihtkohta. Kui oleme oma HCL-konfiguratsiooni muundanud malliks, siis tundub, et see HCL-fail, mis oli seni tavaline Nomad'i konfiguratsioon, on nüüd pisut muutunud.

See tähendab, et oleme asendanud teatud konfiguratsiooni muutujad variablitega, mis pärinevad env-failidest või muudest allikatest. Lisaks oleme saanud võimaluse koguda HCL-faile dünaamiliselt, st saame rakendada mitte ainult tavalisi variablite sisestusi. Kuna jinja toetab tsükleid ja tingimusi, saame seal ka luua konfiguratsioonifaile, mis muutuvad sõltuvalt sellest, kuhu oma rakendusi paigaldate.

Näiteks soovite paigaldada oma teenuse eeltootmisse ja tootmisse. Oletame, et te ei soovi eeltootmises käivitada cron-skripte, vaid tahate lihtsalt näha teenust eraldi domeenil, et veenduda, et see töötab. Igaühele, kes teenust paigaldab, tundub protsess väga lihtne ja läbipaistev. Piisab, kui käivitate fail deploy.sh, märkite, millist teenust soovite paigaldada ja kuhu sihtkohta. Näiteks soovite paigaldada mingit süsteemi Venemaale, Valgevenesse või Kasahstani. Selleks piisab lihtsalt ühe parameetri muutmisest ja teil on õige konfiguratsioonifail koostatud.

Kui Nomad teenus on teie klastrisse paigaldatud, näeb see välja järgmine.

Esiteks vajate välistingimustes mõnda tasakaalustajat, mis jätab kogu kasutajatrafiku enda alla. See töötab koos Consuliga ja küsib temalt, kus, millisel noodil, millise IP-aadressiga hulgast asub konkreetne teenus, mis vastab mingile domeeninimele. Teenused Consulis ilmuvad otse Nomad'ist. Kuna need on sama ettevõtte tooted, on nad omavahel hästi seotud. Võib öelda, et Nomad oskab kohe registreerida kõik selles käivitatud teenused Consulis.

Pärast seda, kui teie väline koormuse jaotaja saab teada, kuhu teenusesse suunata liiklust, edastab ta selle vastavasse konteinerisse või mitmesse konteinerisse, mis vastavad teie rakendusele. Loomulikult tuleb sellega kaasas mõelda ka turvalisusele. Isegi kui kõik teenused käivitatakse samadel virtuaalmasinatel konteinerites, tuleb tavaliselt keelata tasuta juurdepääs igast teenusest igale teisele. Oleme seda saavutanud segmentatsiooni abil. Iga teenus käivitati oma virtuaalses võrgus, kus olid määratud marsruutimise reeglid ja reeglid juurdepääsu lubamiseks/keelamiseks teistele süsteemidele ja teenustele. Need võisid asuda kas selle klastris või väljaspool seda. Näiteks, kui soovite keelata teenusel teatud andmebaasi ühendamise, saab seda teha segmentatsiooni abil võrgu tasemel. Seega pole teil isegi eksikombel võimalik teie testkeskkonnast tootmisandmebaasi ühenduda.

Kui palju maksis meile inimressursside poolest ülemineku protsess?

Umbes 5–6 kuud võttis kogu ettevõtte üleminek Nomadile. Me tegime ülemineku teenuste kaupa, kuid piisavalt kiiresti. Iga meeskond pidi looma oma konteinerid teenuste jaoks.

Meie lähenemine on selline, et iga meeskond vastutab iseseisvalt oma süsteemide docker piltide eest. DevOps tagab vajalikud ühisinfrastruktuurid deploymiseks, st klastrite toetamine, CI-süsteemi toetamine ja nii edasi. Sel ajal oli meil üle 60 süsteemi, mis kolisid Nomadisse, kokku töötati välja umbes 2000 konteinerit.

DevOps vastutab kogu infrastuktuuri eest, mis on seotud deploymise ja serveritega. Iga arendustiim vastutab omakorda oma konkreetse süsteemi konteinerite rakendamise eest, kuna just nemad teavad, mida nad selle või tolle konteineri puhul vajavad.

Põhjused, miks loobuda Nomadist

Milliseid eeliseid me saime, liikudes Nomadi ja dockeriga deploymise suunas?

1. Meie tagasime ühtlased tingimused kõikides keskkondades. Arenduses, QA-keskkonnas, ettevalmistuses ja tootmises kasutatakse samu konteinerite pilte, samade sõltuvustega. Seega on teil praktiliselt null võimalust, et tootmisse satub midagi, mida te ei ole varem kohalikult või testkeskkonnas testinud.
2. Samuti selgus, et on piisavalt lihtne lisada uus teenus. Iga uus süsteem on juurutamise vaatenurgast väga lihtne käivitada. Piisab, kui minna konfiguratsioonide hoidlasse, lisada sinna järjekordne konfogi teie süsteemi jaoks ja kõik on valmis. Saate juurutada oma süsteemi tootmisse ilma DevOps'i lisapüüdlusteta.
3. Kogu konfiguratsioonifailid ühes ühises hoidlas olid ülevaatavad. Hetkel, kui me juurutasime oma süsteeme virtuaalserverite, kasutasime Ansible'it, kus konfogid asusid samas hoidlas. Siiski oli enamikule arendajatest sellega töötamine mõnevõrra keerulisem. Siin on konfiguratsioonide ja koodi kogus, mida peate teenuse juurutamiseks lisama, oluliselt väiksem. Pluss seisukohalt on DevOps'il seda väga lihtne parandada või muuta. Näiteks uue versiooniga, näiteks Nomadiga, võivad nad lihtsalt ja massiliselt uuendada kõiki operatiivfailide, mis asuvad samas kohas.

Kuid me seisime silmitsi ka mitmete puudustega:

Selgus, et me ei suutnud saavutada sujuvust juurutustes Nomadi korral. Kui konteinerid erinevatest tingimustest välja vabastatakse, võis juhtuda, et see käivitati ja Nomad nägi seda kui valmisolekut liikluse vastuvõtmiseks. See juhtus veel enne, kui rakendus selle sees jõudis käivituda. Seetõttu hakkas süsteem lühikeseks ajaks andma 500-e vigu, kuna liiklus hakkas minema konteinerisse, mis ei olnud veel valmis selle vastuvõtmiseks.

Me kohtasime mõningaid büge. Peamine probleem seisneb selles, et Nomad ei suuda hästi töödelda suurt klastrit, kui teil on palju süsteeme ja konteinerit. Kui soovite võtta hooldusse ühe serveri, mis on klastris Nomad, on üsna suur tõenäosus, et klaster ei tunne end hästi ja puruneb tükkideks. Osa konteineritest võib näiteks kukkuda ja mitte tõusta — see võib teile hiljem väga kalliks maksma minna, kui kõik teie tootmisse kuuluvad süsteemid asuvad just Nomadi haldusalas.

Seetõttu otsustasime mõelda, kuhu edasi minna. Sel hetkel olime juba palju paremini teadlikud, mida tahame saavutada. Nimelt: tahame usaldusväärsust, natuke rohkem funktsioone kui Nomad pakub, ja küpsemat, stabiilsemat süsteemi.

Selles osas langetatud valik langes Kubernetes'e kasuks, kuna see on kõige populaarsem platvorm klastrite käitamiseks. Eriti arvestades, et meie konteinerite suurus ja arv olid piisavalt suured. Selliste eesmärkide saavutamiseks tundus Kubernetes olevat kõige sobivam süsteem, mida saime vaadata.

Üleminek Kubernetes'e

Räägin veidi sellest, millised on põhikontseptsioonid Kubernetes'es ja kuidas need erinevad Nomad'st.

Esiteks on Kubernetes'e kõige alusmõisted pod. Pod — see on ühe või mitme konteineri grupp, mis käivitub alati koos. Ja nad töötavad justkui alati rangelt ühel virtuaalsel masinal. Nad on üksteisele juurdepääsetavad IP-aadressil 127.0.0.1 erinevatel portidel.

Oletame, et teil on PHP-rakendus, mis koosneb nginx'ist ja php-fpm'ist – klassikaline skeem. Tõenäoliselt soovite, et nii nginx kui php-fpm konteinerid oleksid alati koos. Kubernetes võimaldab seda saavutada, kirjeldades neid ühise pod'ina. Just seda me ei saanud Nomad'i abil.

Teine mõisted on deployment. Asi on selles, et pod iseenesest on efemeerne asi, see käivitub ja kaob. Kas soovite kõigepealt tapada kõik oma eelnevad konteinerid ja seejärel käivitada kohe uued versioonid või soovite neid järk-järgult välja anda – just selle protsessi eest vastutab mõisted deployment. See kirjeldab, kuidas te oma pod’e deponeerite, kui palju ja kuidas neid uuendada.

Kolmas mõisted on teenus. Teie teenus on tegelikult teie süsteem, mis võtab vastu teatud liikluse ja suunab selle ühe või mitme teie teenusele vastava podi juurde. See tähendab, et saate öelda, et kogu sissetulev liiklus selle kindla nimega teenusele tuleb suunata just nendele podidele. Ja see tagab teile ka koormuse jaotuse. Seega, kui käivitate kaks teie rakenduse poodi, ja kogu sisse tulev liiklus jaotatakse ühtlaselt nende teenusega seotud podide vahel.

Ja neljas põhikontseptsioon — Ingress. See on teenus, mis käivitatakse Kubernetes klastris. See toimib kui väline koormuse tasakaalustaja, mis võtab kõik päringud enda peale. Kubernetes Ingress API kaudu saab määratleda, kuhu need päringud saatma peab. Ja ta teeb seda väga paindlikult. Saate öelda, et kõik selle hosti ja kindla URL-i päringud saadetakse sellele teenusele. Need päringud, mis tulevad sellele hostile ja teisele URL-ile, saadetakse aga teisele teenusele.

Kõige ägedam asi arendaja seisukohalt on see, et saate seda kõike ise hallata. Seades Ingressi konfiguratsiooni, saate kogu liikluse, mis tuleb kindla API-le, suunata eraldi konteineritesse, mis on näiteks kirjutatud Go-s. Ja see liiklus, mis tuleb sama domeeni, kuid teisele URL-ile, suunatakse konteineritesse, mis on kirjutatud PHP-s, kus on palju loogikat, kuid nad ei ole eriti kiired.

Kui võrrelda neid mõisteid Nomadi kontekstis, siis võib öelda, et esimesed kolm mõistet on kõik koos teenus. Viimane mõisted Nomadi puhul aga puudub. Selle asemel kasutasime välist koormuse tasakaalustajat: see võib olla haproxy, nginx, nginx+ ja nii edasi. Kube puhul ei pea te seda täiendavat mõistet eraldi tooma. Siiski, kui vaadata Ingressi seest, siis see on kas nginx, haproxy või traefik, kuid nagu ka Kubernetese sisse ehitatud.

Kõik, mida ma olen kirjeldanud, on põhimõtteliselt ressursid, mis eksisteerivad Kubernetese klastris. Nende kirjeldamiseks kube'is kasutatakse yaml-formaati, mis on loetavam ja harjumuseküllasem kui HCL-failid Nomadi puhul. Kuid struktuurselt kirjeldavad need näiteks pod-i sama asja. Nad ütlevad – tahan deployida sellised pod'id sinna, koos selliste imagetega, sellises koguses.

Lisaks sellele mõistsime, et me ei soovi iga eraldi ressursi käsitsi loomisega tegeleda: deployment, teenused, Ingress jne. Selle asemel soovisime, et saaksime iga meie süsteemi Kubernetes'e terminite järgi kirjeldada, et ei peaks käsitsi kõiki vajalikke ressursi sõltuvusi õigesse järjekorda taastama. Sellise süsteemina, mis võimaldas meil seda teha, valisime Helm.

Peamised mõisted Helm'is

Helm on paketihaldur Kubernetes'e jaoks. See sarnaneb väga programmikeelte paketihaldurite tööle. Need võimaldavad sul hoida teenust, mis koosneb näiteks nginx'i deployment'ist, php-fpm deployment'ist, Ingress'i konfiguratsioonist, configmap'idest (see on objekt, mis võimaldab sul määrata env'i ja muid parameetreid oma süsteemi jaoks) nii-öelda chart'idena. Samal ajal töötab Helm Kubernetes'e kohal. See ei ole eraldiseisev süsteem, vaid lihtsalt veel üks teenus, mis töötab klusteris. Sa suhtled temaga tema API kaudu käsurea käsu abil. Tema mugavus ja ilu seisneb selles, et isegi kui helm puruneb või sa eemaldad selle klastrist, ei kao sinu teenused, kuna helm teenib tegelikult vaid süsteemi käivitamiseks. Teenuste toimivuse ja oleku eest vastutab edaspidi Kubernetes.

Samuti mõistsime, et mallimine, mida olime varem sunnitud ise jinja kaudu oma konfiguratsioonidesse lisama, on helm'i üks peamisi võimalusi. Kõik konfiguratsioonid, mille sa oma süsteemide jaoks loote, hoitakse helm'is mallidena, mis sarnanevad natuke jinja'le, kuid tegelikult kasutavad Go keele mallimist, millel helm on kirjutatud, nagu ka Kubernetes.

Helm lisab meile veel paar täiendavat mõistet.

Diagramm — see on sinu teenuse kirjeldus. Teistes paketihaldurites nimetataks seda paketiks, bundle'iks või millegiks sarnaseks. Siin kutsutakse seda chart'iks.

Values – nad on muutujad, mida soovid kasutada oma konfiguratsioonide koostamiseks mallidest.

Release. Iga kord, kui teenus, mis on paigaldatud helm'i abil, saab inkrementaalse versiooni vabastusest. Helm mäletab, milliseks konfiguratsioon teenus oli eelmisel, eel-eelmisel vabastamisel jne. Seetõttu, kui on vaja tagasi minna, piisab helm callback käskluse täitmisest, määrates selle eelneva vabastuse versiooni. Isegi kui vastav konfiguratsioon teie hoidlas ei ole tagasimineku ajal saadaval, mäletab helm ikkagi, milline see oli, ja viib teie süsteemi tagasi eelneva vabastuse olekusse.

Kui me kasutame helm'i, muutuvad tavalised konfiguratsioonid Kuberneteses samuti mallideks, kus on võimalik kasutada muutujaid, funktsioone ja rakendada tingimuslikke operaatorite. Nii saate oma teenuse konfiguratsiooni koguda vastavalt keskkonnale.

Kä praktikas otsustasime toimida veidi teisiti kui Nomadi puhul. Kui Nomadi puhul hoiti ühes hoidlas nii paigalduskonfiguratsioone kui ka n-muutujaid, mis on vajalikud meie teenuse paigaldamiseks, siis siin otsustasime need eraldada kahte eraldi hoidlasse. Hoidlas «deploy» hoitakse ainult n-muutujaid, mis on vajalikud paigalduseks, ja hoidlas «helm» hoitakse konfiguratsioone või chart'e.

Mida see meile andis?

Kuna me ei hoia endi konfiguratsioonifailides tõeliselt tundlikke andmeid, näiteks andmebaaside paroole. Need hoitakse Kuberneteses secrets kujul, kuid seal on ikkagi eraldi asju, millele me ei taha kõigile juurdepääsu anda. Seetõttu on juurdepääs hoidla «deploy» rohkem piiratud, samas kui hoidla «helm» sisaldab lihtsalt teenuse kirjeldust. Selle tõttu saab sellele ohutult anda juurdepääsu laiemale ringile.

Kuna meil on mitte ainult tootmis- vaid ka teisi keskkondi, siis tänu sellele eraldamisele saame uuesti kasutada meie helm chart'e, et paigaldada teenuseid mitte ainult tootmisse, vaid näiteks QA-keskkonda. Isegi nende kohapeal käivitamiseks kasutades Minikube — see on selline asi kohaliku Kubernetes'e käivitamiseks.

Iga repootris oleme jaganud iga teenuse jaoks eraldi katalooge. See tähendab, et iga katalooge sisaldab mallide, mis kuuluvad vastavale graafikule ja kirjeldavad ressursse, mis tuleb meie süsteemi käivitamiseks juurutada. Repositooriumis "deploy" on meil ainult env-d. Sellisel juhul ei kasutanud me jinja kaudu mallide koostamist, kuna helm pakub mallide koostamist otse – see on üks selle põhifunktsioone.

Olemas on juurutamiseks mõeldud skript – deploy.sh, mis lihtsustab ja standardiseerib juurutamise käivitamist helmiga. Seega, igaühele, kes soovib juurutada, näeb juurutamise liides välja täpselt sama, nagu see oli Nomadi kaudu juurutamisel. Sama deploy.sh, teie teenuse nimi ja koht, kuhu soovite selle juurutada. See toob kaasa, et helm käivitatakse. See kogub seejärel konfiguratsioonid mallidest, asendab vajalikud value-failid ja juurutab need Kubernetesesse.

Järeldused

Kubernetes teenus näeb keerulisem välja kui Nomad.

Siin tuleb väljuv liiklus Ingressi. See on täpselt front-controller, kes võtab kõik päringud vastu ja saadab need hiljem vastavatele teenustele vastavalt päringu andmetele. Ta määrab need konfiguratsioonide põhjal, mis on osa teie rakenduse kirjeldusest helmiga ja mida arendajad ise määratlevad. Teenus saadab päringud oma pod-idele, st konkreetsetele konteineritele, tasakaalustades sisenevat liiklust kõikide konteinerite vahel, mis kuuluvad antud teenusele. Ja loomulikult ei tohi unustada, et turvalisusest võrgu tasemel ei saa me lahkuda. Seetõttu töötab Kubernetes klastris segmentatsioon, mis põhineb märgistamisel. Kõigil teenustel on kindlad sildid, millega on seotud teenuste juurdepääsu õigused nende või teiste välistest/sisestest ressurssidest klastris või väljaspool.

Tehes olles, nägime, et Kubernetes omab kõiki Nomadi võimalusi, mida olime varem kasutanud, ning lisab palju uut. Seda saab laiendada pluginatega ja praktiliselt kohandatud ressursside tüüpide kaudu. See tähendab, et teil on võimalus mitte ainult kasutada midagi, mis tuleb Kubernetesiga standardina, vaid luua omaenda ressurss ja teenus, mis seda ressurssi loeb. See avab täiendavad laiendusvõimalused teie süsteemi jaoks ilma Kubernetes'e uuesti installimata ja muutusteta.

Sellise kasutamise näiteks on Prometheus, mis töötab meie Kubernetes'i klastris. Selleks, et see hakkaks koguma mõõdikuid mõnest teenusest, peame teenuse kirjeldusse lisama täiendava ressursitüübi, nn teenuse jälgija. Prometheus suudab peaaegu automaatselt alustada uue süsteemi mõõdikute kogumist, kuna see oskab lugeda kohandatud ressursside tüüpe töötades Kubernetes'is. See on piisavalt mugav.

Esimene deploy, mille me Kubernetes'e puhul tegime, oli märtsis 2018. Ja selle aja jooksul pole me kunagi selle kasutamisel mingeid probleeme kogenud. See töötab piisavalt stabiilselt ja õigetel põhjustel teeme otsekohe laiendusi. Tänasel päeval on meil piisavalt võimalusi, mis seal on, ja meile meeldivad Kubernetes'e arengukiirus. Hetkel on Kubernetes'is üle 3000 konteineri. Klaster hõlmab mitut Node'i. Samal ajal on see hallatav, stabiilne ja väga kontrollitav.

Allikas: habr.com