🥇 Kröfur um þróun forrita í Kubernetes

Í dag ætla ég að tala um hvernig á að skrifa umsóknir og hvaða kröfur eru gerðar til að umsókn þín virki vel í Kubernetes. Svo að það sé enginn höfuðverkur með forritið, svo að þú þurfir ekki að finna upp og byggja neinar „rifur“ í kringum það - og allt virkar eins og Kubernetes sjálft ætlaði.

Þessi fyrirlestur er hluti af "Slurm Night School á Kubernetes" Hægt er að skoða opna bóklega fyrirlestra Kvöldskólans á Youtube, flokkað í lagalista. Fyrir þá sem kjósa texta frekar en myndband höfum við útbúið þessa grein.

Ég heiti Pavel Selivanov, sem stendur er ég leiðandi DevOps verkfræðingur hjá Mail.ru Cloud Solutions, við gerum ský, við gerum stjórnunarkubernetes og svo framvegis. Verkefnin mín fela núna í sér aðstoð við þróun, að útfæra þessi ský, útfæra forritin sem við skrifum og þróa beint verkfærin sem við útvegum notendum okkar.

Ég hef verið að gera DevOps, held ég síðustu, líklega, þrjú ár. En í grundvallaratriðum hef ég verið að gera það sem DevOps gerir í líklega um fimm ár núna. Þar áður tók ég mest þátt í admin dóti. Ég byrjaði að vinna með Kubernetes fyrir löngu - líklega eru um fjögur ár liðin síðan ég byrjaði að vinna með það.

Almennt séð byrjaði ég þegar Kubernetes var útgáfa 1.3, líklega, og kannski 1.2 - þegar það var enn á frumstigi. Nú er það ekki lengur á frumstigi - og það er augljóst að það er mikil eftirspurn á markaðnum eftir verkfræðingum sem vilja geta gert Kubernetes. Og fyrirtæki hafa mjög mikla eftirspurn eftir slíku fólki. Þess vegna birtist reyndar þessi fyrirlestur.

Ef við tölum samkvæmt áætluninni um það sem ég mun tala um, lítur það svona út, innan sviga er skrifað (TL;DR) - „of lengi; ekki lesa". Kynningin mín í dag mun samanstanda af endalausum listum.

Reyndar líkar mér sjálfur ekki svona kynningar þegar þær eru gerðar, en þetta er þannig umræðuefni að þegar ég var að undirbúa þessa kynningu þá fattaði ég einfaldlega ekki hvernig ætti að skipuleggja þessar upplýsingar öðruvísi.

Vegna þess að í stórum dráttum eru þessar upplýsingar „ctrl+c, ctrl+v“, meðal annars frá Wiki okkar í DevOps hlutanum, þar sem við höfum skrifaðar kröfur til forritara: „krakkar, svo að við ræsum forritið þitt í Kubernetes, það ætti að vera svona."

Þess vegna reyndist kynningin vera svo stór listi. Því miður. Ég mun reyna að segja eins mikið og hægt er svo það sé ekki leiðinlegt ef hægt er.

Það sem við ætlum að skoða núna:

þetta eru í fyrsta lagi annálar (forritaskrár?), hvað á að gera við þá í Kubernetes, hvað á að gera við þá, hvað þeir ættu að vera;
hvað á að gera við stillingar í Kubernetes, hverjar eru bestu og verstu leiðirnar til að stilla forrit fyrir Kubernetes;
Við skulum tala um hvað aðgengisathuganir eru almennt, hvernig þær ættu að líta út;
við skulum tala um hvað tignarleg lokun er;
tölum aftur um auðlindir;
Við skulum snerta efni gagnageymslu enn og aftur;
og í lokin mun ég segja þér hvað hugtakið þetta dularfulla skýja-innfædda forrit er. Cloudnativeness, sem lýsingarorð þessa hugtaks.

Logs

Ég legg til að byrja á loggunum - með því hvar þarf að ýta þessum loggum í Kubernetes. Nú hefur þú opnað forrit í Kubernetes. Samkvæmt klassíkinni skrifuðu áður forrit alltaf logs einhvers staðar í skrá. Slæm forrit skrifuðu logs í skrá í heimamöppu þróunaraðilans sem setti forritið af stað. Góð forrit skrifuðu logs í skrá einhvers staðar í /var/log.

Í samræmi við það, ennfremur, voru góðir stjórnendur með nokkra hluti stillta í innviðum sínum sem þessir logs gætu snúið - sama rsyslog, sem skoðar þessa logs og þegar eitthvað kemur fyrir þá, þá eru þeir margir, það býr til öryggisafrit, setur logs þar , eyðir gömlum skrám, meira en viku, sex mánuði og sumar meira. Í orði ættum við að hafa ákvæði þannig að einfaldlega vegna þess að forritið skrifar logs, þá klárast ekki plássið á framleiðsluþjónunum (bardagaþjónum?). Og í samræmi við það stöðvaðist öll framleiðslan ekki vegna stokkanna.

Þegar við förum yfir í heim Kubernetes og keyrum það sama þar, þá er það fyrsta sem þú getur borgað eftirtekt til sú staðreynd að fólk, þegar það skrifaði logs í skrá, heldur áfram að skrifa þær.

Það kemur í ljós að ef við tölum um Kubernetes, þá er rétti staðurinn til að skrifa logs einhvers staðar úr docker gámi einfaldlega að skrifa þá úr forritinu yfir í svokallaða Stdout/Stderr, það er að segja stýrikerfið staðlaða úttaksstrauma, staðalvillu framleiðsla . Þetta er réttasta, einfaldasta og rökréttasta leiðin til að setja logs í grundvallaratriðum í Docker og sérstaklega í Kubernetis. Vegna þess að ef forritið þitt skrifar annála til Stdout/Stderr, þá er það undir Docker og Kubernetes viðbótinni komið að ákveða hvað á að gera við þessa annála. Docker mun sjálfgefið byggja sérstakar skrár sínar á JSON sniði.

Hér vaknar spurningin, hvað ætlar þú að gera næst með þessum annálum? Auðveldasta leiðin er skýr, við höfum getu til að gera kubectl logs og skoðaðu þessar logs af þessum "belg". En sennilega er þetta ekki mjög góður kostur - eitthvað annað þarf að gera við annálana.

Í bili skulum við tala á sama tíma, þar sem við snertum efni logs, um slíkt sem logs ættu að líta út. Það er, þetta á ekki beint við Kubernetes, en þegar við förum að hugsa um hvað eigi að gera við logs væri gott að hugsa um þetta líka.

Við þurfum einhvers konar tól, á vinsamlegan hátt, sem mun taka þessa annála sem hafnarstjórinn okkar setur inn í skrárnar sínar og senda þá eitthvert. Í stórum dráttum setjum við venjulega af stað einhvers konar umboðsmann inni í Kubernetes í formi DaemonSet - annálasafnara, sem er einfaldlega sagt hvar annálarnir sem Docker safnar eru staðsettir. Og þessi söfnunaraðili tekur þær einfaldlega, kannski greinir þær á einhvern hátt í leiðinni, auðgar þær kannski með einhverjum viðbótarupplýsingum og sendir þær að lokum til geymslu einhvers staðar. Þar eru nú þegar möguleg tilbrigði. Algengast er líklega Elasticsearch, þar sem þú getur geymt logs og þú getur auðveldlega sótt þá þaðan. Síðan, með því að nota beiðni, nota Kibana, til dæmis, búa til línurit út frá þeim, búa til viðvaranir út frá þeim og svo framvegis.

Mikilvægasta hugmyndin, ég vil endurtaka það aftur, er að inni í Docker, sérstaklega inni í Kubernetes, er mjög slæm hugmynd að geyma annálana þína í skrá.

Vegna þess að í fyrsta lagi er erfitt að koma stokkunum inn í gáminn í skrá. Þú verður fyrst að fara inn í gáminn, keyra þar og líta svo á logs. Næsti punktur er að ef þú ert með logs í skrá, þá eru gámarnir yfirleitt með mínímalísku umhverfi og það eru engin tól sem venjulega er þörf fyrir venjulega vinnu með logs. Grafið þau, skoðaðu þau, opnaðu þau í textaritli. Næsta augnablik er þegar við höfum logs í skrá inni í gámi, ef þessum gámi er eytt, skilurðu, logarnir munu deyja ásamt því. Í samræmi við það þýðir öll endurræsing ílátsins að það eru ekki fleiri logs. Aftur, slæmur kostur.

