Bok svima! Moje ime je Pavel Agaletsky. Radim kao team lead u timu koji razvija Lamoda sustav dostave. U 2018. sam govorio na HighLoad++ konferenciji, a danas bih želio predstaviti transkript svog izvješća.

Moja je tema posvećena iskustvu naše tvrtke u postavljanju sustava i usluga u različita okruženja. Počevši od naših pretpovijesnih vremena, kada smo implementirali sve sustave u obične virtualne poslužitelje, do postupnog prijelaza s Nomada na implementaciju u Kubernetesu. Reći ću vam zašto smo to učinili i kakve smo probleme imali u tom procesu.

Postavljanje aplikacija na VM

Počnimo s činjenicom da su prije 3 godine svi sustavi i usluge tvrtke postavljeni na obične virtualne poslužitelje. Tehnički je organiziran na način da je sav kod za naše sustave pohranjen i sastavljen pomoću alata za automatsko sklapanje, pomoću jenkinsa. Korištenjem Ansiblea, uveden je iz našeg sustava kontrole verzija na virtualne poslužitelje. Štoviše, svaki sustav koji je naša tvrtka imala bio je raspoređen na najmanje 2 poslužitelja: jedan na čelu, drugi na repu. Ova dva sustava bila su apsolutno identična jedan drugome u svim svojim postavkama, snazi, konfiguraciji itd. Jedina razlika između njih bila je u tome što je glava primala korisnički promet, dok rep nikada nije primao korisnički promet.

čemu je to bilo?

Kada smo postavljali nova izdanja naše aplikacije, željeli smo osigurati besprijekorno uvođenje, odnosno bez vidljivih posljedica za korisnike. To je postignuto zahvaljujući činjenici da je sljedeće kompilirano izdanje koje koristi Ansible uvedeno do kraja. Tamo su ljudi koji su bili uključeni u implementaciju mogli provjeriti i uvjeriti se da je sve u redu: sve metrike, odjeljci i aplikacije rade; pokreću se potrebne skripte. Tek nakon što su se uvjerili da je sve u redu, promet je prebačen. Počeo je odlaziti na poslužitelj koji je prije bio tail. A onaj koji je prethodno bio glavni ostao je bez korisničkog prometa, a na njemu je i dalje bila prethodna verzija naše aplikacije.

Tako da je za korisnike bilo besprijekorno. Zato što je prebacivanje trenutno, jer je to jednostavno prebacivanje balansera. Možete se vrlo jednostavno vratiti na prethodnu verziju jednostavnim prebacivanjem balansera natrag. Također smo mogli provjeriti je li aplikacija sposobna za proizvodnju čak i prije nego što je primila korisnički promet, što je bilo prilično zgodno.

Koje smo prednosti vidjeli u svemu tome?

1. Prije svega, dovoljno je jednostavno radi. Svi razumiju kako takva shema implementacije funkcionira, jer je većina ljudi ikada implementirala na obične virtualne poslužitelje.
2. Ovo je dovoljno pouzdano, budući da je tehnologija postavljanja jednostavna, testirana od strane tisuća tvrtki. Milijuni poslužitelja raspoređeni su na ovaj način. Teško je nešto slomiti.
3. I konačno smo mogli dobiti atomske implementacije. Implementacije koje se događaju istovremeno za korisnike, bez primjetne faze prebacivanja između stare i nove verzije.

No, u svemu tome vidjeli smo i nekoliko nedostataka:

1. Osim proizvodnog okruženja, razvojnog okruženja, postoje i druga okruženja. Na primjer, qa i predprodukcija. U to vrijeme imali smo mnogo servera i oko 60 servisa. Iz tog razloga bilo je potrebno za svaku uslugu održavajte najnoviju verziju za nju virtualni stroj. Štoviše, ako želite ažurirati biblioteke ili instalirati nove ovisnosti, morate to učiniti u svim okruženjima. Također ste morali sinkronizirati vrijeme kada ćete implementirati sljedeću novu verziju vaše aplikacije s vremenom kada devops izvrši potrebne postavke okruženja. U tom slučaju lako je doći u situaciju da će naše okruženje biti nešto drugačije u svim okruženjima odjednom. Na primjer, u QA okruženju postojat će neke verzije biblioteka, au produkcijskom okruženju će biti različite, što će dovesti do problema.
2. Poteškoće s ažuriranjem ovisnosti tvoja prijava. Ne ovisi o vama, nego o drugoj momčadi. Naime, iz devops tima koji održava servere. Morate im dati odgovarajući zadatak i opis onoga što želite učiniti.
3. U to vrijeme smo također željeli podijeliti velike velike monolite koje smo imali u zasebne male servise, jer smo shvatili da će ih biti sve više. Tada smo ih već imali više od 100. Za svaku novu uslugu bilo je potrebno napraviti zasebno novo virtualno računalo koje je također trebalo održavati i implementirati. Osim toga, ne treba vam jedan automobil, već najmanje dva. Svemu tome pridodano je QA okruženje. To uzrokuje probleme i otežava vam izgradnju i pokretanje novih sustava. složen, skup i dugotrajan proces.

Stoga smo odlučili da bi bilo prikladnije prijeći s postavljanja uobičajenih virtualnih strojeva na postavljanje naših aplikacija u docker spremniku. Ako imate docker, potreban vam je sustav koji može pokrenuti aplikaciju u klasteru, jer ne možete samo podići spremnik. Obično želite pratiti koliko je kontejnera podignuto tako da se podižu automatski. Iz tog razloga morali smo odabrati sustav upravljanja.

Dugo smo razmišljali koju bismo mogli uzeti. Činjenica je da je u to vrijeme ovaj paket za implementaciju na običnim virtualnim poslužiteljima bio pomalo zastario, jer nisu imali najnovije verzije operativnih sustava. U nekom trenutku je postojao čak i FreeBSD, koji nije bio baš zgodan za podršku. Shvatili smo da moramo migrirati na docker što je prije moguće. Naši devopsi pogledali su svoje postojeće iskustvo s različitim rješenjima i odabrali sustav poput Nomada.

Prijeđi na Nomad

Nomad je proizvod tvrtke HashiCorp. Poznati su i po drugim rješenjima:

"Konzul" je alat za otkrivanje usluge.

"Teraform" - sustav za upravljanje poslužiteljima koji omogućuje konfiguraciju istih kroz konfiguraciju, tzv. infrastruktura-kao-kod.

"skitnica" omogućuje vam postavljanje virtualnih strojeva lokalno ili u oblaku putem specifičnih konfiguracijskih datoteka.

Nomad se tada činio kao prilično jednostavno rješenje na koje se može brzo prijeći bez promjene cjelokupne infrastrukture. Osim toga, prilično ga je lako naučiti. Zato smo ga odabrali kao sustav filtracije za naš spremnik.

Što vam je potrebno za implementaciju vašeg sustava u Nomad?

1. Prije svega trebate docker slika tvoja prijava. Morate ga izgraditi i smjestiti u spremište docker slika. U našem slučaju, ovo je artefakt - sustav koji vam omogućuje da u njega ugurate razne artefakte različitih vrsta. Može pohranjivati ​​arhive, docker slike, PHP pakete skladatelja, NPM pakete i tako dalje.
2. Također potrebno konfiguracijska datoteka, koji će Nomadu reći što, gdje i u kojoj količini želite rasporediti.

Kada govorimo o Nomadu, on koristi HCL jezik kao svoj format datoteke informacija, što je skraćenica za HashiCorp konfiguracijski jezik. Ovo je nadskup Yamla koji vam omogućuje da svoju uslugu opišete terminima Nomada.

Omogućuje vam da kažete koliko spremnika želite implementirati, iz kojih slika da im proslijedite različite parametre tijekom implementacije. Dakle, ovu datoteku unosite u Nomad, a on u skladu s njom pokreće spremnike u proizvodnju.

U našem slučaju, shvatili smo da jednostavno pisanje potpuno identičnih HCL datoteka za svaku uslugu ne bi bilo vrlo zgodno, jer postoji mnogo usluga i ponekad ih želite ažurirati. Događa se da se jedna usluga ne koristi u jednoj instanci, već u više različitih. Na primjer, jedan od sustava koje imamo u proizvodnji ima više od 100 primjeraka u proizvodnji. Pokreću se iz istih slika, ali se razlikuju u konfiguracijskim postavkama i konfiguracijskim datotekama.

