Zdravo svima! Moje ime je Pavel Agaletsky. Radim kao vođa tima u timu koji razvija Lamoda sistem isporuke. 2018. godine sam govorio na HighLoad ++ konferenciji, a danas želim predstaviti transkript svog izvještaja.

Moja tema je posvećena iskustvu naše kompanije u implementaciji sistema i usluga u različitim okruženjima. Počevši od naših praistorijskih vremena, kada smo sve sisteme postavili u obične virtuelne servere, završavajući postepenim prelaskom sa Nomad na Kubernetes implementaciju. Reći ću vam zašto smo to uradili i koje smo probleme imali u tom procesu.

Postavite aplikacije na VM

Počnimo s činjenicom da su prije 3 godine svi sistemi i usluge kompanije bili raspoređeni na običnim virtuelnim serverima. Tehnički je to bilo organizovano tako da je sav kod naših sistema ležao i sklapao se pomoću automatskih alata za montažu, koristeći jenkins. Uz pomoć Ansible-a, već je uveden iz našeg sistema kontrole verzija na virtuelne servere. Istovremeno, svaki sistem koji je bio u našoj kompaniji bio je raspoređen na najmanje 2 servera: jedan od njih - na glavi, drugi - na repu. Ova dva sistema su bila apsolutno identična jedan drugom po svim svojim postavkama, snazi, konfiguraciji i tako dalje. Jedina razlika između njih je u tome što je glava primala korisnički promet, dok rep nikada nije primao korisnički promet za sebe.

za šta je to bilo?

Kada smo implementirali nova izdanja naše aplikacije, željeli smo osigurati mogućnost neometane implementacije, odnosno bez primjetnih posljedica za korisnike. To je postignuto zahvaljujući činjenici da je sljedeće kompajlirano izdanje korištenjem Ansiblea izbačeno do kraja. Tamo su ljudi koji su bili uključeni u implementaciju mogli provjeriti i uvjeriti se da je sve u redu: sve metrike, sekcije i aplikacije rade; pokrenute su potrebne skripte. Tek nakon što su se uvjerili da je sve u redu, prebacili su se u saobraćaj. Počeo je da ide na server koji je ranije bio rep. I onaj koji je ranije bio glava ostao je bez korisničkog prometa, dok je sa prethodnom verzijom naše aplikacije bio dostupan na njemu.

Tako da je bilo neprimetno za korisnike. Zato što je prebacivanje trenutno, pošto je to samo prebacivanje balansera. Vrlo je lako vratiti se na prethodnu verziju jednostavnim prebacivanjem balansera nazad. Također smo mogli biti sigurni da je aplikacija spremna za proizvodnju čak i prije nego što je korisnički promet otišao na nju, što je bilo prilično zgodno.

Koje vrline vidimo u svemu tome?

1. Prije svega, dovoljno je samo radi. Svi razumiju kako funkcionira takva shema implementacije, jer se većina ljudi ikada postavila na obične virtuelne servere.
2. Ovo je dovoljno pouzdano, budući da je tehnologija implementacije jednostavna, testirana od strane hiljada kompanija. Milioni servera su raspoređeni na ovaj način. Teško je nešto slomiti.
3. I konačno smo mogli dobiti atomske implementacije. Implementacije koje se dešavaju istovremeno za korisnike, bez primjetne faze prebacivanja između stare i nove verzije.

Ali u svemu tome smo vidjeli i nekoliko nedostataka:

1. Pored 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 je moralo za svaku uslugu održavajte najnoviju verziju za nju virtuelna mašina. Štaviše, ako želite da ažurirate biblioteke ili instalirate nove zavisnosti, to morate da uradite u svim okruženjima. Također je bilo potrebno uskladiti vrijeme kada ćete implementirati sljedeću novu verziju vaše aplikacije sa vremenom kada devops izvrši potrebna podešavanja okruženja. U ovom slučaju lako je doći u situaciju da će naše okruženje odjednom biti nešto drugačije u svim sredinama zaredom. Na primjer, u QA okruženju će postojati neke verzije biblioteka, au produkciji - druge, što će dovesti do problema.
2. Poteškoće u ažuriranju zavisnosti vašu prijavu. Ne zavisi od tebe, nego od drugog tima. Naime, od devops tima koji održava servere. Trebali biste im dati odgovarajući zadatak i opisati šta želite da radite.
3. U to vrijeme smo željeli i velike velike monolite koje smo imali podijeliti 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 posebnu novu virtuelnu mašinu, koju je takođe trebalo servisirati i implementirati. Osim toga, ne trebate jedan automobil, već barem dva. Svemu ovome se dodaje QA okruženje. To uzrokuje probleme i otežava vam izgradnju i pokretanje novih sistema. složen, skup i dugotrajan proces.

Stoga smo odlučili da bi bilo zgodnije preći sa postavljanja običnih virtuelnih mašina na implementaciju naših aplikacija u docker kontejneru. Ako imate docker, potreban vam je sistem koji može pokrenuti aplikaciju u klasteru, jer ne možete tek tako podići kontejner. Obično želite da pratite koliko je kontejnera podignuto tako da se automatski podižu. Iz tog razloga, morali smo izabrati kontrolni sistem.

Dugo smo razmišljali o tome koju da uzmemo. Činjenica je da je u to vrijeme ovaj stog za implementaciju na obične virtuelne servere bio pomalo zastario, jer nije bilo najnovijih verzija operativnih sistema. U nekom trenutku je tu bio čak i FreeBSD, što nije bilo baš zgodno za održavanje. Shvatili smo da moramo prijeći na docker što je prije moguće. Naši devopsi su pogledali svoja iskustva s različitim rješenjima i odabrali sistem kao što je Nomad.

Prelazak na Nomad

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

Konzul je alat za otkrivanje usluga.

"Teraform" - sistem za upravljanje serverima koji vam omogućava da ih konfigurišete kroz konfiguraciju, takozvanu infrastrukturu kao kod.

Vagrant omogućava vam da implementirate virtuelne mašine lokalno ili u oblaku putem određenih konfiguracionih datoteka.

Nomad se u to vrijeme činio kao prilično jednostavno rješenje na koje se možete brzo prebaciti bez promjene cjelokupne infrastrukture. Osim toga, prilično je lako naučiti. Stoga smo ga odabrali kao sistem za filtriranje za naš kontejner.

Šta vam je potrebno da zapravo postavite svoj sistem u Nomad?

1. Prije svega, trebate docker image vašu prijavu. Morate ga izgraditi i staviti u docker image store. U našem slučaju, ovo je artifactory - sistem koji vam omogućava da u njega gurnete razne artefakte raznih vrsta. Može pohraniti arhive, docker slike, PHP kompozitor pakete, NPM pakete, itd.
2. Također potrebno konfiguracijski fajl, koji će reći Nomadu šta, gdje i koliko želite da rasporedite.

Kada govorimo o Nomadu, on koristi jezik HCL kao format datoteke informacija, što je skraćenica za HashiCorp konfiguracijski jezik. To je superskup Yaml-a koji vam omogućava da opišete svoju uslugu u terminima Nomada.

Omogućava vam da kažete koliko kontejnera želite da postavite, iz kojih slika da im prenesete različite parametre tokom postavljanja. Dakle, date ovaj fajl Nomadu, i on pokreće kontejnere u proizvodnju u skladu sa njim.