Og síðasti punkturinn er að inni í gámum hefurðu venjulega umsókn þína og það er það - það er venjulega eina ferlið í gangi. Það er alls ekki talað um neitt ferli sem myndi snúa skrám með annálunum þínum. Um leið og annálarnir byrja að skrifa í skrá þýðir þetta að, afsakaðu, við munum byrja að missa framleiðsluþjóninn. Vegna þess að í fyrsta lagi er erfitt að finna þá, enginn rekur þá, auk þess sem enginn stjórnar þeim - í samræmi við það vex skráin endalaust þar til plássið á þjóninum einfaldlega klárast. Þess vegna segi ég aftur að innskráning í Docker, sérstaklega í Kubernetes, í skrá er slæm hugmynd.

Næsta atriði, hér vil ég tala um þetta aftur - þar sem við erum að snerta efni loga, væri gott að tala um hvernig logs ættu að líta út til að gera það þægilegt að vinna með þá. Eins og ég sagði þá tengist efnið ekki beint Kubernetes, en það tengist mjög vel efni DevOps. Um efnið þróunarmenningu og vináttu milli þessara tveggja mismunandi deilda - Dev og Ops, svo að öllum líði vel.

Þetta þýðir að helst, í dag, ættu annálar að vera skrifaðar á JSON sniði. Ef þú ert með eitthvað óskiljanlegt forrit sjálft, sem skrifar logs á óskiljanlegu sniði vegna þess að þú setur inn einhvers konar prent eða eitthvað slíkt, þá er kominn tími til að gúgla einhvers konar ramma, einhvers konar umbúðir sem gerir þér kleift að innleiða venjulega skráningu; virkjaðu skráningarfæribreytur í JSON þar, vegna þess að JSON er einfalt snið, þá er að flokka það einfalt.

Ef JSON þinn virkar ekki samkvæmt einhverjum forsendum, enginn veit hvað, þá að minnsta kosti skrifaðu logs á sniði sem hægt er að parsa. Hér, frekar, það er þess virði að hugsa um þá staðreynd að, til dæmis, ef þú ert að keyra fullt af gámum eða bara ferlum með nginx, og hver hefur sínar eigin skráningarstillingar, þá virðist það líklega vera mjög óþægilegt fyrir þig að greina þær. Vegna þess að fyrir hvert nýtt nginx tilvik þarftu að skrifa þinn eigin þáttara, því þeir skrifa logs öðruvísi. Aftur, það var líklega þess virði að hugsa um að ganga úr skugga um að öll þessi nginx tilvik væru með sömu skráningarstillingar og skrifuðu allar annála sína algerlega einsleitt. Sama gildir um nákvæmlega allar umsóknir.

Í lokin vil ég líka bæta olíu á eldinn að helst ætti að forðast fjöllínu snið logs. Hér er málið, ef þú hefur einhvern tíma unnið með annálasöfnurum, þá hefur þú líklegast séð hverju þeir lofa þér, að þeir geti unnið með margra línu logs, vita hvernig á að safna þeim o.s.frv. Reyndar, að mínu mati, getur ekki einn safnari í dag safnað fjöllína annálum venjulega, að fullu og án villna. Á mannlegan hátt þannig að það sé þægilegt og villulaust.

En stafla rekja er alltaf multi-line logs og hvernig á að forðast þá. Spurningin hér er sú að log er skrá yfir atburð og stactrace er í raun ekki log. Ef við söfnum annálum og setjum þá einhvers staðar í Elasticsearch og teiknum síðan línurit úr þeim, búum til nokkrar skýrslur um notendavirkni á síðunni þinni, þá þegar þú færð staflaspor þýðir það að eitthvað óvænt er að gerast, ómeðhöndlaðar aðstæður í forritinu þínu. Og það er skynsamlegt að hlaða sjálfkrafa upp staflaspor einhvers staðar inn í kerfi sem getur fylgst með þeim.

Þetta er hugbúnaður (sama Sentry) sem er sérstaklega gerður til að vinna með staflaspor. Það getur strax búið til sjálfvirk verkefni, úthlutað þeim til einhvers, viðvörun þegar stacttraces eiga sér stað, flokka þessar staacttraces eftir einni tegund, og svo framvegis. Í grundvallaratriðum er ekki mikið vit í að tala um slóðir þegar við tölum um logs, því þetta eru, þegar allt kemur til alls, mismunandi hlutir með mismunandi tilgang.

Stillingar

Næst tölum við um stillingar í Kubernetes: hvað á að gera við það og hvernig forrit inni í Kubernetes ættu að vera stillt. Almennt séð segi ég venjulega að Docker snúist ekki um gáma. Allir vita að Docker snýst um gáma, jafnvel þeir sem hafa ekki unnið mikið með Docker. Ég endurtek, Docker snýst ekki um gáma.

Docker snýst að mínu mati um staðla. Og það eru staðlar fyrir nánast allt: staðla til að byggja upp forritið þitt, staðlar fyrir uppsetningu forritsins.

Og þessi hlutur - við notuðum hann áður, hann varð bara sérstaklega vinsæll með tilkomu gáma - þetta er kallað ENV (umhverfis) breytur, það er umhverfisbreytur sem eru í stýrikerfinu þínu. Þetta er almennt tilvalin leið til að stilla forritið þitt, vegna þess að ef þú ert með forrit í JAVA, Python, Go, Perl, Guð forði, og þau geta öll lesið gagnagrunnshýsilinn, gagnagrunnsnotandann, gagnagrunns lykilorðsbreytur, þá er það tilvalið. Þú ert með forrit á fjórum mismunandi tungumálum stillt í gagnagrunnsáætluninni á sama hátt. Það eru ekki fleiri mismunandi stillingar.

Allt er hægt að stilla með ENV breytum. Þegar við tölum um Kubernetes, þá er frábær leið til að lýsa ENV breytum beint inni í dreifingu. Í samræmi við það, ef við erum að tala um leynileg gögn, þá getum við strax ýtt leynilegum gögnum úr ENV breytum (lykilorð í gagnagrunna o.s.frv.) inn í leyndarmál, búið til leyniklasa og gefið til kynna í ENV lýsingunni í Deployment að við séum ekki beint að lýsa því yfir. gildi þessarar breytu, og gildi þessarar gagnagrunns lykilorðsbreytu verður lesið úr leyndarmálinu. Þetta er venjuleg Kubernetes hegðun. Og þetta er besti kosturinn til að stilla forritin þín. Bara á kóðastigi, aftur á þetta við um forritara. Ef þú ert DevOps geturðu spurt: „Krakkar, vinsamlegast kenndu forritinu þínu að lesa umhverfisbreytur. Og við verðum öll ánægð."

Ef allir í fyrirtækinu lesa sömu nefndar umhverfisbreytur, þá er það frábært. Svo það gerist ekki að sumir bíði eftir postgres gagnagrunninum, aðrir séu að bíða eftir gagnagrunnsnafninu, aðrir séu að bíða eftir einhverju öðru, aðrir séu að bíða eftir dbn af einhverju tagi, þannig að það sé einsleitni í samræmi við það.

Vandamálið kemur þegar þú ert með svo margar umhverfisbreytur að þú opnar bara Deployment - og það eru fimm hundruð línur af umhverfisbreytum. Í þessu tilfelli hefurðu einfaldlega vaxið fram úr umhverfisbreytum - og þú þarft ekki lengur að pynta sjálfan þig. Í þessu tilfelli væri skynsamlegt að byrja að nota stillingar. Það er, þjálfaðu forritið þitt til að nota stillingar.

Eina spurningin er að stillingar eru ekki það sem þú heldur. Config.pi er ekki stilling sem er þægileg í notkun. Eða einhver stilling á þínu eigin sniði, að öðrum kosti hæfileikarík - þetta er heldur ekki stillingin sem ég meina.