Stoga smo odlučili da bi nam bilo zgodno pohraniti sve naše konfiguracijske datoteke za implementaciju u jedno zajedničko spremište. Ovako su bili vidljivi: bilo ih je lako održavati i mogli smo vidjeti koje sustave imamo. Ako je potrebno, također je lako ažurirati ili promijeniti nešto. Dodavanje novog sustava također nije teško - samo trebate stvoriti konfiguracijsku datoteku unutar novog direktorija. Unutar njega nalaze se sljedeće datoteke: service.hcl, koja sadrži opis naše usluge, te neke env datoteke koje omogućuju konfiguraciju ove usluge, koja je postavljena u produkciji.

Međutim, neki od naših sustava implementirani su u proizvodnju ne u jednoj kopiji, već u nekoliko odjednom. Stoga smo odlučili da bi nam bilo zgodno pohraniti konfiguracije ne u njihovom čistom obliku, već u obliku predloška. I odabrali smo jinja 2. U ovom formatu pohranjujemo i konfiguracije same usluge i env datoteke potrebne za nju.

Osim toga, u repozitorij smo postavili skriptu za implementaciju zajedničku za sve projekte, koja vam omogućuje pokretanje i implementaciju vaše usluge u proizvodnju, u željeno okruženje, u željeni cilj. U slučaju kada smo našu HCL konfiguraciju pretvorili u predložak, tada je HCL datoteka, koja je prije bila obična Nomad konfiguracija, u ovom slučaju počela izgledati malo drugačije.

To jest, zamijenili smo neke varijable lokacije konfiguracije umetnutim varijablama koje su preuzete iz env datoteka ili drugih izvora. Osim toga, dobili smo priliku dinamički prikupljati HCL datoteke, to jest, možemo koristiti ne samo obične umetke varijabli. Budući da jinja podržava petlje i uvjete, tamo također možete stvoriti konfiguracijske datoteke, koje se mijenjaju ovisno o tome gdje točno implementirate svoje aplikacije.

Na primjer, želite implementirati svoju uslugu u predprodukciju i proizvodnju. Recimo da u pretprodukciji ne želite pokretati cron skripte, već samo želite vidjeti uslugu na zasebnoj domeni kako biste bili sigurni da funkcionira. Za svakoga tko implementira uslugu, proces izgleda vrlo jednostavno i transparentno. Sve što trebate učiniti je izvršiti deploy.sh datoteku, navesti koju uslugu želite implementirati i na koji cilj. Na primjer, želite postaviti određeni sustav u Rusiju, Bjelorusiju ili Kazahstan. Da biste to učinili, jednostavno promijenite jedan od parametara i imat ćete ispravnu konfiguracijsku datoteku.

Kada je usluga Nomad već implementirana u vašem klasteru, izgleda ovako.

Prvo, trebate neku vrstu balansera izvana, koji će primiti sav korisnički promet. Radit će zajedno s Consulom i od njega saznati gdje se, na kojem čvoru, na kojoj IP adresi nalazi određena usluga koja odgovara određenom nazivu domene. Usluge u Consulu dolaze od samog Nomada. Budući da se radi o proizvodima iste tvrtke, dosta su povezani jedni s drugima. Možemo reći da Nomad izvan kutije može registrirati sve usluge koje su u njemu pokrenute unutar Consula.

Nakon što vaš prednji balanser opterećenja zna kojoj usluzi poslati promet, prosljeđuje ga u odgovarajući spremnik ili više spremnika koji odgovaraju vašoj aplikaciji. Naravno, potrebno je misliti i na sigurnost. Iako se sve usluge izvode na istim virtualnim strojevima u spremnicima, to obično zahtijeva sprječavanje slobodnog pristupa bilo koje usluge bilo kojoj drugoj. To smo postigli kroz segmentaciju. Svaka usluga pokrenuta je u vlastitoj virtualnoj mreži na kojoj su propisana pravila usmjeravanja i pravila za dopuštanje/zabranu pristupa drugim sustavima i uslugama. Mogu se nalaziti i unutar klastera i izvan njega. Na primjer, ako želite spriječiti da se usluga poveže s određenom bazom podataka, to se može učiniti kroz segmentaciju na razini mreže. To jest, čak ni greškom, ne možete se slučajno povezati iz testnog okruženja na svoju produkcijsku bazu podataka.