U našem slučaju, shvatili smo da samo pisanje potpuno istih, identičnih HCL fajlova za svaki servis ne bi bilo baš zgodno, jer postoji mnogo servisa i ponekad želite da ih ažurirate. Dešava se da jedna usluga nije raspoređena u jednoj instanci, već u nizu različitih. Na primjer, jedan od sistema koje imamo u proizvodnji ima preko 100 primjeraka u proizvodnji. Pokreću se od istih slika, ali se razlikuju po 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. Na taj način su postali vidljivi: bili su laki za održavanje i mogli ste vidjeti kakve sisteme imamo. Ako je potrebno, lako je nešto ažurirati ili promijeniti. Dodavanje novog sistema također nije teško - samo dodajte konfiguracijsku datoteku unutar novog direktorija. Unutar njega se nalaze fajlovi: service.hcl, koji sadrži opis našeg servisa, i neke env-fajlove koji omogućavaju konfiguraciju ovog servisa, koji je raspoređen u proizvodnji.

Međutim, neki od naših sistema su raspoređeni u proizvodnji ne u jednoj kopiji, već u nekoliko odjednom. Stoga smo odlučili da bi nam bilo zgodno pohraniti ne konfiguracije u njihovom čistom obliku, već u njihovom šablonskom obliku. I kao jezik šablona koji smo odabrali jinja 2. U ovom formatu pohranjujemo i konfiguracije samog servisa i env datoteke potrebne za njega.

Osim toga, u spremište smo postavili skriptu za implementaciju koja je zajednička za sve projekte, koja vam omogućava da pokrenete i implementirate svoju uslugu u proizvodnji, u pravom okruženju, na pravom cilju. U slučaju kada smo našu HCL konfiguraciju pretvorili u šablon, tada je HCL datoteka, koja je prije toga bila uobičajena Nomad konfiguracija, u ovom slučaju počela izgledati malo drugačije.

To jest, neke varijable config place smo zamijenili umetcima varijabli koji su preuzeti iz env datoteka ili iz drugih izvora. Osim toga, dobili smo mogućnost dinamičke izgradnje HCL datoteka, odnosno možemo koristiti ne samo uobičajene umetke varijabli. Pošto jinja podržava cikluse i uslove, tamo možete staviti i konfiguracione fajlove, koji se menjaju u zavisnosti od toga gde tačno postavljate svoje aplikacije.

Na primjer, želite primijeniti svoju uslugu u pretprodukciji i proizvodnji. Recimo da u predprodukciji ne želite da pokrećete cron skripte, već samo želite da vidite uslugu na zasebnoj domeni da biste bili sigurni da radi. Za svakoga ko implementira uslugu, proces je vrlo jednostavan i transparentan. Dovoljno je izvršiti deploy.sh datoteku, navesti koji servis želite postaviti i na koji cilj. Na primjer, želite da postavite neki sistem u Rusiju, Bjelorusiju ili Kazahstan. Da biste to učinili, jednostavno promijenite jedan od parametara i imat ćete ispravnu konfiguracijsku datoteku.

Kada je Nomad usluga već raspoređena u vašem klasteru, to izgleda ovako.

Za početak vam je potreban neki balanser opterećenja izvana, koji će sav korisnički promet uzeti u sebe. Radit će zajedno sa Consulom i iz njega saznati gdje, na kojem čvoru, na kojoj IP adresi se nalazi određena usluga, koja odgovara određenom nazivu domene. Usluge u Consulu dolaze od samog Nomada. Pošto se radi o proizvodima iste kompanije, dobro su povezani. Možemo reći da iz kutije Nomad može registrovati sve servise pokrenute u njemu unutar Consul-a.

Nakon što vaš vanjski balanser zna na koju uslugu da pošalje promet, on ga preusmjerava na odgovarajući kontejner ili više kontejnera koji odgovaraju vašoj aplikaciji. Naravno, potrebno je razmišljati i o sigurnosti. Iako se sve usluge pokreću na istim virtuelnim mašinama u kontejnerima, to obično zahteva da zabranite besplatan pristup bilo kojoj usluzi bilo kojoj drugoj. To smo postigli segmentacijom. Svaki servis je pokrenut u vlastitoj virtuelnoj mreži na kojoj su ispisana pravila rutiranja i pravila za dozvoljavanje/odbijanje pristupa drugim sistemima i servisima. Oni mogu biti i unutar ovog 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 segmentiranjem na nivou mreže. To jest, čak ni greškom, ne možete se slučajno povezati iz testnog okruženja na svoju proizvodnu bazu.