Það sem ég er að tala um er stillingar á viðunandi sniðum, það er að segja að langvinsælasti staðallinn er .yaml staðallinn. Það er skýrt hvernig á að lesa það, það er læsilegt fyrir menn, það er skýrt hvernig á að lesa það úr forritinu.

Í samræmi við það, auk YAML, geturðu líka, til dæmis, notað JSON, þáttun er um það bil eins þægileg og YAML hvað varðar lestur forritsstillingar þaðan. Það er áberandi óþægilegra fyrir fólk að lesa. Þú getur prófað sniðið, a la ini. Það er frekar þægilegt að lesa, frá mannlegu sjónarhorni, en það getur verið óþægilegt að vinna það sjálfkrafa, í þeim skilningi að ef þú vilt einhvern tíma búa til þínar eigin stillingar gæti ini sniðið þegar verið óþægilegt að búa til.

En í öllum tilvikum, hvaða snið sem þú velur, þá er málið að frá Kubernetes sjónarhóli er það mjög þægilegt. Þú getur sett alla stillinguna þína inni í Kubernetes, í ConfigMap. Og taktu síðan þetta configmap og biddu að það sé fest inni í hólfinu þínu í einhverri tiltekinni möppu, þar sem forritið þitt mun lesa stillingarnar úr þessu configmap eins og það væri bara skrá. Þetta er í raun það sem er gott að gera þegar þú ert með marga stillingarvalkosti í forritinu þínu. Eða þetta er bara einhvers konar flókin uppbygging, það er hreiður.

Ef þú ert með configmap, þá geturðu mjög vel kennt forritinu þínu, til dæmis að fylgjast sjálfkrafa með breytingum á skránni þar sem configmap er fest, og einnig sjálfkrafa endurhlaða forritinu þínu þegar stillingarnar breytast. Þetta væri almennt kjörinn kostur.

Aftur, ég talaði þegar um þetta - leynilegar upplýsingar eru ekki í configmap, leynilegar upplýsingar eru ekki í breytum, leynilegar upplýsingar eru ekki í leyndarmálum. Þaðan tengdu þessar leynilegu upplýsingar við diplómatíu. Venjulega geymum við allar lýsingar á Kubernetes hlutum, uppfærslum, stillingarkortum, þjónustu í git. Samkvæmt því er slæm hugmynd að setja lykilorðið að gagnagrunninum í git, jafnvel þó það sé gitið þitt, sem þú ert með innan fyrirtækisins. Vegna þess að, að minnsta kosti, git man allt og einfaldlega að fjarlægja lykilorð þaðan er ekki svo auðvelt.

Heilsufarsskoðun

Næsti liður er þetta sem heitir Health check. Almennt séð er heilsufarsskoðun einfaldlega að athuga hvort forritið þitt virki. Á sama tíma erum við oftast að tala um tiltekin vefforrit, sem í samræmi við það, frá sjónarhóli heilbrigðisskoðunar (betra að þýða ekki hér og lengra) verður þetta einhver sérstök vefslóð sem þau vinna sem staðall, þeir gera það venjulega /health.

Þegar þessi vefslóð er opnuð segir forritið okkar annað hvort „já, allt í lagi, allt í lagi með mig, 200“ eða „nei, allt er ekki í lagi með mig, um 500.“ Í samræmi við það, ef forritið okkar er ekki http, ekki vefforrit, erum við núna að tala um einhvers konar púka, við getum fundið út hvernig á að gera heilsufarsskoðun. Það er, það er ekki nauðsynlegt, ef forritið er ekki http, þá virkar allt án heilsufarsskoðunar og það er ekki hægt að gera það á nokkurn hátt. Þú getur reglulega uppfært einhverjar upplýsingar í skránni, þú getur komið með einhverja sérstaka skipun fyrir púkann þinn, eins og, daemon status, sem mun segja "já, allt er í lagi, púkinn er að virka, hann er á lífi."

Til hvers er það? Það fyrsta og augljósasta er líklega hvers vegna heilsufarsskoðun er nauðsynleg - til að skilja að forritið virkar. Ég meina, það er bara heimskulegt, þegar það er komið upp núna, þá lítur það út fyrir að það sé að virka, svo þú getur verið viss um að það virki. Og það kemur í ljós að forritið er í gangi, gámurinn er í gangi, tilvikið virkar, allt er í lagi - og þá eru notendur búnir að slíta öll símanúmer frá tækniaðstoðinni og segja „hvað ertu..., þú sofnaði, ekkert virkar."

Heilsufarsskoðun er bara þannig leið til að sjá frá sjónarhóli notandans að það virkar. Ein af aðferðunum. Við skulum orða þetta svona. Frá sjónarhóli Kubernetes er þetta líka leið til að skilja hvenær forritið byrjar, því við skiljum að það er munur á því hvenær ílátið var ræst, búið til og byrjað og hvenær forritið var ræst beint í þessum íláti. Vegna þess að ef við tökum eitthvert meðaltal Java-forrit og reynum að ræsa það í bryggjunni, þá getur það byrjað ágætlega í fjörutíu sekúndur, eða jafnvel eina mínútu, eða jafnvel tíu. Í þessu tilviki geturðu að minnsta kosti bankað á hafnir þess, það mun ekki svara þar, það er, það er ekki enn tilbúið til að taka á móti umferð.

Aftur, með hjálp heilsufarsskoðunar og með hjálp þeirrar staðreyndar að við erum að snúa hér, getum við skilið í Kubernetes að ekki aðeins ílátið hefur hækkað í forritinu, heldur hefur forritið sjálft byrjað, það svarar nú þegar heilsufarsskoðun, sem þýðir að við getum sent umferð þangað.

Það sem ég er að tala um núna er kallað viðbúnaðar-/líffærnipróf innan Kubernetes; í samræmi við það eru viðbúnaðarprófin okkar ábyrg fyrir framboði forritsins í jafnvægi. Það er, ef viðbúnaðarpróf eru gerðar í forritinu, þá er allt í lagi, umferð viðskiptavina fer í forritið. Ef viðbúnaðarpróf eru ekki framkvæmd, þá tekur forritið einfaldlega ekki þátt, þetta tiltekna tilvik tekur ekki þátt í jafnvægi, það er fjarlægt úr jafnvægi, umferð viðskiptavina rennur ekki. Í samræmi við það er þörf á Liveness prófum innan Kubernetes svo að ef forritið festist er hægt að endurræsa það. Ef lífleikaprófið virkar ekki fyrir forrit sem er lýst yfir í Kubernetes, þá er forritið ekki bara fjarlægt úr jafnvægi, það er endurræst.

Og hér er mikilvægt atriði sem ég vil nefna: frá hagkvæmu sjónarmiði er viðbúnaðarprófið venjulega notað oftar og er oftar þörf á því en lífleikaprófið. Það er að segja einfaldlega hugsunarlaust yfir bæði viðbúnaðar- og lífleikapróf, vegna þess að Kubernetes getur gert það, og við skulum nota allt sem það getur gert, er ekki mjög góð hugmynd. Ég skal útskýra hvers vegna. Vegna þess að liður númer tvö í prófun er að það væri góð hugmynd að athuga undirliggjandi þjónustu í heilsufarsskoðunum þínum. Þetta þýðir að ef þú ert með vefforrit sem gefur út einhverjar upplýsingar, sem aftur á móti verður að taka einhvers staðar frá. Í gagnagrunni, til dæmis. Jæja, það vistar upplýsingarnar sem koma inn í þetta REST API í sama gagnagrunni. Síðan, í samræmi við það, ef heilsuskoðun þín bregst einfaldlega eins og slashhealth sem þú hefur samband við, segir forritið „200, allt í lagi, allt er í lagi,“ og á sama tíma er gagnagrunnur forritsins þíns óaðgengilegur og heilsuskoðunarforritið segir „200, allt í lagi, allt er í lagi “ - Þetta er slæmt heilbrigðiseftirlit. Svona á þetta ekki að virka.

