Pozdravljeni vsi skupaj! Moje ime je Pavel Agaletsky. Delam kot team lead v ekipi, ki razvija dostavni sistem Lamoda. Leta 2018 sem govoril na konferenci HighLoad++, danes pa bi rad predstavil prepis svojega poročila.

Moja tema je posvečena izkušnjam našega podjetja pri uvajanju sistemov in storitev v različna okolja. Od prazgodovine, ko smo vse sisteme uvedli v navadne virtualne strežnike, do postopnega prehoda iz Nomada v uvedbo v Kubernetes. Povedal vam bom, zakaj smo to storili in kakšne težave smo imeli pri tem.

Uvajanje aplikacij v VM

Začnimo z dejstvom, da so bili pred 3 leti vsi sistemi in storitve podjetja nameščeni na običajnih virtualnih strežnikih. Tehnično je bilo organizirano tako, da je bila vsa koda za naše sisteme shranjena in sestavljena z avtomatskimi orodji za sestavljanje, z jenkins. Z uporabo Ansible je bil iz našega sistema za nadzor različic uveden na virtualne strežnike. Poleg tega je bil vsak sistem, ki ga je imelo naše podjetje, razporejen na vsaj 2 strežnika: enega na čelu, drugega na repu. Ta dva sistema sta bila povsem enaka drug drugemu v vseh svojih nastavitvah, moči, konfiguraciji itd. Edina razlika med njima je bila, da je glava prejela uporabniški promet, rep pa nikoli.

Zakaj je bilo to storjeno?

Ko smo uvajali nove izdaje naše aplikacije, smo želeli zagotoviti brezhibno uvajanje, torej brez opaznih posledic za uporabnike. To je bilo doseženo zaradi dejstva, da je bila naslednja prevedena izdaja z uporabo Ansible uvedena do konca. Tam so lahko ljudje, ki so sodelovali pri uvajanju, preverili in se prepričali, da je vse v redu: vse metrike, razdelki in aplikacije delujejo; zaženejo se potrebni skripti. Šele ko so se prepričali, da je vse ok, so promet preusmerili. Začel je iti na strežnik, ki je bil prej tail. In tisti, ki je bil prej glavni, je ostal brez uporabniškega prometa, na njem pa še vedno prejšnja različica naše aplikacije.

Tako je bilo za uporabnike brezhibno. Ker je preklop trenuten, saj gre preprosto za preklop balanserja. Zelo enostavno se lahko vrnete na prejšnjo različico tako, da preprosto preklopite nazaj na balanser. Prav tako smo lahko preverili, ali je bila aplikacija sposobna produkcije, še preden je prejela uporabniški promet, kar je bilo zelo priročno.

Kakšne prednosti smo videli v vsem tem?

1. Najprej je dovolj preprosto deluje. Vsi razumejo, kako deluje takšna shema uvajanja, saj je večina ljudi že kdaj uvedla na običajne virtualne strežnike.
2. To je dovolj zanesljivo, saj je tehnologija uvajanja preprosta, preizkušeno s strani na tisoče podjetij. Na ta način je nameščenih na milijone strežnikov. Težko je kaj zlomiti.
3. In končno smo lahko dobili atomske postavitve. Uvajanja, ki se izvajajo hkrati za uporabnike, brez opazne stopnje preklapljanja med staro in novo različico.

Toda pri vsem tem smo opazili tudi več pomanjkljivosti:

1. Poleg proizvodnega okolja, razvojnega okolja, obstajajo še druga okolja. Na primer, qa in predprodukcija. Takrat smo imeli veliko strežnikov in približno 60 storitev. Zaradi tega je bilo potrebno za vsako storitev vzdržujte najnovejšo različico zanjo navidezni stroj. Poleg tega, če želite posodobiti knjižnice ali namestiti nove odvisnosti, morate to narediti v vseh okoljih. Prav tako ste morali sinhronizirati čas, ko boste uvedli naslednjo novo različico vaše aplikacije, s časom, ko devops izvede potrebne nastavitve okolja. V tem primeru zlahka pridemo v situacijo, ko bo naše okolje v vseh okoljih hkrati nekoliko drugačno. Na primer, v okolju QA bo na voljo nekaj različic knjižnic, v produkcijskem okolju pa bodo različne, kar bo povzročilo težave.
2. Težava pri posodabljanju odvisnosti vašo prijavo. Ni odvisno od vas, ampak od druge ekipe. In sicer od ekipe devops, ki vzdržuje strežnike. Dati jim morate ustrezno nalogo in opisati, kaj želite narediti.
3. Takrat smo tudi želeli velike velike monolite, ki smo jih imeli, razdeliti na ločene male servise, saj smo razumeli, da jih bo vedno več. Takrat smo jih imeli že več kot 100. Za vsako novo storitev je bilo treba ustvariti poseben nov virtualni stroj, ki ga je bilo treba tudi vzdrževati in postavljati. Poleg tega ne potrebujete enega avtomobila, ampak vsaj dva. Vsemu temu je dodano okolje QA. To povzroča težave in vam otežuje gradnjo in zagon novih sistemov. zapleten, drag in dolgotrajen postopek.

Zato smo se odločili, da bi bilo primerneje preiti z uvajanja običajnih virtualnih strojev na uvajanje naših aplikacij v vsebniku docker. Če imate docker, potrebujete sistem, ki lahko izvaja aplikacijo v gruči, saj ne morete samo dvigniti vsebnika. Običajno želite spremljati, koliko zabojnikov je dvignjenih, da se samodejno dvignejo. Iz tega razloga smo morali izbrati nadzorni sistem.

Dolgo sva razmišljala, katerega bi lahko vzela. Dejstvo je, da je bil takrat ta umestitveni sklad na običajnih virtualnih strežnikih nekoliko zastarel, saj niso imeli najnovejših različic operacijskih sistemov. V nekem trenutku je obstajal celo FreeBSD, ki ga ni bilo zelo priročno podpirati. Razumeli smo, da se moramo čim prej preseliti na docker. Naši devops so preučili svoje obstoječe izkušnje z različnimi rešitvami in izbrali sistem, kot je Nomad.

Preklopite na Nomad

Nomad je produkt podjetja HashiCorp. Znani so tudi po drugih rešitvah:

"Konzul" je orodje za odkrivanje storitev.

"Teraform" - sistem za upravljanje strežnikov, ki omogoča konfiguracijo le-teh preko konfiguracije, tako imenovane infrastrukture kot kode.

"Potepuh" omogoča uvajanje virtualnih strojev lokalno ali v oblaku prek posebnih konfiguracijskih datotek.

Nomad se je takrat zdel dokaj enostavna rešitev, na katero bi lahko hitro prešli brez spreminjanja celotne infrastrukture. Poleg tega se je precej enostavno naučiti. Zato smo ga izbrali kot filtrirni sistem za našo posodo.

Kaj potrebujete za namestitev vašega sistema v Nomad?

1. Najprej potrebujete slika dockerja vašo prijavo. Zgraditi ga morate in postaviti v repozitorij slik dockerja. V našem primeru je to artefaktura - sistem, ki vam omogoča, da vanj potisnete različne artefakte različnih vrst. Lahko shranjuje arhive, docker slike, skladateljske pakete PHP, pakete NPM in tako naprej.
2. Tudi potrebno konfiguracijsko datoteko, ki bo Nomadu povedal, kaj, kje in v kakšni količini želite namestiti.

Ko govorimo o Nomadu, uporablja jezik HCL kot format informacijske datoteke, kar pomeni Konfiguracijski jezik HashiCorp. To je nadmnožica Yamla, ki vam omogoča, da svojo storitev opišete z izrazi Nomad.

Omogoča vam, da poveste, koliko vsebnikov želite razmestiti, iz katerih slik jim med uvajanjem posredujete različne parametre. Tako to datoteko posredujete Nomadu, ta pa zažene vsebnike v produkcijo v skladu z njo.

V našem primeru smo ugotovili, da preprosto pisanje popolnoma enakih datotek HCL za vsako storitev ne bi bilo zelo priročno, ker je storitev veliko in jih včasih želite posodobiti. Zgodi se, da ena storitev ni nameščena v enem primeru, ampak v več različnih. Na primer, eden od sistemov, ki jih imamo v proizvodnji, ima v proizvodnji več kot 100 primerkov. Zaženejo se iz istih slik, vendar se razlikujejo po konfiguracijskih nastavitvah in konfiguracijskih datotekah.

