Danas planiram razgovarati o tome kako pisati aplikacije i koji su zahtjevi da vaša aplikacija dobro radi u Kubernetesu. Da nema glavobolje s aplikacijom, da ne morate oko nje izmišljati i graditi nikakve “cratchove” - 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, izrađujemo oblake, izrađujemo 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 izravan razvoj alata koje pružamo našim korisnicima.
Bavim se DevOpsom, mislim zadnje, vjerojatno, tri godine. Ali, u principu, radim ono što DevOps radi već otprilike pet godina. Prije toga sam se uglavnom bavio administratorskim poslovima. S Kubernetesom sam počeo raditi davno - prošlo je valjda oko četiri godine otkako sam počeo raditi s njim.
Općenito, počeo sam kad je Kubernetes bio verzija 1.3, vjerojatno, a možda i 1.2 – kad je još bio u povojima. Sada to više nije u povojima – a očito je da na tržištu postoji ogromna potražnja za inženjerima koji bi htjeli moći raditi Kubernetes. A tvrtke imaju vrlo veliku potražnju za takvim ljudima. Stoga se, zapravo, pojavilo ovo predavanje.
Ako govorimo po planu o čemu ću govoriti, to izgleda ovako, u zagradama je napisano (TL;DR) - “predugo; ne čitaj". Moja današnja prezentacija sastojat će se od beskonačnih popisa.
Zapravo, ni ja sam ne volim takve prezentacije kada se prave, ali ovo je takva tema da kada sam pripremao ovu prezentaciju jednostavno nisam znao kako drugačije organizirati te informacije.
Jer, uglavnom, ove informacije su “ctrl+c, ctrl+v”, iz, između ostalog, našeg Wikija u odjeljku DevOps, gdje smo napisali zahtjeve za programere: “dečki, tako da pokrenemo vašu aplikaciju u Kubernetes, trebalo bi biti ovako."
Zato je prezentacija ispala tako velika lista. Oprosti. Pokušat ću ispričati što više da ne bude dosadno ako je moguće.
Što ćemo sada pogledati:
- to su, prvo, dnevnici (dnevnici aplikacija?), što s njima u Kubernetesu, što s njima, kakvi bi trebali biti;
- što učiniti s konfiguracijama u Kubernetesu, koji su najbolji i najgori načini konfiguriranja aplikacije za Kubernetes;
- Razgovarajmo o tome što su provjere pristupačnosti općenito, kako bi trebale izgledati;
- razgovarajmo o tome što je elegantno isključivanje;
- razgovarajmo opet o resursima;
- Dotaknimo se još jednom teme pohrane podataka;
- i na kraju ću vam reći kako se zove ova tajanstvena aplikacija u oblaku. Oblačnost, kao pridjev ovog pojma.
Dnevnici
Predlažem da počnete s zapisnicima - s time gdje te zapisnike treba ubaciti u Kubernetes. Sada ste pokrenuli aplikaciju u Kubernetesu. Prema klasici, prije su aplikacije uvijek zapisivale zapisnike negdje u datoteku. Loše aplikacije pisale su zapisnike u datoteku u početnom direktoriju programera koji je pokrenuo aplikaciju. Dobre aplikacije pisale su zapisnike u datoteku negdje u /var/log.
Sukladno tome, dalje, dobri administratori su imali konfigurirane neke stvari u svojim infrastrukturama da ti dnevnici mogu rotirati - isti rsyslog, koji gleda te zapise i kada im se nešto dogodi, ima ih puno, stvara sigurnosne kopije, stavlja zapise tamo , briše stare datoteke, više od tjedan dana, šest mjeseci i nešto više. U teoriji, trebali bismo imati odredbe tako da jednostavno zato što aplikacija piše zapise, prostor na proizvodnim poslužiteljima (borbenim poslužiteljima?) ne ponestane. I, sukladno tome, cijela proizvodnja nije stala zbog trupaca.
Kada se preselimo u svijet Kubernetesa i tamo pokrenemo istu stvar, prva stvar na koju možete obratiti pažnju je činjenica da ljudi, kako su zapisivali zapise u datoteku, nastavljaju ih pisati.
Ispostavilo se da je, ako govorimo o Kubernetesu, pravo mjesto za pisanje zapisa negdje iz docker spremnika jednostavno njihovo pisanje iz aplikacije u takozvani Stdout/Stderr, odnosno standardne izlazne tokove operativnog sustava, standardnu pogrešku izlaz . Ovo je najispravniji, najjednostavniji i najlogičniji način da se logovi stave u principu u Docker i konkretno u Kubernetis. Jer ako vaša aplikacija piše zapise u Stdout/Stderr, tada je na Dockeru i Kubernetes dodatku da odluče što će učiniti s tim zapisima. Docker će prema zadanim postavkama izgraditi svoje posebne datoteke u JSON formatu.
Ovdje se postavlja pitanje što ćete dalje s tim trupcima? Najlakši način je jasan, imamo mogućnost učiniti kubectl logs i pogledajte ove zapise ovih "mahuna". Ali, vjerojatno, ovo nije baš dobra opcija - s trupcima treba učiniti nešto drugo.
Za sada, razgovarajmo u isto vrijeme, budući da smo se dotakli teme trupaca, o tome kako bi trupci trebali izgledati. Odnosno, ovo se ne odnosi direktno na Kubernetes, ali kada počnemo razmišljati što ćemo s logovima, bilo bi dobro razmisliti i o ovome.
Trebamo neku vrstu alata, na prijateljski način, koji će uzeti ove zapise koje naš docker stavlja u svoje datoteke i poslati ih nekamo. Uglavnom, obično pokrećemo neku vrstu agenta unutar Kubernetesa u obliku DaemonSet-a - sakupljača zapisa, kojem se jednostavno kaže gdje se nalaze zapisi koje Docker prikuplja. A taj sakupljač ih jednostavno uzme, možda ih usput nekako i raščlani, možda obogati nekim dodatnim metainformacijama i, na kraju, pošalje nekamo na pohranu. Tu su već moguće varijacije. Najčešći je vjerojatno Elasticsearch, gdje možete pohraniti zapise i jednostavno ih dohvatiti od tamo. Zatim, koristeći zahtjev, koristeći Kibanu, na primjer, izgradite grafikone na temelju njih, izgradite upozorenja na temelju njih, i tako dalje.
Najvažnija ideja, koju želim ponovno ponoviti, jest da je unutar Dockera, posebno unutar Kubernetesa, pohranjivanje vaših zapisa u datoteku vrlo loša ideja.
Jer prvo, teško je dobiti zapisnike unutar spremnika u datoteci. Prvo morate ući u spremnik, izvršiti tamo, a zatim pogledati zapise. Sljedeća točka je da ako imate zapise u datoteci, tada spremnici obično imaju minimalističko okruženje i nema pomoćnih programa koji su obično potrebni za normalan rad sa zapisima. Zakopajte ih, pogledajte ih, otvorite ih u uređivaču teksta. Sljedeći trenutak je kada imamo zapise u datoteci unutar spremnika, ako se ovaj spremnik izbriše, razumijete, zapisnici će umrijeti zajedno s njim. U skladu s tim, svako ponovno pokretanje spremnika znači da više nema zapisa. Opet loša opcija.
I posljednja točka je da unutar spremnika obično imate svoju aplikaciju i to je to - to je obično jedini proces koji se izvodi. Uopće nema govora o bilo kakvom procesu koji bi rotirao datoteke s vašim zapisima. Čim se zapisnici počnu zapisivati u datoteku, to znači da ćemo, oprostite, početi gubiti produkcijski poslužitelj. Jer, prvo, teško ih je pronaći, nitko ih ne prati, plus nitko ih ne kontrolira - prema tome, datoteka raste beskrajno dok prostor na poslužitelju jednostavno ne ponestane. Stoga ponovno kažem da je prijava u datoteku u Dockeru, posebice u Kubernetesu, loša ideja.
Sljedeća točka, ovdje želim ponovno razgovarati o tome - budući da se dotičemo teme trupaca, bilo bi dobro razgovarati o tome kako bi trupci trebali izgledati kako bi bilo zgodno raditi s njima. Kao što sam rekao, tema nije izravno povezana s Kubernetesom, ali je vrlo dobro povezana s temom DevOps. Na temu razvojne kulture i prijateljstva između ova dva različita odjela - Dev i Ops, kako bi svima bilo ugodno.
To znači da bi idealno, danas, zapisi trebali biti pisani u JSON formatu. Ako imate neku svoju nerazumljivu aplikaciju, koja piše logove u nerazumljivim formatima jer ubacite nekakav print ili nešto slično, onda je vrijeme da proguglate nekakav framework, nekakav omotač koji vam omogućuje implementaciju normalnog logovanja; ondje omogućite parametre bilježenja u JSON-u, jer je JSON jednostavan format, njegovo raščlanjivanje je jednostavno.
Ako vaš JSON ne radi prema nekim kriterijima, nitko ne zna kakvim, onda barem zapisnike zapisujte u formatu koji se može analizirati. Ovdje je, radije, vrijedno razmisliti o činjenici da, na primjer, ako pokrećete hrpu spremnika ili samo procesa s nginxom, a svaki ima svoje vlastite postavke bilježenja, tada se vjerojatno čini da će vam biti vrlo nezgodno raščlaniti ih. Zato što za svaku novu instancu nginxa morate napisati svoj vlastiti parser, jer oni drugačije pišu zapisnike. Opet, vjerojatno je vrijedilo razmisliti o tome da sve te instance nginxa imaju istu konfiguraciju bilježenja i da su zapisivali sve svoje zapisnike apsolutno ujednačeno. Isto vrijedi za apsolutno sve aplikacije.
Na kraju, također želim doliti ulje na vatru da bi, idealno, trebalo izbjegavati zapisnike formata s više redaka. Evo o čemu se radi, ako ste ikad radili sa skupljačima trupaca, onda ste najvjerojatnije vidjeli što vam obećavaju, da mogu raditi s višelinijskim trupcima, da ih znaju sakupljati i tako dalje. Zapravo, po mom mišljenju, niti jedan sakupljač danas ne može sakupiti višeredne dnevnike normalno, potpuno i bez grešaka. Na ljudski način, tako da bude zgodno i bez grešaka.
Ali praćenje stoga uvijek je zapisnik s više redaka i kako ih izbjeći. Ovdje se postavlja pitanje da je dnevnik zapis događaja, a stactrace zapravo nije dnevnik. Ako prikupimo zapisnike i stavimo ih negdje u Elasticsearch, a zatim iz njih crtamo grafikone, gradimo neka izvješća o aktivnostima korisnika na vašem web-mjestu, onda kada dobijete praćenje hrpe, to znači da se događa nešto neočekivano. neobrađena situacija u vašoj aplikaciji. I ima smisla automatski uploadati praćenje hrpe negdje u sustav koji ih može pratiti.
Ovo je softver (isti Sentry) koji je napravljen posebno za rad s praćenjem hrpe. Može odmah kreirati automatizirane zadatke, dodijeliti ih nekome, upozoriti kada se pojave stacttraceovi, grupirati te stacttraceove po jednoj vrsti i tako dalje. U principu, nema puno smisla govoriti o stactracesu kada govorimo o trupcima, jer su to ipak različite stvari s različitim namjenama.
Konfiguracija
Zatim govorimo o konfiguraciji u Kubernetesu: što učiniti s tim i kako bi aplikacije unutar Kubernetesa trebale biti konfigurirane. Općenito, obično kažem da se Docker ne bavi kontejnerima. Svi znaju da se Docker bavi kontejnerima, čak i oni koji nisu puno radili s Dockerom. Ponavljam, Docker se ne bavi kontejnerima.
Docker se, po mom mišljenju, bavi standardima. A standardi postoje za gotovo sve: standardi za izradu vaše aplikacije, standardi za instaliranje vaše aplikacije.
I ova stvar - koristili smo je prije, samo je postala posebno popularna pojavom kontejnera - ova stvar se zove ENV (environment) varijable, odnosno varijable okoline koje se nalaze u vašem operativnom sustavu. Ovo je općenito idealan način za konfiguriranje vaše aplikacije, jer ako imate aplikacije u JAVI, Python, Go, Perl, ne daj Bože, i sve one mogu čitati varijable hosta baze podataka, korisnika baze podataka, lozinke baze podataka, onda je idealno. Imate aplikacije na četiri različita jezika konfigurirane 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 sjajan način za deklariranje ENV varijabli unutar Deploymenta. Sukladno tome, ako govorimo o tajnim podacima, tada tajne podatke iz ENV varijabli (lozinke za baze podataka itd.) možemo odmah gurnuti u tajnu, stvoriti tajni klaster i u ENV opisu u Deploymentu naznačiti da ne deklariramo izravno vrijednost ove varijable i vrijednost ove varijable lozinke baze podataka bit će pročitane iz tajne. Ovo je standardno ponašanje Kubernetesa. A ovo je najidealnija opcija za konfiguriranje vaših aplikacija. Samo na razini koda, opet se to odnosi na programere. Ako ste DevOps, možete pitati: “Društvo, molim vas naučite svoju aplikaciju da čita varijable okoline. I svi ćemo biti sretni.”
Ako svi u tvrtki čitaju iste imenovane varijable okruženja, onda je to sjajno. Da se ne dogodi da jedni čekaju postgres bazu, drugi čekaju ime baze, treći čekaju nešto treće, treći čekaju nekakav dbn, pa da, shodno tome, postoji uniformnost.
Problem nastaje kada imate toliko varijabli okoline da samo otvorite Deployment - a tu je pet stotina redaka varijabli okoline. U ovom slučaju jednostavno ste prerasli varijable okruženja - i više se ne morate mučiti. U ovom slučaju, imalo bi smisla početi koristiti konfiguracije. To jest, obučite svoju aplikaciju za korištenje konfiguracija.
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 vlastitom formatu, alternativno darovana - 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 ga čitati, čovjeku je čitljiv, jasno je kako ga čitati iz aplikacije.
Sukladno tome, osim YAML-a, također možete, na primjer, koristiti JSON, parsiranje je približno jednako zgodno kao YAML u smislu čitanja konfiguracije aplikacije od tamo. Ljudima je osjetno nezgodnije za čitanje. Možete isprobati format, a la ini. Prilično je zgodno za čitanje, s ljudske točke gledišta, ali može biti nezgodno automatski ga obrađivati, u smislu da ako ikada poželite generirati vlastite konfiguracije, ini format već može biti nezgodan za generiranje.
Ali u svakom slučaju, koji god format odabrali, poanta je da je s Kubernetes gledišta vrlo zgodan. Cijelu svoju konfiguraciju možete staviti u Kubernetes, u ConfigMap. Zatim uzmite ovu konfiguracijsku mapu i tražite da se montira unutar vašeg modula u neki određeni direktorij, gdje će vaša aplikacija čitati konfiguraciju iz ove konfiguracijske mape kao da je samo datoteka. To je zapravo ono što je dobro učiniti kada imate puno konfiguracijskih opcija u svojoj aplikaciji. Ili je to samo neka vrsta složene strukture, postoji gniježđenje.
Ako imate configmap, možete vrlo dobro naučiti svoju aplikaciju, na primjer, da automatski prati promjene u datoteci u kojoj je configmap montiran, i također automatski ponovno 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 konfiguracijskoj mapi, tajne informacije nisu u varijablama, tajne informacije nisu u tajnama. Odatle povežite ove tajne podatke s diplomacijom. Obično pohranjujemo sve opise Kubernetes objekata, implementacija, konfiguracijskih mapa, usluga u git. Prema tome, stavljanje lozinke u bazu podataka u git, čak i ako je to vaš git, koji imate interno u tvrtki, je loša ideja. Jer, u najmanju ruku, git pamti sve i jednostavno uklanjanje lozinki od tamo nije tako lako.
Provjera zdravlja
Sljedeća točka je ova stvar koja se zove provjera zdravlja. Općenito, provjera zdravlja jednostavno provjerava radi li vaša aplikacija. Pritom najčešće govorimo o određenim web aplikacijama, za koje će, sukladno tome, sa stajališta provjere ispravnosti (bolje ne prevoditi ovdje i dalje) ovo biti neki poseban URL, koji oni obrađuju kao standard, obično rade /health.
Pri pristupanju tom URL-u, sukladno tome, naša aplikacija kaže ili “da, dobro, kod mene je sve u redu, 200” ili “ne, kod mene nije sve u redu, nekih 500”. Sukladno tome, ako naša aplikacija nije http, nije web aplikacija, sada govorimo o nekoj vrsti demona, 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 napraviti. Možete povremeno ažurirati neke informacije u datoteci, možete smisliti neku posebnu naredbu za svog demona, poput, daemon status, koji će reći "da, sve je u redu, demon radi, živ je."
Čemu služi? Prva i najočitija stvar vjerojatno je zašto je potrebna zdravstvena provjera - kako bismo shvatili da aplikacija radi. Mislim, to je samo glupo, kad je sada gore, izgleda da radi, tako da možeš biti siguran da radi. I ispada da aplikacija radi, spremnik radi, instanca radi, sve je u redu - a onda korisnici već isključe sve telefonske brojeve tehničke podrške i kažu “što si ti..., ti zaspao, ništa ne radi.”
Provjera zdravstvenog stanja samo je takav način da se s korisnikove točke gledišta vidi da radi. Jedna od metoda. Recimo to ovako. Sa stajališta Kubernetesa, ovo je također način da shvatimo kada se aplikacija pokreće, jer razumijemo da postoji razlika između vremena kada je spremnik pokrenut, kreiran i pokrenut i kada je aplikacija pokrenuta izravno u ovom spremniku. Jer ako uzmemo neku prosječnu java aplikaciju i pokušamo je pokrenuti u docku, onda na četrdeset sekundi, ili čak minutu, ili čak deset, može krenuti sasvim dobro. U ovom slučaju možete barem pokucati na njegove portove, tamo se neće javiti, odnosno još nije spreman primiti promet.
Opet, uz pomoć provjere zdravlja i uz pomoć činjenice da se ovdje okrećemo, možemo razumjeti u Kubernetesu da nije samo spremnik podignut u aplikaciji, već je i sama aplikacija pokrenuta, već odgovara na provjeru zdravlja, što znači da možemo poslati promet tamo.
Ono o čemu sada govorim zove se Readiness/Liveness testovi unutar Kubernetesa; prema tome, naši testovi spremnosti odgovorni su za dostupnost aplikacije u balansiranju. Odnosno, ako se rade testovi spremnosti u aplikaciji, onda je sve ok, klijentski promet ide prema aplikaciji. Ako se testovi spremnosti ne izvrše, tada aplikacija jednostavno ne sudjeluje, ova konkretna instanca ne sudjeluje u balansiranju, uklanja se iz balansiranja, klijentski promet ne teče. Sukladno tome, potrebni su Liveness testovi unutar Kubernetesa kako bi se aplikacija, ako zapne, mogla ponovno pokrenuti. Ako test živosti ne radi za aplikaciju koja je deklarirana u Kubernetesu, tada se aplikacija ne samo uklanja iz balansiranja, već se ponovno pokreće.
I ovdje je važna stvar koju bih želio spomenuti: s praktičnog gledišta, test spremnosti obično se koristi češće i češće je potreban od testa živosti. Odnosno, jednostavno nepromišljeno proglašavanje i testova spremnosti i testova živosti, jer Kubernetes to može, a iskoristimo sve što može, nije baš dobra ideja. Objasnit ću zašto. Jer točka broj dva u testiranju je da bi bilo dobro provjeriti temeljnu uslugu u svojim zdravstvenim provjerama. To znači da ako imate web aplikaciju koja daje neke informacije, koje pak 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š Healthcheck odgovori jednostavno kao kontaktirani slashhealth, aplikacija kaže "200, u redu, sve je u redu", au isto vrijeme baza podataka vaše aplikacije je nedostupna, a aplikacija Healthcheck kaže "200, u redu, sve je u redu ” - Ovo je loš zdravstveni pregled. Ovako ne bi trebalo funkcionirati.
Odnosno, vaša prijava, kada na nju dođe zahtjev /health, ne odgovara samo "200, u redu", prvo odlazi, na primjer, u bazu podataka, pokušava se povezati s njom, radi nešto vrlo osnovno tamo, poput odabira, samo provjerava postoji li veza u bazu podataka i možete postavljati upite bazi podataka. Ako je sve ovo bilo uspješno, tada je odgovor "200, ok." Ako ne uspije, piše da postoji greška, baza podataka nije dostupna.
Stoga se s tim u vezi ponovno vraćam na Readiness/Liveness testove - zašto vam najvjerojatnije treba test spremnosti, ali test živosti je u pitanju. Jer ako opišete zdravstvene provjere točno onako kako sam upravo rekao, tada će se pokazati da nisu dostupne u dijelu instanceв или со всех instanceu bazi podataka, na primjer. Kada ste proglasili test spremnosti, naše zdravstvene provjere su počele padati, a sukladno tome sve aplikacije iz kojih baza nije dostupna, jednostavno se isključe iz balansiranja i zapravo “vise” samo u zapuštenom stanju i čekaju da im se baze raditi.
Ako smo proglasili liveness test, onda zamislite, naša baza podataka se pokvarila, au vašem Kubernetesu se pola svega počne ponovno pokretati jer test živosti nije uspio. To znači da morate ponovno pokrenuti. To uopće nije ono što želite, čak sam imao osobno iskustvo u praksi. Imali smo aplikaciju za chat koja je bila napisana u JS-u i unesena u Mongo bazu podataka. A problem je bio što je na početku mog rada s Kubernetesom opisivali spremnost, živost testova po principu da Kubernetes to može, pa ćemo ga i koristiti. U skladu s tim, u nekom trenutku Mongo je postao malo "tup" i uzorak je počeo propadati. Sukladno tome, prema testu kiše, mahune su počele “ubijati”.
Kao što razumijete, kada su "ubijeni", ovo je chat, odnosno na njemu visi mnogo veza klijenata. I oni su “ubijeni” - ne, ne klijenti, samo veze - ne svi u isto vrijeme, a zbog činjenice da se ne ubijaju u isto vrijeme, neki ranije, neki kasnije, ne počinju u isto vrijeme vrijeme. Plus standardno nasumično, ne možemo predvidjeti s milisekundom točnošću vrijeme početka aplikacije svaki put, tako da to čine jednu po jednu instancu. Digne se jedan infospot, doda se na balansiranje, tu dolaze svi klijenti, ne može izdržati toliki teret, jer je sam, a ugrubo ih tu radi desetak, i padne. Sljedeći se digne, sav teret je na njemu, on također padne. Pa, ovi se padovi nastavljaju nizati. Na kraju, kako je to riješeno - samo smo morali striktno zaustaviti korisnički promet prema ovoj aplikaciji, pustiti sve instance da se dignu i onda pokrenuti sav korisnički promet odjednom tako da je već raspoređen na svih deset instanci.
Da nije bilo ovog najavljenog testa živosti, koji bi ga sve prisilio na ponovno pokretanje, aplikacija bi to sasvim dobro podnijela. Ali sve od balansiranja nam je onemogućeno, jer su baze nedostupne i svi korisnici su “otpali”. Zatim, kada ta baza postane dostupna, sve je uključeno u balansiranje, ali aplikacije se ne moraju ponovno pokretati, niti je potrebno gubiti vrijeme i resurse na to. Svi su već tu, spremni su za promet, samo se promet otvori, sve je u redu - aplikacija je postavljena, sve radi dalje.
Dakle, testovi spremnosti i živosti su različiti, čak štoviše, teoretski možete raditi različite zdravstvene provjere, jednu vrstu radijusa, jednu vrstu liv, na primjer, i provjeravati različite stvari. Tijekom testova spremnosti provjerite svoje pozadine. A na testu živosti, na primjer, ne provjeravate sa stajališta da je test živosti općenito samo aplikacija koja reagira, može li uopće odgovoriti.
Zato što je test vitalnosti, uglavnom, kada smo "zaglavljeni". Počela je beskonačna petlja ili nešto treće - i više se ne obrađuju zahtjevi. Stoga ih ima smisla čak i razdvojiti – i u njih implementirati različitu logiku.
Što se tiče onoga što trebate odgovoriti kada imate test, kada radite zdravstvene preglede. To je stvarno bol. Oni koji su upoznati s ovim vjerojatno će se nasmijati - ali ozbiljno, u životu sam vidio servise koji u 200% slučajeva odgovaraju "XNUMX". Odnosno tko je uspješan. Ali u isto vrijeme u tijelu odgovora pišu "takva i takva pogreška."
Odnosno, dolazi vam status odgovora - sve je uspješno. Ali u isto vrijeme, morate analizirati tijelo, jer tijelo kaže "oprostite, zahtjev je završio s pogreškom" i to je samo stvarnost. Vidio 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 provjerama ispravnosti, te načelno pri radu s web aplikacijama.
Ako je sve prošlo u redu, odgovorite dvjestotim odgovorom. U principu, odgovarat će vam bilo koji dvjestoti odgovor. Ako jako 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 ide loše i zdravstvena provjera ne reagira, odgovorite bilo kojom petstotinkom. Opet, ako razumijete kako odgovoriti, koliko se različiti statusi odgovora međusobno razlikuju. 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 točka, želim se vratiti malo o provjeri temeljnih usluga. Ako počnete, na primjer, provjeravati sve temeljne usluge koje stoje iza vaše aplikacije - sve općenito. Ono što dobivamo sa stajališta arhitekture mikroservisa, imamo takav koncept kao "nisko spajanje" - to jest, kada vaše usluge minimalno ovise jedna o drugoj. Ako jedan od njih zakaže, svi ostali bez ove funkcije jednostavno će nastaviti raditi. Neke funkcije jednostavno ne rade. U skladu s tim, ako povežete sve zdravstvene provjere jedne s drugima, tada ćete završiti s jednom neuspješnom infrastrukturom, a budući da je pala, sve zdravstvene provjere svih usluga također počinju padati - a postoji više infrastrukture općenito za cijela arhitektura mikroservisa br. Tamo se sve smračilo.
Stoga još jednom želim ponoviti da morate provjeriti temeljne servise, one bez kojih vaša aplikacija u sto posto slučajeva ne može raditi svoj posao. Odnosno, logično je da ako imate REST API preko kojeg korisnik sprema u bazu ili dohvaća iz baze podataka, onda u nedostatku baze podataka ne možete jamčiti 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 frontendu - a taj backend nije dostupan, to znači da dajete svoj odgovor bez ikakvog dijela metapodataka.
Dalje, imamo i jedan od bolnih problema prilikom pokretanja aplikacija.
Zapravo, ovo se uglavnom ne odnosi samo na Kubernetes; slučajno se dogodilo da se kultura neke vrste masovnog razvoja, a posebno DevOps, počela širiti otprilike u isto vrijeme kad i Kubernetes. Stoga, uglavnom, ispada da trebate elegantno zatvoriti svoju aplikaciju bez Kubernetesa. I prije Kubernetesa ljudi su to radili, no dolaskom Kubernetesa počelo se masovno pričati o tome.
Graciozno isključivanje
Općenito, što je Graceful Shutdown i zašto je potreban? Ovdje se radi o tome da trebate učiniti kada se vaša aplikacija iz nekog razloga sruši app stop - ili primite, na primjer, signal od operativnog sustava, vaša aplikacija to mora razumjeti i poduzeti nešto po tom pitanju. Najgori mogući scenarij je, naravno, kada vaša prijava primi SIGTERM i kaže: "SIGTERM, čekajmo, radimo, ne radimo ništa." Ovo je potpuno loša opcija.
Gotovo jednako loša opcija je kada vaša aplikacija dobije SIGTERM i bude kao “rekli su segterm, to znači da završavamo, nisam vidio, ne znam nikakve korisničke zahtjeve, ne znam kakve zahtjevi na kojima trenutno radim, rekli su SIGTERM, to znači da završavamo " Ovo je također loša opcija.
Koja je opcija dobra? Prva točka je uzeti u obzir završetak operacija. Dobra opcija je da vaš poslužitelj ipak uzme u obzir što radi ako primi SIGTERM.
SIGTERM je soft shutdown, posebno je dizajniran, može se presresti na razini koda, može se obraditi, reci sad, čekaj, prvo ćemo završiti posao koji imamo, pa ćemo izaći.
Iz perspektive Kubernetesa, to izgleda ovako. Kada kažemo podu koji radi u Kubernetes klasteru, "molim te, zaustavi se, odlazi", ili se ponovno pokrenemo, ili se ažuriranje dogodi kada Kubernetes ponovno kreira podove, Kubernetes šalje istu poruku SIGTERM podu, čeka neko vrijeme, i , to je vrijeme koje on čeka, također je konfigurirano, postoji takav poseban parametar u diplomama i zove se Graceful ShutdownTimeout. Kao što razumijete, ne zove se tako uzalud, i nije uzalud što sada o tome govorimo.
Tamo možemo konkretno reći koliko dugo trebamo čekati između trenutka kada aplikaciji pošaljemo SIGTERM i kada shvatimo da je aplikacija izgleda poludjela za nečim ili je "zapela" i neće završiti - i moramo poslati ga SIGKILL, odnosno teško dovršiti njegov posao. To jest, prema tome, imamo neku vrstu demona koji radi, obrađuje operacije. Razumijemo da naše operacije na kojima radi demon u prosjeku ne traju više od 30 sekundi. Prema tome, kada stigne SIGTERM, razumijemo da naš demon može završiti najviše 30 sekundi nakon SIGTERM-a. Napišemo ga npr. 45 sekundi za svaki slučaj i kažemo taj SIGTERM. Nakon toga čekamo 45 sekundi. U teoriji, tijekom tog vremena demon je trebao dovršiti svoj posao i okončati sam sebe. Ali ako odjednom ne može, to znači da je najvjerojatnije zapelo - više ne obrađuje naše zahtjeve normalno. I za 45 sekundi možete ga sigurno, zapravo, zakucati.
I tu se zapravo mogu uzeti u obzir čak 2 aspekta. Prvo, shvatite da ako ste dobili zahtjev, počeli ste nekako raditi s njim i niste dali odgovor korisniku, ali ste dobili SIGTERM, na primjer. Ima smisla doraditi ga i dati odgovor korisniku. Ovo je točka broj jedan u ovom pogledu. Poanta broj dva ovdje je da ako napišete vlastitu aplikaciju, općenito izgradite arhitekturu na takav način da primite zahtjev za svoju aplikaciju, zatim počnete nešto raditi, počnete preuzimati datoteke odnekud, preuzimati bazu podataka, i što ne. - Da. Općenito, vaš korisnik, vaš zahtjev visi pola sata i čeka da mu odgovorite - tada, najvjerojatnije, trebate raditi na arhitekturi. To jest, samo uzmite u obzir čak i zdrav razum da ako su vaše operacije kratke, onda ima smisla ignorirati SIGTERM i modificirati ga. Ako su vaše operacije duge, onda nema smisla ignorirati SIGTERM u ovom slučaju. Ima smisla redizajnirati arhitekturu kako bi se izbjegle tako duge operacije. Kako korisnici ne bi samo ostali i čekali. Ne znam, napravite tamo nekakav websocket, napravite reverse hookove koje će vaš server već poslati klijentu, bilo što drugo, ali nemojte tjerati korisnika da visi pola sata i samo čekajte sesiju dok ne odgovori mu. Jer nepredvidivo je gdje bi moglo puknuti.
Kada se vaša aplikacija prekine, trebali biste unijeti odgovarajući izlazni kod. To jest, ako je od vaše aplikacije zatraženo da se zatvori, zaustavi, a ona se sama normalno zaustavila, tada ne morate vraćati neku vrstu izlaznog koda 1,5,255 i tako dalje. Sve što nije nulti kod, barem u Linux sustavima, siguran sam u to, smatra se neuspješnim. Odnosno, smatra se da je Vaša prijava u ovom slučaju završila s greškom. Sukladno tome, na prijateljski način, ako je vaša prijava završila bez greške, kažete 0 na izlazu. Ako vaša aplikacija iz nekog razloga ne uspije, u izlazu kažete da nije 0. I možete raditi s ovim informacijama.
I zadnja opcija. Loše je kada vaš korisnik pošalje zahtjev i visi pola sata dok ga vi obradite. Ali općenito, također bih želio reći o tome što se općenito isplati sa strane klijenta. Nije važno imate li mobilnu aplikaciju, front-end itd. Potrebno je uzeti u obzir da se općenito sesija korisnika može prekinuti, svašta se može dogoditi. Zahtjev se može poslati, na primjer, nedovoljno obrađen i bez odgovora. Vaše sučelje ili vaša mobilna aplikacija - bilo koje sučelje općenito, recimo to tako - trebalo bi to uzeti u obzir. Ako radite s websocketima, ovo je općenito najgora muka koju sam ikada imao.
Kada programeri nekih uobičajenih chatova to ne znaju, ispada da websocket može puknuti. Za njih, kada se nešto dogodi na proxyju, mi samo promijenimo konfiguraciju i ona se ponovno učitava. Naravno, sve dugotrajne sesije su pokidane u ovom slučaju. Programeri nam dotrče i kažu: “Dečki, što radite, pokvario se chat svim našim klijentima!” Kažemo im: “Što to radite? Vaši se klijenti ne mogu ponovno povezati? Kažu: "Ne, trebamo da se sesije ne pokidaju." Ukratko, ovo je zapravo besmislica. Potrebno je uzeti u obzir stranu klijenta. Pogotovo, kao što sam rekao, s dugotrajnim sesijama kao što su websockets, može se pokvariti i, neprimijećen od strane korisnika, morate biti u mogućnosti ponovno instalirati takve sesije. I tada je sve savršeno.
sredstva
Zapravo, ovdje ću vam samo ispričati iskrenu 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 jednom je rekao: “Moja aplikacija se ne pokreće u klasteru.” Pogledao sam da vidim da se ne pokreće, ali ili se ne uklapa u resurse ili su postavili vrlo mala ograničenja. Ukratko, aplikacija se ne može pokrenuti zbog resursa. Ja kažem: "Neće krenuti zbog resursa, vi odlučite koliko vam treba i postavite odgovarajuću vrijednost." On kaže: "Kakvi resursi?" Počeo sam mu objašnjavati da treba postaviti Kubernetes, limite na zahtjeve i bla, bla, bla. Čovjek je slušao pet minuta, kimnuo i rekao: “Došao sam ovdje raditi kao programer, ne želim ništa znati ni o kakvim resursima. Došao sam ovdje napisati kod i to je to.” Tužno je. Ovo je vrlo tužan koncept sa stajališta programera. Pogotovo u modernom svijetu, da tako kažem, progresivnih devopa.
Zašto su uopće potrebni resursi? U Kubernetesu postoje 2 vrste resursa. Neki se nazivaju zahtjevi, drugi se nazivaju ograničenja. Pod resursima ćemo razumjeti da u osnovi uvijek postoje samo dva osnovna ograničenja. Odnosno, vremenska ograničenja CPU-a i ograničenja RAM-a za spremnik koji radi u Kubernetesu.
Ograničenje postavlja gornju granicu kako se resurs može koristiti u vašoj aplikaciji. To jest, prema tome, ako kažete 1 GB RAM-a u ograničenjima, tada vaša aplikacija neće moći koristiti više od 1 GB RAM-a. A ako iznenada poželi i pokuša to učiniti, tada će proces koji se zove oom killer, bez memorije, to jest, doći i ubiti vašu aplikaciju - to jest, jednostavno će se ponovno pokrenuti. Aplikacije se neće ponovno pokrenuti na temelju procesora. Što se tiče CPU-a, ako aplikacija pokuša koristiti puno, više od navedenog u ograničenjima, CPU će jednostavno biti strogo odabran. To ne dovodi do ponovnih pokretanja. Ovo je granica - ovo je gornja granica.
I postoji zahtjev. Zahtjev je način na koji Kubernetes razumije kako su čvorovi u vašem Kubernetes klasteru popunjeni aplikacijama. Odnosno, zahtjev je vrsta predaje vaše aplikacije. Piše ono što želim koristiti: "Želio bih da rezervirate ovoliko CPU-a i ovoliko memorije za mene." Tako jednostavna analogija. Što ako imamo čvor koji ima, ne znam, ukupno 8 CPU-a. I tamo stiže pod, čiji zahtjevi kažu 1 CPU, što znači da čvoru preostaje 7 CPU-a. To jest, prema tome, čim 8 podova stigne na ovaj čvor, od kojih svaki ima 1 CPU u svojim zahtjevima, čvor je, kao da je sa stajališta Kubernetesa ostao bez CPU-a i više podova sa zahtjevima ne može biti pokrenut na ovom čvoru. Ako svim čvorovima ponestane CPU-a, Kubernetes će početi govoriti da u klasteru nema odgovarajućih čvorova za pokretanje vaših podova jer je CPU ponestao.
Zašto su potrebni zahtjevi i zašto bez zahtjeva, mislim da nema potrebe pokretati ništa u Kubernetesu? Zamislimo hipotetsku situaciju. Aplikaciju pokrećete bez zahtjeva, Kubernetes ne zna koliko čega imate, na koje čvorove to možete gurnuti. Pa gura, gura, gura na čvorove. U nekom trenutku počet ćete dobivati promet na svoju aplikaciju. I jedna od aplikacija odjednom počne koristiti resurse do granica koje ima prema ograničenjima. Ispostavilo se da postoji još jedna aplikacija u blizini i njoj također trebaju resursi. Čvor zapravo počinje fizički ostajati bez resursa, na primjer, OP. Čvor zapravo počinje fizički ostajati bez resursa, na primjer, memorije s izravnim pristupom (RAM). Kada čvor ostane bez struje, prvo će docker prestati reagirati, zatim kocka, a zatim OS. Jednostavno će se onesvijestiti i SVE će vam definitivno prestati raditi. To jest, to će dovesti do toga da se vaš čvor zaglavi i morat ćete ga ponovno pokrenuti. Ukratko, situacija nije baš dobra.
A kada imate zahtjeve, limiti se ne razlikuju puno, barem ne puno puta više od limita ili zahtjeva, onda možete imati tako normalno, racionalno punjenje aplikacija po čvorovima Kubernetes klastera. Pritom je Kubernetes otprilike svjestan koliko čega gdje stavlja, koliko se gdje koristi. Odnosno, to je jednostavno takav trenutak. Važno je to razumjeti. I važno je kontrolirati da je to naznačeno.
Pohrana podataka
Naša sljedeća točka odnosi se na pohranu podataka. Što učiniti s njima i općenito, što učiniti s postojanošću u Kubernetesu?
Mislim, opet, unutar našeg , bila je tema o bazi podataka u Kubernetesu. A čini mi se da čak i otprilike znam što su vam kolege rekli na pitanje: “Je li moguće pokrenuti bazu podataka u Kubernetesu?” Iz nekog razloga, čini mi se da su vam kolege trebali reći da ako postavljate pitanje je li moguće pokrenuti bazu podataka u Kubernetesu, onda je to nemoguće.
Logika je ovdje jednostavna. Za svaki slučaj, objasnit ću vam još jednom, ako ste stvarno cool tip koji može izgraditi prilično otporan na greške sustav distribuirane mrežne pohrane, shvatite kako uklopiti bazu podataka u ovaj slučaj, kako bi trebao funkcionirati izvorni oblak u spremnicima u bazi podataka općenito. Najvjerojatnije nemate pitanja o tome kako ga pokrenuti. Ako imate takvo pitanje i želite biti sigurni da se sve odvija i stoji ispravno u proizvodnji i nikada ne pada, onda se to neće dogoditi. Ovim ćete pristupom zajamčeno pucati sebi u nogu. Tako da bolje nemoj.
Što bismo trebali učiniti s podacima koje bi naša aplikacija željela pohraniti, nekim slikama koje korisnici postavljaju, nekim stvarima koje naša aplikacija generira tijekom rada, pri pokretanju, na primjer? Što učiniti s njima u Kubernetesu?
Općenito, idealno, da, naravno, Kubernetes je vrlo dobro dizajniran i općenito je inicijalno zamišljen za aplikacije bez stanja. Odnosno, za one aplikacije koje uopće ne pohranjuju informacije. Ovo je idealno.
Ali, naravno, idealna opcija ne postoji uvijek. Pa što? Prva i najjednostavnija točka je uzeti nekakav S3, samo ne domaći, što također nije jasno kako radi, već od nekog provajdera. Dobar, normalan pružatelj - i nauči svoju aplikaciju da koristi S3. To jest, kada vaš korisnik želi prenijeti datoteku, recite "ovdje, molim vas, prenesite je na S3." Kada ga želi primiti, recite: "Ovdje je poveznica na S3 natrag i preuzmite je 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 užasne ostavštine, ne može koristiti S3 protokol, ali mora raditi s lokalnim imenicima u lokalne mape. Uzmite nešto manje-više jednostavno, implementirajte Kubernetes. Odnosno, odmah ograditi Cepha za neke minimalne zadatke, čini mi se, loša ideja. Jer Ceph je, naravno, dobar i moderan. Ali ako zapravo ne razumijete što radite, onda kada jednom stavite nešto na Ceph, možete vrlo lako i jednostavno to više nikada odande izvaditi. Jer, kao što znate, Ceph pohranjuje podatke u svoj klaster u binarnom obliku, a ne u obliku jednostavnih datoteka. Stoga, ako se Ceph klaster iznenada pokvari, tada postoji potpuna i velika vjerojatnost da više nikada nećete dobiti svoje podatke od tamo.
Imat ćemo tečaj o Cephu, možete .
Stoga je bolje napraviti nešto jednostavno poput NFS poslužitelja. Kubernetes može raditi s njima, možete montirati direktorij pod NFS poslužitelj - vaša aplikacija je poput lokalnog imenika. U isto vrijeme, naravno, morate shvatiti da, opet, morate učiniti nešto sa svojim NFS-om, morate shvatiti da ponekad može postati nedostupan i razmislite o tome što ćete učiniti u tom slučaju. Možda bi to trebalo sigurnosno kopirati negdje na zasebnom računalu.
Sljedeća točka o kojoj sam govorio je što učiniti ako vaša aplikacija generira neke datoteke tijekom rada. Na primjer, kada se pokrene, generira neku statičnu datoteku, koja se temelji na nekim informacijama koje aplikacija prima samo u trenutku pokretanja. Kakav trenutak. Ako nema mnogo takvih podataka, onda se uopće ne morate truditi, samo instalirajte ovu aplikaciju za sebe i radite. Ovdje je jedino pitanje što, gledajte. Vrlo često, svakakvi naslijeđeni sustavi, kao što je WordPress i tako dalje, posebno s modificiranim nekakvim pametnim dodacima, pametni PHP programeri, često znaju napraviti tako da sami sebi generiraju nekakvu datoteku. Prema tome, jedan generira jednu datoteku, drugi generira drugu datoteku. Oni su drugačiji. Balansiranje se događa u Kubernetes klasteru klijenata jednostavno slučajno. Sukladno tome, ispada da oni, na primjer, ne znaju surađivati. Jedan daje jednu informaciju, drugi daje korisniku drugu informaciju. Ovo je nešto što biste trebali izbjegavati. Odnosno, u Kubernetesu je zajamčeno da sve što pokrenete može raditi u više instanci. Jer Kubernetes je pokretna stvar. Sukladno tome, može premjestiti bilo što, kad god poželi, a da nikoga ne pita. Stoga, morate računati na ovo. Sve što se pokrene u jednoj instanci prije ili kasnije propadne. Što više rezervacija imate, to bolje. Ali opet, kažem, ako imate nekoliko takvih datoteka, onda ih možete staviti točno ispod sebe, male su težine. Ako ih ima malo više, vjerojatno ih ne biste trebali gurati u posudu.
Savjetovao bih da u Kubernetesu postoji tako divna stvar, možete koristiti glasnoću. Konkretno, postoji volumen tipa prazni dir. To jest, radi se o tome da će Kubernetes automatski stvoriti direktorij u svojim direktorijima usluga na poslužitelju na kojem ste započeli. I dat će vam ga da ga možete koristiti. Postoji samo jedna važna točka. To jest, vaši podaci neće biti pohranjeni unutar spremnika, već na glavnom računalu na kojem se izvodite. Štoviše, Kubernetes može kontrolirati takve prazne direktorije u normalnoj konfiguraciji i može kontrolirati njihovu maksimalnu veličinu i ne dopustiti da se prekorači. Jedina stvar je da se ono što ste upisali u prazan direktorij ne izgubi tijekom ponovnog pokretanja modula. To jest, ako vaša mahuna greškom padne i ponovno se podigne, informacije u praznom direktoriju neće nikamo otići. Može ga ponovno koristiti na novom početku - i to je dobro. Ako vaša mahuna negdje ode, onda će prirodno otići bez podataka. Odnosno, čim pod iz čvora na kojem je pokrenut s praznim direktorijem nestane, prazan direktorij se briše.
Što je još dobro kod praznog direktorija? Na primjer, može se koristiti kao predmemorija. Zamislimo da naša aplikacija nešto generira u hodu, daje korisnicima i to radi dugo vremena. Dakle, aplikacija ga, primjerice, generira i daje korisnicima, a pritom ga negdje i pohranjuje, tako da sljedeći put kada korisnik dođe po istu stvar, brže ga da odmah generiranog. Prazan direktorij može se zatražiti od Kubernetesa da ga stvori u memoriji. I stoga, vaše predmemorije općenito mogu raditi brzinom munje - u smislu brzine pristupa disku. To jest, imate prazan direktorij u memoriji, u OS-u je pohranjen u memoriji, ali za vas, za korisnika unutar modula, to izgleda kao samo lokalni direktorij. Ne trebate aplikaciju za posebno podučavanje bilo kakve magije. Samo izravno uzmete i stavite datoteku u direktorij, ali zapravo u memoriju OS-a. Ovo je također vrlo zgodna značajka u smislu Kubernetesa.
Kakve probleme ima Minio? Glavni problem s Miniom je što da bi ta stvar radila, mora biti pokrenuta negdje, i mora postojati nekakav datotečni sustav, odnosno pohrana. I tu nailazimo na iste probleme koje ima Ceph. Odnosno, Minio mora negdje pohraniti svoje datoteke. To je jednostavno HTTP sučelje za vaše datoteke. Štoviše, funkcionalnost je očito lošija od Amazonovog S3. Prethodno nije mogao ispravno autorizirati korisnika. Sada, koliko ja znam, već može kreirati kante s različitim ovlaštenjima, ali opet, čini mi se da je glavni problem, da tako kažem, barem temeljni sustav pohrane.
Kako prazan direktorij u memoriji utječe na ograničenja? Ni na koji način ne utječe na ograničenja. Leži u memoriji hosta, a ne u memoriji vašeg spremnika. To jest, vaš spremnik ne vidi prazan direktorij u memoriji kao dio svoje zauzete memorije. Domaćin to vidi. Sukladno tome, da, sa gledišta kubernetesa, kada počnete koristiti ovo, bilo bi dobro shvatiti da dio svoje memorije posvećujete praznom direktoriju. I u skladu s tim, shvatite da memorija može ponestati ne samo zbog aplikacija, već i zato što netko piše u te prazne direktorije.
Izvornost u oblaku
I posljednja podtema je ono što je Cloudnative. Zašto je to potrebno? Izvornost u oblaku i tako dalje.
Odnosno one aplikacije koje su sposobne i napisane za rad u modernoj cloud infrastrukturi. Ali, zapravo, postoji još jedan aspekt Cloudnativea. Da ovo nije samo aplikacija koja uvažava sve zahtjeve moderne cloud infrastrukture, već i zna kako raditi s tom modernom cloud infrastrukturom, iskoristite prednosti i nedostatke činjenice da radi u tim oblacima. Nemojte samo pretjerivati i raditi u oblaku, 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 stvoriti račun usluge. Odnosno račun za autorizaciju u samom Kubernetesu na njegovom serveru. Tamo dodajte neka prava koja su nam potrebna. Kubernetesu možete pristupiti iz svoje aplikacije. Što možete učiniti na ovaj način? Na primjer, od aplikacije primajte podatke o tome gdje se nalaze vaše druge aplikacije, druge slične instance i zajedno se nekako klasterirajte na vrhu Kubernetesa, ako postoji takva potreba.
Opet, doslovno smo nedavno imali slučaj. Imamo jednog kontrolora koji prati red. A kada se neki novi zadaci pojave u ovom redu čekanja, on ide u Kubernetes - i unutar Kubernetesa stvara novi pod. Daje ovom pod-u neki novi zadatak i unutar okvira ovog pod-a, pod obavlja zadatak, šalje odgovor samom kontroleru, a kontroler onda radi nešto s tom informacijom. Na primjer, dodaje bazu podataka. To jest, opet, ovo je plus činjenice da naša aplikacija radi u Kubernetesu. Možemo koristiti samu ugrađenu funkcionalnost Kubernetesa kako bismo na neki način proširili i učinili funkcionalnost naše aplikacije praktičnijom. Odnosno, nemojte skrivati neku vrstu magije o tome kako pokrenuti aplikaciju, kako pokrenuti worker. U Kubernetesu jednostavno pošaljete zahtjev u aplikaciji ako je aplikacija napisana u Pythonu.
Isto vrijedi ako idemo dalje od Kubernetesa. Imamo naš Kubernetes koji radi negdje - dobro je ako je u nekom oblaku. Opet, možemo koristiti, pa čak i trebamo, vjerujem, koristiti mogućnosti samog oblaka tamo gdje se nalazimo. Od elementarnih stvari koje nam oblak pruža. Balansiranje, odnosno možemo kreirati cloud balancere i koristiti ih. Ovo je izravna prednost onoga što možemo koristiti. Jer balansiranje oblaka, prvo, jednostavno glupo uklanja odgovornost s nas za to kako radi, kako je konfigurirano. Osim toga, vrlo je zgodno, jer se obični Kubernetes može integrirati s oblacima.
Isto vrijedi i za skaliranje. Obični Kubernetes može se integrirati s pružateljima usluga u oblaku. Zna kako razumjeti da ako klasteru ponestane čvorova, odnosno ponestalo je prostora za čvorove, onda trebate dodati - Kubernetes će sam dodati nove čvorove u vaš klaster i početi pokretati podove na njima. To jest, kada dođe vaše opterećenje, broj ognjišta se počinje povećavati. Kada ponestane čvorova u klasteru za ove podove, Kubernetes pokreće nove čvorove i, u skladu s tim, broj podova se još može povećati. I to je vrlo povoljno. Ovo je izravna prilika za skaliranje klastera u hodu. Ne baš brzo, u smislu da to nije sekunda, to je više kao minuta kako bi se dodali novi čvorovi.
Ali iz mog iskustva, opet, to je najcool stvar koju sam ikad vidio. Kada se klaster Cloudnative skalirao na temelju doba dana. Bila je to pozadinska usluga koju su koristili ljudi u pozadinskom uredu. Odnosno, dođu na posao u 9 ujutro, počnu se prijavljivati u sustav i shodno tome klaster Cloudnative, gdje sve to radi, počinje bujati, lansirati nove podove kako bi svi koji dolaze na posao mogli raditi s aplikacijom. Kad odu s posla u 8 ili 6 sati, Kubernetes klasteri primijete da više nitko ne koristi aplikaciju i počnu se smanjivati. Ušteda do 30 posto je zajamčena. To je u to vrijeme radilo u Amazonu; u to vrijeme u Rusiji nije bilo nikoga tko bi to mogao tako dobro izvesti.
Odmah ću vam reći, ušteda je 30 posto jednostavno zato što koristimo Kubernetes i iskorištavamo mogućnosti oblaka. Sada se to može učiniti u Rusiji. Naravno, neću nikome reklamirati, ali recimo samo da postoje pružatelji usluga koji to mogu učiniti, pružiti to odmah iz kutije s gumbom.
Postoji još jedna posljednja točka na koju bih vam također želio skrenuti pozornost. Kako 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, odnosno to znači da je vaša aplikacija, odnosno vaša infrastruktura, potrebna na potpuno isti način kao i code Opišite svoju aplikaciju, svoju poslovnu logiku u obliku koda. I radite s njim kao kodom, to jest, testirajte ga, razvijte, pohranite u git, primijenite CICD na njega.
I to je upravo ono što vam omogućuje, prvo, da uvijek imate kontrolu nad svojom infrastrukturom, da uvijek razumijete u kakvom je stanju. Drugo, izbjegavajte ručne operacije koje uzrokuju pogreške. Treće, jednostavno izbjegavajte ono što se zove fluktuacija, kada stalno trebate obavljati iste ručne zadatke. Četvrto, omogućuje vam puno brži oporavak u slučaju kvara. U Rusiji, svaki put kad govorim o tome, uvijek postoji ogroman broj ljudi koji kažu: "Da, jasno je, ali imate pristupe, ukratko, nema potrebe ništa popravljati." Ali istina je. Ako je nešto pokvareno u vašoj infrastrukturi, tada je sa stajališta Cloudnative pristupa i sa gledišta Infrastrukture kao koda, lakše nego da to popravljate, odete na poslužitelj, otkrijete što je pokvareno i popravite to. za brisanje poslužitelja i ponovno stvaranje. I dat ću sve ovo obnoviti.
O svim ovim pitanjima detaljnije se govori na . Prateći poveznicu možete se upoznati s programom i uvjetima. Zgodna stvar je što možete savladati Kubernetes učeći od kuće ili radeći 1-2 sata dnevno.
Izvor: www.habr.com