Það er umsókn þín, þegar beiðni kemur til hennar /health, það svarar ekki bara, „200, allt í lagi“, það fer fyrst til dæmis í gagnagrunninn, reynir að tengjast honum, gerir eitthvað mjög undirstöðu þar, eins og að velja einn, athugar bara hvort það sé tenging í gagnagrunninum og þú getur spurt gagnagrunninn. Ef allt þetta tókst, þá er svarið "200, allt í lagi." Ef það tekst ekki segir það að það sé villa, gagnagrunnurinn er ekki tiltækur.

Þess vegna, í þessum efnum, vík ég aftur að viðbúnaðar/líffærniprófunum - hvers vegna þú þarft líklegast viðbúnaðarpróf, en um líffærnipróf er að ræða. Vegna þess að ef þú lýsir heilsufarsskoðun nákvæmlega eins og ég sagði bara, þá kemur í ljós að það er ekki í boði í tilvikshlutanumв или со всех instanceí gagnagrunni til dæmis. Þegar þú lýstir yfir viðbúnaðarprófi byrjaði heilsufarsskoðun okkar að mistakast, og í samræmi við öll forritin sem gagnagrunnurinn er ekki aðgengilegur úr, er einfaldlega slökkt á þeim frá jafnvægi og í raun „hanga“ bara í vanræktu ástandi og bíða eftir að gagnagrunnar þeirra vinna.

Ef við höfum lýst yfir lífleikaprófi, ímyndaðu þér þá, gagnagrunnurinn okkar hefur bilað og í Kubernetes þínum byrjar helmingur alls að endurræsa sig vegna þess að lífleikaprófið mistekst. Þetta þýðir að þú þarft að endurræsa. Þetta er alls ekki það sem þú vilt, ég hafði meira að segja persónulega reynslu í starfi. Við vorum með spjallforrit sem var skrifað í JS og færð inn í Mongo gagnagrunn. Og vandamálið var að það var í upphafi vinnu minnar með Kubernetes, við lýstum viðbúnaði, lífleika prófana á þeirri meginreglu að Kubernetes geti gert það, svo við munum nota það. Í samræmi við það, á einhverjum tímapunkti varð Mongo svolítið „daufur“ og sýnishornið fór að mistakast. Samkvæmt því, samkvæmt rigningarprófinu, fóru fræbelgirnir að „drepa“.

Eins og þú skilur, þegar þeir eru „drepnir“, er þetta spjall, það er að segja að það eru fullt af tengingum frá viðskiptavinum sem hanga á því. Þeir eru líka "drepnir" - nei, ekki viðskiptavinir, aðeins tengingar - ekki allir á sama tíma, og vegna þess að þeir eru ekki drepnir á sama tíma, sumir fyrr, aðrir síðar, byrja þeir ekki á sama tíma tíma. Auk venjulegs handahófs getum við ekki spáð fyrir um með millisekúndna nákvæmni upphafstíma forritsins í hvert skipti, svo þeir gera það eitt tilvik í einu. Einn infospot rís, bætist við jöfnunina, þangað koma allir viðskiptavinir, hann þolir ekki slíkt álag, því hann er einn, og í grófum dráttum eru þeir tugir að störfum þar, og það fellur. Sá næsti rís upp, öll byrðin er á honum, hann fellur líka. Jæja, þessar fossar halda bara áfram að falla. Að lokum, hvernig þetta var leyst - við urðum bara að stranglega stöðva notendaumferð að þessu forriti, láta öll tilvik hækka og hefja síðan alla notendaumferð í einu þannig að henni var þegar dreift á öll tíu tilvikin.

Ef það væri ekki fyrir þetta lífleikapróf væri tilkynnt, sem myndi neyða þetta allt til að endurræsa, hefði forritið höndlað það bara vel. En allt frá jafnvægi er óvirkt fyrir okkur, vegna þess að gagnagrunnarnir eru óaðgengilegir og allir notendur hafa „fallið af“. Síðan, þegar þessi gagnagrunnur verður tiltækur, er allt innifalið í jöfnun, en forrit þurfa ekki að byrja aftur og það þarf ekki að eyða tíma og fjármagni í þetta. Þeir eru allir þegar hér, þeir eru tilbúnir fyrir umferð, svo umferð opnast bara, allt er í lagi - forritið er til staðar, allt heldur áfram að virka.

Þess vegna eru viðbúnaðar- og lífleikapróf mismunandi, jafnvel þar að auki geturðu fræðilega gert mismunandi heilsufarsskoðun, eina tegund radíus, eina tegund liv, til dæmis, og athugað mismunandi hluti. Á meðan á viðbúnaðarprófum stendur skaltu athuga bakenda þína. Og á lífleikaprófi, til dæmis, athugarðu ekki frá því sjónarhorni að lífleikaprófið sé almennt bara forrit sem svarar, ef það getur svarað yfirleitt.

Vegna þess að lífleikaprófið er í stórum dráttum þegar við erum „föst“. Endalaus lykkja er hafin eða eitthvað annað - og ekki er unnið úr fleiri beiðnum. Þess vegna er skynsamlegt að jafnvel aðgreina þau - og innleiða mismunandi rökfræði í þeim.

Varðandi hverju þú þarft að svara þegar þú ferð í próf, þegar þú gerir heilsufarsskoðun. Þetta er bara virkilega sársauki. Þeir sem þekkja þetta munu líklega hlæja - en í alvöru talað, ég hef séð þjónustu í lífi mínu sem svarar „200“ í XNUMX% tilvika. Það er, hver er farsæll. En á sama tíma í meginmáli svarsins skrifa þeir „svona og slíka villu“.

Það er að segja að viðbragðsstaðan kemur til þín - allt gengur vel. En á sama tíma verður þú að flokka meginmálið, því meginmálið segir "því miður, beiðnin endaði með villu" og þetta er bara raunveruleiki. Ég sá þetta í raunveruleikanum.

Og svo að sumu fólki finnist það ekki fyndið og öðrum finnst það mjög sárt, þá er samt þess virði að fylgja einfaldri reglu. Í heilsufarsskoðunum og í grundvallaratriðum þegar unnið er með vefforrit.

Ef allt gekk vel skaltu svara með tvöhundruðasta svarinu. Í grundvallaratriðum mun hvaða tvö hundruðasta svar sem er henta þér. Ef þú lest ragsy mjög vel og veist að sumar svörunarstöður eru frábrugðnar öðrum skaltu svara með viðeigandi: 204, 5, 10, 15, hvað sem er. Ef það er ekki mjög gott, þá bara "tveir núll núll." Ef allt fer á versta veg og heilbrigðiseftirlitið svarar ekki, svarið þá með hvaða fimmhundruð. Aftur, ef þú skilur hvernig á að bregðast við, hvernig mismunandi svörunarstöður eru frábrugðnar hver öðrum. Ef þú skilur það ekki, þá er 502 valkostur þinn til að bregðast við heilbrigðiseftirliti ef eitthvað fer úrskeiðis.

Þetta er annað atriði, ég vil koma aðeins aftur um að athuga undirliggjandi þjónustu. Ef þú byrjar til dæmis að athuga allar undirliggjandi þjónustur sem standa á bak við umsókn þína - allt almennt. Það sem við fáum frá sjónarhóli örþjónustuarkitektúrs höfum við hugtak eins og „lágtenging“ - það er að segja þegar þjónusta þín er að lágmarki háð hver annarri. Ef ein þeirra mistekst munu allir hinir án þessarar virkni einfaldlega halda áfram að virka. Sum virkni virkar bara ekki. Í samræmi við það, ef þú bindur öll heilbrigðiseftirlit hvert við annað, þá endar þú með því að eitt falli í innviðunum, og vegna þess að það féll, byrja öll heilbrigðisskoðun allrar þjónustu líka að mistakast - og það eru fleiri innviðir almennt fyrir heill örþjónustuarkitektúr nr. Þar varð allt dimmt.

Þess vegna vil ég endurtaka þetta aftur að þú þarft að athuga undirliggjandi þjónustu, þá án hennar getur umsókn þín í hundrað prósent tilvika ekki staðið sig. Það er, það er rökrétt að ef þú ert með REST API þar sem notandinn vistar í gagnagrunninn eða sækir úr gagnagrunninum, þá getur þú ekki ábyrgst vinnu með notendum þínum, ef gagnagrunnur er ekki til.