Koliko nas je kadrovski koštala tranzicija?

Prijelaz cijele tvrtke na Nomad trajao je otprilike 5-6 mjeseci. Kretali smo se od usluge do usluge, ali dosta brzo. Svaki je tim morao izraditi vlastite spremnike za usluge.

Usvojili smo takav pristup da je svaki tim samostalno odgovoran za docker slike svojih sustava. Devops pruža opću infrastrukturu potrebnu za implementaciju, odnosno podršku za sam klaster, podršku za CI sustav i tako dalje. I tada smo imali više od 60 sustava preseljenih u Nomad, što je iznosilo oko 2 tisuće kontejnera.

Devops je odgovoran za opću infrastrukturu svega što je povezano s implementacijom i poslužiteljima. A svaki razvojni tim je pak odgovoran za implementaciju spremnika za svoj specifični sustav, budući da je tim taj koji zna što mu općenito treba u pojedinom spremniku.

Razlozi napuštanja Nomada

Koje smo prednosti dobili prelaskom na implementaciju pomoću Nomada i dockera, između ostalog?

1. Mi osigurali jednake uvjete za sve sredine. U razvoju, QA okruženju, pretprodukciji, proizvodnji koriste se iste slike spremnika, s istim ovisnostima. Sukladno tome, nemate gotovo nikakve šanse da ono što će završiti u proizvodnji nije ono što ste prethodno testirali lokalno ili u svom testnom okruženju.
2. Također smo utvrdili da je dovoljno jednostavno dodati novu uslugu. Sa stajališta postavljanja, svi novi sustavi pokreću se vrlo jednostavno. Samo idite u spremište koje pohranjuje konfiguracije, tamo dodajte još jednu konfiguraciju za svoj sustav i sve je spremno. Svoj sustav možete implementirati u proizvodnju bez ikakvog dodatnog napora devopsa.
3. sve konfiguracijske datoteke u jednom zajedničkom spremištu pokazalo se da je na pregledu. U vrijeme kada smo postavljali naše sustave pomoću virtualnih poslužitelja, koristili smo Ansible, u kojem su konfiguracije bile u istom repozitoriju. Međutim, za većinu programera ovo je bilo malo teže raditi. Ovdje je količina konfiguracija i koda koje trebate dodati za implementaciju usluge postala mnogo manja. Osim toga, devopsima je vrlo lako to popraviti ili promijeniti. U slučaju prijelaza, primjerice, na novu verziju Nomada, mogu skupno ažurirati sve operativne datoteke koje se nalaze na istom mjestu.

Ali također smo naišli na nekoliko nedostataka:

Pokazalo se da mi nije mogao postići besprijekorne implementacije u slučaju Nomada. Prilikom izbacivanja kontejnera pod različitim uvjetima moglo bi se pokazati da radi, a Nomad ga je doživljavao kao spremnik spreman za promet. To se dogodilo prije nego što se aplikacija unutar njega uopće uspjela pokrenuti. Zbog toga je sustav u kratkom vremenu počeo proizvoditi 500 grešaka jer je promet počeo ići u spremnik koji ga još nije bio spreman prihvatiti.

Naišli smo na neke po močvarama. Najznačajniji bug je taj što Nomad ne rukuje dobro velikim klasterom ako imate mnogo sustava i spremnika. Kada želite uzeti jedan od poslužitelja koji je uključen u Nomad klaster na održavanje, postoji prilično velika vjerojatnost da se klaster neće osjećati baš dobro i da će se raspasti. Neki spremnici mogu, na primjer, pasti i ne podignuti se - to će vas kasnije jako puno koštati ako se svi vaši proizvodni sustavi nalaze u klasteru kojim upravlja Nomad.

Pa smo odlučili razmisliti kamo dalje. U tom smo trenutku postali puno svjesniji onoga što želimo postići. Naime: želimo pouzdanost, malo više funkcija nego što nudi Nomad i zreliji, stabilniji sustav.

