Danes nameravam govoriti o tem, kako pisati aplikacije in kakšne so zahteve, da vaša aplikacija dobro deluje v Kubernetesu. Da z aplikacijo ni preglavic, da si okoli nje ne rabiš izmišljevati in graditi "prask" - in vse deluje tako, kot si je zamislil sam Kubernetes.
To predavanje je del "" Ogledate si lahko odprta teoretična predavanja Večerne šole . Za tiste, ki imate raje besedilo kot video, smo pripravili ta članek.
Moje ime je Pavel Selivanov, trenutno sem vodilni inženir DevOps pri Mail.ru Cloud Solutions, izdelujemo oblake, izdelujemo kubernete za upravljanje in tako naprej. Moje naloge zdaj vključujejo pomoč pri razvoju, uvajanje teh oblakov, uvajanje aplikacij, ki jih pišemo, in neposreden razvoj orodij, ki jih nudimo našim uporabnikom.
DevOps delam, mislim, da zadnja, verjetno tri leta. Toda načeloma počnem to, kar počne DevOps, že verjetno približno pet let. Pred tem sem se večinoma ukvarjal z administratorskimi zadevami. S Kubernetesom sem se začel ukvarjati že dolgo nazaj – verjetno so minila že kakšna štiri leta, odkar sem se z njim ukvarjal.
Na splošno sem začel, ko je bil Kubernetes različice 1.3, verjetno, in morda 1.2 - ko je bil še v povojih. Zdaj ni več v povojih – in očitno je na trgu ogromno povpraševanja po inženirjih, ki bi radi znali delati Kubernetes. In podjetja imajo zelo veliko povpraševanje po takih ljudeh. Zato se je pravzaprav pojavilo to predavanje.
Če govorimo po načrtu, o čem bom govoril, izgleda takole, v oklepaju je zapisano (TL;DR) - “predolgo; ne beri". Moja današnja predstavitev bo sestavljena iz neskončnih seznamov.
Pravzaprav tudi sam ne maram takšnih predstavitev, ko so narejene, vendar je to taka tema, da ko sem pripravljal to predstavitev, preprosto nisem razumel, kako drugače urediti te informacije.
Ker so te informacije na splošno »ctrl+c, ctrl+v«, med drugim iz našega Wikija v razdelku DevOps, kjer imamo zapisane zahteve za razvijalce: »fantje, tako da zaženemo vašo aplikacijo v Kubernetes, moralo bi biti tako."
Zato se je predstavitev izkazala za tako velik seznam. oprosti. Poskušal bom povedati čim več, da ne bo dolgočasno, če se le da.
Kaj si bomo zdaj ogledali:
- to so najprej dnevniki (dnevniki aplikacij?), kaj narediti z njimi v Kubernetesu, kaj narediti z njimi, kakšni naj bodo;
- kaj narediti s konfiguracijami v Kubernetesu, kateri so najboljši in najslabši načini za konfiguracijo aplikacije za Kubernetes;
- Pogovorimo se o tem, kaj sploh so pregledi dostopnosti, kako naj bi izgledali;
- pogovorimo se o tem, kaj je elegantna zaustavitev;
- spet govorimo o virih;
- Še enkrat se dotaknimo teme shranjevanja podatkov;
- in na koncu vam bom povedal, kako se imenuje ta skrivnostna aplikacija v oblaku. Oblačnost, kot pridevnik tega izraza.
Dnevniki
Predlagam, da začnete z dnevniki - s tem, kam je treba te dnevnike potisniti v Kubernetes. Zdaj ste zagnali aplikacijo v Kubernetesu. Po klasiki so prej aplikacije vedno zapisovale dnevnike nekje v datoteko. Slabe aplikacije so zapisale dnevnike v datoteko v domačem imeniku razvijalca, ki je zagnal aplikacijo. Dobre aplikacije so zapisale dnevnike v datoteko nekje v /var/log.
Skladno s tem so imeli dobri skrbniki v svojih infrastrukturah konfiguriranih nekaj stvari, da so lahko ti dnevniki rotirali - isti rsyslog, ki pogleda te dnevnike in ko se jim kaj zgodi, jih je veliko, ustvari varnostne kopije, shrani dnevnike tja , izbriše stare datoteke, več kot en teden, šest mesecev in nekatere več. V teoriji bi morali imeti določbe, da preprosto zato, ker aplikacija piše dnevnike, ne zmanjka prostora na produkcijskih strežnikih (bojnih strežnikih?). In zato se celotna proizvodnja ni ustavila zaradi hlodov.
Ko se preselimo v svet Kubernetes in tam zaženemo isto stvar, je prva stvar, na katero ste lahko pozorni, dejstvo, da ljudje, kot so zapisali dnevnike v datoteko, jih še naprej pišejo.
Izkazalo se je, da če govorimo o Kubernetesu, je pravo mesto za zapisovanje dnevnikov nekam iz docker vsebnika preprosto pisanje iz aplikacije v tako imenovani Stdout/Stderr, to je standardne izhodne tokove operacijskega sistema, standardni izhod napake. To je najpravilnejši, najpreprostejši in najbolj logičen način za vnos dnevnikov v načelu v Docker in še posebej v Kubernetis. Kajti če vaša aplikacija piše dnevnike v Stdout/Stderr, potem se Docker in dodatek Kubernetes odločita, kaj storiti s temi dnevniki. Docker bo privzeto zgradil svoje posebne datoteke v formatu JSON.
Tu se pojavi vprašanje, kaj boste naredili s temi hlodi? Najlažji način je jasen, imamo možnost narediti kubectl logs in poglejte te dnevnike teh "strokov". Toda verjetno to ni zelo dobra možnost - s hlodi je treba narediti nekaj drugega.
Zaenkrat se pogovorimo hkrati, ker smo se dotaknili teme hlodov, o tem, kako bi morali izgledati hlodi. Se pravi, to ne velja neposredno za Kubernetes, a ko začnemo razmišljati, kaj narediti z dnevniki, bi bilo dobro razmisliti tudi o tem.
Potrebujemo nekakšno orodje, na prijateljski način, ki bo vzelo te dnevnike, ki jih naš docker vstavi v svoje datoteke, in jih nekam poslalo. Na splošno običajno znotraj Kubernetesa zaženemo neke vrste agenta v obliki DaemonSet - zbiralnika dnevnikov, ki mu preprosto povemo, kje se nahajajo dnevniki, ki jih zbira Docker. In ta zbiralec jih preprosto vzame, morda celo nekako spotoma razčleni, morda obogati s kakšno dodatno metainformacijo in na koncu pošlje nekam v skladišče. Tam so že možne variacije. Najpogostejši je verjetno Elasticsearch, kjer lahko shranjujete dnevnike in jih od tam priročno pridobite. Nato z uporabo zahteve, na primer z uporabo Kibane, na njihovi podlagi zgradite grafe, na podlagi njih zgradite opozorila itd.
Najpomembnejša ideja, ki jo želim znova ponoviti, je, da je znotraj Dockerja, zlasti znotraj Kubernetesa, shranjevanje vaših dnevnikov v datoteko zelo slaba ideja.
Prvič, ker je težko dobiti dnevnike znotraj vsebnika v datoteki. Najprej morate iti v vsebnik, tam izvesti in nato pogledati dnevnike. Naslednja točka je, da če imate dnevnike v datoteki, imajo vsebniki običajno minimalistično okolje in ni pripomočkov, ki so običajno potrebni za normalno delo z dnevniki. Zakopljite jih, poglejte jih, odprite v urejevalniku besedil. Naslednji trenutek je, ko imamo dnevnike v datoteki znotraj vsebnika, če se ta vsebnik izbriše, razumete, bodo dnevniki umrli skupaj z njim. V skladu s tem vsak ponovni zagon vsebnika pomeni, da ni več dnevnikov. Spet slaba možnost.
In zadnja točka je, da imate znotraj vsebnikov običajno svojo aplikacijo in to je to - običajno je to edini proces, ki se izvaja. O kakršnem koli procesu, ki bi rotiral datoteke z vašimi dnevniki, sploh ni govora. Takoj ko se dnevniki začnejo zapisovati v datoteko, to pomeni, da bomo, oprostite, začeli izgubljati produkcijski strežnik. Ker jih je, prvič, težko najti, nihče jim ne sledi, poleg tega jih nihče ne nadzoruje - zato datoteka neskončno raste, dokler preprosto ne zmanjka prostora na strežniku. Zato znova poudarjam, da je prijava v datoteko v Docker, zlasti v Kubernetes, slaba ideja.
Naslednja točka, tukaj želim znova govoriti o tem - ker se dotikamo teme hlodov, bi bilo dobro govoriti o tem, kako bi morali izgledati hlodi, da bi bilo priročno delati z njimi. Kot sem rekel, tema ni neposredno povezana s Kubernetesom, je pa zelo dobro povezana s temo DevOps. Na temo razvojne kulture in prijateljstva med tema dvema različnima oddelkoma - Dev in Ops, da je vsem udobno.
To pomeni, da bi morali biti danes dnevniki v idealnem primeru zapisani v formatu JSON. Če imate kakšno svojo nerazumljivo aplikacijo, ki piše dnevnike v nerazumljive formate, ker vstavite nekakšen tisk ali kaj podobnega, potem je čas, da poguglate kakšno ogrodje, nekakšen ovoj, ki vam omogoča implementacijo normalnega beleženja; tam omogočite parametre beleženja v JSON, ker je JSON preprosta oblika, je razčlenjevanje preprosto.
Če vaš JSON ne deluje po nekaterih merilih, ne ve kaj, potem vsaj zapisujte dnevnike v obliki, ki jo je mogoče razčleniti. Tukaj je bolje razmisliti o dejstvu, da če na primer poganjate kup vsebnikov ali samo procesov z nginxom in ima vsak svoje nastavitve beleženja, potem se verjetno zdi, da vam bo zelo neprijetno jih razčleniti. Ker za vsako novo instanco nginx morate napisati svoj razčlenjevalec, ker pišejo dnevnike drugače. Spet je bilo verjetno vredno razmisliti o tem, da bi zagotovili, da imajo vsi ti primerki nginx enako konfiguracijo beleženja in zapisujejo vse svoje dnevnike popolnoma enotno. Enako velja za absolutno vse aplikacije.
Na koncu želim priliti tudi olje na ogenj, da se je v idealnem primeru treba izogibati dnevnikom v večvrstičnem formatu. Takole je, če ste že kdaj delali z zbiralci hlodov, potem ste verjetno videli, kaj vam obljubljajo, da znajo delati z večvrstičnimi hlodi, jih znajo zbirati itd. Pravzaprav po mojem mnenju niti en zbiralec danes ne more normalno, v celoti in brez napak zbrati večvrstičnih dnevnikov. Na človeški način, tako da je priročno in brez napak.
Toda sled sklada je vedno večvrstični dnevnik in kako se jim izogniti. Vprašanje tukaj je, da je dnevnik zapis dogodka in stactrace dejansko ni dnevnik. Če zberemo dnevnike in jih postavimo nekam v Elasticsearch in nato iz njih narišemo grafe, zgradimo nekaj poročil o dejavnosti uporabnikov na vašem spletnem mestu, potem ko dobite sled sklada, to pomeni, da se dogaja nekaj nepričakovanega, neobravnavana situacija v vaši aplikaciji. In smiselno je samodejno naložiti sled sklada nekam v sistem, ki jim lahko sledi.
To je programska oprema (isti Sentry), ki je narejena posebej za delo s sledenjem skladov. Lahko takoj ustvari avtomatizirana opravila, jih dodeli nekomu, opozori, ko se pojavijo stacttraces, združi te stacttraces po eni vrsti in tako naprej. Načeloma nima velikega smisla govoriti o stactraces, ko govorimo o hlodih, saj gre vendarle za različne stvari z različnimi nameni.
Konfiguracija
Nato govorimo o konfiguraciji v Kubernetesu: kaj storiti z njim in kako naj bodo konfigurirane aplikacije znotraj Kubernetesa. Na splošno običajno rečem, da pri Dockerju ne gre za vsebnike. Vsi vedo, da gre pri Dockerju za vsebnike, tudi tisti, ki z Dockerjem niso veliko delali. Ponavljam, pri Dockerju ne gre za vsebnike.
Docker se po mojem mnenju nanaša na standarde. In standardi obstajajo za praktično vse: standardi za izdelavo vaše aplikacije, standardi za namestitev vaše aplikacije.
In ta stvar - uporabljali smo jo že prej, postala je še posebej priljubljena s pojavom vsebnikov - tej stvari se reče spremenljivke ENV (okolje), to je spremenljivke okolja, ki so v vašem operacijskem sistemu. To je na splošno idealen način za konfiguracijo vaše aplikacije, kajti če imate aplikacije v JAVA, Python, Go, Perl, bog ne daj, in vse lahko berejo spremenljivke gostitelja baze podatkov, uporabnika baze podatkov, gesla baze podatkov, potem je idealen. V načrtu zbirke podatkov imate na enak način konfigurirane aplikacije v štirih različnih jezikih. Ni več različnih konfiguracij.
Vse je mogoče konfigurirati s spremenljivkami ENV. Ko govorimo o Kubernetesu, obstaja odličen način za deklaracijo spremenljivk ENV neposredno znotraj uvajanja. V skladu s tem, če govorimo o skrivnih podatkih, potem lahko skrivne podatke iz spremenljivk ENV (gesla za baze podatkov itd.) takoj potisnemo v skrivnost, ustvarimo skrivno gručo in v opisu ENV v razdelku navedemo, da ne deklariramo neposredno vrednost te spremenljivke in vrednost te spremenljivke gesla baze podatkov bo prebrana iz skrivnosti. To je standardno vedenje Kubernetes. In to je najbolj idealna možnost za konfiguracijo vaših aplikacij. Samo na ravni kode, to spet velja za razvijalce. Če ste DevOps, lahko vprašate: »Fantje, prosim, naučite svojo aplikacijo brati spremenljivke okolja. In vsi bomo srečni.”
Če vsi v podjetju berejo enako imenovane spremenljivke okolja, potem je to super. Da se ne zgodi, da eni čakajo na postgres bazo, drugi čakajo na ime baze, tretji čakajo na nekaj drugega, tretji čakajo na nekakšen dbn, da bo temu primerno enotnost.
Težava nastane, ko imate toliko spremenljivk okolja, da samo odprete Razmestitev - in tam je petsto vrstic spremenljivk okolja. V tem primeru ste preprosto prerasli spremenljivke okolja - in se vam ni treba več mučiti. V tem primeru bi bilo smiselno začeti uporabljati konfiguracije. To pomeni, da usposobite svojo aplikacijo za uporabo konfiguracij.
Edino vprašanje je, da konfiguracije niso to, kar mislite. Config.pi ni konfiguracija, ki bi bila priročna za uporabo. Ali kakšna konfiguracija v vašem lastnem formatu, alternativno podarena - tudi to ni konfiguracija, na katero mislim.
Govorim o konfiguraciji v sprejemljivih formatih, torej daleč najbolj priljubljen standard je standard .yaml. Jasno je, kako ga brati, človek je berljiv, jasno je, kako ga brati iz aplikacije.
V skladu s tem lahko poleg YAML uporabite tudi na primer JSON, razčlenjevanje je približno tako priročno kot YAML v smislu branja konfiguracije aplikacije od tam. Za ljudi je opazno bolj neprijetno za branje. Lahko poskusite format, a la ini. S človeškega vidika je zelo priročen za branje, vendar je morda neprijetno, če ga samodejno obdelamo, v smislu, da če boste kdaj želeli ustvariti lastne konfiguracije, je format ini morda že neprimeren za ustvarjanje.
Toda v vsakem primeru, ne glede na obliko, ki jo izberete, je bistvo v tem, da je z vidika Kubernetesa zelo priročna. Svojo celotno konfiguracijo lahko postavite v Kubernetes, v ConfigMap. Nato vzemite ta konfiguracijski zemljevid in ga prosite, da se namesti v vaš pod v določen imenik, kjer bo vaša aplikacija prebrala konfiguracijo iz tega konfiguracijskega zemljevida, kot da bi bila samo datoteka. To je pravzaprav tisto, kar je dobro storiti, ko imate v svoji aplikaciji veliko konfiguracijskih možnosti. Ali pa je samo nekakšna kompleksna struktura, obstaja gnezdenje.
Če imate konfiguracijski zemljevid, potem lahko zelo dobro naučite svojo aplikacijo, na primer, da samodejno sledi spremembam v datoteki, kjer je nameščen konfiguracijski zemljevid, in tudi samodejno znova naloži vašo aplikacijo, ko se konfiguracije spremenijo. To bi bila na splošno idealna možnost.
Še enkrat, o tem sem že govoril - tajne informacije niso v konfiguracijskem zemljevidu, tajne informacije niso v spremenljivkah, tajne informacije niso v skrivnostih. Od tam povežite te tajne podatke z diplomacijo. Običajno hranimo vse opise predmetov Kubernetes, razmestitev, konfiguracijskih zemljevidov, storitev v git. Skladno s tem je vnos gesla v bazo v git, tudi če je vaš git, ki ga imate interno v podjetju, slaba ideja. Ker si git najmanj zapomni vse in preprosto odstranjevanje gesel od tam ni tako enostavno.
Zdravstveni pregled
Naslednja točka je ta stvar, ki se imenuje zdravstveni pregled. Na splošno je pregled stanja preprosto preverjanje, ali vaša aplikacija deluje. Pri tem najpogosteje govorimo o določenih spletnih aplikacijah, za katere bo to ustrezno z vidika zdravstvenega pregleda (bolje, da ne prevajamo tukaj in naprej) nek poseben URL, ki ga obdelajo kot standard, običajno to počnejo /health.
Pri dostopu do tega URL-ja torej naša aplikacija reče ali "ja, v redu, z mano je vse v redu, 200" ali "ne, z mano ni vse v redu, nekaj 500." V skladu s tem, če naša aplikacija ni http, ni spletna aplikacija, zdaj govorimo o nekakšnem demonu, lahko ugotovimo, kako narediti preglede zdravja. Se pravi, ni potrebno, če aplikacija ni http, potem vse deluje brez zdravstvenega pregleda in tega nikakor ni mogoče storiti. Občasno lahko posodobite nekaj informacij v datoteki, lahko pripravite kakšen poseben ukaz za svojega demona, na primer, daemon status, ki bo rekel "da, vse je v redu, demon deluje, živ je."
Čemu služi? Prva in najbolj očitna stvar je verjetno, zakaj je potreben zdravstveni pregled – da razumemo, ali aplikacija deluje. Mislim, samo neumno je, ko je zdaj gor, je videti, kot da deluje, tako da si lahko prepričan, da deluje. In izkaže se, da aplikacija deluje, vsebnik teče, instanca deluje, vse je v redu - in potem so uporabniki že prekinili vse telefonske številke tehnične podpore in rekli "kaj si ..., ti zaspal, nič ne deluje.”
Pregled zdravstvenega stanja je samo način, da z vidika uporabnika vidite, da deluje. Ena od metod. Recimo takole. Z vidika Kubernetesa je to tudi način, kako razumeti, kdaj se aplikacija zažene, saj razumemo, da obstaja razlika med tem, kdaj je bil vsebnik zagnan, ustvarjen in zagnan, in kdaj je bila aplikacija zagnana neposredno v tem vsebniku. Kajti če vzamemo neko povprečno javansko aplikacijo in jo poskušamo zagnati v doku, se lahko za štirideset sekund ali celo minuto ali celo deset zažene čisto v redu. V tem primeru lahko vsaj potrkate na njegova vrata, tam se ne bo oglasil, to pomeni, da še ni pripravljen na sprejem prometa.
Spet s pomočjo zdravstvenega pregleda in s pomočjo dejstva, da se obračamo tukaj, lahko v Kubernetesu razumemo, da se v aplikaciji ni dvignil samo vsebnik, ampak se je aplikacija sama zagnala, že se odziva na zdravstveni pregled, kar pomeni, da lahko tja pošljemo promet.
To, o čemer zdaj govorim, se imenuje testi pripravljenosti/živosti znotraj Kubernetesa; v skladu s tem so naši testi pripravljenosti odgovorni za razpoložljivost aplikacije pri uravnoteženju. Se pravi, če se v aplikaciji izvajajo testi pripravljenosti, potem je vse v redu, promet strank gre v aplikacijo. Če se testi pripravljenosti ne izvedejo, potem aplikacija preprosto ne sodeluje, ta konkretni primerek ne sodeluje pri uravnoteženju, je odstranjen iz uravnoteženja, promet odjemalca ne teče. V skladu s tem so potrebni testi Liveness znotraj Kubernetesa, tako da se lahko aplikacija znova zažene, če se zatakne. Če preizkus živahnosti ne deluje za aplikacijo, ki je deklarirana v Kubernetesu, potem aplikacija ni samo odstranjena iz uravnoteženja, temveč se znova zažene.
In tu je pomembna točka, ki bi jo rad omenil: s praktičnega vidika se test pripravljenosti običajno uporablja pogosteje in je pogosteje potreben kot test živahnosti. To pomeni, da preprosto nepremišljeno razglašanje tako testov pripravljenosti kot testa uporabnosti, ker Kubernetes to zmore in uporabimo vse, kar zmore, ni zelo dobra ideja. Pojasnil bom zakaj. Kajti točka številka dva pri testiranju je, da bi bilo dobro preveriti osnovno storitev v svojih zdravstvenih pregledih. To pomeni, da če imate spletno aplikacijo, ki izda neke informacije, ki jih mora seveda od nekje vzeti. V bazi podatkov, na primer. No, shrani informacije, ki pridejo v ta REST API, v isto bazo podatkov. V skladu s tem, če se vaš zdravstveni pregled odzove preprosto kot stik s slashhealthom, aplikacija reče »200, v redu, vse je v redu«, hkrati pa je zbirka podatkov vaše aplikacije nedostopna, aplikacija za zdravstveni pregled pa reče »200, v redu, vse je v redu ” - To je slab zdravstveni pregled. Tako ne bi smelo delovati.
To je vaša prijava, ko nanjo pride zahteva /health, se ne odzove le »200, v redu«, gre najprej na primer v zbirko podatkov, se poskuša povezati z njo, tam naredi nekaj zelo osnovnega, na primer izberite enega, samo preveri, ali obstaja povezava v bazo podatkov in lahko poizvedujete po bazi podatkov. Če je bilo vse to uspešno, potem je odgovor "200, ok." Če ni uspešen, piše, da je prišlo do napake, baza podatkov ni na voljo.
Zato se v zvezi s tem ponovno vračam k testom pripravljenosti/živosti - zakaj najverjetneje potrebujete test pripravljenosti, pod vprašajem pa je test živahnosti. Kajti če opišete zdravstvene preglede natanko tako, kot sem pravkar rekel, potem se bo izkazalo, da ni na voljo v instančnem deluв или со всех instancev bazi podatkov, na primer. Ko ste razglasili test pripravljenosti, so naši zdravstveni pregledi začeli odpovedovati in temu primerno so vse aplikacije, iz katerih baza podatkov ni dostopna, preprosto izklopljene iz uravnoteženja in dejansko "visijo" samo v zanemarjenem stanju in čakajo, da se njihove baze delo.
Če smo razglasili test živahnosti, potem si predstavljajte, naša baza podatkov se je pokvarila in v vašem Kubernetesu se polovica vsega začne znova zagnati, ker test živahnosti ne uspe. To pomeni, da morate znova zagnati. To sploh ni tisto, kar bi si želeli, imel sem celo osebno izkušnjo v praksi. Imeli smo aplikacijo za klepet, ki je bila napisana v JS in vnesena v bazo podatkov Mongo. In problem je bil v tem, da smo na začetku mojega dela s Kubernetesom opisovali pripravljenost, živost testov po načelu, da Kubernetes to zmore, zato ga bomo uporabili. Skladno s tem je Mongo na neki točki postal nekoliko "dolgočasen" in vzorec je začel odpovedovati. Skladno s tem so po testu dežja stroki začeli »ubijati«.
Kot razumete, ko so "ubiti", je to klepet, to pomeni, da na njem visi veliko povezav strank. Prav tako so "ubiti" - ne, ne stranke, samo povezave - ne vsi hkrati in zaradi dejstva, da niso ubiti hkrati, nekateri prej, drugi kasneje, se ne začnejo hkrati čas. Poleg tega standardno naključno ne moremo predvideti z natančnostjo milisekunde vsakokratnega začetka aplikacije, zato to počnejo en primerek naenkrat. En infospot se dvigne, doda se v izravnavo, tja pridejo vse stranke, ne zdrži takšne obremenitve, ker je sam, grobo rečeno, tam jih dela ducat, in pade. Naslednji se dvigne, ves tovor je na njem, tudi pade. No, ti padci se kar vrstijo. Na koncu, kako se je to rešilo - morali smo samo striktno ustaviti uporabniški promet tej aplikaciji, pustiti, da se dvignejo vse instance in nato zagnati ves uporabniški promet naenkrat, da je bil že porazdeljen med vseh deset instanc.
Če ne bi bilo napovedanega tega liveness testa, ki bi vse skupaj prisilil v ponovni zagon, bi aplikacija to kar dobro opravila. Nam pa je vse od bilanciranja onemogočeno, ker so baze nedostopne in so vsi uporabniki “odpadli”. Potem, ko je ta baza na voljo, je vse vključeno v izravnavo, vendar aplikacij ni treba znova zagnati in za to ni treba izgubljati časa in sredstev. Vsi so že tukaj, pripravljeni za promet, tako da se promet samo odpre, vse je v redu - aplikacija je na mestu, vse deluje naprej.
Zato so testi pripravljenosti in življenjske dobe različni, še več, teoretično lahko delaš različne zdravstvene preglede, en tip radii, en tip liv na primer in preverjaš različne stvari. Med preizkusi pripravljenosti preverite svoja zaledja. In na primer pri testu živahnosti ne preverite z vidika, da je test živahnosti na splošno le aplikacija, ki se odziva, ali se sploh lahko odzove.
Ker je test živahnosti na splošno takrat, ko smo »zataknjeni«. Začela se je neskončna zanka ali kaj drugega - in nobena zahteva ni več obdelana. Zato jih je smiselno celo ločiti – in vanje implementirati drugačno logiko.
Glede tega, kaj morate odgovoriti, ko imate test, ko opravljate zdravstvene preglede. To je samo resna bolečina. Tisti, ki se s tem spoznajo, se bodo verjetno smejali - ampak resno, v življenju sem videl storitve, ki v 200% primerov odgovorijo "XNUMX". Se pravi, kdo je uspešen. Toda hkrati v telesu odgovora napišejo "taka in taka napaka."
Se pravi, status odziva pride do vas - vse je uspešno. Toda hkrati morate razčleniti telo, ker telo pravi "žal, zahteva se je končala z napako" in to je samo resničnost. To sem videl v resničnem življenju.
In da se nekaterim ne zdi smešno, drugim pa zelo boleče, je še vedno vredno upoštevati preprosto pravilo. Pri pregledih zdravja in načeloma pri delu s spletnimi aplikacijami.
Če je šlo vse v redu, odgovorite z dvestotim odgovorom. Načeloma vam bo ustrezal vsak dvestoti odgovor. Če zelo dobro berete ragsy in veste, da so nekateri statusi odgovorov drugačni od drugih, odgovorite z ustreznimi: 204, 5, 10, 15, karkoli. Če ni zelo dobro, potem samo "dve nič nič." Če gre vse slabo in se zdravstveni pregled ne odzove, odgovorite s katero koli petstotinko. Še enkrat, če razumete, kako se odzvati, kako se različni statusi odgovorov med seboj razlikujejo. Če ne razumete, je 502 vaša možnost, da se odzovete na zdravstvene preglede, če gre kaj narobe.
To je še ena točka, rad bi se vrnil malo o preverjanju osnovnih storitev. Če začnete na primer preverjati vse osnovne storitve, ki stojijo za vašo aplikacijo – vse na splošno. Kar dobimo z vidika arhitekture mikrostoritev, imamo tak koncept, kot je "nizka povezava" - to je, ko so vaše storitve minimalno odvisne druga od druge. Če eden od njih odpove, bodo vsi ostali brez te funkcije preprosto še naprej delovali. Nekatere funkcije preprosto ne delujejo. V skladu s tem, če povežete vse zdravstvene preglede med seboj, boste na koncu imeli eno stvar, ki bo padla v infrastrukturi, in ker je padla, začnejo odpovedovati tudi vsi zdravstveni pregledi vseh storitev - in na splošno obstaja več infrastrukture za celotna mikrostoritvena arhitektura št. Tam se je vse stemnilo.
Zato želim še enkrat ponoviti, da morate preveriti osnovne storitve, tiste, brez katerih vaša aplikacija v sto odstotkih primerov ne more opravljati svojega dela. To pomeni, da je logično, da če imate REST API, prek katerega uporabnik shranjuje v bazo podatkov ali pridobiva iz baze podatkov, potem v odsotnosti baze podatkov ne morete zagotoviti dela s svojimi uporabniki.
Če pa so vaši uporabniki, ko jih vzamete iz baze, dodatno obogateni z nekimi drugimi metapodatki, iz drugega zaledja, ki jih vnesete, preden pošljete odgovor v frontend - in to zaledje ni na voljo, to pomeni, da dajete svoj odgovor brez kakršnega koli dela metapodatkov.
Naprej imamo tudi eno izmed bolečih težav pri zagonu aplikacij.
Pravzaprav to na splošno ne velja samo za Kubernetes; zgodilo se je, da se je kultura nekakšnega množičnega razvoja in zlasti DevOps začela širiti približno istočasno kot Kubernetes. Zato se na splošno izkaže, da morate elegantno zapreti svojo aplikacijo brez Kubernetesa. Že pred Kubernetesom so ljudje to počeli, s prihodom Kubernetesa pa smo o tem začeli množično govoriti.
Elegantna zaustavitev
Na splošno, kaj je Graceful Shutdown in zakaj je potreben? To je približno, ko se vaša aplikacija iz nekega razloga zruši, kar morate storiti app stop - ali prejmete na primer signal od operacijskega sistema, vaša aplikacija ga mora razumeti in glede tega nekaj narediti. Najslabši možni scenarij je seveda, ko vaša prijava prejme SIGTERM in je kot "SIGTERM, počakajmo, delajmo, ne naredimo ničesar." To je naravnost slaba možnost.
Skoraj enako slaba možnost je, ko vaša aplikacija prejme SIGTERM in je kot "so rekli segterm, to pomeni, da končujemo, nisem videl, ne vem nobene zahteve uporabnikov, ne vem, kakšne zahteve, na katerih trenutno delam, so rekli SIGTERM, to pomeni, da končujemo " Tudi to je slaba možnost.
Katera možnost je dobra? Prva točka je upoštevati dokončanje operacij. Dobra možnost je, da vaš strežnik še vedno upošteva, kaj počne, če prejme SIGTERM.
SIGTERM je mehka zaustavitev, je posebej zasnovana, lahko jo prestrežemo na nivoju kode, lahko jo obdelamo, recite zdaj, počakajte, najprej bomo dokončali delo, ki ga imamo, potem bomo izstopili.
Z vidika Kubernetesa je videti tako. Ko rečemo podu, ki se izvaja v gruči Kubernetes, »prosim, ustavi se, pojdi stran«, ali se znova zaženemo, ali pride do posodobitve, ko Kubernetes znova ustvari pode, Kubernetes pošlje isto sporočilo SIGTERM podu, počaka na nekaj časa in , to je čas, ko čaka, je tudi konfiguriran, obstaja tak poseben parameter v diplomah in se imenuje Graceful ShutdownTimeout. Kot razumete, se ne imenuje zaman in ni zaman, da o tem zdaj govorimo.
Tam lahko natančno povemo, kako dolgo moramo počakati od trenutka, ko aplikaciji pošljemo SIGTERM, do takrat, ko ugotovimo, da se zdi, da je aplikacija nekaj ponorela ali da je »zataknjena« in se ne bo končala - in moramo pošlji SIGKILL, kar pomeni, da težko dokonča svoje delo. To pomeni, da imamo nekakšen demon, ki teče, obdeluje operacije. Zavedamo se, da naše operacije, na katerih deluje demon, v povprečju ne trajajo več kot 30 sekund naenkrat. Skladno s tem, ko prispe SIGTERM, razumemo, da lahko naš demon konča največ 30 sekund po SIGTERM. Napišemo ga na primer 45 sekund za vsak slučaj in rečemo tisti SIGTERM. Po tem počakamo 45 sekund. Teoretično bi moral v tem času demon dokončati svoje delo in se končal. Če pa nenadoma ne more, to pomeni, da se je najverjetneje zataknilo – naših zahtev ne obdeluje več normalno. In v 45 sekundah ga lahko varno ujamete.
In tukaj je pravzaprav mogoče upoštevati celo 2 vidika. Prvič, razumejte, da če ste prejeli zahtevo, ste nekako začeli delati z njo in niste dali odgovora uporabniku, ampak ste prejeli npr. SIGTERM. Smiselno ga je dodelati in dati odgovor uporabniku. To je točka številka ena v zvezi s tem. Druga točka tukaj je, da če pišete svojo aplikacijo, na splošno zgradite arhitekturo tako, da prejmete zahtevo za vašo aplikacijo, potem začnete nekaj delati, začnete prenašati datoteke od nekod, prenašati bazo podatkov in še kaj. - to. Na splošno vaš uporabnik, vaša zahteva visi pol ure in čaka, da mu odgovorite - potem morate najverjetneje delati na arhitekturi. To pomeni, da upoštevajte celo zdrav razum, da če so vaše operacije kratke, potem je smiselno ignorirati SIGTERM in ga spremeniti. Če so vaše operacije dolge, potem nima smisla ignorirati SIGTERM v tem primeru. Smiselno je preoblikovati arhitekturo, da se izognemo tako dolgim operacijam. Tako, da uporabniki ne samo visijo in čakajo. Ne vem, naredite tam nekakšen websocket, naredite reverse hooke, ki jih bo vaš strežnik že poslal odjemalcu, karkoli drugega, vendar ne silite uporabnika, da visi pol ure in samo počakajte na sejo, dokler ne odgovori mu. Ker je nepredvidljivo, kje se lahko zalomi.
Ko se vaša aplikacija zaključi, morate navesti ustrezno izhodno kodo. To pomeni, da če je bila vaša aplikacija pozvana, naj se zapre, ustavi in se je lahko normalno ustavila, vam ni treba vrniti neke vrste izhodne kode 1,5,255 in tako naprej. Vse, kar ni ničelna koda, vsaj v sistemih Linux, o tem sem prepričan, velja za neuspešno. Se pravi, šteje se, da se je vaša prijava v tem primeru končala z napako. V skladu s tem na prijateljski način, če se je vaša prijava zaključila brez napake, na izpisu rečete 0. Če vaša aplikacija iz nekega razloga ne uspe, v izhodu rečete, da ni 0. In s temi informacijami lahko delate.
In zadnja možnost. Hudo je, če vaš uporabnik pošlje zahtevo in visi pol ure, medtem ko jo obdelate. Toda na splošno bi rad povedal tudi o tem, kaj se na splošno splača s strani stranke. Ni pomembno, ali imate mobilno aplikacijo, front-end itd. Upoštevati je treba, da se na splošno seja uporabnika lahko prekine, lahko se zgodi karkoli. Zahteva je lahko poslana na primer premalo obdelana in brez vrnjenega odgovora. Vaš frontend ali vaša mobilna aplikacija – vsak frontend na splošno, recimo tako – bi moral to upoštevati. Če delate s spletnimi vtičnicami, je to na splošno najhujša bolečina, kar sem jih kdaj imel.
Ko razvijalci nekaterih običajnih klepetov tega ne vedo, se izkaže, da se lahko spletna vtičnica zlomi. Za njih, ko se nekaj zgodi na proxyju, samo spremenimo konfiguracijo in ta se znova naloži. Seveda so v tem primeru vse dolgožive seje raztrgane. Razvijalci pritečejo k nam in rečejo: "Fantje, kaj počnete, klepet se je pokvaril vsem našim strankam!" Rečemo jim: »Kaj delaš? Ali se vaše stranke ne morejo znova povezati? Pravijo: "Ne, potrebujemo, da se seje ne raztrgajo." Skratka, to je pravzaprav neumnost. Upoštevati je treba strankino stran. Zlasti, kot pravim, pri dolgotrajnih sejah, kot so spletne vtičnice, se lahko zlomi in, ne da bi jih uporabnik opazil, morate imeti možnost, da takšne seje znova namestite. In potem je vse popolno.
Viri
Pravzaprav vam bom povedal preprosto zgodbo. Spet iz resničnega življenja. Najbolj bolna stvar, kar sem jih kdaj slišal o virih.
Viri v tem primeru, mislim, neke vrste zahteve, omejitve, ki jih lahko postavite na pode v svojih gručah Kubernetes. Najbolj smešna stvar, ki sem jo slišal od razvijalca ... Eden od mojih kolegov razvijalcev na prejšnjem delovnem mestu je nekoč rekel: "Moja aplikacija se ne zažene v gruči." Pogledal sem, da se ne zaganja, toda ali ni ustrezal virom ali pa so postavili zelo majhne omejitve. Skratka, aplikacija se ne more zagnati zaradi virov. Jaz pravim: "Ne bo začelo zaradi virov, vi se odločite, koliko potrebujete in nastavite ustrezno vrednost." Pravi: "Kakšna sredstva?" Začel sem mu razlagati, da je treba postaviti Kubernetes, limite na zahteve in bla, bla, bla. Moški je poslušal pet minut, prikimal in rekel: »Prišel sem delat kot razvijalec, ne želim vedeti ničesar o kakršnih koli virih. Sem sem prišel, da bi napisal kodo in to je to." Žalostno je. To je zelo žalosten koncept z vidika razvijalca. Še posebej v sodobnem svetu tako rekoč progresivnih devopov.
Zakaj so sredstva sploh potrebna? V Kubernetesu sta 2 vrsti virov. Nekatere se imenujejo zahteve, druge pa omejitve. Pod viri bomo razumeli, da v bistvu vedno obstajata le dve osnovni omejitvi. To je časovne omejitve procesorja in omejitve RAM-a za vsebnik, ki se izvaja v Kubernetesu.
Omejitev postavlja zgornjo mejo glede uporabe vira v vaši aplikaciji. To pomeni, da če v omejitvah rečete 1 GB RAM-a, potem vaša aplikacija ne bo mogla uporabiti več kot 1 GB RAM-a. In če nenadoma želi in poskuša to storiti, potem pride proces, imenovan oom killer, brez pomnilnika, to je, in ubije vašo aplikacijo - to pomeni, da se bo preprosto znova zagnal. Aplikacije se ne bodo znova zagnale glede na CPE. Kar zadeva CPE, če aplikacija poskuša uporabiti veliko več, kot je navedeno v omejitvah, bo CPE preprosto strogo izbran. To ne vodi do ponovnih zagonov. To je meja - to je zgornja meja.
In obstaja prošnja. Zahteva je, kako Kubernetes razume, kako so vozlišča v vaši gruči Kubernetes poseljena z aplikacijami. To pomeni, da je zahteva nekakšna zaveza vaše aplikacije. Piše, kaj želim uporabiti: "Rad bi, da rezervirate toliko procesorja in toliko pomnilnika zame." Tako preprosta analogija. Kaj pa, če imamo vozlišče, ki ima, ne vem, skupno 8 procesorjev. In tja prispe pod, katerega zahteve pravijo 1 CPE, kar pomeni, da ima vozlišče preostalih 7 CPE. To pomeni, da takoj, ko v to vozlišče prispe 8 podov, od katerih ima vsak v svojih zahtevah 1 CPU, je vozlišču, kot da bi z vidika Kubernetesa zmanjkalo CPE-ja in več podov z zahtevami ni mogoče zagnan na tem vozlišču. Če vsem vozliščem zmanjka CPE, bo Kubernetes začel sporočati, da v gruči ni ustreznih vozlišč za zagon vaših podov, ker je CPE zmanjkalo.
Zakaj so zahteve potrebne in zakaj brez zahtev mislim, da v Kubernetesu ni treba ničesar zagnati? Predstavljajmo si hipotetično situacijo. Svojo aplikacijo zaženete brez zahtev, Kubernetes ne ve, koliko česa imate, na katera vozlišča lahko to potisnete. No, rine, rine, rine na vozlišča. Na neki točki boste začeli prejemati promet v svojo aplikacijo. In ena od aplikacij nenadoma začne uporabljati sredstva do omejitev, ki jih ima glede na omejitve. Izkazalo se je, da je v bližini še ena aplikacija, ki prav tako potrebuje vire. Vozlišču dejansko začne fizično zmanjkovati virov, na primer OP. Vozlišču dejansko začne fizično zmanjkovati virov, na primer pomnilnika z naključnim dostopom (RAM). Ko vozlišču zmanjka energije, se najprej neha odzivati priklopna postaja, nato kocka in nato OS. Preprosto bodo padli v nezavest in zagotovo vam bo VSE nehalo delovati. To pomeni, da se bo vaše vozlišče zataknilo in ga boste morali znova zagnati. Skratka, stanje ni ravno dobro.
In ko imaš zahteve, omejitve niso zelo različne, vsaj ne velikokrat več kot so omejitve oziroma zahteve, potem imaš lahko tako normalno, racionalno polnjenje aplikacij po vozliščih gruč Kubernetes. Hkrati se Kubernetes približno zaveda, koliko česa kam da, koliko česa se kje uporablja. Se pravi, to je samo tak trenutek. Pomembno je razumeti. In pomembno je nadzorovati, da je to indicirano.
Shranjevanje podatkov
Naša naslednja točka je shranjevanje podatkov. Kaj storiti z njimi in na splošno, kaj storiti z obstojnostjo v Kubernetesu?
Mislim, spet znotraj našega , bila je tema o bazi podatkov v Kubernetesu. In zdi se mi, da celo približno vem, kaj so vam rekli vaši kolegi na vprašanje: "Ali je možno poganjati bazo podatkov v Kubernetesu?" Iz nekega razloga se mi zdi, da bi vam morali vaši kolegi povedati, da če postavljate vprašanje, ali je v Kubernetesu mogoče zagnati bazo podatkov, potem je to nemogoče.
Logika je preprosta. Za vsak slučaj bom še enkrat razložil, če ste res kul fant, ki zna zgraditi dokaj odporen sistem porazdeljene omrežne shrambe, razumeti, kako v ta primer vgraditi zbirko podatkov, kako bi moralo delovati izvorno v oblaku v vsebnikih v bazi podatkov na splošno. Najverjetneje nimate nobenega vprašanja o tem, kako ga zagnati. Če imate takšno vprašanje in se želite prepričati, da se vse odvije in stoji do smrti v proizvodnji in nikoli ne pade, potem se to ne zgodi. S tem pristopom se boste zagotovo ustrelili v nogo. Zato je bolje, da ne.
Kaj naj naredimo s podatki, ki bi jih naša aplikacija rada shranila, nekaterimi slikami, ki jih naložijo uporabniki, nekaterimi stvarmi, ki jih naša aplikacija ustvari med svojim delovanjem, ob zagonu, na primer? Kaj storiti z njimi v Kubernetesu?
Na splošno je idealno, da, seveda, Kubernetes je zelo dobro zasnovan in je bil na splošno prvotno zasnovan za aplikacije brez stanja. Se pravi za tiste aplikacije, ki sploh ne shranjujejo informacij. To je idealno.
Seveda pa idealna možnost ne obstaja vedno. Pa kaj? Prva in najpreprostejša točka je, da vzamete nekakšen S3, samo ne domačega, kar tudi ni jasno, kako deluje, ampak od nekega ponudnika. Dober, normalen ponudnik - in nauči svojo aplikacijo uporabljati S3. To pomeni, da ko želi vaš uporabnik naložiti datoteko, recite "tukaj, prosim, naložite jo v S3." Ko jo želi prejeti, recite: "Tu je povezava do S3 nazaj in jo vzemite od tu." To je idealno.
Če nenadoma iz nekega razloga ta idealna možnost ni primerna, imate aplikacijo, ki je niste napisali, ne razvijate ali je nekakšna strašna zapuščina, ne more uporabljati protokola S3, ampak mora delovati z lokalnimi imeniki v lokalne mape. Vzemite nekaj bolj ali manj preprostega, namestite Kubernetes. To pomeni, da je Ceph takoj ograjevati za neke minimalne naloge, se mi zdi slaba ideja. Ker Ceph je seveda dober in moden. Če pa res ne razumete, kaj počnete, potem, ko nekaj nadenete na Cepha, lahko zelo enostavno in preprosto nikoli več ne spravite tega od tam. Ker, kot veste, Ceph shranjuje podatke v svojo gručo v binarni obliki in ne v obliki preprostih datotek. Če se torej grozd Ceph nenadoma pokvari, obstaja popolna in velika verjetnost, da od tam nikoli več ne boste dobili svojih podatkov.
Imeli bomo tečaj o Cephu, lahko .
Zato je bolje narediti nekaj preprostega, kot je strežnik NFS. Kubernetes lahko deluje z njimi, imenik lahko namestite pod strežnik NFS - vaša aplikacija je kot lokalni imenik. Hkrati pa morate seveda razumeti, da morate spet nekaj narediti s svojim NFS, razumeti morate, da včasih lahko postane nedostopen, in razmislite o vprašanju, kaj boste storili v tem primeru. Morda bi ga bilo treba varnostno kopirati nekje na ločenem računalniku.
Naslednja točka, o kateri sem govoril, je, kaj storiti, če vaša aplikacija med delovanjem ustvari nekaj datotek. Na primer, ko se zažene, ustvari neko statično datoteko, ki temelji na nekaterih informacijah, ki jih aplikacija prejme šele ob zagonu. Kakšen trenutek. Če teh podatkov ni veliko, potem se vam sploh ni treba truditi, samo namestite to aplikacijo zase in delajte. Edino vprašanje tukaj je, kaj, poglej. Zelo pogosto vse vrste podedovanih sistemov, kot je WordPress in tako naprej, še posebej z modificiranimi nekakšnimi pametnimi vtičniki, pametni razvijalci PHP, pogosto znajo narediti tako, da sami ustvarijo neko datoteko. V skladu s tem eden ustvari eno datoteko, drugi pa drugo datoteko. So drugačni. Uravnoteženje se zgodi v gruči Kubernetes strank preprosto po naključju. Temu primerno se izkaže, da na primer ne znajo sodelovati. Ena daje eno informacijo, druga daje uporabniku drugo informacijo. Temu se morate izogibati. To pomeni, da je v Kubernetesu zagotovljeno, da lahko vse, kar zaženete, deluje v več primerih. Ker je Kubernetes premikajoča se stvar. Skladno s tem lahko premakne karkoli, kadar koli hoče, ne da bi koga vprašal. Zato morate na to računati. Vse, kar se zažene v enem primeru, prej ali slej propade. Več ko imate rezervacij, bolje je. Ampak spet pravim, če imate nekaj takšnih datotek, jih lahko postavite tik pod seboj, tehtajo majhno količino. Če jih je malo več, jih verjetno ne smete tlačiti v posodo.
Svetoval bi, da je v Kubernetesu tako čudovita stvar, lahko uporabite glasnost. Zlasti obstaja prostornina tipa prazni dir. To pomeni, da bo Kubernetes samodejno ustvaril imenik v svojih imenikih storitev na strežniku, kjer ste začeli. In dal vam ga bo, da ga boste lahko uporabili. Obstaja le ena pomembna točka. To pomeni, da vaši podatki ne bodo shranjeni znotraj vsebnika, temveč na gostitelju, na katerem se izvajate. Poleg tega lahko Kubernetes nadzoruje takšne prazne imenike v običajni konfiguraciji in lahko nadzoruje njihovo največjo velikost ter ne dovoli, da bi bila presežena. Edina točka je, da se tisto, kar ste zapisali v prazen imenik, ne izgubi med ponovnim zagonom sklopa. To pomeni, da če vaš pod pomotoma pade in se znova dvigne, informacije v praznem imeniku ne bodo šle nikamor. Lahko ga znova uporabi ob novem začetku – in to je dobro. Če vaš pod nekam odide, bo seveda odšel brez podatkov. To pomeni, da takoj ko pod iz vozlišča, kjer je bil zagnan s praznim imenikom, izgine, se prazen imenik izbriše.
Kaj je še dobrega pri praznem imeniku? Na primer, lahko se uporablja kot predpomnilnik. Predstavljajmo si, da naša aplikacija nekaj sproti generira, da uporabnikom in to počne dolgo časa. Zato ga aplikacija na primer generira in daje uporabnikom, hkrati pa ga nekje shrani, da bo uporabnik naslednjič, ko pride po isto stvar, hitreje dal takoj generiranega. Kubernetes lahko zahteva, da ustvari prazen imenik v pomnilniku. In tako lahko vaši predpomnilniki na splošno delujejo z bliskovito hitrostjo - v smislu hitrosti dostopa do diska. To pomeni, da imate prazen imenik v pomnilniku, v operacijskem sistemu je shranjen v pomnilniku, vendar je za vas, za uporabnika znotraj sklopa, videti le kot lokalni imenik. Ne potrebujete aplikacije za posebej poučevanje čarovnije. Samo neposredno vzamete in postavite svojo datoteko v imenik, vendar v resnici v pomnilnik OS. To je tudi zelo priročna funkcija v smislu Kubernetesa.
Kakšne težave ima Minio? Glavna težava Minia je, da mora ta zadeva, da deluje, nekje teči in mora obstajati nekakšen datotečni sistem, torej shramba. In tu naletimo na enake težave kot Ceph. To pomeni, da mora Minio nekje shraniti svoje datoteke. To je preprosto vmesnik HTTP za vaše datoteke. Poleg tega je funkcionalnost očitno slabša kot pri Amazonovem S3. Prej ni mogel pravilno avtorizirati uporabnika. Zdaj, kolikor vem, lahko že ustvarja vedra z različnimi avtorizacijami, ampak spet se mi zdi, da je glavni problem tako rekoč vsaj osnovni sistem za shranjevanje.
Kako prazen imenik v pomnilniku vpliva na omejitve? Na noben način ne vpliva na omejitve. Leži v spominu gostitelja in ne v spominu vašega vsebnika. To pomeni, da vaš vsebnik ne vidi praznega imenika v pomnilniku kot del svojega zasedenega pomnilnika. Gostitelj to vidi. Skladno s tem ja, z vidika kubernetesa, ko začneš uporabljati to, bi bilo dobro razumeti, da del svojega pomnilnika posvetiš praznemu direktoriju. In v skladu s tem razumejte, da lahko pomnilnik zmanjka samo zaradi aplikacij, ampak tudi zato, ker nekdo piše v te prazne direktorije.
Oblačnost
In zadnja podtema je, kaj je Cloudnative. Zakaj je to potrebno? Oblačnost in tako naprej.
Se pravi tiste aplikacije, ki so sposobne in napisane za delovanje v sodobni oblačni infrastrukturi. Toda v resnici ima Cloudnative še en tak vidik. Da to ni le aplikacija, ki upošteva vse zahteve sodobne oblačne infrastrukture, ampak zna s to sodobno oblačno infrastrukturo tudi delati, izkoristite prednosti in slabosti dejstva, da deluje v teh oblakih. Ne pretiravajte in delajte v oblaku, ampak izkoristite prednosti dela v oblaku.
Vzemimo samo Kubernetes kot primer. Vaša aplikacija se izvaja v Kubernetesu. Vaša aplikacija lahko vedno ali bolje rečeno skrbniki za vašo aplikacijo lahko vedno ustvarijo storitveni račun. To je račun za avtorizacijo v samem Kubernetesu v njegovem strežniku. Tam dodajte nekaj pravic, ki jih potrebujemo. In do Kubernetesa lahko dostopate iz svoje aplikacije. Kaj lahko storite na ta način? Na primer, iz aplikacije prejmite podatke o tem, kje se nahajajo vaše druge aplikacije, drugi podobni primerki, in se skupaj nekako združite na vrhu Kubernetesa, če obstaja taka potreba.
Pred kratkim smo spet dobesedno imeli primer. Imamo enega kontrolorja, ki spremlja čakalno vrsto. In ko se v tej čakalni vrsti pojavi nekaj novih nalog, gre v Kubernetes - in znotraj Kubernetesa ustvari nov pod. Temu podu da neko novo nalogo in v okviru tega pod-a pod izvede nalogo, sam pošlje odgovor krmilniku, ta pa nato nekaj naredi s temi informacijami. Na primer, doda bazo podatkov. To je, spet, to je plus dejstva, da naša aplikacija deluje v Kubernetesu. Uporabimo lahko samo vgrajeno funkcionalnost Kubernetes, da nekako razširimo in naredimo funkcionalnost naše aplikacije bolj priročno. To pomeni, da ne skrivajte neke vrste čarovnije o tem, kako zagnati aplikacijo, kako zagnati delavca. V Kubernetesu preprosto pošljete zahtevo v aplikaciji, če je aplikacija napisana v Pythonu.
Enako velja, če gremo dlje od Kubernetesa. Naš Kubernetes nekje teče - dobro je, če je v nekem oblaku. Spet lahko uporabimo in celo bi morali, verjamem, uporabiti zmogljivosti samega oblaka, kjer delujemo. Od elementarnih stvari, ki nam jih ponuja oblak. Uravnoteženje, torej lahko ustvarimo uravnoteževalce oblakov in jih uporabljamo. To je neposredna prednost tega, kar lahko uporabimo. Ker uravnoteženje oblaka, prvič, preprosto neumno od nas odvzame odgovornost za to, kako deluje, kako je konfigurirano. Poleg tega je zelo priročno, saj se običajni Kubernetes lahko integrira z oblaki.
Enako velja za skaliranje. Običajni Kubernetes se lahko integrira s ponudniki v oblaku. Ve, kako razumeti, da če gruči zmanjka vozlišč, to pomeni, da je zmanjkalo prostora za vozlišča, potem morate dodati - Kubernetes bo sam dodal nova vozlišča v vašo gručo in na njih začel lansirati pode. Se pravi, ko pride vaša obremenitev, se začne število ognjišč povečevati. Ko zmanjka vozlišč v gruči za te pode, Kubernetes zažene nova vozlišča in v skladu s tem se lahko število podov še poveča. In to je zelo priročno. To je neposredna priložnost za sprotno prilagajanje gruče. Ni zelo hitro, v smislu, da ne traja sekunda, ampak bolj minuta za dodajanje novih vozlišč.
Toda po mojih izkušnjah je to nekaj najbolj kul, kar sem jih kdaj videl. Ko se je gruča Cloudnative spreminjala glede na čas dneva. To je bila zaledna storitev, ki so jo uporabljali ljudje v zaledni pisarni. To pomeni, da pridejo v službo ob 9. uri zjutraj, se začnejo prijavljati v sistem in skladno s tem začne grozd Cloudnative, kjer vse teče, nabrekniti, zažene nove pode, tako da lahko vsi, ki pridejo v službo, delajo z aplikacijo. Ko gredo iz službe ob 8. ali 6. uri, grozdi Kubernetes opazijo, da nihče več ne uporablja aplikacije, in se začnejo krčiti. Zagotovljeni so do 30-odstotni prihranki. Takrat je delovalo v Amazonu, takrat v Rusiji ni bilo nikogar, ki bi to znal narediti tako dobro.
Povem vam naravnost, prihranek je 30 odstotkov preprosto zato, ker uporabljamo Kubernetes in izkoriščamo zmogljivosti oblaka. Zdaj je to mogoče storiti v Rusiji. Seveda ne bom nikomur reklamirala, a recimo le, da obstajajo ponudniki, ki to zmorejo, zagotavljajo takoj iz škatle z gumbom.
Še zadnja točka, na katero bi rad opozoril. Da bi bila vaša aplikacija, vaša infrastruktura Cloudnative, je smiselno končno začeti prilagajati pristop, imenovan Infrastructure as a Code, kar pomeni, da je vaša aplikacija, oziroma vaša infrastruktura, potrebna na popolnoma enak način kot koda Opišite svojo aplikacijo, svojo poslovno logiko v obliki kode. In delajte z njim kot s kodo, to je, preizkusite ga, razvijte, shranite v git, uporabite CICD zanj.
In prav to vam omogoča, da imate, prvič, vedno nadzor nad svojo infrastrukturo, da vedno razumete, v kakšnem stanju je. Drugič, izogibajte se ročnim operacijam, ki povzročajo napake. Tretjič, preprosto se izogibajte temu, kar se imenuje fluktuacija, ko morate nenehno opravljati ista ročna opravila. Četrtič, omogoča vam veliko hitrejše okrevanje v primeru okvare. V Rusiji se vsakič, ko govorim o tem, najde ogromno ljudi, ki pravijo: "Ja, jasno je, ampak imate pristope, skratka, ni treba ničesar popravljati." Ampak res je. Če je nekaj pokvarjeno v vaši infrastrukturi, potem je z vidika pristopa Cloudnative in z vidika infrastrukture kot kode lažje, kot da bi to popravili, šli na strežnik, ugotovili, kaj je pokvarjeno in to popravili. da izbrišete strežnik in ga znova ustvarite. In vse to bom dal obnoviti.
Vsa ta vprašanja so podrobneje obravnavana na . Na povezavi se lahko seznanite s programom in pogoji. Priročna stvar je, da lahko obvladate Kubernetes tako, da se učite od doma ali delate 1-2 uri na dan.
Vir: www.habr.com