Danas planiram da pričam o tome kako pisati aplikacije i koji su uslovi da bi vaša aplikacija dobro radila u Kubernetesu. Tako da nema glavobolje sa aplikacijom, tako da ne morate da izmišljate i pravite bilo kakve "grebotine" oko nje - i sve radi onako kako je sam Kubernetes zamislio.
Ovo predavanje je dio "" Otvorena teorijska predavanja Večernje škole možete pogledati . Za one koji više vole tekst nego video, pripremili smo ovaj članak.
Moje ime je Pavel Selivanov, trenutno sam vodeći DevOps inženjer u Mail.ru Cloud Solutions, pravimo oblake, pravimo upravljačke kubernete i tako dalje. Moji zadaci sada uključuju pomoć u razvoju, uvođenje ovih oblaka, uvođenje aplikacija koje pišemo i direktan razvoj alata koje pružamo našim korisnicima.
Ja se bavim DevOps-om, mislim zadnje, vjerovatno, tri godine. Ali, u principu, radim ono što DevOps radi već otprilike pet godina. Prije toga sam se uglavnom bavio admin stvarima. Počeo sam da radim sa Kubernetes-om davno – verovatno je prošlo oko četiri godine otkako sam počeo da radim sa njim.
Generalno, počeo sam kada je Kubernetes bio verzija 1.3, verovatno, a možda i 1.2 - kada je još bio u povojima. Sada više nije u povojima – i očigledno je da postoji ogromna potražnja na tržištu za inženjerima koji bi želeli da mogu da rade Kubernetes. A kompanije imaju veoma veliku potražnju za takvim ljudima. Stoga se, zapravo, i pojavilo ovo predavanje.
Ako govorimo po planu o čemu ću pričati, to izgleda ovako, u zagradama piše (TL;DR) - „predugo; ne čitaj". Moja današnja prezentacija će se sastojati od beskrajnih lista.
Zapravo, ni sam ne volim takve prezentacije kada se prave, ali ovo je takva tema da kada sam pripremao ovu prezentaciju jednostavno nisam smislio kako drugačije organizirati te informacije.
Jer, uglavnom, ova informacija je „ctrl+c, ctrl+v“, između ostalog, sa naše Wiki u DevOps sekciji, gde smo napisali zahteve za programere: „momci, da pokrenemo vašu aplikaciju u Kubernetes, trebalo bi da bude ovako."
Zato je prezentacija ispala tako velika lista. Izvini. Pokušaću da ispričam što više da ne bude dosadno ako je moguće.
Šta ćemo sada pogledati:
- to su, prvo, logovi (dnevnici aplikacije?), šta sa njima raditi u Kubernetesu, šta sa njima, šta bi trebalo da budu;
- šta raditi sa konfiguracijama u Kubernetesu, koji su najbolji i najgori načini za konfigurisanje aplikacije za Kubernetes;
- Hajde da razgovaramo o tome šta su provjere pristupačnosti općenito, kako bi trebale izgledati;
- hajde da razgovaramo o tome šta je graciozno gašenje;
- hajde da ponovo razgovaramo o resursima;
- Dotaknimo se još jednom teme skladištenja podataka;
- i na kraju ću vam reći koji je pojam ove misteriozne aplikacije u oblaku. Oblačnost, kao pridjev ovog pojma.
Dnevnici
Predlažem da počnete od logova - od toga gde ove evidencije treba da se uguraju u Kubernetes. Sada ste pokrenuli aplikaciju u Kubernetesu. Prema klasicima, ranije su aplikacije uvijek pisale dnevnike negdje u fajl. Loše aplikacije su pisale zapise u datoteku u početnom direktoriju programera koji je pokrenuo aplikaciju. Dobre aplikacije su napisale zapise u datoteku negdje u njoj /var/log.
Shodno tome, dalje, dobri administratori su u svojim infrastrukturama konfigurisali neke stvari koje mogu da rotiraju ovi logovi - isti rsyslog, koji gleda ove logove i kada im se nešto desi, ima ih puno, pravi rezervne kopije, stavlja logove tamo , briše stare fajlove, više od nedelju dana, šest meseci i još ponešto. U teoriji, trebali bismo imati odredbe tako da jednostavno zato što aplikacija piše dnevnike, prostor na produkcijskim serverima (borbeni serveri?) ne ponestane. I, shodno tome, cijela proizvodnja nije stala zbog trupaca.
Kada pređemo u svijet Kubernetesa i tamo pokrenemo istu stvar, prva stvar na koju možete obratiti pažnju je činjenica da ljudi, kako su pisali logove u fajl, nastavljaju da ih pišu.
Ispostavilo se da ako govorimo o Kubernetes-u, pravo mjesto za pisanje dnevnika negdje iz docker kontejnera je jednostavno zapisivanje iz aplikacije u takozvani Stdout/Stderr, odnosno standardni izlazni tokovi operativnog sistema, standardni izlaz greške. Ovo je najispravniji, najjednostavniji i najlogičniji način postavljanja dnevnika u principu u Docker, a posebno u Kubernetis. Jer ako vaša aplikacija zapisuje dnevnike u Stdout/Stderr, onda je na Dockeru i Kubernetes dodatku da odluče što će učiniti s tim zapisnicima. Docker će po defaultu izgraditi svoje posebne datoteke u JSON formatu.
Ovdje se postavlja pitanje šta ćete dalje raditi sa ovim logovima? Najlakši način je jasan, mi imamo mogućnosti za to kubectl logs i pogledajte ove zapise ovih "mahura". Ali, vjerovatno, ovo nije baš dobra opcija - potrebno je nešto drugo učiniti s trupcima.
Za sada, hajde da pričamo u isto vrijeme, pošto smo se dotakli teme trupaca, o nečemu kako bi trupci trebali izgledati. Odnosno, ovo se ne odnosi direktno na Kubernetes, ali kada počnemo da razmišljamo šta da radimo sa evidencijama, bilo bi dobro da razmislimo i o tome.
Treba nam neka vrsta alata, na prijateljski način, koji će uzeti ove zapise koje naš docker stavlja u svoje datoteke i poslati ih negdje. Uglavnom, obično pokrećemo neku vrstu agenta unutar Kubernetesa u obliku DaemonSet-a - sakupljača dnevnika, kojem se jednostavno kaže gdje se nalaze evidencije koje Docker prikuplja. A ovaj sakupljač ih jednostavno uzima, možda čak i usput usput analizira, možda ih obogaćuje nekim dodatnim meta-informacijama i, na kraju, šalje ih negdje na pohranu. Tu su već moguće varijacije. Najčešći je vjerovatno Elasticsearch, gdje možete pohraniti dnevnike i odatle ih lako dohvatiti. Zatim, koristeći zahtjev, koristeći Kibana, na primjer, napravite grafikone na osnovu njih, napravite upozorenja na osnovu njih, itd.
Najvažnija ideja, želim je ponoviti, je da je unutar Docker-a, posebno unutar Kubernetesa, pohranjivanje vaših dnevnika u fajl vrlo loša ideja.
Jer, prvo, teško je dobiti zapise unutar kontejnera u datoteci. Prvo morate ući u kontejner, izvršiti tamo, a zatim pogledati dnevnike. Sljedeća stvar je da ako imate dnevnike u datoteci, onda kontejneri obično imaju minimalističko okruženje i ne postoje uslužni programi koji su obično potrebni za normalan rad sa evidencijama. Zakopajte ih, pogledajte ih, otvorite ih u uređivaču teksta. Sljedeći trenutak je kada imamo logove u datoteci unutar kontejnera, ako se ovaj kontejner izbriše, razumijete, logovi će umrijeti zajedno s njim. Prema tome, svako ponovno pokretanje kontejnera znači da više nema evidencije. Opet loša opcija.
I posljednja stvar je da unutar kontejnera obično imate svoju aplikaciju i to je to - obično je to jedini proces koji se pokreće. Nema govora o bilo kakvom procesu koji bi rotirao fajlove sa vašim logovima. Čim se logovi počnu upisivati u datoteku, to znači da ćemo, izvinite, početi gubiti proizvodni server. Jer, kao prvo, teško ih je pronaći, niko ih ne prati, plus niko ih ne kontroliše - u skladu s tim, datoteka raste beskrajno sve dok prostor na serveru jednostavno ne ponestane. Stoga, ponavljam da je prijavljivanje u Docker, posebno u Kubernetes, u fajl loša ideja.
Sljedeća stvar, ovdje želim ponovo o tome - pošto se dotičemo teme dnevnika, bilo bi dobro da razgovaramo o tome kako bi logovi trebali izgledati kako bi bilo zgodno raditi s njima. Kao što sam rekao, tema nije direktno vezana za Kubernetes, ali se jako dobro odnosi na temu DevOps-a. Na temu kulture razvoja i prijateljstva između ova dva različita odjela - Dev i Ops, da svima bude udobno.
To znači da bi danas u idealnom slučaju zapisnici trebali biti napisani u JSON formatu. Ako imate neku svoju nerazumljivu aplikaciju, koja piše logove u nerazumljivim formatima jer ubacujete kakav print ili nešto slično, onda je vrijeme da proguglate nekakav framework, nekakav omot koji vam omogućava da implementirate normalno logovanje; tamo omogućite bilježenje parametara u JSON-u, jer je JSON jednostavan format, raščlanjivanje je jednostavno.
Ako vaš JSON ne radi po nekim kriterijima, niko ne zna po čemu, onda barem napišite dnevnike u formatu koji se može raščlaniti. Ovdje je, radije, vrijedno razmisliti o činjenici da, na primjer, ako pokrećete gomilu kontejnera ili samo procese sa nginxom, a svaki ima svoje postavke evidentiranja, onda se vjerovatno čini da će vam biti vrlo nezgodno analizirati ih. Zato što za svaku novu nginx instancu morate napisati svoj parser, jer oni drugačije pišu dnevnike. Opet, vjerojatno je vrijedilo razmisliti o tome da sve ove nginx instance imaju istu konfiguraciju evidentiranja i da sve svoje dnevnike zapisuju apsolutno ujednačeno. Isto se odnosi na apsolutno sve aplikacije.
Na kraju, želim doliti ulje na vatru da bi, u idealnom slučaju, trebalo izbjegavati dnevnike u više redova. Evo u čemu je stvar, ako ste ikada radili sa sakupljačima dnevnika, onda ste najvjerovatnije vidjeli šta vam obećavaju, da mogu raditi sa višelinijskim logovima, da znaju kako ih sakupljati itd. Zapravo, po mom mišljenju, ni jedan sakupljač danas ne može normalno, potpuno i bez grešaka sakupljati višelinijske dnevnike. Na ljudski način, tako da je zgodno i bez grešaka.
Ali praćenje steka je uvijek višelinijska evidencija i kako ih izbjeći. Pitanje je da je dnevnik zapis događaja, a stactrace zapravo nije dnevnik. Ako prikupimo dnevnike i stavimo ih negdje u Elasticsearch, a zatim iz njih izvučemo grafikone, napravimo neke izvještaje o aktivnostima korisnika na vašoj web-lokaciji, onda kada dobijete stack trace, to znači da se dešava nešto neočekivano u vašoj aplikaciji. I ima smisla automatski otpremiti trag steka negdje u sistem koji ih može pratiti.
Ovo je softver (isti Sentry) koji je napravljen posebno za rad sa praćenjem steka. Može odmah kreirati automatizirane zadatke, dodijeliti ih nekome, upozoriti kada se stacttraces pojave, grupirati ove stacttraces po jednom tipu, itd. U principu, nema puno smisla govoriti o stactraces-ima kada govorimo o logovima, jer su to, na kraju krajeva, različite stvari s različitim svrhama.
Konfiguracija
Zatim ćemo razgovarati o konfiguraciji u Kubernetesu: šta raditi s tim i kako bi se aplikacije unutar Kubernetesa trebale konfigurirati. Generalno, obično kažem da Docker nije o kontejnerima. Svi znaju da se Docker bavi kontejnerima, čak i oni koji nisu puno radili s Dockerom. Ponavljam, Docker nije o kontejnerima.
Docker se, po mom mišljenju, odnosi na standarde. I postoje standardi za praktično sve: standardi za izradu vaše aplikacije, standardi za instaliranje vaše aplikacije.
A ova stvar - koristili smo je ranije, upravo je postala posebno popularna sa pojavom kontejnera - ova stvar se zove ENV (okruženje) varijable, odnosno varijable okruženja koje se nalaze u vašem operativnom sistemu. Ovo je generalno idealan način da konfigurišete svoju aplikaciju, jer ako imate aplikacije u JAVA, Python, Go, Perl, ne daj Bože, i sve one mogu čitati host baze podataka, korisnika baze podataka, varijable lozinke baze podataka, onda je to idealno. Imate aplikacije na četiri različita jezika konfigurisane u planu baze podataka na isti način. Nema više različitih konfiguracija.
Sve se može konfigurirati pomoću ENV varijabli. Kada govorimo o Kubernetesu, postoji odličan način da se deklarišu ENV varijable direktno unutar Deployment-a. U skladu s tim, ako je riječ o tajnim podacima, onda tajne podatke iz ENV varijabli (lozinke za baze podataka itd.) možemo odmah gurnuti u tajnu, kreirati tajni klaster i naznačiti u ENV opisu u Deploymentu da ne deklariramo direktno vrijednost ove varijable, a vrijednost ove varijable lozinke baze podataka će biti pročitana iz tajne. Ovo je standardno ponašanje Kubernetesa. A ovo je najidealnija opcija za konfiguriranje vaših aplikacija. Samo na nivou koda, ovo se opet odnosi na programere. Ako ste DevOps, možete pitati: „Momci, naučite svoju aplikaciju da čita varijable okruženja. I svi ćemo biti srećni.”
Ako svi u kompaniji čitaju iste imenovane varijable okruženja, onda je to sjajno. Da se ne desi da jedni čekaju postgres bazu, drugi naziv baze, treći čekaju nešto drugo, treći čekaju nekakav dbn, pa da, shodno tome, postoji uniformnost.
Problem nastaje kada imate toliko varijabli okruženja da samo otvorite Deployment - a postoji pet stotina redova varijabli okruženja. U ovom slučaju, jednostavno ste prerasli varijable okruženja - i više ne morate da se mučite. U ovom slučaju, imalo bi smisla početi koristiti konfiguracije. To jest, obučite svoju aplikaciju da koristi konfiguracije.
Jedino pitanje je da konfiguracije nisu ono što mislite. Config.pi nije konfiguracija koja je zgodna za korištenje. Ili neka konfiguracija u vašem formatu, alternativno nadarena - ovo također nije konfiguracija na koju mislim.
Ono o čemu govorim je konfiguracija u prihvatljivim formatima, odnosno daleko najpopularniji standard je .yaml standard. Jasno je kako se čita, čitljivo je ljudima, jasno je kako se čita iz aplikacije.
U skladu s tim, pored YAML-a, možete, na primjer, koristiti i JSON, raščlanjivanje je jednako zgodno kao i YAML u smislu čitanja konfiguracije aplikacije odatle. Ljudima je znatno nezgodnije čitati. Možete probati format, a la ini. Sa ljudske tačke gledišta, prilično je zgodno za čitanje, ali može biti nezgodno obraditi ga automatski, u smislu da ako ikada poželite da generišete sopstvene konfiguracije, ini format može već biti nezgodan za generisanje.
Ali u svakom slučaju, koji god format da odaberete, poenta je da je sa Kubernetes tačke gledišta vrlo zgodan. Možete staviti cijelu svoju konfiguraciju u Kubernetes, u ConfigMap. Zatim uzmite ovu konfiguracijsku mapu i zamolite da se montira unutar vašeg pod-a u nekom određenom direktoriju, gdje će vaša aplikacija pročitati konfiguraciju iz ove konfiguracijske mape kao da je to samo datoteka. To je, zapravo, ono što je dobro učiniti kada imate puno opcija konfiguracije u svojoj aplikaciji. Ili je to samo neka složena struktura, postoji gniježđenje.
Ako imate configmap, onda možete vrlo dobro naučiti svoju aplikaciju, na primjer, da automatski prati promjene u datoteci gdje je konfigmapa montirana, a također automatski ponovo učitava vašu aplikaciju kada se konfiguracije promijene. Ovo bi općenito bila idealna opcija.
Opet, već sam govorio o ovome - tajne informacije nisu u configmapu, tajne informacije nisu u varijablama, tajne informacije nisu u tajnama. Odatle povežite ove tajne informacije sa diplomatijom. Obično sve opise Kubernetes objekata, implementacije, configmape, servise čuvamo u git-u. Shodno tome, stavljanje lozinke za bazu podataka u git, čak i ako je to vaš git, koji imate interno u kompaniji, je loša ideja. Jer, u najmanju ruku, git pamti sve i jednostavno uklanjanje lozinki odatle nije tako lako.
Provjera zdravlja
Sljedeća stvar je ova stvar koja se zove Zdravstveni pregled. Općenito, provjera zdravlja je jednostavno provjera da li vaša aplikacija radi. Pri tome, najčešće govorimo o određenim web aplikacijama, za koje će, shodno tome, sa stanovišta zdravstvene provjere (bolje je ne prevoditi ovdje i dalje) to biti neki poseban URL, koji oni obrađuju kao standard, obično rade /health.
Prilikom pristupa ovom URL-u, shodno tome, naša aplikacija kaže ili “da, dobro, sve je u redu sa mnom, 200” ili “ne, nije sve u redu sa mnom, nekih 500”. Shodno tome, ako naša aplikacija nije http, nije web aplikacija, sada govorimo o nekakvom demonu, možemo smisliti kako napraviti zdravstvene provjere. Odnosno, nije potrebno, ako aplikacija nije http, onda sve radi bez provjere zdravlja i to se nikako ne može učiniti. Možete periodično ažurirati neke informacije u datoteci, možete smisliti neku posebnu naredbu za svoj demon, kao, daemon status, koji će reći "da, sve je u redu, demon radi, živ je."
čemu služi? Prva i najočiglednija stvar je vjerovatno zašto je potrebna zdravstvena provjera - da bi se shvatilo da aplikacija radi. Mislim, jednostavno je glupo, kada je sada gore, izgleda da radi, tako da možete biti sigurni da radi. I ispostavilo se da aplikacija radi, kontejner radi, instanca radi, sve je u redu - a onda su korisnici već prekinuli sve brojeve telefona tehničke podrške i rekli „šta si ti..., ti zaspao, ništa ne radi.”
Zdravstvena provjera je upravo takav način da se sa stanovišta korisnika vidi da funkcionira. Jedna od metoda. Recimo to ovako. Sa stanovišta Kubernetesa, ovo je i način da se shvati kada se aplikacija pokreće, jer razumijemo da postoji razlika između vremena kada je kontejner pokrenut, kreiran i pokrenut i kada je aplikacija pokrenuta direktno u ovom kontejneru. Jer ako uzmemo neku prosječnu java aplikaciju i pokušamo je pokrenuti u dock-u, onda na četrdesetak sekundi, pa čak i minutu, pa čak i deset, može se dobro pokrenuti. U ovom slučaju, možete barem pokucati na njegove portove, neće odgovoriti tamo, odnosno još nije spreman za primanje prometa.
Opet, uz pomoć zdravstvene provjere i uz pomoć činjenice da se okrećemo ovdje, u Kubernetesu možemo shvatiti da se u aplikaciji ne samo da je kontejner ustao, već je i sama aplikacija pokrenuta, već odgovara na zdravstveni pregled, što znači da tamo možemo poslati saobraćaj.
Ono o čemu sada govorim se zove Readiness/Liveness testovi unutar Kubernetesa, naši testovi spremnosti su odgovorni za dostupnost aplikacije u balansiranju. Odnosno, ako se u aplikaciji vrše testovi spremnosti, onda je sve u redu, klijentski promet ide u aplikaciju. Ako se testovi spremnosti ne izvrše, onda aplikacija jednostavno ne sudjeluje, ova konkretna instanca ne sudjeluje u balansiranju, uklanja se iz balansiranja i klijentski promet ne teče. Shodno tome, testovi Livenessa unutar Kubernetesa su potrebni kako bi se, ako se aplikacija zaglavi, mogla ponovo pokrenuti. Ako test živosti ne radi za aplikaciju koja je deklarirana u Kubernetesu, tada se aplikacija ne uklanja samo iz balansiranja, već se ponovo pokreće.
I evo jedne važne stvari koju bih želio spomenuti: s praktične tačke gledišta, test spremnosti se obično koristi češće i češće je potreban od testa živosti. Odnosno, jednostavno nepromišljeno deklarisanje i testova spremnosti i životnosti, jer Kubernetes to može, i hajde da iskoristimo sve što može, nije baš dobra ideja. Objasniću zašto. Jer tačka broj dva u testiranju je da bi bilo dobro provjeriti osnovnu uslugu u svojim zdravstvenim pregledima. To znači da ako imate web aplikaciju koja daje neke informacije, koje ona, naravno, mora odnekud uzeti. U bazi podataka, na primjer. Pa, sprema informacije koje dolaze u ovaj REST API u istu bazu podataka. Zatim, u skladu s tim, ako vaša zdravstvena provjera odgovara jednostavno kao kontaktirani slashhealth, aplikacija kaže „200, u redu, sve je u redu“, a istovremeno je baza podataka vaše aplikacije nedostupna, a aplikacija za provjeru zdravlja kaže „200, u redu, sve je u redu ” - Ovo je loša zdravstvena kontrola. Ovo ne bi trebalo da funkcioniše.
Odnosno, vaša aplikacija, kada joj dođe zahtjev /health, ne odgovara samo "200, ok", prvo ide, na primjer, u bazu podataka, pokušava se povezati s njom, radi nešto vrlo osnovno tamo, kao što je odaberite jednu, samo provjerava da li postoji veza u bazu podataka i možete postaviti upit bazi podataka. Ako je sve ovo bilo uspješno, onda je odgovor "200, ok." Ako nije uspješan, piše da je došlo do greške, baza podataka je nedostupna.
Stoga se s tim u vezi ponovo vraćam na testove spremnosti/živosti – zašto vam je najvjerovatnije potreban test spremnosti, a test živosti je u pitanju. Jer ako opišete zdravstvene preglede tačno kao što sam upravo rekao, onda će se ispostaviti da to nije dostupno u dijelu instanceв или со всех instanceu bazi podataka, na primjer. Kada ste proglasili test spremnosti, naše zdravstvene provjere su počele da ne uspijevaju, te su shodno tome sve aplikacije iz kojih baza podataka nije dostupna, jednostavno se isključuju iz balansiranja i zapravo „vise“ samo u zapuštenom stanju i čekaju da im se baze podataka rad.
Ako smo proglasili test živosti, onda zamislite, naša baza podataka je pokvarena, a u vašem Kubernetesu pola svega počinje da se restartuje jer test živosti ne uspije. To znači da morate ponovo pokrenuti. Ovo uopšte nije ono što želite, čak sam imao lično iskustvo u praksi. Imali smo chat aplikaciju koja je napisana na JS-u i unesena u Mongo bazu podataka. A problem je bio u tome što smo na početku mog rada sa Kubernetesom opisali spremnost, živost testova po principu da Kubernetes to može, pa ćemo ga koristiti. Shodno tome, u nekom trenutku Mongo je postao malo "tup" i uzorak je počeo da propada. Shodno tome, prema testu kiše, mahune su počele da se „ubijaju“.
Kao što razumijete, kada su „ubijeni“, ovo je chat, odnosno na njemu visi mnogo veza klijenata. Oni su i “ubijani” - ne, ne klijenti, samo veze - ne svi u isto vrijeme, a zbog činjenice da nisu ubijeni u isto vrijeme, neki ranije, neki kasnije, ne počinju u isto vrijeme vrijeme. Plus standardno nasumično, ne možemo sa preciznošću od milisekundi predvidjeti vrijeme početka aplikacije svaki put, tako da to rade jednu po jednu instancu. Jedan infospot se diže, dodaje se na balansiranje, svi klijenti dolaze tamo, ne može da izdrži takvo opterećenje, jer je sam, a, grubo rečeno, radi ih desetak, i pada. Sljedeći se diže, cijeli teret je na njemu, on također pada. Pa, ovi vodopadi samo nastavljaju da kaskadiraju. Na kraju, kako je to riješeno - samo smo morali striktno zaustaviti korisnički promet na ovoj aplikaciji, pustiti sve instance da se podignu i onda pokrenuti sav korisnički promet odjednom tako da je već raspoređen na svih deset instanci.
Da nije najavljen ovaj test živosti, koji bi primorao da se sve ponovo pokrene, aplikacija bi to dobro riješila. Ali sve od balansiranja nam je onemogućeno, jer su baze podataka nedostupne i svi korisnici su “otpali”. Zatim, kada ova baza podataka postane dostupna, sve je uključeno u balansiranje, ali aplikacije ne moraju ponovo pokretati, i nema potrebe za gubitkom vremena i resursa na to. Svi su već tu, spremni su za saobraćaj, pa se saobraćaj tek otvara, sve je u redu - aplikacija je na mjestu, sve radi.
Stoga su testovi spremnosti i životnosti različiti, čak štoviše, teoretski možete raditi različite zdravstvene provjere, jedan tip radijusa, jedan tip liv, na primjer, i provjeriti različite stvari. Tokom testova spremnosti, provjerite svoje pozadine. A na testu živosti, na primjer, ne provjeravate sa stanovišta da je test živosti općenito samo aplikacija koja reagira, ako uopće može odgovoriti.
Zato što je test živosti, uglavnom, kada smo „zaglavljeni“. Počela je beskrajna petlja ili nešto drugo - i više se zahtjevi ne obrađuju. Stoga ih ima smisla čak i razdvojiti - i implementirati drugačiju logiku u njih.
Što se tiče toga šta treba da odgovorite kada imate test, kada radite zdravstvene preglede. To je stvarno bol. Oni koji su upoznati sa ovim će se vjerovatno nasmijati – ali ozbiljno, u životu sam viđao servise koji u 200% slučajeva odgovaraju “XNUMX”. Odnosno, ko je uspešan. Ali u isto vrijeme u tijelu odgovora pišu „tava i takva greška“.
Odnosno, status odgovora vam dolazi - sve je uspješno. Ali u isto vrijeme, morate analizirati tijelo, jer tijelo kaže „izvinite, zahtjev je završio sa greškom“ i to je samo realnost. Video sam ovo u stvarnom životu.
A kako nekima to ne bi bilo smiješno, a drugima vrlo bolno, ipak se vrijedi pridržavati jednostavnog pravila. U zdravstvenim pregledima i u principu pri radu sa web aplikacijama.
Ako je sve prošlo kako treba, odgovorite sa dvjestotim odgovorom. U principu, odgovaraće vam bilo koji dvostoti odgovor. Ako vrlo dobro čitate ragsy i znate da se neki statusi odgovora razlikuju od drugih, odgovorite odgovarajućim: 204, 5, 10, 15, kako god. Ako nije baš dobro, onda samo "dva nula nula". Ako sve prođe loše, a zdravstveni pregled ne reaguje, odgovorite bilo kojom petstotinom. Opet, ako razumijete kako da odgovorite, koliko se različiti statusi odgovora razlikuju jedni od drugih. Ako ne razumijete, onda je 502 vaša opcija da odgovorite na zdravstvene preglede ako nešto pođe po zlu.
Ovo je još jedna stvar, želim da se vratim malo o provjeri osnovnih usluga. Ako počnete, na primjer, provjeravati sve osnovne usluge koje stoje iza vaše aplikacije - sve općenito. Ono što dobijamo sa stanovišta mikroservisne arhitekture, imamo koncept kao što je „niska sprega“ - to jest, kada su vaše usluge minimalno zavisne jedna od druge. Ako jedan od njih ne uspije, svi ostali bez ove funkcionalnosti jednostavno će nastaviti s radom. Neke od funkcionalnosti jednostavno ne rade. U skladu s tim, ako sve zdravstvene preglede povežete jedni s drugima, završit ćete tako da jedna stvar padne u infrastrukturi, a budući da je pala, svi zdravstveni pregledi svih usluga također počinju propadati - i postoji više infrastrukture općenito za cjelokupna mikroservisna arhitektura br. Tamo se sve zamračilo.
Stoga, želim još jednom da ponovim da morate provjeriti osnovne servise, one bez kojih vaša aplikacija u sto posto slučajeva ne može obaviti svoj posao. Odnosno, logično je da ako imate REST API preko kojeg korisnik sprema u bazu podataka ili preuzima iz baze, onda u nedostatku baze podataka ne možete garantirati rad sa svojim korisnicima.
Ali ako su vaši korisnici, kada ih izvadite iz baze podataka, dodatno obogaćeni nekim drugim metapodacima, iz drugog backenda, koje unosite prije slanja odgovora na frontend - a ovaj backend nije dostupan, to znači da dajete svoj odgovor bez ikakvog dijela metapodataka.
Zatim, imamo i jedan od bolnih problema prilikom pokretanja aplikacija.
U stvari, ovo se uglavnom ne odnosi samo na Kubernetes, jednostavno se dogodilo da su se kultura neke vrste masovnog razvoja, a posebno DevOps-a, počela širiti otprilike u isto vrijeme kada i Kubernetes. Stoga se, uglavnom, ispostavlja da morate graciozno zatvoriti svoju aplikaciju bez Kubernetesa. I prije Kubernetesa, ljudi su to radili, ali sa pojavom Kubernetesa počeli smo masovno pričati o tome.
Graceful Shutdown
Generalno, šta je Graceful Shutdown i zašto je potrebno? Radi se o tome kada se vaša aplikacija iz nekog razloga sruši, što trebate učiniti app stop - ili primite, na primjer, signal od operativnog sistema, vaša aplikacija ga mora razumjeti i učiniti nešto po tom pitanju. Najgori scenario je, naravno, kada vaša aplikacija dobije SIGTERM i kaže da je „SIGTERM, držimo se, radimo, ne radite ništa“. Ovo je potpuno loša opcija.
Gotovo jednako loša opcija je kada vaša aplikacija primi SIGTERM i bude kao „rekli su segterm, to znači da završavamo, nisam vidio, ne znam nijedan zahtjev korisnika, ne znam kakav zahtjeve na kojima trenutno radim, rekli su SIGTERM, to znači da završavamo " Ovo je takođe loša opcija.
Koja je opcija dobra? Prva tačka je da se uzme u obzir završetak operacija. Dobra opcija je da vaš server i dalje uzima u obzir šta radi ako primi SIGTERM.
SIGTERM je meko gašenje, posebno je dizajniran, može se presresti na nivou koda, može se obraditi, recimo sad, čekaj, prvo ćemo završiti posao koji imamo, pa ćemo izaći.
Iz Kubernetes perspektive, ovako izgleda. Kada kažemo pod koja radi u Kubernetes klasteru, "molim vas zaustavite, idite," ili smo ponovo pokrenuti, ili se ažuriranje dogodi kada Kubernetes ponovo kreira podove, Kubernetes šalje istu SIGTERM poruku u pod, čeka neko vrijeme, i, ovo je vrijeme koje on čeka, također je konfigurisano, postoji takav poseban parametar u diplomama i zove se Graceful ShutdownTimeout. Kao što ste shvatili, ne zove se tako uzalud, i nije uzalud o tome sada.
Tamo možemo konkretno reći koliko dugo trebamo čekati između vremena kada pošaljemo SIGTERM u aplikaciju i kada shvatimo da je aplikacija poludjela za nečim ili da je "zaglavila" i da neće završiti - a mi moramo pošaljite mu SIGKILL, odnosno teško završite svoj posao. To jest, prema tome, imamo neku vrstu demona koji radi, on obrađuje operacije. Razumijemo da u prosjeku naše operacije na kojima demon radi ne traju više od 30 sekundi u isto vrijeme. Shodno tome, kada SIGTERM stigne, razumijemo da naš demon može, najviše, završiti 30 sekundi nakon SIGTERM-a. Napišemo to, na primjer, 45 sekundi za svaki slučaj i kažemo da SIGTERM. Nakon toga čekamo 45 sekundi. U teoriji, za to vrijeme demon je trebao završiti svoj posao i sam sebe okončati. Ali ako odjednom ne može, to znači da je najvjerovatnije zapelo - više ne obrađuje naše zahtjeve normalno. I za 45 sekundi možete ga bezbedno, u stvari, prikovati.
I ovdje se, zapravo, mogu uzeti u obzir čak 2 aspekta. Prvo, shvatite da ako ste primili zahtjev, počeli ste nekako raditi s njim i niste dali odgovor korisniku, ali ste primili SIGTERM, na primjer. Ima smisla to precizirati i dati odgovor korisniku. Ovo je tačka broj jedan u ovom pogledu. Poenta broj dva ovdje je da ako napišete svoju vlastitu aplikaciju, općenito izgradite arhitekturu na takav način da dobijete zahtjev za svoju aplikaciju, onda započnete neki posao, počnete da preuzimate datoteke odnekud, preuzimate bazu podataka, i šta ne. To. Općenito, vaš korisnik, vaš zahtjev visi pola sata i čeka da mu odgovorite - tada, najvjerovatnije, trebate poraditi na arhitekturi. Odnosno, samo uzmite u obzir čak i zdrav razum da ako su vaše operacije kratke, onda ima smisla zanemariti SIGTERM i modificirati ga. Ako su vaše operacije duge, onda nema smisla zanemariti SIGTERM u ovom slučaju. Ima smisla redizajnirati arhitekturu kako bi se izbjegle tako duge operacije. Kako korisnici ne bi samo motali i čekali. Ne znam, napravi tamo nekakav websocket, napravi reverse hookove koje će tvoj server već poslati klijentu, bilo šta drugo, ali nemoj tjerati korisnika da visi pola sata i samo čekaj sesiju dok ti odgovori mu. Zato što je nepredvidivo gdje bi mogao puknuti.
Kada se vaša aplikacija završi, trebali biste dati neki odgovarajući izlazni kod. Odnosno, ako je od vaše aplikacije zatraženo da se zatvori, zaustavi i ona je mogla sama da se zaustavi normalno, onda ne morate vraćati neku vrstu izlaznog koda 1,5,255 i tako dalje. Sve što nije nulti kod, barem u Linux sistemima, siguran sam u to, smatra se neuspješnim. Odnosno, smatra se da je vaša prijava u ovom slučaju završila sa greškom. Shodno tome, na prijateljski način, ako je vaša aplikacija završena bez greške, kažete 0 na izlazu. Ako vaša aplikacija ne uspije iz nekog razloga, kažete da nije-0 u izlazu. I možete raditi s ovim informacijama.
I posljednja opcija. Loše je kada vaš korisnik pošalje zahtjev i visi pola sata dok ga obrađujete. Ali generalno, želeo bih da kažem i ono što se generalno isplati sa strane klijenta. Nije važno imate li mobilnu aplikaciju, front-end itd. Potrebno je uzeti u obzir da generalno sesija korisnika može biti prekinuta, može se dogoditi svašta. Zahtjev se može poslati, na primjer, nedovoljno obrađen i bez vraćenog odgovora. Vaš frontend ili vaša mobilna aplikacija - bilo koji frontend općenito, recimo to na taj način - treba to uzeti u obzir. Ako radite s websocketovima, ovo je općenito najgora bol koju sam ikada imao.
Kada programeri nekih redovnih chatova to ne znaju, ispostavilo se da se websocket može pokvariti. Za njih, kada se nešto dogodi na proxy-ju, mi samo promijenimo konfiguraciju i ona se ponovo učitava. Naravno, sve dugovječne sesije su u ovom slučaju pokidane. Programeri nam dotrčavaju i kažu: "Momci, šta radite, razgovor je pokvaren za sve naše klijente!" Kažemo im: „Šta to radite? Da li se vaši klijenti ne mogu ponovo povezati? Kažu: „Ne, treba nam da se sednice ne kidaju“. Ukratko, ovo je zapravo glupost. Potrebno je uzeti u obzir stranu klijenta. Naročito, kao što sam rekao, kod dugotrajnih sesija kao što su websockets, može se pokvariti i, neprimijećeno od strane korisnika, morate biti u mogućnosti da ponovo instalirate takve sesije. I tada je sve savršeno.
Resursi
Zapravo, ovdje ću vam ispričati pravu priču. Opet iz stvarnog života. Najbolesnija stvar koju sam ikada čuo o resursima.
Resursi u ovom slučaju, mislim, neka vrsta zahtjeva, ograničenja koja možete staviti na podove u svojim Kubernetes klasterima. Najsmješnija stvar koju sam čuo od programera... Jedan od mojih kolega programera na prethodnom radnom mjestu je jednom rekao: "Moja aplikacija neće početi u klasteru." Pogledao sam da ne počinje, ali ili se ne uklapa u resurse, ili su postavili vrlo mala ograničenja. Ukratko, aplikacija se ne može pokrenuti zbog resursa. Kažem: “Neće početi zbog resursa, vi odlučite koliko vam treba i postavite odgovarajuću vrijednost.” On kaže: "Kakvi resursi?" Počeo sam da mu objašnjavam da treba postaviti Kubernetes, limite na zahteve i bla, bla, bla. Čovek je slušao pet minuta, klimnuo glavom i rekao: „Došao sam ovde da radim kao programer, ne želim da znam ništa o bilo kakvim resursima. Došao sam da napišem kod i to je to.” To je tužno. Ovo je vrlo tužan koncept sa stanovišta programera. Pogotovo u modernom svijetu, da tako kažem, progresivnih devopova.
Zašto su resursi uopšte potrebni? U Kubernetesu postoje 2 vrste resursa. Neki se zovu zahtjevi, drugi se zovu ograničenja. Pod resursima ćemo shvatiti da u osnovi uvijek postoje samo dva osnovna ograničenja. To jest, vremenska ograničenja CPU-a i ograničenja RAM-a za kontejner koji radi u Kubernetesu.
Ograničenje postavlja gornju granicu načina na koji se resurs može koristiti u vašoj aplikaciji. To jest, shodno tome, ako kažete 1 GB RAM-a u granicama, onda vaša aplikacija neće moći koristiti više od 1 GB RAM-a. A ako on to odjednom poželi i pokuša da uradi, tada će proces koji se zove oom killer, bez memorije, to jest, doći i ubiti vašu aplikaciju - to jest, jednostavno će se ponovo pokrenuti. Aplikacije se neće ponovo pokrenuti na osnovu CPU-a. Što se tiče CPU-a, ako aplikacija pokušava da koristi mnogo, više nego što je navedeno u ograničenjima, CPU će jednostavno biti strogo odabran. Ovo ne dovodi do ponovnog pokretanja. Ovo je granica - ovo je gornja granica.
I postoji zahtjev. Zahtjev je kako Kubernetes razumije kako su čvorovi u vašem Kubernetes klasteru popunjeni aplikacijama. Odnosno, zahtjev je neka vrsta potvrde vaše aplikacije. Piše ono što želim da koristim: "Želio bih da rezervišete ovoliko CPU-a i ovoliko memorije za mene." Tako jednostavna analogija. Šta ako imamo čvor koji ima, ne znam, 8 CPU-a ukupno. I tamo stiže pod, čiji zahtjevi kažu 1 CPU, što znači da čvor ima još 7 CPU-a. Odnosno, čim 8 podova stigne na ovaj čvor, od kojih svaki ima 1 CPU u svojim zahtjevima, čvor je, kao da je sa stanovišta Kubernetesa, ostao bez CPU-a i više podova sa zahtjevima ne može biti pokrenut na ovom čvoru. Ako svi čvorovi ostanu bez CPU-a, tada će Kubernetes početi govoriti da u klasteru nema odgovarajućih čvorova za pokretanje vaših podova jer je CPU ponestalo.
Zašto su potrebni zahtjevi i zašto bez zahtjeva, mislim da nema potrebe ništa pokretati u Kubernetesu? Zamislimo hipotetičku situaciju. Pokrenete svoju aplikaciju bez zahtjeva, Kubernetes ne zna koliko toga imate, na koje čvorove možete to gurnuti. Pa, on gura, gura, gura na čvorove. U nekom trenutku ćete početi primati promet na svoju aplikaciju. I jedna od aplikacija odjednom počinje da koristi resurse do granica koje ima prema ograničenjima. Ispostavilo se da postoji još jedna aplikacija u blizini i da joj također trebaju resursi. Čvoru zapravo počinje fizički ponestajati resursa, na primjer, OP. Čvoru zapravo počinje fizički ponestajati resursa, na primjer, memorije sa slučajnim pristupom (RAM). Kada čvor ostane bez napajanja, prije svega će docker prestati reagirati, zatim kubelet, a zatim OS. Jednostavno će se onesvijestiti i SVE će definitivno prestati raditi za vas. Odnosno, ovo će dovesti do toga da se vaš čvor zaglavi i moraćete da ga ponovo pokrenete. Ukratko, situacija nije baš dobra.
A kada imate zahtjeve, ograničenja se ne razlikuju mnogo, barem ne mnogo puta više od ograničenja ili zahtjeva, onda možete imati tako normalno, racionalno popunjavanje aplikacija preko čvorova Kubernetes klastera. Istovremeno, Kubernetes je otprilike svjestan koliko od čega gdje stavlja, koliko čega se gdje koristi. Odnosno, to je upravo takav trenutak. Važno je to razumjeti. I važno je kontrolisati da je to indicirano.
Pohrana podataka
Naša sljedeća tačka je o pohranjivanju podataka. Šta učiniti s njima i općenito, što učiniti s upornošću u Kubernetesu?
Mislim, opet, unutar našeg , postojala je tema o bazi podataka u Kubernetesu. I čini mi se da čak otprilike znam šta su vam kolege rekle na pitanje: „Da li je moguće pokrenuti bazu podataka u Kubernetesu?“ Iz nekog razloga, čini mi se da su vam kolege trebale reći da ako postavljate pitanje da li je moguće pokrenuti bazu podataka u Kubernetesu, onda je to nemoguće.
Logika je ovdje jednostavna. Za svaki slučaj, još jednom ću objasniti, ako ste stvarno kul tip koji može izgraditi prilično tolerantni sistem distribuirane mrežne pohrane, razumjeti kako uklopiti bazu podataka u ovaj slučaj, kako bi trebao funkcionirati cloud izvorni u kontejnerima u bazi podataka uopšte. Najvjerovatnije nemate pitanja o tome kako ga pokrenuti. Ako imate takvo pitanje, a želite da budete sigurni da se to sve odvija i da stoji u redu u proizvodnji i da nikada ne padne, onda se to neće dogoditi. Ovakvim pristupom garantovano ćete pucati sebi u nogu. Stoga je bolje da ne.
Šta da radimo sa podacima koje naša aplikacija želi da pohrani, nekim slikama koje korisnici postavljaju, nekim stvarima koje naša aplikacija generiše tokom svog rada, pri pokretanju, na primer? Šta raditi s njima u Kubernetesu?
Općenito, idealno, da, naravno, Kubernetes je vrlo dobro dizajniran i općenito je prvobitno zamišljen za aplikacije bez državljanstva. Odnosno, za one aplikacije koje uopće ne pohranjuju informacije. Ovo je idealno.
Ali, naravno, idealna opcija ne postoji uvijek. Pa šta? Prva i najjednostavnija stvar je da uzmete neki S3, samo ne domaći, za koji je takođe nejasno kako radi, ali od nekog provajdera. Dobar, normalan provajder - i nauči svoju aplikaciju da koristi S3. Odnosno, kada vaš korisnik želi da otpremi fajl, recite „ovde, molim vas, otpremite ga na S3“. Kada ga želi primiti, recite: “Evo linka za S3 nazad i uzmi ga odavde.” Ovo je idealno.
Ako iznenada iz nekog razloga ova idealna opcija nije prikladna, imate aplikaciju koju niste napisali, ne razvijate ili je neka vrsta strašnog naslijeđa, ne može koristiti S3 protokol, već mora raditi s lokalnim direktorijima u lokalne fascikle. Uzmite nešto manje-više jednostavno, implementirajte Kubernetes. Odnosno, odmah ograditi Ceph za neke minimalne zadatke, čini mi se, je loša ideja. Jer Ceph je, naravno, dobar i moderan. Ali ako stvarno ne razumijete šta radite, onda kada jednom stavite nešto na Ceph, možete to vrlo lako i jednostavno nikada više izvući odatle. Jer, kao što znate, Ceph pohranjuje podatke u svom klasteru u binarnom obliku, a ne u obliku jednostavnih datoteka. Stoga, ako se iznenada Ceph klaster pokvari, postoji potpuna i velika vjerovatnoća da nikada više nećete dobiti svoje podatke odatle.
Imaćemo kurs o Cephu, možete .
Stoga je bolje učiniti nešto jednostavno poput NFS servera. Kubernetes može raditi s njima, možete montirati direktorij ispod NFS servera - vaša aplikacija je kao lokalni direktorij. U isto vrijeme, naravno, morate shvatiti da, opet, morate nešto učiniti sa svojim NFS-om, morate shvatiti da ponekad može postati nedostupan i razmisliti o tome šta ćete učiniti u ovom slučaju. Možda bi trebalo napraviti rezervnu kopiju negdje na posebnoj mašini.
Sljedeća stvar o kojoj sam govorio je šta učiniti ako vaša aplikacija generiše neke datoteke tokom rada. Na primjer, kada se pokrene, generiše neku statičku datoteku, koja se zasniva na nekim informacijama koje aplikacija prima samo u trenutku pokretanja. Kakav trenutak. Ako takvih podataka nema puno, onda se uopće ne morate truditi, samo instalirajte ovu aplikaciju za sebe i radite. Pitanje je samo šta, vidi. Vrlo često, svakakvi naslijeđeni sistemi, kao što je WordPress i tako dalje, posebno sa modificiranim nekakvim pametnim pluginovima, pametni PHP programeri, često znaju kako to napraviti tako da sami generiraju neku vrstu fajla. Prema tome, jedan generiše jedan fajl, drugi generiše drugi fajl. Oni su različiti. Balansiranje se dešava u klijentovom Kubernetes klasteru jednostavno slučajno. Shodno tome, ispada da oni na primjer ne znaju kako da rade zajedno. Jedan daje jednu informaciju, drugi daje korisniku drugu informaciju. Ovo je ono što treba da izbegavate. To jest, u Kubernetesu, sve što pokrenete garantovano će moći da radi na više instanci. Zato što je Kubernetes pokretna stvar. Shodno tome, on može da pomeri bilo šta, kad god poželi, a da nikoga uopšte ne pita. Stoga, morate računati na ovo. Sve što je pokrenuto u jednom slučaju će prije ili kasnije propasti. Što više rezervacija imate, to bolje. Ali opet, kažem, ako imate nekoliko takvih fajlova, onda ih možete staviti tačno ispod sebe, oni su teški malo. Ako ih ima malo više, vjerovatno ih ne biste trebali gurati u kontejner.
Savjetovao bih da postoji tako divna stvar u Kubernetesu, možete koristiti volumen. Konkretno, postoji volumen tipa prazan dir. Odnosno, Kubernetes će automatski kreirati direktorij u svojim servisnim direktorijima na poslužitelju na kojem ste započeli. I on će vam ga dati da ga možete koristiti. Postoji samo jedna važna tačka. To jest, vaši podaci neće biti pohranjeni unutar kontejnera, već na hostu na kojem radite. Štaviše, Kubernetes može kontrolisati takve prazne direktorije pod normalnom konfiguracijom i može kontrolirati njihovu maksimalnu veličinu i ne dozvoliti njeno prekoračenje. Jedina stvar je da se ono što ste napisali u prazan dir ne izgubi tokom restartovanja pod. Odnosno, ako vaš pod greškom padne i ponovo se podigne, informacija u praznom direktorijumu neće nikuda otići. Može ga ponovo koristiti na novom početku - i to je dobro. Ako vaša kapsula negdje ode, onda će naravno otići bez podataka. Odnosno, čim pod iz čvora gdje je pokrenut sa praznim dir nestane, prazan dir se briše.
Šta je još dobro u vezi sa praznim direktorijumom? Na primjer, može se koristiti kao keš memorija. Zamislimo da naša aplikacija generiše nešto u hodu, daje to korisnicima i to radi dugo vremena. Dakle, aplikacija ga, na primjer, generiše i daje korisnicima, a istovremeno ga negdje pohranjuje, tako da će sljedeći put kada korisnik dođe po istu stvar, biti brže da ga odmah generira. Prazan dir se može zatražiti od Kubernetesa da ga kreira u memoriji. I stoga, vaše keš memorije generalno mogu raditi munjevitom brzinom - u smislu brzine pristupa disku. Odnosno, imate prazan direktorij u memoriji, u OS-u je pohranjen u memoriji, ali za vas, za korisnika unutar pod-a, izgleda kao samo lokalni direktorij. Nije vam potrebna aplikacija da biste posebno podučavali bilo kakvu magiju. Vi samo direktno uzimate i stavljate svoju datoteku u direktorij, ali, u stvari, u memoriju na OS-u. Ovo je takođe veoma zgodna karakteristika u smislu Kubernetesa.
Kakve probleme ima Minio? Glavni problem sa Miniom je taj što da bi ova stvar funkcionisala, mora negde da radi i da postoji neka vrsta sistema datoteka, odnosno skladištenja. I ovdje se susrećemo sa istim problemima koje ima i Ceph. To jest, Minio mora negdje pohraniti svoje datoteke. To je jednostavno HTTP interfejs za vaše datoteke. Štaviše, funkcionalnost je očito lošija od one kod Amazonovog S3. Ranije nije mogao pravilno ovlastiti korisnika. Sad, koliko ja znam, već može kreirati kante sa različitim ovlaštenjima, ali opet, čini mi se da je glavni problem, da tako kažem, minimalni sistem za pohranu podataka.
Kako Prazan direktorij u memoriji utječe na ograničenja? Ni na koji način ne utiče na limite. Leži u memoriji hosta, a ne u memoriji vašeg kontejnera. To jest, vaš kontejner ne vidi prazan direktorij u memoriji kao dio svoje zauzete memorije. Domaćin to vidi. Shodno tome, da, sa stanovišta kubernetesa, kada počnete da koristite ovo, bilo bi dobro da shvatite da deo svoje memorije posvećujete praznom direktorijumu. I shodno tome, shvatite da memorija može ponestati ne samo zbog aplikacija, već i zato što neko upisuje u ove prazne direktorije.
Cloudnativeness
I poslednja podtema je šta je Cloudnative. Zašto je to potrebno? Oblačnost i tako dalje.
Odnosno one aplikacije koje su sposobne i napisane da rade u modernoj infrastrukturi oblaka. Ali, u stvari, Cloudnative ima još jedan takav aspekt. Da ovo nije samo aplikacija koja uzima u obzir sve zahtjeve moderne cloud infrastrukture, već zna i kako raditi sa ovom modernom cloud infrastrukturom, iskoristite prednosti i mane činjenice da radi u ovim oblacima. Nemojte samo pretjerati i raditi u oblacima, već iskoristite prednosti rada u oblaku.
Uzmimo samo Kubernetes kao primjer. Vaša aplikacija radi u Kubernetesu. Vaša aplikacija uvijek može, odnosno administratori vaše aplikacije, uvijek mogu kreirati servisni račun. Odnosno, nalog za autorizaciju u samom Kubernetes-u na njegovom serveru. Tamo dodajte neka prava koja su nam potrebna. I možete pristupiti Kubernetesu iz vaše aplikacije. Šta možete učiniti na ovaj način? Na primjer, iz aplikacije primajte podatke o tome gdje se nalaze vaše druge aplikacije, druge slične instance i zajedno se nekako grupirajte na vrhu Kubernetesa, ako postoji takva potreba.
Opet, nedavno smo bukvalno imali slučaj. Imamo jednog kontrolora koji prati red čekanja. A kada se neki novi zadaci pojave u ovom redu, on ide u Kubernetes - i unutar Kubernetesa kreira novi pod. Daje ovom pod-u neki novi zadatak i u okviru ovog pod-a, pod izvršava zadatak, šalje odgovor samom kontroloru, a kontroler onda radi nešto s tim informacijama. Na primjer, dodaje bazu podataka. To je, opet, plus činjenice da naša aplikacija radi u Kubernetesu. Možemo koristiti samu ugrađenu Kubernetes funkcionalnost kako bismo nekako proširili i učinili funkcionalnost naše aplikacije praktičnijom. Odnosno, nemojte skrivati neku vrstu magije o tome kako pokrenuti aplikaciju, kako pokrenuti radnika. U Kubernetesu jednostavno šaljete zahtjev u aplikaciju ako je aplikacija napisana na Pythonu.
Isto važi i ako idemo dalje od Kubernetesa. Negdje je pokrenut naš Kubernetes - dobro je ako je u nekoj vrsti oblaka. Opet, možemo koristiti, pa čak i, vjerujem, trebali bismo koristiti mogućnosti samog oblaka tamo gdje radimo. Od elementarnih stvari koje nam oblak pruža. Balansiranje, odnosno možemo kreirati cloud balansere i koristiti ih. Ovo je direktna prednost onoga što možemo koristiti. Zato što balansiranje oblaka, kao prvo, jednostavno glupo skida odgovornost za to kako funkcioniše, kako je konfigurisano. Osim toga, vrlo je zgodno, jer se obični Kubernetes može integrirati s oblacima.
Isto važi i za skaliranje. Obični Kubernetes se može integrirati sa dobavljačima u oblaku. Zna kako razumjeti da ako u klasteru ponestane čvorova, odnosno ponestane prostora čvorova, onda morate dodati - sam Kubernetes će dodati nove čvorove u vaš klaster i početi pokretati podove na njima. Odnosno, kada dođe vaš teret, broj ognjišta počinje da se povećava. Kada ponestane čvorova u klasteru za ove podove, Kubernetes pokreće nove čvorove i, shodno tome, broj podova se i dalje može povećati. I veoma je zgodno. Ovo je direktna prilika za skaliranje klastera u hodu. Ne baš brzo, u smislu da nije sekunda, više je kao minut za dodavanje novih čvorova.
Ali iz mog iskustva, opet, to je nešto najkul što sam ikada vidio. Kada se Cloudnative klaster skalirao na osnovu doba dana. To je bio backend servis koji su koristili ljudi u back officeu. Odnosno, dođu na posao u 9 ujutro, počnu se prijavljivati u sistem i shodno tome, Cloudnative klaster, u kojem sve radi, počinje da buja, pokreće nove podove kako bi svi koji dolaze na posao mogli raditi sa aplikacijom. Kada odu s posla u 8 ili 6 sati, Kubernetes klasteri primjećuju da više niko ne koristi aplikaciju i počinju da se smanjuju. Uštede do 30 posto su zagarantovane. U to vrijeme to je funkcioniralo u Amazonu, u to vrijeme nije bilo nikoga ko bi to mogao učiniti tako dobro.
Reći ću vam direktno, uštede su 30 posto jednostavno zato što koristimo Kubernetes i koristimo mogućnosti oblaka. Sada se to može uraditi u Rusiji. Neću se nikome oglašavati, naravno, ali recimo samo da postoje provajderi koji to mogu učiniti, daju odmah iz kutije pomoću dugmeta.
Postoji još jedna posljednja stvar na koju bih vam također skrenuo pažnju. Da bi vaša aplikacija, vaša infrastruktura bila Cloudnative, ima smisla konačno početi prilagođavati pristup koji se zove Infrastructure as a Code, to jest, to znači da vaša aplikacija, odnosno vaša infrastruktura, treba potpuno isto što i kod Opišite vašu aplikacija, vaša poslovna logika u obliku koda. I radite s njim kao kodom, odnosno testirajte ga, razvucite ga, pohranite u git, primijenite CICD na njega.
I upravo to vam omogućava, prvo, da uvijek imate kontrolu nad svojom infrastrukturom, da uvijek razumijete u kakvom se stanju nalazi. Drugo, izbjegavajte ručne operacije koje uzrokuju greške. Treće, izbjegavajte jednostavno ono što se zove fluktuacija, kada stalno trebate obavljati iste ručne zadatke. Četvrto, omogućava vam da se oporavite mnogo brže u slučaju kvara. U Rusiji, svaki put kada pričam o tome, uvek postoji ogroman broj ljudi koji kažu: „Da, jasno je, ali imate pristupe, ukratko, nema potrebe da se bilo šta popravlja“. Ali to je istina. Ako je nešto pokvareno u vašoj infrastrukturi, onda je sa stanovišta Cloudnative pristupa i sa gledišta infrastrukture kao koda, lakše nego da to popravite, odete na server, otkrijete šta je pokvareno i popravite to da izbrišete server i ponovo ga kreirate. I dat ću sve ovo obnoviti.
Sva ova pitanja su detaljnije obrađena na . Prateći link možete se upoznati sa programom i uslovima. Zgodna stvar je što Kubernetes možete savladati tako što ćete učiti od kuće ili raditi 1-2 sata dnevno.
izvor: www.habr.com