S tim u vezi naš izbor je pao na Kubernetes kao najpopularniju platformu za pokretanje klastera. Pogotovo s obzirom da je veličina i broj naših kontejnera bio dovoljno velik. Za takve svrhe, Kubernetes se činio najprikladnijim sustavom koji smo mogli pogledati.

Prijelaz na Kubernetes

Reći ću vam nešto o osnovnim konceptima Kubernetesa i kako se razlikuju od Nomada.

Prije svega, najosnovniji koncept u Kubernetesu je koncept pod. Mahuna je grupa od jednog ili više spremnika koji uvijek rade zajedno. I uvijek rade kao da su strogo na jednom virtualnom stroju. Dostupni su jedni drugima putem IP-a 127.0.0.1 na različitim portovima.

Pretpostavimo da imate PHP aplikaciju koja se sastoji od nginx-a i php-fpm-a - klasične sheme. Najvjerojatnije ćete htjeti držati i nginx i php-fpm spremnike zajedno u svakom trenutku. Kubernetes vam omogućuje da to postignete opisujući ih kao jednu zajedničku mahunu. To je upravo ono što nismo mogli dobiti s Nomadom.

Drugi koncept je razvoj. Činjenica je da je mahuna sama po sebi efemerna stvar; ona se pokrene i nestane. Želite li prvo uništiti sve svoje prethodne spremnike, a zatim pokrenuti nove verzije odjednom ili ih želite postupno uvoditi? To je proces za koji je odgovoran koncept implementacije. Opisuje kako postavljate svoje podove, u kojoj količini i kako ih ažurirati.

Treći koncept je usluga. Vaša usluga je zapravo vaš sustav, koji prima dio prometa i zatim ga prosljeđuje jednoj ili više grupa koje odgovaraju vašoj usluzi. Odnosno, omogućuje vam da kažete da sav dolazni promet prema toj i takvoj usluzi s takvim i takvim imenom mora biti poslan tim određenim podovima. A u isto vrijeme vam omogućuje uravnoteženje prometa. Odnosno, možete pokrenuti dva modula svoje aplikacije, a sav dolazni promet ravnomjerno će se rasporediti između modula povezanih s ovom uslugom.

I četvrti osnovni koncept je Ulaz. Ovo je usluga koja radi na Kubernetes klasteru. Djeluje kao vanjski balanser opterećenja koji preuzima sve zahtjeve. Korištenjem Kubernetes API-ja, Ingress može odrediti gdje se ti zahtjevi trebaju poslati. Štoviše, on to čini vrlo fleksibilno. Možete reći da se svi zahtjevi prema ovom hostu i tom i tom URL-u šalju ovoj usluzi. A ovi zahtjevi koji dolaze ovom hostu i drugom URL-u šalju se drugoj usluzi.

Najbolja stvar sa stajališta nekoga tko razvija aplikaciju je da možete sami upravljati svime. Postavljanjem Ingress konfiguracije, možete poslati sav promet koji dolazi na taj i takav API u odvojene spremnike napisane, na primjer, u Go. Ali ovaj promet, koji dolazi na istu domenu, ali na drugi URL, trebao bi biti poslan u spremnike napisane u PHP-u, gdje ima puno logike, ali nisu baš brzi.

Usporedimo li sve ove koncepte s Nomadom, možemo reći da su prva tri koncepta zajedno Usluga. I posljednji koncept je odsutan u samom Nomadu. Koristili smo vanjski balanser kao njega: to može biti haproxy, nginx, nginx+, i tako dalje. U slučaju kocke, ne morate posebno uvoditi ovaj dodatni koncept. Međutim, ako pogledate Ingress interno, on je ili nginx, haproxy ili traefik, ali na neki način ugrađen u Kubernetes.

Svi koncepti koje sam opisao zapravo su resursi koji postoje unutar Kubernetes klastera. Za njihovo opisivanje u kocki koristi se yaml format koji je čitljiviji i poznatiji od HCL datoteka u slučaju Nomada. Ali strukturno oni opisuju istu stvar u slučaju, na primjer, pod. Kažu - želim tamo rasporediti takve i takve mahune, s takvim i takvim slikama, u takvim i takvim količinama.