Koliko nas je tranzicija koštala kadrovski?

Otprilike 5-6 mjeseci trajalo je prelazak cijele kompanije na Nomad. Kretali smo se servis po servis, ali prilično brzim tempom. Svaki tim je morao kreirati svoje uslužne kontejnere.

Usvojili smo takav pristup da je svaki tim nezavisno odgovoran za docker slike svojih sistema. Devops, sa druge strane, obezbeđuje opštu infrastrukturu neophodnu za implementaciju, odnosno podršku za sam klaster, podršku za CI sistem i tako dalje. I tada smo imali više od 60 sistema premještenih u Nomad, a ispostavilo se da je to bilo oko 2 hiljade kontejnera.

DevOps je odgovoran za opštu infrastrukturu svega što se odnosi na implementaciju, sa serverima. A svaki razvojni tim je, zauzvrat, odgovoran za implementaciju kontejnera za svoj specifični sistem, pošto je tim taj koji zna šta mu je generalno potrebno u određenom kontejneru.

Razlozi za napuštanje Nomada

Koje smo prednosti dobili prelaskom na implementaciju koristeći Nomad i Docker?

1. Mi obezbedili iste uslove za sve sredine. U razvoju, QA-okruženju, predprodukciji, proizvodnji, koriste se iste slike kontejnera, sa istim ovisnostima. U skladu s tim, nemate praktički nikakve šanse da se u produkciji ispostavi nešto drugačije od onoga što ste prethodno testirali lokalno ili u testnom okruženju.
2. Takođe smo ustanovili da je to dovoljno lako dodati novu uslugu. Svaki novi sistem u smislu implementacije se pokreće vrlo jednostavno. Dovoljno je da odete u spremište koje čuva konfiguracije, tamo dodate sledeću konfiguraciju za vaš sistem i sve je spremno. Možete postaviti svoj sistem u proizvodnju bez dodatnog napora od strane devops-a.
3. sve konfiguracijske datoteke u jednom zajedničkom spremištu ispostavilo se da je zanemareno. U trenutku kada smo postavljali naše sisteme koristeći virtuelne servere, koristili smo Ansible, u kojem su konfiguracije bile u istom spremištu. Međutim, za većinu programera, ovo je bilo malo teže raditi. Ovdje je količina konfiguracija i koda koje trebate dodati da biste postavili uslugu postala mnogo manja. Plus za devops je vrlo lako popraviti ili promijeniti. U slučaju prijelaza, na primjer, na novu verziju Nomada, oni mogu uzeti i masovno ažurirati sve operativne datoteke koje leže na istom mjestu.

Ali naišli smo i na nekoliko nedostataka:

Ispostavilo se da smo nisu uspjeli postići besprijekornu implementaciju u slučaju Nomada. Prilikom izbacivanja kontejnera iz različitih uslova moglo bi se ispostaviti da je pokrenut, a Nomad ga je doživljavao kao kontejner spreman za primanje prometa. To se dogodilo čak i prije nego što je aplikacija u njoj stigla da se pokrene. Iz tog razloga, sistem je za kratko vrijeme počeo izdavati 500 grešaka, jer je promet počeo da ide ka kontejneru koji još nije bio spreman da ga prihvati.

Naišli smo na neke po močvarama. Najznačajnija greška je da Nomad ne rukuje dobro velikim klasterom ako imate mnogo sistema i kontejnera. Kada želite da uzmete u rad jedan od servera koji je uključen u Nomad klaster, postoji prilično velika vjerovatnoća da se klaster neće osjećati dobro i da će se raspasti. Neki kontejneri mogu, na primjer, pasti i ne rasti - to će vas kasnije mnogo koštati ako se svi vaši sistemi u proizvodnji nalaze u klasteru kojim upravlja Nomad.