Zato smo se odločili, da bi bilo za nas priročno shraniti vse konfiguracijske datoteke za uvajanje v eno skupno skladišče. Tako so bili vidni: enostavno jih je bilo vzdrževati in videli smo, katere sisteme imamo. Če je potrebno, je tudi enostavno kaj posodobiti ali spremeniti. Dodajanje novega sistema prav tako ni težko - samo ustvariti morate konfiguracijsko datoteko znotraj novega imenika. V njem so naslednje datoteke: service.hcl, ki vsebuje opis naše storitve, in nekaj datotek env, ki omogočajo konfiguracijo te storitve, ki je nameščena v produkciji.

Vendar pa nekateri naši sistemi niso nameščeni v proizvodnji v eni kopiji, ampak v več hkrati. Zato smo se odločili, da bi bilo priročno, da konfiguracije ne shranimo v njihovi čisti obliki, temveč v obliki predloge. In smo izbrali jinja 2. V tem formatu shranjujemo tako konfiguracije same storitve kot datoteke env, potrebne zanjo.

Poleg tega smo v repozitorij postavili uvajalni skript, ki je skupen vsem projektom, kar vam omogoča, da zaženete in uvedete svojo storitev v produkcijo, v želeno okolje, v želeni cilj. V primeru, ko smo našo konfiguracijo HCL spremenili v predlogo, je datoteka HCL, ki je bila prej običajna konfiguracija Nomad, v tem primeru začela videti nekoliko drugače.

To pomeni, da smo zamenjali nekatere spremenljivke lokacije konfiguracije z vstavljenimi spremenljivkami, ki so vzete iz datotek env ali drugih virov. Poleg tega smo dobili možnost dinamičnega zbiranja datotek HCL, kar pomeni, da lahko uporabljamo ne le običajne vstavke spremenljivk. Ker jinja podpira zanke in pogoje, lahko tam ustvarite tudi konfiguracijske datoteke, ki se spreminjajo glede na to, kje točno namestite svoje aplikacije.

Svojo storitev želite na primer uvesti v predprodukcijo in proizvodnjo. Recimo, da v predprodukciji ne želite izvajati skriptov cron, ampak samo želite videti storitev na ločeni domeni, da se prepričate, da deluje. Za vsakogar, ki uvede storitev, je postopek videti zelo preprost in pregleden. Vse kar morate storiti je, da izvedete datoteko deploy.sh, določite, katero storitev želite razmestiti in kateri cilj. Na primer, želite postaviti določen sistem v Rusijo, Belorusijo ali Kazahstan. Če želite to narediti, preprosto spremenite enega od parametrov in imeli boste pravilno konfiguracijsko datoteko.

Ko je storitev Nomad že nameščena v vaši gruči, je videti takole.

Najprej potrebujete nekakšen izravnalnik zunaj, ki bo sprejel ves promet uporabnikov. Deloval bo skupaj s Consulom in od njega izvedel, kje, na katerem vozlišču, na katerem IP naslovu se nahaja določena storitev, ki ustreza določenemu imenu domene. Storitve v Consulu prihajajo iz samega Nomada. Ker gre za izdelke istega podjetja, so med seboj precej povezani. Lahko rečemo, da lahko Nomad izven škatle registrira vse storitve, ki so v njem zagnane znotraj Consula.

Ko vaš sprednji izravnalnik obremenitve ve, kateri storitvi naj pošlje promet, ga posreduje ustreznemu vsebniku ali več vsebnikom, ki ustrezajo vaši aplikaciji. Seveda je treba misliti tudi na varnost. Čeprav se vse storitve izvajajo na istih virtualnih strojih v vsebnikih, je to običajno zahteva preprečitev prostega dostopa katere koli storitve do katere koli druge. To smo dosegli s segmentacijo. Vsaka storitev je bila zagnana v svojem virtualnem omrežju, na katerem so bila predpisana pravila usmerjanja in pravila za dovoljevanje/zavrnitev dostopa do drugih sistemov in storitev. Lahko se nahajajo tako znotraj tega grozda kot zunaj njega. Na primer, če želite preprečiti, da bi se storitev povezala z določeno zbirko podatkov, lahko to storite s segmentacijo na ravni omrežja. To pomeni, da se tudi po pomoti ne morete pomotoma povezati iz testnega okolja v svojo produkcijsko bazo podatkov.