Osim toga, shvatili smo da ne želimo svaki pojedinačni resurs kreirati ručno: implementaciju, usluge, Ingress itd. Umjesto toga, htjeli smo opisati svaki od naših sustava u smislu Kubernetesa tijekom implementacije, tako da ne bismo morali ručno ponovno kreirati sve potrebne ovisnosti o resursima u pravom redoslijedu. Helm je odabran kao sustav koji nam je to omogućio.

Osnovni pojmovi u Helm

Helm je upravitelj paketa za Kubernetes. Vrlo je slično načinu na koji rade upravitelji paketa u programskim jezicima. Omogućuju vam da pohranite uslugu koja se sastoji od, na primjer, implementacije nginx-a, implementacije php-fpm-a, konfiguracije za Ingress, configmaps (ovo je entitet koji vam omogućuje da postavite env i druge parametre za vaš sustav) u obliku tzv. nazvane karte. U isto vrijeme Helm radi na vrhu Kubernetesa. Odnosno, ovo nije nekakav sustav koji stoji po strani, već samo još jedna usluga pokrenuta unutar kocke. S njim komunicirate putem API-ja putem konzolne naredbe. Njegova pogodnost i ljepota je da čak i ako se helm pokvari ili ga uklonite iz klastera, vaše usluge neće nestati, jer helm u biti služi samo za pokretanje sustava. Sam Kubernetes tada je odgovoran za performanse i stanje usluga.

To smo i mi shvatili šablonizacija, što smo prije bili prisiljeni učiniti sami uvođenjem jinje u naše konfiguracije, jedna je od glavnih značajki helma. Sve konfiguracije koje stvorite za svoje sustave pohranjuju se u helm u obliku predložaka, malo sličnih jinji, ali zapravo koriste predložake jezika Go, na kojem je helm napisan, poput Kubernetesa.

Helm nam dodaje još nekoliko koncepata.

Grafikon - ovo je opis vaše usluge. U drugim upraviteljima paketa to bi se zvalo paket, paket ili nešto slično. Ovdje se zove grafikon.

Vrijednosti su varijable koje želite koristiti za izgradnju vaših konfiguracija iz predložaka.

Pustite. Svaki put kada usluga koja je postavljena pomoću helma primi inkrementalnu verziju izdanja. Helm pamti kakva je bila konfiguracija usluge u prethodnom izdanju, izdanju prije toga, i tako dalje. Stoga, ako se trebate vratiti, samo pokrenite naredbu helm callback, usmjeravajući je na prethodnu verziju izdanja. Čak i ako odgovarajuća konfiguracija u vašem repozitoriju nije dostupna u vrijeme vraćanja, helm će i dalje zapamtiti što je bilo i vratit će vaš sustav na stanje u kojem je bio u prethodnom izdanju.

U slučaju kada koristimo helm, regularne konfiguracije za Kubernetes također se pretvaraju u predloške u kojima je moguće koristiti varijable, funkcije i primijeniti uvjetne izjave. Na ovaj način možete prikupiti konfiguraciju svoje usluge ovisno o okruženju.

U praksi smo odlučili napraviti stvari malo drugačije nego što smo učinili s Nomadom. Ako su u Nomadu i konfiguracije za implementaciju i n-varijable koje su bile potrebne za implementaciju naše usluge bile pohranjene u jednom repozitoriju, ovdje smo ih odlučili podijeliti u dva odvojena repozitorija. Repozitorij "deploy" pohranjuje samo n-varijabli potrebnih za implementaciju, a repozitorij "helm" pohranjuje konfiguracije ili grafikone.

Što nam je ovo dalo?

Unatoč činjenici da ne pohranjujemo nikakve stvarno osjetljive podatke u samim konfiguracijskim datotekama. Na primjer, lozinke za baze podataka. One su pohranjene kao tajne u Kubernetesu, ali unatoč tome još uvijek postoje određene stvari kojima ne želimo svima dati pristup. Stoga je pristup repozitoriju "deploy" ograničeniji, a repozitorij "helm" jednostavno sadrži opis usluge. Iz tog razloga, može mu sigurno pristupiti širi krug ljudi.