Tako da smo odlučili da razmislimo o tome kuda dalje. Tada smo postali mnogo svjesniji šta želimo postići. Naime: želimo pouzdanost, malo više mogućnosti nego što nudi Nomad, i zreliji, stabilniji sistem.

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 je izgledao kao najpogodniji sistem od onih koje smo mogli pogledati.

Prelazak na Kubernetes

Pričaću malo o tome koji su osnovni koncepti Kubernetesa i po čemu se razlikuju od Nomada.

Prije svega, najosnovniji koncept u Kubernetesu je koncept pod. mahuna je grupa od jednog ili više kontejnera koji uvijek počinju zajedno. I rade kao da uvijek striktno na istoj virtuelnoj mašini. Oni su dostupni jedni drugima putem IP adrese 127.0.0.1 na različitim portovima.

Recimo da imate PHP aplikaciju koja se sastoji od nginxa i php-fpm - klasičnog uzorka. Najvjerovatnije ćete željeti da i nginx i php-fpm kontejneri uvijek budu zajedno. Kubernetes vam omogućava da to postignete opisujući ih kao jedan zajednički pod. To je upravo ono što nismo mogli dobiti sa Nomadom.

Drugi koncept je raspoređivanje. Poenta je da je sama mahuna efemerna stvar, ona počinje i nestaje. Bilo da želite prvo pobiti sve svoje prethodne kontejnere, a zatim odmah pokrenuti nove verzije, ili ih želite postepeno izbacivati ​​- upravo je koncept implementacije odgovoran za ovaj proces. Opisuje kako postavljate svoje podove, koliko ih i kako ih ažurirati.

Treći koncept je usluga. Vaša usluga je zapravo vaš sistem koji preuzima određeni promet, a zatim ga usmjerava na jedan ili više podova koji odgovaraju vašoj usluzi. Odnosno, omogućava vam da kažete da sav dolazni saobraćaj na tu i tu uslugu sa takvim i takvim imenom mora biti poslat na ove specifične podove. I u isto vrijeme, pruža vam balansiranje prometa. Odnosno, možete pokrenuti dva pod-a svoje aplikacije, a sav dolazni promet će biti ravnomjerno izbalansiran između pod-ova koji se odnose na ovu uslugu.

I četvrti osnovni koncept - Ulaz. Ovo je usluga koja radi na Kubernetes klasteru. Djeluje kao vanjski balanser opterećenja koji preuzima sve zahtjeve. Preko Kubernetes API-ja, Ingress može odrediti gdje se ti zahtjevi trebaju poslati. I to radi veoma fleksibilno. Možete reći da se svi zahtjevi za ovaj host i taj i takav URL šalju ovoj usluzi. I ovi zahtjevi koji dolaze na ovaj host i na drugi URL se šalju drugom servisu.

Najhladnija stvar sa stanovišta nekoga ko razvija aplikaciju je to što možete sami upravljati svime. Postavljanjem Ingress konfiguracije, sav promet koji dolazi do tog i tog API-ja možete slati u zasebne kontejnere, registrirane, na primjer, u Go. Ali ovaj saobraćaj koji dolazi na isti domen, ali na drugi URL, šalje se u kontejnere napisane u PHP-u, gde ima dosta logike, ali nisu baš brzi.

Ako sve ove koncepte uporedimo sa Nomadom, onda možemo reći da su prva tri koncepta zajedno Služba. I posljednji koncept je odsutan u samom Nomadu. Koristili smo eksterni balanser kao takav: 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 iznutra, onda je to ili nginx, ili haproxy, ili traefik, ali, takoreći, ugrađen u Kubernetes.

Svi koncepti koje sam opisao su, u stvari, 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, mahuna. Kažu - ja hoću da rasporedim tamo takve i takve mahune, sa takvim i takvim slikama, u takvoj i takvoj količini.