En ef notendur þínir, þegar þú tekur þá út úr gagnagrunninum, eru auk þess auðgaðir með einhverjum öðrum lýsigögnum, frá öðrum bakenda, sem þú slærð inn áður en þú sendir svar til framenda - og þessi bakendi er ekki tiltækur, þýðir þetta að þú gefur svara án nokkurs hluta lýsigagnanna.

Næst höfum við líka eitt af sársaukafullu vandamálunum þegar forrit eru ræst.

Reyndar á þetta ekki bara við um Kubernetes almennt, það gerðist bara að menning einhvers konar fjöldaþróunar og DevOps sérstaklega fór að breiðast út um svipað leyti og Kubernetes. Þess vegna kemur í ljós að þú þarft að loka forritinu þínu með þokkabót án Kubernetes. Jafnvel áður en Kubernetes gerðist þetta, en með tilkomu Kubernetes fórum við að tala um það í massavís.

Þokkafull lokun

Almennt, hvað er Graceful Shutdown og hvers vegna er þörf á henni? Þetta snýst um þegar forritið þitt hrynur af einhverjum ástæðum, þú þarft að gera það app stop - eða þú færð til dæmis merki frá stýrikerfinu, forritið þitt verður að skilja það og gera eitthvað í því. Versta tilvikið er auðvitað þegar forritið þitt fær SIGTERM og er eins og „SIGTERM, höldum áfram, vinnum, gerum ekki neitt. Þetta er beinlínis slæmur kostur.

Næstum jafn slæmur valkostur er þegar forritið þitt fær SIGTERM og er eins og „þeir sögðu segterm, það þýðir að við erum að enda, ég hef ekki séð, ég þekki engar notendabeiðnir, ég veit ekki hvers konar beiðnir sem ég er að vinna að núna, sögðu þeir SIGTERM, það þýðir að við erum að enda " Þetta er líka slæmur kostur.

Hvaða valkostur er góður? Fyrsta atriðið er að taka tillit til þess að aðgerðum er lokið. Góður kostur er að þjónninn þinn taki samt tillit til þess sem hann gerir ef hann fær SIGTERM.

SIGTERM er mjúk lokun, það er sérstaklega hannað, það er hægt að stöðva það á kóðastigi, það er hægt að vinna úr því, segðu að nú, bíddu, við munum fyrst klára verkið sem við höfum, síðan munum við hætta.

Frá sjónarhóli Kubernetes lítur þetta svona út. Þegar við segjum við belg sem er í gangi í Kubernetes þyrpingunni, „vinsamlegast hættu, farðu,“ eða við erum endurræst, eða uppfærsla á sér stað þegar Kubernetes endurskapar belgina, sendir Kubernetes bara sömu SIGTERM skilaboðin til belgsins, bíður eftir einhvern tíma, og , þetta er tíminn sem hann bíður, hann er líka stilltur, það er svo sérstök breytu í prófskírteinum og það er kallað Graceful ShutdownTimeout. Eins og þú skilur, er það ekki kallað það fyrir ekki neitt, og það er ekki fyrir ekkert sem við erum að tala um það núna.

Þar getum við sérstaklega sagt til um hversu langan tíma við þurfum að bíða frá því að við sendum SIGTERM í umsóknina þar til við skiljum að umsóknin virðist hafa klikkað fyrir einhverju eða sé „fast“ og ætlar ekki að enda - og við þurfum að sendu það SIGKILL, það er, harður klárað verk sitt. Það er, í samræmi við það, við erum með einhvers konar púka í gangi, hann vinnur aðgerðir. Við skiljum að að meðaltali varir aðgerðir okkar sem púkinn vinnur ekki lengur en 30 sekúndur í einu. Í samræmi við það, þegar SIGTERM kemur, skiljum við að púkinn okkar getur í mesta lagi klárað 30 sekúndur eftir SIGTERM. Við skrifum það, til dæmis, 45 sekúndur fyrir öryggisatriði og segjum að SIGTERM. Eftir það bíðum við í 45 sekúndur. Í orði, á þessum tíma ætti púkinn að hafa lokið verki sínu og endað sjálfan sig. En ef það skyndilega gat það ekki þýðir það að það er líklegast fast - það er ekki lengur að vinna úr beiðnum okkar venjulega. Og á 45 sekúndum geturðu örugglega neglt hann niður.

Og hér má í raun taka tillit til tveggja þátta. Í fyrsta lagi skaltu skilja að ef þú fékkst beiðni fórstu að vinna með hana einhvern veginn og svaraðir ekki notandanum, en þú fékkst til dæmis SIGTERM. Það er skynsamlegt að betrumbæta það og gefa notandanum svar. Þetta er punktur númer eitt í þessu sambandi. Punktur númer tvö hér er að ef þú skrifar þitt eigið forrit, byggir almennt arkitektúrinn þannig að þú færð beiðni um umsóknina þína, þá byrjar þú að vinna, byrjar að hlaða niður skrám einhvers staðar frá, hlaða niður gagnagrunni og hvað ekki. - Það. Almennt, notandinn þinn, beiðni þín hangir í hálftíma og bíður eftir að þú svarir honum - þá, líklega, þarftu að vinna í arkitektúrnum. Það er, taktu bara tillit til heilbrigðrar skynsemi að ef aðgerðir þínar eru stuttar, þá er skynsamlegt að hunsa SIGTERM og breyta því. Ef aðgerðir þínar eru langar, þá þýðir ekkert að hunsa SIGTERM í þessu tilfelli. Það er skynsamlegt að endurhanna arkitektúrinn til að forðast svona langan aðgerðir. Svo að notendur hanga ekki bara og bíða. Ég veit það ekki, búðu til einhvers konar netsokk þarna, búðu til öfuga króka sem þjónninn þinn mun nú þegar senda til viðskiptavinarins, eitthvað annað, en ekki neyða notandann til að hanga í hálftíma og bíða bara eftir session þar til þú svara honum. Vegna þess að það er ófyrirsjáanlegt hvar það gæti brotnað.

Þegar umsókn þinni lýkur ættir þú að gefa upp viðeigandi útgöngukóða. Það er að segja, ef umsóknin þín var beðin um að loka, hætta, og hún gat stöðvað sig venjulega, þá þarftu ekki að skila einhvers konar útgöngukóða 1,5,255 og svo framvegis. Allt sem er ekki núllkóði, að minnsta kosti í Linux kerfum, ég er viss um þetta, er talið misheppnað. Það er, það er talið að umsókn þín í þessu tilviki hafi endað með villu. Í samræmi við það, á vinsamlegan hátt, ef umsókn þín kláraðist án villu, segirðu 0 á úttakinu. Ef forritið þitt mistekst af einhverjum ástæðum segirðu ekki-0 í úttakinu. Og þú getur unnið með þessar upplýsingar.

Og síðasti kosturinn. Það er slæmt þegar notandinn þinn sendir beiðni og hangir í hálftíma á meðan þú vinnur hana. En almennt vil ég líka segja um hvað er almennt þess virði frá hlið viðskiptavinarins. Það skiptir ekki máli hvort þú ert með farsímaforrit, framenda osfrv. Það er nauðsynlegt að taka með í reikninginn að almennt er hægt að slíta lotu notandans, allt getur gerst. Beiðni getur verið send, til dæmis, vanvinnsla og engu svari skilað. Framendinn þinn eða farsímaforritið þitt - hvaða framend sem er almennt, við skulum orða það þannig - ætti að taka mið af þessu. Ef þú vinnur með veftengi þá er þetta yfirleitt versti sársauki sem ég hef nokkurn tíma fengið.