Koliko nas je kadrovsko stala tranzicija?

Prehod celotnega podjetja na Nomad je trajal približno 5-6 mesecev. Premikali smo se od storitve do storitve, a dokaj hitro. Vsaka ekipa je morala ustvariti svoje vsebnike za storitve.

Sprejeli smo tak pristop, da je vsaka ekipa samostojno odgovorna za docker slike svojih sistemov. Devops zagotavlja splošno infrastrukturo, potrebno za uvajanje, to je podporo za samo gručo, podporo za sistem CI in tako naprej. In takrat smo v Nomad preselili več kot 60 sistemov, kar je zneslo približno 2 tisoč kontejnerjev.

Devops je odgovoren za splošno infrastrukturo vsega, kar je povezano z uvajanjem in strežniki. Vsaka razvojna ekipa pa je odgovorna za implementacijo vsebnikov za svoj specifični sistem, saj je ekipa tista, ki ve, kaj na splošno potrebuje v določenem vsebniku.

Razlogi za opustitev Nomada

Katere prednosti smo pridobili s prehodom na uvedbo med drugim z uporabo Nomada in dockerja?

1. Mi zagotovljeni enaki pogoji za vsa okolja. V razvoju, QA okolju, predprodukciji, proizvodnji se uporabljajo iste slike vsebnika z enakimi odvisnostmi. V skladu s tem praktično nimate možnosti, da tisto, kar bo končalo v proizvodnji, ni tisto, kar ste predhodno testirali lokalno ali v svojem testnem okolju.
2. Ugotovili smo tudi, da je dovolj enostavno dodajanje nove storitve. Z vidika uvajanja se vsi novi sistemi zaženejo zelo preprosto. Preprosto pojdite v repozitorij, ki shranjuje konfiguracije, tam dodajte še eno konfiguracijo za svoj sistem in vse je pripravljeno. Svoj sistem lahko uvedete v proizvodnjo brez kakršnega koli dodatnega truda devops.
3. vsi konfiguracijske datoteke v enem skupnem repozitoriju se je izkazalo, da je v pregledu. V času, ko smo svoje sisteme postavljali z uporabo virtualnih strežnikov, smo uporabljali Ansible, v katerem so bile konfiguracije v istem repozitoriju. Vendar je bilo za večino razvijalcev to nekoliko težje delati. Tukaj je obseg konfiguracij in kode, ki jih morate dodati za uvedbo storitve, postal veliko manjši. Poleg tega ga devops zelo enostavno popravi ali spremeni. V primeru prehodov, na primer, na novo različico Nomada, lahko vzamejo in množično posodobijo vse operacijske datoteke, ki se nahajajo na istem mestu.

Vendar smo naleteli tudi na več pomanjkljivosti:

Izkazalo se je, da smo ni bilo mogoče doseči nemotenih uvajanj v primeru Nomada. Pri uvajanju vsebnikov pod različnimi pogoji se lahko izkaže, da teče, in Nomad ga je zaznal kot vsebnik, pripravljen na sprejem prometa. To se je zgodilo, preden se je aplikacija v njej sploh lahko zagnala. Zaradi tega je sistem za kratek čas začel proizvajati 500 napak, ker je promet začel iti v zabojnik, ki ga še ni bil pripravljen sprejeti.

Naleteli smo na nekatere po barjih. Najpomembnejša napaka je, da Nomad ne obravnava dobro velike gruče, če imate veliko sistemov in vsebnikov. Ko želite enega od strežnikov, ki so vključeni v gručo Nomad, odstraniti zaradi vzdrževanja, obstaja dokaj velika verjetnost, da se gruča ne bo dobro počutila in bo razpadla. Nekateri vsebniki lahko na primer padejo in se ne dvignejo - to vas bo kasneje zelo stalo, če so vsi vaši proizvodni sistemi v gruči, ki jo upravlja Nomad.