Budući da nemamo samo proizvodnju, već i druga okruženja, zahvaljujući ovom odvajanju možemo ponovno upotrijebiti naše upravljačke karte za implementaciju usluga ne samo u proizvodnji, već i, na primjer, u QA okruženju. Čak i za njihovu lokalnu implementaciju pomoću Minikube - ovo je stvar za lokalno pokretanje Kubernetesa.

Unutar svakog repozitorija ostavili smo podjelu u zasebne direktorije za svaku uslugu. To jest, unutar svakog direktorija postoje predlošci koji se odnose na odgovarajući grafikon i opisuju resurse koje je potrebno rasporediti za pokretanje našeg sustava. Ostavili smo samo envs u repozitoriju "deploy". U ovom slučaju nismo koristili izradu predložaka pomoću jinje, jer sam helm pruža izradu predložaka izvan okvira - to je jedna od njegovih glavnih funkcija.

Ostavili smo skriptu za implementaciju - deploy.sh, koja pojednostavljuje i standardizira pokretanje za implementaciju pomoću helma. Dakle, za svakoga tko se želi implementirati, sučelje za implementaciju izgleda potpuno isto kao kada se implementira kroz Nomad. Isti deploy.sh, naziv vaše usluge i gdje je želite implementirati. To uzrokuje interno pokretanje kormila. On, zauzvrat, prikuplja konfiguracije iz predložaka, u njih umeće datoteke s potrebnim vrijednostima, zatim ih postavlja, pokrećući ih u Kubernetes.

Zaključci

Čini se da je usluga Kubernetes složenija od Nomada.

Ovdje odlazni promet dolazi na Ingress. Ovo je samo prednji kontroler koji preuzima sve zahtjeve i naknadno ih šalje servisima koji odgovaraju podacima zahtjeva. Određuje ih na temelju konfiguracija koje su dio opisa vaše aplikacije u Helmu i koje programeri sami postavljaju. Usluga šalje zahtjeve svojim podovima, odnosno određenim spremnicima, balansirajući dolazni promet između svih spremnika koji pripadaju ovoj usluzi. I, naravno, ne bismo trebali zaboraviti da ne bismo trebali ići nigdje od sigurnosti na razini mreže. Stoga segmentacija radi u Kubernetes klasteru koji se temelji na označavanju. Sve usluge imaju određene oznake kojima su pridružena prava pristupa usluga određenim vanjskim/unutarnjim resursima unutar ili izvan klastera.

Dok smo vršili prijelaz, vidjeli smo da Kubernetes ima sve mogućnosti Nomada, koje smo prije koristili, a također je dodao puno novih stvari. Može se proširiti pomoću dodataka, a zapravo kroz prilagođene vrste resursa. To jest, imate priliku ne samo koristiti nešto što dolazi s Kubernetesom izvan kutije, već stvoriti vlastiti resurs i uslugu koja će čitati vaš resurs. To vam daje dodatne opcije za proširenje vašeg sustava bez potrebe za ponovnim instaliranjem Kubernetesa i bez potrebe za izmjenama.

Primjer takve upotrebe je Prometheus, koji radi unutar našeg Kubernetes klastera. Kako bi počeo prikupljati metriku od pojedine usluge, potrebno je u opis usluge dodati dodatnu vrstu resursa, tzv. service monitor. Prometheus, zbog činjenice da može čitati prilagođenu vrstu resursa kada se pokrene u Kubernetesu, automatski počinje prikupljati metriku iz novog sustava. Prilično je zgodno.

Prva implementacija koju smo izvršili na Kubernetesu bila je u ožujku 2018. I tijekom ovog vremena nikada nismo imali problema s njim. Radi prilično stabilno bez značajnih grešaka. Osim toga, možemo ga dodatno proširiti. Danas imamo dovoljno mogućnosti koje on ima i jako nam se sviđa tempo razvoja Kubernetesa. Trenutno se u Kubernetesu nalazi više od 3000 kontejnera. Klaster zauzima nekoliko čvorova. Istovremeno je upotrebljiv, stabilan i vrlo upravljiv.

Izvor: www.habr.com