Þegar forritarar sumra venjulegra spjalla vita það ekki, þá kemur í ljós að veftengillinn getur brotnað. Fyrir þá, þegar eitthvað gerist í umboðinu, breytum við bara stillingunni og hún endurhleður. Auðvitað eru allar langvarandi fundir rifnar í þessu tilfelli. Hönnuðir koma hlaupandi til okkar og segja: „Strákar, hvað eruð þið að gera, spjallið hefur bilað hjá öllum viðskiptavinum okkar! Við segjum þeim: „Hvað ertu að gera? Geta viðskiptavinir þínir ekki tengst aftur? Þeir segja: „Nei, við þurfum að fundur verði ekki rifinn. Í stuttu máli er þetta eiginlega bull. Taka þarf tillit til viðskiptavinarhliðarinnar. Sérstaklega, eins og ég segi, með langvarandi lotum eins og netsokkum, getur það brotnað og, án þess að notandinn tekur eftir því, þarftu að geta sett upp slíkar lotur aftur. Og þá er allt fullkomið.

Resources

Reyndar, hér skal ég bara segja þér beina sögu. Aftur úr raunveruleikanum. Það sjúkasta sem ég hef heyrt um auðlindir.

Tilföng í þessu tilfelli, ég meina, einhvers konar beiðnir, takmarkanir sem þú getur sett á belg í Kubernetes klösunum þínum. Það fyndnasta sem ég heyrði frá þróunaraðila... Einn af félögum mínum á fyrri vinnustað sagði einu sinni: „Forritið mitt mun ekki byrja í þyrpingunni.“ Ég horfði til að sjá að það var ekki að byrja, en annað hvort passaði það ekki inn í úrræðin, eða þeir höfðu sett mjög lítil takmörk. Í stuttu máli getur forritið ekki ræst vegna fjármagns. Ég segi: „Það byrjar ekki vegna fjármagns, þú ákveður hversu mikið þú þarft og setur nægilegt gildi. Hann segir: "Hvers konar auðlindir?" Ég fór að útskýra fyrir honum að setja þyrfti Kubernetes, takmarkanir á beiðnum og bla, bla, bla. Maðurinn hlustaði í fimm mínútur, kinkaði kolli og sagði: „Ég kom hingað til að vinna sem þróunaraðili, ég vil ekki vita neitt um auðlindir. Ég kom hingað til að skrifa kóða og það er það.“ Það er sorglegt. Þetta er mjög sorglegt hugtak frá sjónarhóli þróunaraðila. Sérstaklega í nútíma heimi, ef svo má segja, framsækinna devops.

Hvers vegna þarf yfirhöfuð fjármagn? Það eru 2 tegundir af auðlindum í Kubernetes. Sumar eru kallaðar beiðnir, aðrar eru kallaðar takmarkanir. Með auðlindum munum við skilja að það eru í grundvallaratriðum alltaf aðeins tvær grunntakmarkanir. Það er, CPU tímamörk og vinnsluminni takmörk fyrir gám sem keyrir í Kubernetes.

Takmörk setja efri mörk á hvernig hægt er að nota tilföng í forritinu þínu. Það er, í samræmi við það, ef þú segir 1GB af vinnsluminni í mörkunum, þá mun forritið þitt ekki geta notað meira en 1GB af vinnsluminni. Og ef hann vill skyndilega og reynir að gera þetta, þá mun ferli sem kallast oom killer, úr minni, það er, koma og drepa forritið þitt - það er, það mun einfaldlega endurræsa. Forrit munu ekki endurræsa byggt á CPU. Hvað varðar CPU, ef forrit reynir að nota mikið, meira en tilgreint er í mörkunum, verður örgjörvinn einfaldlega stranglega valinn. Þetta leiðir ekki til endurræsingar. Þetta eru mörkin - þetta eru efri mörkin.

Og það er beiðni. Beiðni er hvernig Kubernetes skilur hvernig hnútar í Kubernetes klasanum þínum eru fylltir með forritum. Það er, beiðni er eins konar skuldbinding umsóknar þinnar. Það segir það sem ég vil nota: „Ég myndi vilja að þú geymir svona mikinn örgjörva og þetta mikið minni fyrir mig. Svo einföld samlíking. Hvað ef við erum með hnút sem hefur, ég veit það ekki, alls 8 örgjörva. Og þar kemur fræbelgur, þar sem beiðnir hans segja 1 CPU, sem þýðir að hnúturinn hefur 7 örgjörva eftir. Það er, í samræmi við það, um leið og 8 belg koma að þessum hnút, sem hver um sig hefur 1 CPU í beiðnum sínum, þá er hnúturinn, eins og frá sjónarhóli Kubernetes, búinn að klára CPU og fleiri belg með beiðnum geta ekki verið hleypt af stokkunum á þessum hnút. Ef allir hnútar klárast af CPU, þá mun Kubernetes byrja að segja að það séu engir hentugir hnútar í þyrpingunni til að keyra belgina þína vegna þess að CPU er búinn.

Af hverju er þörf á beiðnum og hvers vegna án beiðna held ég að það sé engin þörf á að ræsa neitt í Kubernetes? Við skulum ímynda okkur ímyndaða stöðu. Þú ræsir forritið þitt án beiðna, Kubernetes veit ekki hversu mikið af því sem þú hefur, hvaða hnúta þú getur ýtt því á. Jæja, hann ýtir, ýtir, ýtir á hnútana. Á einhverjum tímapunkti muntu byrja að fá umferð í forritið þitt. Og eitt af forritunum byrjar allt í einu að nota auðlindir upp að þeim mörkum sem það hefur samkvæmt takmörkunum. Það kemur í ljós að það er annað forrit nálægt og það þarf líka fjármagn. Hnúturinn byrjar í raun að verða uppiskroppa með auðlindir, til dæmis OP. Hnúturinn byrjar í raun að verða uppiskroppa með auðlindir, til dæmis, handahófsaðgangsminni (RAM). Þegar hnútur verður orkulaus mun fyrst og fremst hafnarstjórinn hætta að svara, síðan kúlan og síðan stýrikerfið. Þeir munu einfaldlega fara meðvitundarlausir og ALLT mun örugglega hætta að virka fyrir þig. Það er, þetta mun leiða til þess að hnúturinn þinn festist og þú þarft að endurræsa hann. Í stuttu máli er staðan ekki mjög góð.

Og þegar þú hefur beiðnir, eru mörkin ekki mjög mismunandi, að minnsta kosti ekki margfalt fleiri en mörkin eða beiðnirnar, þá geturðu haft svona eðlilega, skynsamlega fyllingu á umsóknum yfir hnúta Kubernetes klasa. Á sama tíma er Kubernetes um það bil meðvituð um hversu mikið af því sem það setur hvar, hversu mikið af því sem er notað hvar. Það er að segja, þetta er bara svona augnablik. Það er mikilvægt að skilja það. Og það er mikilvægt að hafa eftirlit með því að þetta sé gefið til kynna.

Gagnageymsla

Næsta atriði okkar er um gagnageymslu. Hvað á að gera við þá og almennt, hvað á að gera við þrautseigju í Kubernetes?

Ég held, aftur, innan okkar Kvöldskóli, það var umræðuefni um gagnagrunninn í Kubernetes. Og mér sýnist að ég viti meira að segja nokkurn veginn hvað samstarfsmenn þínir sögðu þér þegar þeir voru spurðir: "Er hægt að keyra gagnagrunn í Kubernetes?" Einhverra hluta vegna sýnist mér að samstarfsmenn þínir hefðu átt að segja þér að ef þú ert að spyrja um hvort hægt sé að keyra gagnagrunn í Kubernetes, þá sé það ómögulegt.

Rökfræðin hér er einföld. Bara svona, ég skal útskýra enn og aftur, ef þú ert mjög svalur strákur sem getur byggt upp nokkuð bilanaþolið kerfi fyrir dreifða netgeymslu, skildu hvernig á að passa gagnagrunn inn í þetta tilfelli, hvernig skýjaætt í gámum ætti að virka í gagnagrunni almennt. Líklegast hefur þú enga spurningu um hvernig á að keyra það. Ef þú ert með slíka spurningu og þú vilt ganga úr skugga um að allt gangi upp og standi alveg til dauða í framleiðslu og detti aldrei, þá gerist þetta ekki. Þú ert viss um að skjóta þig í fótinn með þessari nálgun. Svo það er betra að gera það ekki.