Osim toga, shvatili smo da ne želimo ručno kreirati svaki pojedinačni resurs: implementaciju, usluge, Ingress i tako dalje. Umesto toga, želeli smo da opišemo svaki naš sistem u smislu Kubernetesa tokom implementacije, tako da ne moramo ručno da ponovo kreiramo sve neophodne zavisnosti od resursa u pravom redosledu. Helm je izabran kao takav sistem koji nam je to omogućio.

Osnovni koncepti u Helmu

Helm je menadžer paketa za Kubernetes. Vrlo je slično načinu na koji menadžeri paketa rade u programskim jezicima. Oni vam omogućavaju da pohranite uslugu koja se sastoji od, na primjer, implementacije nginx-a, implementacije php-fpm-a, konfiguracije za Ingress, configmapa (ovo je entitet koji vam omogućava da postavite env i druge parametre za vaš sistem) u obliku tzv. nazivaju grafikoni. U isto vrijeme, Helm radi na vrhu Kubernetesa. Odnosno, ovo nije neka vrsta sistema koji stoji po strani, već samo još jedan servis koji radi unutar kocke. Sa njim komunicirate preko njegovog API-ja preko naredbe na konzoli. Njegova pogodnost i šarm je da čak i ako se helm pokvari ili ga uklonite iz klastera, vaše usluge neće nestati, jer helm u suštini služi samo za pokretanje sistema. Sam Kubernetes je dalje odgovoran za zdravlje i stanje usluga.

I mi smo to shvatili šabloniranje, koji smo do tada morali sami da radimo kroz uvođenje jinja u naše konfiguracije, jedna je od glavnih karakteristika kormila. Sve konfiguracije koje kreirate za svoje sisteme se pohranjuju u helm kao šabloni, pomalo kao jinja, ali zapravo koriste šablone Go jezika na kojem je helm napisan, baš kao i Kubernetes.

Helm nam dodaje još nekoliko dodatnih koncepata.

grafikon je opis vaše usluge. U drugim menadžerima paketa, to bi se zvalo bundle, bundle, ili nešto slično. Ovdje se to zove grafikon.

vrijednosti su varijable koje želite koristiti za izradu vaših konfiguracija iz šablona.

puštanje. Svaki put kada usluga koja se implementira s helm-om dobije inkrementalnu verziju izdanja. Helm se sjeća koja je bila konfiguracija usluge za prethodno izdanje, pretprošlu godinu i tako dalje. Stoga, ako trebate da se vratite, samo pokrenite naredbu povratnog poziva helm, usmjeravajući je na prethodnu verziju izdanja. Čak i ako odgovarajuća konfiguracija u vašem spremištu nije dostupna u vrijeme vraćanja, helm će i dalje zapamtiti što je to bilo i vratiti vaš sistem na stanje u kojem je bio u prethodnom izdanju.

U slučaju kada koristimo helm, uobičajene konfiguracije za Kubernetes takođe se pretvaraju u šablone u kojima je moguće koristiti varijable, funkcije i primijeniti uslovne izraze. Tako možete prikupiti konfiguraciju vašeg servisa u zavisnosti od okruženja.

U praksi smo odlučili da radimo stvari malo drugačije nego što smo radili sa Nomadom. Ako je Nomad pohranio i konfiguracije za implementaciju i n-varijable koje su potrebne za implementaciju našeg servisa u jedno spremište, onda smo odlučili da ih podijelimo u dva odvojena spremišta. Repozitorijum "deploy" pohranjuje samo n-varijable potrebnih za implementaciju, dok "helm" spremište pohranjuje konfiguracije ili grafikone.

Šta nam je to dalo?

Unatoč činjenici da ne pohranjujemo nikakve stvarno osjetljive podatke u samim konfiguracijskim datotekama. Na primjer, lozinke baze podataka. One su pohranjene kao tajne u Kubernetesu, ali ipak, i dalje postoje odvojene stvari kojima ne želimo da damo pristup svima za redom. Stoga je pristup "deploy" spremištu ograničeniji, a "helm" spremište sadrži samo opis usluge. Iz tog razloga, može se omogućiti siguran pristup većem krugu ljudi.