Zato smo se odločili razmisliti, kam bi šli naprej. Takrat smo se veliko bolj zavedali, kaj želimo doseči. Namreč: želimo si zanesljivost, malo več funkcij, kot jih ponuja Nomad, in bolj zrel, stabilnejši sistem.

V zvezi s tem je naša izbira padla na Kubernetes kot najbolj priljubljeno platformo za zagon grozdov. Še posebej glede na to, da je bila velikost in število naših kontejnerjev dovolj velika. Za takšne namene se je Kubernetes zdel najprimernejši sistem, ki smo ga lahko pogledali.

Prehod na Kubernetes

Povedal vam bom nekaj o osnovnih konceptih Kubernetesa in o tem, kako se razlikujejo od Nomada.

Prvič, najosnovnejši koncept v Kubernetesu je koncept pod. Pod je skupina enega ali več vsebnikov, ki vedno delujejo skupaj. In vedno delujejo kot na enem virtualnem stroju. Drug drugemu sta dostopna preko IP 127.0.0.1 na različnih vratih.

Predpostavimo, da imate aplikacijo PHP, ki je sestavljena iz nginx in php-fpm – klasične sheme. Najverjetneje boste želeli imeti vsebnike nginx in php-fpm ves čas skupaj. Kubernetes vam omogoča, da to dosežete tako, da jih opišete kot en skupni pod. Točno tega nismo mogli dobiti z Nomadom.

Drugi koncept je uvajanje. Dejstvo je, da je pod sama efemerna stvar; začne se in izgine. Ali želite najprej uničiti vse svoje prejšnje vsebnike in nato naenkrat zagnati nove različice ali pa jih želite uvajati postopoma? To je proces, za katerega je odgovoren koncept uvajanja. Opisuje, kako razporedite svoje pode, v kakšni količini in kako jih posodobiti.

Tretji koncept je Storitev. Vaša storitev je pravzaprav vaš sistem, ki prejme nekaj prometa in ga nato posreduje eni ali več enotam, ki ustrezajo vaši storitvi. To pomeni, da vam omogoča, da rečete, da mora biti ves dohodni promet do te in te storitve s takšnim in tem imenom poslan tem posebnim podom. In hkrati vam zagotavlja uravnoteženje prometa. To pomeni, da lahko zaženete dva sklopa svoje aplikacije in ves dohodni promet bo enakomerno uravnotežen med sklopi, povezanimi s to storitvijo.

In četrti osnovni koncept je Vstop. To je storitev, ki deluje v gruči Kubernetes. Deluje kot zunanji uravnavalec obremenitve, ki prevzame vse zahteve. Z uporabo API-ja Kubernetes lahko Ingress določi, kam naj se te zahteve pošljejo. Poleg tega to počne zelo prožno. Lahko rečete, da so vse zahteve do tega gostitelja in tega in tega URL-ja poslane tej storitvi. Te zahteve, ki prihajajo k temu gostitelju in drugemu URL-ju, so poslane drugi storitvi.

Najbolj kul z vidika nekoga, ki razvija aplikacijo, je, da lahko vse upravljaš sam. Z nastavitvijo konfiguracije Ingress lahko pošljete ves promet, ki prihaja v ta in ta API, v ločene vsebnike, napisane na primer v Go. Toda ta promet, ki prihaja na isto domeno, vendar na drug URL, bi moral biti poslan v vsebnike, napisane v PHP, kjer je veliko logike, vendar niso zelo hitri.

Če vse te koncepte primerjamo z Nomadom, lahko rečemo, da so prvi trije koncepti vsi skupaj Storitev. In zadnjega koncepta v samem Nomadu ni. Zanj smo uporabili zunanji izravnalnik: lahko je haproxy, nginx, nginx+ itd. V primeru kocke vam tega dodatnega koncepta ni treba uvesti posebej. Vendar, če pogledate Ingress interno, je bodisi nginx, haproxy ali traefik, vendar nekako vgrajen v Kubernetes.

Vsi koncepti, ki sem jih opisal, so pravzaprav viri, ki obstajajo znotraj gruče Kubernetes. Za njihov opis v kocki je uporabljen format yaml, ki je v primeru Nomada bolj berljiv in znan kot datoteke HCL. Toda strukturno opisujejo isto stvar v primeru, na primer, pod. Pravijo - tam želim razporediti takšne in takšne stroke, s takšnimi in takimi podobami, v takšnih in takšnih količinah.