Hvað eigum við að gera við gögnin sem forritið okkar vill geyma, sumar myndir sem notendur hlaða upp, suma hluti sem forritið okkar býr til við notkun þess, við ræsingu, til dæmis? Hvað á að gera við þá í Kubernetes?

Almennt, helst, já, auðvitað, Kubernetes er mjög vel hannað og var almennt upphaflega hugsað fyrir ríkisfangslaus forrit. Það er að segja fyrir þau forrit sem geyma alls ekki upplýsingar. Þetta er tilvalið.

En auðvitað er kjörinn kostur ekki alltaf til. Og hvað? Fyrsti og einfaldasti punkturinn er að taka einhvers konar S3, bara ekki heimagerðan, sem er líka óljóst hvernig það virkar, heldur frá einhverri þjónustuveitu. Góður, venjulegur veitandi - og kenndu forritinu þínu að nota S3. Það er, þegar notandinn þinn vill hlaða upp skrá, segðu „hér, vinsamlegast hlaðið henni upp á S3.“ Þegar hann vill fá það, segðu: "Hér er hlekkur á S3 til baka og taktu hann héðan." Þetta er tilvalið.

Ef skyndilega af einhverjum ástæðum hentar þessi kjöri valkostur ekki, þú ert með forrit sem þú skrifaðir ekki, þú þróar ekki, eða það er einhvers konar hræðileg arfleifð, það getur ekki notað S3 samskiptareglur, heldur verður að vinna með staðbundnum möppum í staðbundnar möppur. Taktu eitthvað meira eða minna einfalt, settu upp Kubernetes. Það er, að girða Ceph strax fyrir nokkur lágmarksverkefni, sýnist mér, vera slæm hugmynd. Því Ceph er auðvitað góður og smart. En ef þú skilur ekki hvað þú ert að gera, þá geturðu auðveldlega og einfaldlega aldrei komið því út aftur þegar þú setur eitthvað á Ceph. Vegna þess að, eins og þú veist, geymir Ceph gögn í klasanum sínum á tvíundarformi, en ekki í formi einfaldra skráa. Þess vegna, ef skyndilega brotnar Ceph þyrpingin, þá eru algjörar og miklar líkur á að þú fáir aldrei gögnin þín þaðan aftur.

Við verðum með námskeið um Ceph, þú getur kynntu þér forritið og sendu inn umsókn.

Þess vegna er betra að gera eitthvað einfalt eins og NFS netþjón. Kubernetes getur unnið með þeim, þú getur tengt möppu undir NFS netþjón - forritið þitt er alveg eins og staðbundin skrá. Á sama tíma, náttúrulega, þú þarft að skilja að aftur, þú þarft að gera eitthvað með NFS þinn, þú þarft að skilja að stundum getur það orðið óaðgengilegt og íhuga spurninguna um hvað þú munt gera í þessu tilfelli. Kannski ætti að afrita það einhvers staðar á sérstakri vél.

Næsti liður sem ég talaði um er hvað á að gera ef forritið þitt býr til einhverjar skrár meðan á notkun stendur. Til dæmis, þegar það byrjar, býr það til einhverja kyrrstæða skrá, sem er byggð á einhverjum upplýsingum sem forritið fær aðeins þegar það er ræst. Þvílík stund. Ef það er ekki mikið af slíkum gögnum, þá þarftu alls ekki að nenna, settu bara upp þetta forrit fyrir þig og vinnðu. Eina spurningin hér er hvað, sjáðu. Mjög oft, alls konar arfleifð kerfi, eins og WordPress og svo framvegis, sérstaklega með breyttum einhvers konar sniðugum viðbótum, snjöllum PHP forriturum, þeir vita oft hvernig á að gera það þannig að þeir búa til einhvers konar skrá fyrir sig. Í samræmi við það býr einn til eina skrá, sú seinni býr til aðra skrá. Þau eru ólík. Jafnvægi á sér stað í Kubernetes klasa viðskiptavinarins einfaldlega fyrir tilviljun. Í samræmi við það kemur í ljós að þeir vita ekki hvernig á að vinna saman til dæmis. Annar gefur einni upplýsingar, hinn gefur notandanum aðrar upplýsingar. Þetta er eitthvað sem þú ættir að forðast. Það er, í Kubernetes er tryggt að allt sem þú setur af stað geti virkað í mörgum tilfellum. Vegna þess að Kubernetes er áhrifamikill hlutur. Í samræmi við það getur hann hreyft hvað sem er, hvenær sem hann vill, án þess að spyrja neinn. Þess vegna þarftu að treysta á þetta. Allt sem er hleypt af stokkunum í einu tilviki mun fyrr eða síðar mistakast. Því fleiri fyrirvara sem þú hefur, því betra. En aftur segi ég, ef þú átt nokkrar slíkar skrár, þá geturðu sett þær beint undir þig, þær vega lítið magn. Ef það eru aðeins fleiri af þeim ættirðu líklega ekki að ýta þeim inn í ílátið.

Ég myndi ráðleggja því að það sé svo dásamlegur hlutur í Kubernetes, þú getur notað hljóðstyrk. Einkum er rúmmál af gerðinni tóm stj. Það er, það er bara að Kubernetes mun sjálfkrafa búa til möppu í þjónustumöppunum sínum á netþjóninum þar sem þú byrjaðir. Og hann mun gefa þér það svo að þú getir notað það. Það er aðeins eitt mikilvægt atriði. Það er að segja að gögnin þín verða ekki geymd inni í gámnum, heldur á hýslinum sem þú keyrir á. Þar að auki getur Kubernetes stjórnað slíkum tómum skjölum við venjulega uppsetningu og getur stjórnað hámarksstærð þeirra og ekki leyft að fara yfir hana. Eini punkturinn er sá að það sem þú hefur skrifað í tómu skránni tapast ekki við endurræsingu pods. Það er, ef belgurinn þinn dettur fyrir mistök og rís aftur, munu upplýsingarnar í tómu skránni ekki fara neitt. Hann getur notað það aftur við nýja byrjun - og það er gott. Ef fræbelgur þinn fer einhvers staðar, þá fer hann náttúrulega án gagna. Það er að segja, um leið og belgurinn frá hnútnum þar sem hann var settur af stað með tóma skrá hverfur, þá er tómum skrá eytt.

Hvað er annars gott við tóma dir? Til dæmis er hægt að nota það sem skyndiminni. Við skulum ímynda okkur að forritið okkar búi til eitthvað á flugu, gefur það notendum og geri það í langan tíma. Þess vegna býr forritið til dæmis til og gefur það til notenda, og geymir það um leið einhvers staðar, þannig að næst þegar notandinn kemur fyrir það sama, verður fljótlegra að gefa það strax búið til. Hægt er að biðja Kubernetes um að búa til tóma skrá í minni. Og þannig geta skyndiminni þín almennt virkað á leifturhraða - hvað varðar aðgangshraða á disknum. Það er að segja, þú ert með tóma skrá í minni, í stýrikerfinu er það geymt í minni, en fyrir þig, fyrir notandann inni í belgnum, lítur það út eins og staðbundin skrá. Þú þarft ekki forritið til að kenna neina töfra sérstaklega. Þú tekur bara og setur skrána þína beint í möppu, en í raun í minni á stýrikerfinu. Þetta er líka mjög þægilegur eiginleiki hvað varðar Kubernetes.

Hvaða vandamál á Minio við? Helsta vandamálið við Minio er að til þess að þetta virki þarf það að vera í gangi einhvers staðar og það verður að vera til einhvers konar skráarkerfi, það er að segja geymsla. Og hér lendum við í sömu vandamálum og Ceph hefur. Það er, Minio verður að geyma skrárnar sínar einhvers staðar. Það er einfaldlega HTTP viðmót fyrir skrárnar þínar. Þar að auki er virknin greinilega lakari en Amazon S3. Áður gat það ekki veitt notandanum almennilega heimild. Núna, eftir því sem ég best veit, getur það þegar búið til fötur með mismunandi heimildum, en aftur sýnist mér að aðalvandamálið sé sem sagt undirliggjandi geymslukerfi í lágmarki.