Budući da imamo ne samo proizvodnu, već i druga okruženja, zahvaljujući ovoj podjeli, možemo ponovo koristiti naše karte upravljanja za implementaciju usluga ne samo u proizvodnju, već i, na primjer, u QA okruženje. Čak i za njihovo lokalno korištenje Minikube - ovo je takva stvar za lokalno pokretanje Kubernetesa.

Unutar svakog spremišta, ostavili smo podjelu u zasebne direktorije za svaku uslugu. Odnosno, unutar svakog direktorija postoje predlošci koji se odnose na odgovarajući grafikon i koji opisuju resurse koje je potrebno rasporediti za pokretanje našeg sistema. U "deploy" spremištu smo ostavili samo zavist. U ovom slučaju, nismo koristili jinja šablone jer helm nudi šablone iz kutije - to je jedna od njegovih glavnih karakteristika.

Napustili smo skriptu za implementaciju - deploy.sh, koja pojednostavljuje i standardizira pokretanje za implementaciju pomoću helm-a. Stoga, za svakoga ko želi da se implementira, interfejs za implementaciju izgleda potpuno isto kao što je bio u slučaju postavljanja preko Nomada. Isti deploy.sh, naziv vašeg servisa i mjesto gdje ga želite implementirati. Ovo uzrokuje da kormilo radi iznutra. On, zauzvrat, prikuplja konfiguracije iz šablona, ​​zamjenjuje potrebne datoteke s vrijednostima u njih, zatim ih postavlja, pokrećući ih u Kubernetes.

nalazi

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

Ovo je mjesto gdje odlazni promet dolazi u Ingress. Ovo je samo prednji kontroler, koji preuzima sve zahtjeve i potom ih šalje servisima koji odgovaraju podacima zahtjeva. Određuje ih na osnovu konfiguracija koje su dio opisa vaše aplikacije u kormilu i koje su programeri sami postavili. Servis, s druge strane, šalje zahtjeve svojim podovima, odnosno određenim kontejnerima, balansirajući dolazni promet između svih kontejnera koji pripadaju ovoj usluzi. I, naravno, ne treba zaboraviti da ne treba nikuda ići od sigurnosti na nivou mreže. Stoga segmentacija radi u Kubernetes klasteru, koji se zasniva na označavanju. Svi servisi imaju određene tagove za koje su vezana prava pristupa usluga određenim eksternim/internim resursima unutar ili izvan klastera.

Kako smo prelazili, vidjeli smo da Kubernetes ima sve karakteristike Nomada koje smo do sada koristili, a dodaje i mnogo novih stvari. Može se proširiti preko dodataka, i zapravo kroz prilagođene tipove resursa. Odnosno, imate priliku ne samo da koristite nešto što dolazi uz Kubernetes iz kutije, već i da kreirate svoj vlastiti resurs i servis koji će čitati vaš resurs. Ovo vam daje više opcija da proširite svoj sistem bez ponovnog instaliranja Kubernetesa i bez potrebe za unosom izmjena.

Primjer takve upotrebe je Prometheus, koji pokrećemo unutar Kubernetes klastera. Da bi počeo da prikuplja metriku od određenog servisa, potrebno je da u opis usluge dodamo dodatnu vrstu resursa, takozvanu uslugu monitora. Prometheus, zbog činjenice da može čitati, pokrenut u Kubernetesu, prilagođenom tipu resursa, automatski počinje da prikuplja metriku iz novog sistema. Dovoljno je zgodno.

Prva implementacija u Kubernetesu bila je u martu 2018. I za to vrijeme nikada nismo imali nikakvih problema s njim. Radi prilično stabilno bez značajnih grešaka. Osim toga, možemo ga dalje proširiti. Do danas imamo dovoljno mogućnosti koje 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 uslužan, stabilan i vrlo upravljiv.

izvor: www.habr.com