Poleg tega smo ugotovili, da ne želimo ročno ustvariti vsakega posameznega vira: uvedba, storitve, Ingress itd. Namesto tega smo želeli opisati vsak naš sistem v smislu Kubernetesa med uvajanjem, tako da nam ne bi bilo treba ročno znova ustvarjati vseh potrebnih odvisnosti od virov v pravem vrstnem redu. Helm je bil izbran kot sistem, ki nam je to omogočil.

Osnovni pojmi v Helmu

Helm je upravitelj paketov za Kubernetes. Zelo je podobno delovanju upraviteljev paketov v programskih jezikih. Omogočajo vam shranjevanje storitve, ki jo sestavljajo na primer uvedba nginx, uvedba php-fpm, konfiguracija za Ingress, configmaps (to je entiteta, ki vam omogoča nastavitev env in drugih parametrov za vaš sistem) v obliki tako- imenovane karte. Hkrati Helm deluje na vrhu Kubernetesa. To pomeni, da to ni nekakšen sistem, ki stoji ob strani, ampak le še ena storitev, ki se je začela znotraj kocke. Z njim komunicirate prek njegovega API-ja prek ukaza konzole. Njegova priročnost in lepota je v tem, da tudi če se helm pokvari ali ga odstranite iz gruče, vaše storitve ne bodo izginile, saj helm v bistvu služi samo za zagon sistema. Kubernetes je nato sam odgovoren za delovanje in stanje storitev.

To smo tudi spoznali šablonizacija, ki smo ga bili prej prisiljeni storiti sami z uvedbo jinja v naše konfiguracije, je ena glavnih značilnosti helma. Vse konfiguracije, ki jih ustvarite za svoje sisteme, so shranjene v helmu v obliki predlog, ki so malo podobne jinji, vendar v resnici uporabljajo predloge jezika Go, v katerem je helm napisan, kot je Kubernetes.

Helm nam doda še nekaj konceptov.

Graf - to je opis vaše storitve. V drugih upraviteljih paketov bi se temu reklo paket, paket ali kaj podobnega. Tukaj se imenuje grafikon.

Vrednote so spremenljivke, ki jih želite uporabiti za izdelavo svojih konfiguracij iz predlog.

Sprostite. Vsakič, ko storitev, ki je razporejena s pomočjo helm, prejme inkrementalno različico izdaje. Helm si zapomni, kakšna je bila konfiguracija storitve v prejšnji izdaji, izdaji pred to in tako naprej. Zato, če se morate vrniti nazaj, preprosto zaženite ukaz za povratni klic krmila in ga usmerite na prejšnjo različico izdaje. Tudi če ustrezna konfiguracija v vašem repozitoriju v času povrnitve ni na voljo, si bo helm še vedno zapomnil, kakšna je bila, in povrnil vaš sistem v stanje, v katerem je bil v prejšnji izdaji.

V primeru, ko uporabljamo helm, se običajne konfiguracije za Kubernetes spremenijo tudi v predloge, v katerih je možno uporabljati spremenljivke, funkcije in uporabljati pogojne stavke. Na ta način lahko zberete svojo konfiguracijo storitve glede na okolje.

V praksi smo se odločili, da bomo stvari naredili nekoliko drugače kot pri Nomadu. Če so bile v Nomadu konfiguracije za uvajanje in n-spremenljivke, ki so bile potrebne za uvajanje naše storitve, shranjene v enem repozitoriju, smo se tukaj odločili, da jih razdelimo v dva ločena repozitorija. Repozitorij »deploy« shranjuje samo n spremenljivk, potrebnih za uvajanje, repozitorij »helm« pa shranjuje konfiguracije ali grafikone.

Kaj nam je to dalo?

Kljub temu, da v samih konfiguracijskih datotekah ne shranjujemo res občutljivih podatkov. Na primer gesla za baze podatkov. V Kubernetesu so shranjeni kot skrivnosti, a kljub temu so tam še vedno določene stvari, do katerih ne želimo vsem omogočiti dostopa. Zato je dostop do repozitorija »deploy« bolj omejen, repozitorij »helm« pa preprosto vsebuje opis storitve. Zaradi tega je lahko varno dostopen širšemu krogu ljudi.