Hvernig hefur Empty dir í minni áhrif á mörkin? Hefur ekki áhrif á takmörk á nokkurn hátt. Það liggur í minningu gestgjafans, en ekki í minningu ílátsins þíns. Það er, ílátið þitt sér ekki tóma skrána í minni sem hluta af uppteknu minni þess. Gestgjafinn sér þetta. Samkvæmt því, já, frá sjónarhóli kubernetes, þegar þú byrjar að nota þetta, þá væri gott að skilja að þú ert að verja hluta af minni þínu í tómt dir. Og í samræmi við það, skildu að minni getur klárast ekki aðeins vegna forrita, heldur einnig vegna þess að einhver skrifar á þessar tómu stjórnendur.

Cloudnativeness

Og síðasta undirefnið er það sem Cloudnative er. Hvers vegna er þörf á því? Cloudnativeness og svo framvegis.

Það er, þessi forrit sem eru fær og skrifuð til að vinna í nútíma skýjainnviði. En í raun hefur Cloudnative annan slíkan þátt. Að þetta sé ekki bara forrit sem tekur mið af öllum kröfum nútíma skýjainnviða, heldur kunni líka að vinna með þessa nútíma skýjainnviði, nýta kosti og galla þess að það virkar í þessum skýjum. Ekki bara fara yfir borð og vinna í skýjunum, heldur nýta kosti þess að vinna í skýinu.

Tökum bara Kubernetes sem dæmi. Forritið þitt er í gangi í Kubernetes. Forritið þitt getur alltaf, eða öllu heldur stjórnendur forritsins, alltaf búið til þjónustureikning. Það er reikningur fyrir heimild í Kubernetes sjálfum á netþjóni sínum. Bættu við nokkrum réttindum sem við þurfum þar. Og þú getur fengið aðgang að Kubernetes úr forritinu þínu. Hvað getur þú gert á þennan hátt? Til dæmis, frá forritinu, fáðu gögn um hvar önnur forrit þín, önnur svipuð tilvik eru staðsett, og saman einhvern veginn þyrping ofan á Kubernetes, ef slík þörf er á.

Aftur áttum við bókstaflega mál nýlega. Við erum með einn stjórnandi sem fylgist með biðröðinni. Og þegar einhver ný verkefni birtast í þessari biðröð fer það til Kubernetes - og inni í Kubernetes býr það til nýjan pod. Gefur þessum belg eitthvað nýtt verkefni og innan ramma þessa belgs framkvæmir belgurinn verkefnið, sendir svar til stjórnandans sjálfs og stjórnandinn gerir svo eitthvað við þessar upplýsingar. Til dæmis, það bætir við gagnagrunni. Það er aftur, þetta er plús við þá staðreynd að forritið okkar keyrir í Kubernetes. Við getum notað innbyggðu Kubernetes virknina sjálfa til að stækka einhvern veginn og gera virkni forritsins okkar þægilegri. Það er, ekki fela einhvers konar töfra um hvernig á að ræsa forrit, hvernig á að ræsa starfsmann. Í Kubernetes sendir þú einfaldlega beiðni í appinu ef forritið er skrifað í Python.

Sama gildir ef við förum lengra en Kubernetes. Við erum með Kubernetes okkar í gangi einhvers staðar - það er gott ef það er í einhvers konar skýi. Aftur, við getum notað, og ættum jafnvel, að ég tel, að nota getu skýsins sjálfs þar sem við erum að keyra. Frá grunnþáttunum sem skýið gefur okkur. Jafnvægi, það er að segja, við getum búið til skýjajafnvægi og notað þá. Þetta er bein kostur við það sem við getum notað. Vegna þess að skýjajafnvægi, í fyrsta lagi, einfaldlega fjarlægir okkur ábyrgð á heimskulega hvernig það virkar, hvernig það er stillt. Auk þess er það mjög þægilegt, vegna þess að venjulegir Kubernetes geta samþætt skýjum.

Sama gildir um skala. Venjulegur Kubernetes getur samþætt við skýjaveitur. Veit hvernig á að skilja að ef hnúturinn klárast, það er að segja að hnútarýmið er uppurið, þá þarftu að bæta við - Kubernetes sjálft mun bæta nýjum hnútum við þyrpinguna þína og byrja að ræsa fræbelg á þá. Það er að segja, þegar álagið þitt kemur, byrjar aflinn að fjölga. Þegar hnúðarnir í þyrpingunni klárast fyrir þessa belg, setur Kubernetes nýja hnúta og í samræmi við það getur fjöldi belgjanna enn fjölgað. Og það er mjög þægilegt. Þetta er beint tækifæri til að stækka þyrpinguna á flugu. Ekki mjög hratt, í þeim skilningi að það er ekki sekúnda, það er meira eins og mínúta til að bæta við nýjum hnútum.

En af minni reynslu er þetta aftur það svalasta sem ég hef séð. Þegar Cloudnative þyrpingin stækkaði miðað við tíma dags. Þetta var bakendaþjónusta sem var notuð af fólki í bakvinnslunni. Það er að segja að þeir mæta til vinnu klukkan 9, byrja að skrá sig inn í kerfið og í samræmi við það byrjar Cloudnative þyrpingin, þar sem þetta er allt í gangi, að bólgna út og setur nýja pod í loftið þannig að allir sem koma til starfa geta unnið með forritið. Þegar þeir fara úr vinnu klukkan 8 eða 6 taka Kubernetes klasarnir eftir því að enginn notar forritið lengur og byrja að minnka. Allt að 30 prósenta sparnaður er tryggður. Það virkaði í Amazon á þeim tíma; á þeim tíma var enginn í Rússlandi sem gat gert það svo vel.

Ég skal segja þér það beint, sparnaðurinn er 30 prósent einfaldlega vegna þess að við notum Kubernetes og nýtum möguleika skýsins. Nú er hægt að gera þetta í Rússlandi. Ég mun auðvitað ekki auglýsa fyrir neinum, en við skulum bara segja að það eru veitendur sem geta gert þetta, útvegað það beint úr kassanum með hnappi.

Það er eitt atriði að lokum sem ég vil líka vekja athygli á. Til þess að forritið þitt, innviðir þínir séu Cloudnative, er skynsamlegt að byrja loksins að aðlaga nálgunina sem kallast Infrastructure as a Code. Það er, þetta þýðir að forritið þitt, eða öllu heldur uppbyggingin þín, þarf nákvæmlega það sama og kóðinn Lýstu þínum umsókn, viðskiptarökfræði þín í formi kóða. Og vinna með það sem kóða, það er að prófa hann, rúlla honum út, geyma hann í git, setja CICD á hann.

Og þetta er einmitt það sem gerir þér í fyrsta lagi kleift að hafa alltaf stjórn á innviðum þínum, að skilja alltaf í hvaða ástandi það er. Í öðru lagi, forðastu handvirkar aðgerðir sem valda villum. Í þriðja lagi, forðastu einfaldlega það sem kallast velta, þegar þú þarft stöðugt að framkvæma sömu handvirku verkefnin. Í fjórða lagi gerir það þér kleift að jafna þig miklu hraðar ef bilun kemur upp. Í Rússlandi, í hvert skipti sem ég tala um þetta, er alltaf mikill fjöldi fólks sem segir: "Já, það er ljóst, en þú hefur aðferðir, í stuttu máli, það er engin þörf á að laga neitt." En það er satt. Ef eitthvað er bilað í innviðum þínum, þá frá sjónarhóli Cloudnative nálgunarinnar og frá sjónarhóli innviða sem kóða, frekar en að laga það, fara á netþjóninn, finna út hvað er bilað og laga það, er það auðveldara til að eyða þjóninum og búa hann til aftur. Og allt þetta mun ég endurheimta.

Nánar er fjallað um öll þessi mál á Kubernetes myndbandsnámskeið: Junior, Basic, Mega. Með því að fylgja hlekknum geturðu kynnt þér dagskrá og skilyrði. Það þægilega er að þú getur náð góðum tökum á Kubernetes með því að læra heima eða vinna í 1-2 tíma á dag.

Heimild: www.habr.com

Kröfur til að þróa forrit í Kubernetes