Ker nimamo samo proizvodnih, ampak tudi druga okolja, lahko zahvaljujoč tej ločitvi znova uporabimo naše krmilne karte za uvajanje storitev ne le v proizvodnjo, temveč tudi, na primer, v okolje QA. Tudi za njihovo lokalno uporabo Minikube - to je stvar za lokalno izvajanje Kubernetesa.

Znotraj vsakega skladišča smo pustili razdelitev v ločene imenike za vsako storitev. To pomeni, da so znotraj vsakega imenika predloge, povezane z ustreznim grafikonom in opisujejo vire, ki jih je treba uporabiti za zagon našega sistema. V repozitoriju »deploy« smo pustili samo env. V tem primeru nismo uporabili predlog z uporabo jinja, ker helm sam omogoča izdelavo predlog izven škatle - to je ena njegovih glavnih funkcij.

Pustili smo skript za uvajanje - deploy.sh, ki poenostavi in ​​standardizira zagon za uvajanje s pomočjo helma. Torej, za vsakogar, ki želi uvesti, je vmesnik za uvajanje popolnoma enak, kot je bil pri uvajanju prek Nomada. Isti deploy.sh, ime vaše storitve in mesto, kjer jo želite namestiti. To povzroči notranji zagon krmilnika. Po drugi strani pa zbira konfiguracije iz predlog, vanje vstavi potrebne datoteke z vrednostmi, jih nato razmesti in zažene v Kubernetes.

Ugotovitve

Zdi se, da je storitev Kubernetes bolj zapletena kot Nomad.

Tu prihaja odhodni promet na Ingress. To je le sprednji krmilnik, ki prevzame vse zahteve in jih nato pošlje servisom, ki ustrezajo podatkom zahteve. Določi jih na podlagi konfiguracij, ki so del opisa vaše aplikacije v krmilniku in ki jih razvijalci nastavijo sami. Storitev pošilja zahteve svojim podom, to je posebnim vsebnikom, ki uravnavajo dohodni promet med vsemi vsebniki, ki pripadajo tej storitvi. In seveda ne smemo pozabiti, da ne smemo iti nikamor od varnosti na ravni omrežja. Zato segmentacija deluje v gruči Kubernetes, ki temelji na označevanju. Vse storitve imajo določene oznake, s katerimi so povezane pravice dostopa storitev do določenih zunanjih/notranjih virov znotraj ali zunaj gruče.

Ko smo naredili prehod, smo videli, da ima Kubernetes vse zmožnosti Nomada, ki smo jih prej uporabljali, dodal pa je tudi veliko novih stvari. Razširite ga lahko z vtičniki in pravzaprav z vrstami virov po meri. To pomeni, da imate priložnost, da ne samo uporabite nekaj, kar je priloženo Kubernetesu takoj, ampak da ustvarite svoj vir in storitev, ki bo prebrala vaš vir. To vam daje dodatne možnosti za razširitev vašega sistema, ne da bi morali ponovno namestiti Kubernetes in ne da bi zahtevali spremembe.

Primer takšne uporabe je Prometheus, ki teče znotraj naše gruče Kubernetes. Da lahko začne zbirati metrike posamezne storitve, moramo v opis storitve dodati dodatno vrsto vira, tako imenovani servisni monitor. Ker lahko Prometheus ob zagonu v Kubernetesu bere vrsto vira po meri, samodejno začne zbirati meritve iz novega sistema. To je zelo priročno.

Prvo uvedbo v Kubernetes smo izvedli marca 2018. In v tem času s tem nikoli nismo imeli težav. Deluje precej stabilno brez večjih napak. Poleg tega ga lahko še razširimo. Danes imamo dovolj zmogljivosti, ki jih ima, in zelo nam je všeč tempo razvoja Kubernetesa. Trenutno je v Kubernetesu več kot 3000 vsebnikov. Grozd zaseda več vozlišč. Hkrati je uporaben, stabilen in zelo vodljiv.

Vir: www.habr.com