Gaur aplikazioak nola idatzi eta zeintzuk diren zure aplikazioak Kubernetesen ondo funtziona dezan hitz egiteko asmoa dut. Aplikazioarekin buruhausterik egon ez dadin, horren inguruan "cratches"rik asmatu eta eraiki beharrik izan ez dadin, eta dena Kubernetesek berak nahi zuen moduan funtzionatzen du.
Hitzaldi hau "" Arratsaldeko Eskolako hitzaldi teoriko irekiak ikus ditzakezu . Bideoa baino testua nahiago dutenentzat, artikulu hau prestatu dugu.
Nire izena Pavel Selivanov da, gaur egun Mail.ru Cloud Solutions-en DevOps ingeniari nagusia naiz, hodeiak egiten ditugu, kudeaketa kubernetak egiten ditugu eta abar. Nire zereginak orain garapenean laguntza, hodei hauek zabaltzea, idazten ditugun aplikazioak zabaltzea eta erabiltzaileei eskaintzen dizkiegun tresnak zuzenean garatzea dira.
DevOps egiten aritu naiz, uste dut azkenekoa, ziurrenik, hiru urte. Baina, printzipioz, orain bost urte inguru daramatzat DevOps-ek egiten duena egiten. Hori baino lehen, administratzaile gauzetan parte hartzen nuen gehienbat. Aspaldi hasi nintzen Kubernetesekin lanean; ziurrenik lau urte inguru pasatu dira horrekin lanean hasi nintzenetik.
Orokorrean, Kubernetes 1.3 bertsioa zenean hasi nintzen, ziurrenik, eta agian 1.2koa, oraindik hastapenetan zegoenean. Orain jada ez dago hastapenetan, eta bistakoa da merkatuan eskari handia dagoela Kubernetes egin nahi duten ingeniarientzat. Eta enpresek eskaera oso handia dute horrelako pertsonentzat. Horregatik, hain zuzen ere, hitzaldi hau agertu zen.
Hitz egingo dudanaren planoari buruz hitz egiten badugu, honela dirudi, parentesi artean (TL;DR) idatzita dago - “luzeegia; ez irakurri". Nire gaurko aurkezpena zerrenda amaigabez osatuta egongo da.
Izan ere, niri ez zaizkit gustatzen horrelako aurkezpenak egiten direnean, baina horrelako gaia da, aurkezpen hau prestatzen ari nintzelarik ez nuen asmatu informazio hori modu ezberdinean nola antolatu.
Oro har, informazio hori “ctrl+c, ctrl+v” delako, besteak beste, DevOps atalean dagoen gure Wikitik, non garatzaileentzako eskakizunak idatzi ditugu: “guys, so that we launch your application in. Kubernetes, horrela izan beharko luke".
Horregatik, aurkezpena hain zerrenda handia izan zen. Barkatu. Ahalik eta gehien kontatzen saiatuko naiz, ahal bada aspergarria izan ez dadin.
Zer ikusiko dugu orain:
- hauek dira, lehenik, erregistroak (aplikazioen erregistroak?), zer egin horiekin Kubernetesen, zer egin, zer izan behar duten;
- zer egin Kubernetes-en konfigurazioekin, zeintzuk diren Kubernetesen aplikazio bat konfiguratzeko modurik onenak eta txarrenak;
- Hitz egin dezagun orokorrean irisgarritasun egiaztapenak zer diren, nolakoak izan behar duten;
- hitz egin dezagun itzalaldi dotorea zer den;
- hitz egin dezagun berriz baliabideei buruz;
- Ukitu dezagun beste behin datuen biltegiratzearen gaia;
- eta amaieran esango dizut zein den hodeiko jatorrizko aplikazio misteriotsu hau. Cloudnativeness, termino honen adjektibo gisa.
Erregistroak
Erregistroetatik hastea proposatzen dut, erregistro hauek Kubernetesen non sartu behar diren. Orain Kubernetesen aplikazio bat abiarazi duzu. Klasikoen arabera, lehen aplikazioek beti idazten zituzten erregistroak fitxategi batean nonbait. Aplikazio txarrek erregistroak idatzi zituzten aplikazioa abiarazi zuen garatzailearen hasierako direktorioko fitxategi batean. Aplikazio onek erregistroak idatzi zituzten fitxategi batean nonbait /var/log.
Horren arabera, gainera, administratzaile onek beren azpiegituretan gauza batzuk konfiguratuta zituzten erregistro hauek biratu ditzaketen - rsyslog bera, erregistro hauek aztertzen dituena eta zerbait gertatzen zaienean, asko daude, babeskopiak sortzen ditu, erregistroak bertan jartzen ditu. , fitxategi zaharrak ezabatzen ditu, aste bat baino gehiago, sei hilabete eta batzuk gehiago. Teorian, xedapenak izan beharko genituzke aplikazioak erregistroak idazten dituenez, ekoizpen-zerbitzarietan (borroka-zerbitzarietan?) lekua agortu ez dadin. Eta, horren arabera, produkzio osoa ez zen eten enborengatik.
Kubernetesen mundura mugitzen garenean eta bertan gauza bera exekutatzen dugunean, errepara diezaiokezun lehenengo gauza da jendeak, fitxategi batean erregistroak idazten dituen heinean, idazten jarraitzen duela.
Ematen du Kubernetes-i buruz hitz egiten badugu, docker edukiontzi batetik erregistroak nonbait idazteko leku egokia aplikaziotik Stdout/Stderr izenekora idaztea besterik ez da, hau da, sistema eragilearen irteera-korronte estandarrak. errore estandarraren irteera. Hau da erregistroak printzipioz Docker-en eta zehazki Kubernetis-en jartzeko modurik zuzenena, errazena eta logikoena. Zure aplikazioak Stdout/Stderr-en erregistroak idazten baditu, Docker eta Kubernetes gehigarriaren esku dago erregistro horiekin zer egin erabakitzea. Docker-ek bere fitxategi bereziak JSON formatuan eraikiko ditu lehenespenez.
Hemen galdera sortzen da, zer egingo duzu gero erregistro hauekin? Biderik errazena argi dago, egiteko gaitasuna dugu kubectl logs eta begiratu “leka” hauen erregistro hauek. Baina, ziurrenik, hau ez da oso aukera ona - beste zerbait egin behar da erregistroekin.
Oraingoz, hitz egin dezagun aldi berean, erregistroen gaia ukitu dugunez, erregistroen itxura izan behar duen gauza bati buruz. Hau da, hau ez da zuzenean Kubernetes-i aplikatzen, baina erregistroekin zer egin pentsatzen hasten garenean, ondo legoke hau ere pentsatzea.
Tresna moduko bat behar dugu, modu adiskidetsuan, gure docker-ak bere fitxategietan jartzen dituen log hauek hartu eta nonbait bidaliko dituena. Orokorrean, Kubernetesen barruan agente motaren bat abiarazten dugu normalean DaemonSet baten moduan: erregistro-biltzailea, Docker-ek biltzen dituen erregistroak non dauden esaten dena. Eta bilketa-agente honek besterik gabe hartzen ditu, agian nolabait analizatu ere egiten ditu bidean, agian meta-informazio gehigarri batekin aberasten ditu eta, azken finean, nonbait gordetzera bidaltzen ditu. Dagoeneko aldaerak posible dira bertan. Ohikoena Elasticsearch izango da ziurrenik, non erregistroak gorde ditzakezu eta handik eroso berreskura ditzakezu. Ondoren, eskaera bat erabiliz, Kibana erabiliz, adibidez, haietan oinarritutako grafikoak eraiki, haietan oinarritutako alertak eraiki eta abar.
Ideia garrantzitsuena, berriro errepikatu nahi dut, Dockerren barruan, bereziki Kubernetesen barruan, zure erregistroak fitxategi batean gordetzea oso ideia txarra da.
Lehenik eta behin, zaila da erregistroak fitxategi batean edukiontzi barruan sartzea. Lehenik edukiontzira sartu behar duzu, bertan exekutatu eta gero erregistroak begiratu. Hurrengo puntua da fitxategi batean erregistroak badituzu, edukiontziek normalean ingurune minimalista izan ohi dutela eta ez dagoela normalean erregistroekin lan egiteko behar diren utilitaterik. Ehortzi, begiratu, ireki testu-editore batean. Hurrengo momentua edukiontzi baten barruan fitxategi batean erregistroak ditugunean, edukiontzi hau ezabatzen bada, ulertzen duzu, erregistroak harekin batera hilko dira. Ondorioz, edukiontzia berrabiarazte batek esan nahi du ez dagoela erregistro gehiago. Berriz ere, aukera txarra.
Eta azken puntua da edukiontzien barruan zure aplikazioa eduki ohi duzula eta kitto - abian den prozesu bakarra izaten da. Ez da batere hitz egiten zure erregistroekin fitxategiak biratuko lituzkeen prozesuei buruz. Erregistroak fitxategi batean idazten hasi bezain pronto, horrek esan nahi du, barkatu, produkzio zerbitzaria galtzen hasiko garela. Lehenik eta behin, zailak direlako aurkitzea, inork ez ditu haien jarraipena egiten, eta inork ez ditu kontrolatzen - horren arabera, fitxategia etengabe hazten da zerbitzariko lekua besterik gabe agortu arte. Horregatik, berriro diot Docker-en, bereziki Kubernetes-en, fitxategi batean saioa egitea ideia txarra dela.
Hurrengo puntua, hemen berriro hitz egin nahi dut: erregistroen gaia ukitzen ari garenez, ondo legoke erregistroak nola begiratu behar duten hitz egitea haiekin lan egitea erosoa izan dadin. Esan bezala, gaia ez dago zuzenean Kubernetesekin erlazionatuta, baina oso ondo dago DevOps gaiarekin. Garapen kulturaren eta bi sail ezberdin horien arteko adiskidetasunaren gaiari buruz - Dev eta Ops, denak eroso egon daitezen.
Horrek esan nahi du, hoberena, gaur egun, erregistroak JSON formatuan idatzi behar direla. Zure aplikazio ulertezin bat baduzu, erregistroak formatu ulertezinetan idazten badituzu, inprimaketa motaren bat edo horrelako zerbait txertatzen duzulako, bada garaia nolabaiteko marko bat Googlen bilatzeko, erregistro arrunta ezartzeko aukera ematen duen bilgarri moduko bat; gaitu bertan JSON-en erregistro-parametroak, JSON formatu sinplea delako, eta analizatzea erraza da.
Zure JSONak irizpide batzuen arabera funtzionatzen ez badu, inork ez daki zer, idatzi erregistroak, gutxienez, analizatu daitekeen formatuan. Hemen, hobeto esanda, pentsatzea merezi du, adibidez, edukiontzi mordoa edo nginx-ekin prozesu besterik ez baduzu exekutatzen ari bazara eta bakoitzak bere erregistro-ezarpenak baditu, ziurrenik badirudi oso deserosoa izango zaizula. analizatu. Nginx instantzia berri bakoitzeko zure analizatzailea idatzi behar duzulako, erregistroak ezberdin idazten dituztelako. Berriz ere, ziurrenik merezi zuen pentsatzea nginx instantzia horiek guztiek erregistro-konfigurazio bera zutela eta beren erregistro guztiak guztiz uniformeki idatzi zituzten. Gauza bera aplikatzen da erabat aplikazio guztietan.
Azkenean, erregaia ere gehitu nahi diot suari, hobe da lerro anitzeko formatuko erregistroak saihestu behar direla. Hona hemen kontua, noizbait erregistro-biltzaileekin lan egin baduzu, ziurrenik zer agintzen dizuten ikusi duzu, lerro anitzeko erregistroekin lan egin dezaketela, nola bildu jakin, etab. Izan ere, nire ustez, gaur egun biltzaile bakar batek ere ezin ditu biltzeko linea anitzeko erregistroak normal, guztiz eta akatsik gabe. Era humanoan, erosoa eta akatsik gabekoa izan dadin.
Baina pila-traza lerro anitzeko erregistroak dira beti eta horiek nola saihestu. Hemen galdera da erregistro bat gertaera baten erregistroa dela, eta stactrace ez dela benetan erregistro bat. Erregistroak biltzen baditugu eta Elasticsearch-en nonbait jartzen baditugu eta ondoren grafikoak marrazten baditugu, zure webgunean erabiltzaileen jardueren txosten batzuk eraikitzen baditugu, orduan pilaren arrastoa lortzen duzunean, ustekabeko zerbait gertatzen ari dela esan nahi du zure aplikazioan kudeatu gabeko egoera bat. Eta zentzuzkoa da pila-arrasto bat automatikoki kargatzea nonbait haien jarraipena egin dezakeen sistema batera.
Hau softwarea da (Sentry bera) pila-trazarekin lan egiteko bereziki egina. Berehala sor ditzake zeregin automatikoak, norbaiti esleitu, stacttraces gertatzen direnean abisatu, stacttraces hauek mota baten arabera taldekatu eta abar. Printzipioz, ez du zentzu handirik stactraces buruz hitz egiteak erregistroei buruz hitz egiten dugunean, hauek, azken finean, helburu desberdinak dituzten gauza desberdinak baitira.
konfigurazioa
Jarraian, Kubernetesen konfigurazioari buruz hitz egingo dugu: zer egin horrekin eta nola konfiguratu behar diren Kubernetes barruko aplikazioak. Orokorrean, normalean esaten dut Docker ez dela edukiontziei buruz. Denek dakite Docker edukiontziei buruzkoa dela, baita Dockerrekin asko lan egin ez dutenek ere. Berriro diot, Docker ez da edukiontziei buruz.
Docker, nire ustez, estandarrei buruzkoa da. Eta ia denetarako estandarrak daude: zure aplikazioa eraikitzeko estandarrak, zure aplikazioa instalatzeko estandarrak.
Eta gauza hau -lehen erabili genuen, edukiontzien etorrerarekin bereziki ezaguna egin zen - ENV (ingurumen) aldagaiak deitzen dira, hau da, zure sistema eragilean dauden ingurune-aldagaiak. Oro har, zure aplikazioa konfiguratzeko modu aproposa da, zeren eta JAVA, Python, Go, Perl, Jainkoak ez dezala aplikazioak badituzu eta guztiek datu-basearen ostalaria, datu-basearen erabiltzailea, datu-basearen pasahitzaren aldagaiak irakur ditzakete, orduan aproposa da. Datu-basearen planean lau hizkuntza desberdinetako aplikazioak dituzu modu berean konfiguratuta. Ez dago konfigurazio ezberdin gehiago.
Dena konfigura daiteke ENV aldagaiak erabiliz. Kubernetes-i buruz hitz egiten dugunean, ENV aldagaiak Deployment barruan deklaratzeko modu bikaina dago. Horren arabera, datu sekretuez ari bagara, berehala ENV aldagaietako datu sekretuak (datu-baseetarako pasahitzak, etab.) sekretu batera eraman ditzakegu, sekretu multzo bat sortu eta Deployment-eko ENV deskribapenean adierazi ez dugula zuzenean deklaratzen ari. aldagai honen balioa eta datu-basearen pasahitz aldagai honen balioa sekretutik irakurriko dira. Hau Kubernetes-en portaera estandarra da. Eta hau da zure aplikazioak konfiguratzeko aukerarik egokiena. Kode mailan, berriro ere hau garatzaileei aplikatzen zaie. DevOps bazara, hauxe galdetu dezakezu: "Mutilak, irakatsi zure aplikazioari ingurune-aldagaiak irakurtzen. Eta denok izango gara pozik».
Enpresako guztiek izendun ingurune-aldagai berdinak irakurtzen badituzte, ezin hobea da. Ez dadin gertatu batzuk postgres datu-basearen zain egotea, beste batzuk datu-basearen izenaren zain egotea, beste batzuk beste zerbaiten zain egotea, beste batzuk nolabaiteko dbn baten zain egotea, beraz, horren arabera, uniformetasuna egon dadin.
Arazoa ingurune-aldagai asko dituzunean, Deployment ireki besterik ez duzunean sortzen da, eta bostehun inguru-aldagai lerro daude. Kasu honetan, ingurune-aldagaiak gainditzen dituzu, eta ez duzu zure burua torturatu beharrik. Kasu honetan, zentzuzkoa izango litzateke konfigurazioak erabiltzen hastea. Hau da, trebatu zure aplikazioa konfigurazioak erabiltzeko.
Galdera bakarra da konfigurazioak ez direla uste duzuna. Config.pi ez da erabiltzeko erosoa den konfigurazioa. Edo zure formatuan dauden konfigurazio batzuk, bestela opariak - hau ere ez da esan nahi dudan konfigurazioa.
Hitz egiten ari naizena formatu onargarrietako konfigurazioa da, hau da, estandarrik ezagunena .yaml estandarra da. Argi dago nola irakurri behar den, gizakiak irakurtzeko modukoa da, argi dago aplikaziotik nola irakurri behar den.
Horren arabera, YAMLaz gain, JSON ere erabil dezakezu, adibidez, analizatzea YAML bezain erosoa da hortik aplikazioaren konfigurazioa irakurtzeko. Jendeak irakurtzea nabarmen deserosoagoa da. Formatua probatu dezakezu, a la ini. Nahiko erosoa da irakurtzea, giza ikuspuntutik, baina automatikoki prozesatzea deserosoa izan daiteke, izan ere, inoiz zure konfigurazioak sortu nahi badituzu, ini formatua sortzea deserosoa izan daiteke.
Baina, nolanahi ere, aukeratzen duzun formatua edozein dela ere, kontua da Kubernetesen ikuspuntutik oso erosoa dela. Zure konfigurazio osoa Kubernetes barruan jar dezakezu, ConfigMap-en. Eta gero hartu konfigurazio-mapa hau eta eskatu zure pod barruan muntatzeko direktorio zehatz batean, non zure aplikazioak konfigurazio-mapa honetako konfigurazioa irakurriko duen fitxategi bat besterik ez balitz bezala. Hau da, hain zuzen ere, zure aplikazioan konfigurazio-aukera asko dituzunean egitea ona dena. Edo egitura konplexu bat besterik ez da, habia dago.
Konfigurazio-mapa bat baduzu, oso ondo irakatsi diezaiokezu zure aplikazioari, adibidez, konfigurazio-mapa muntatzen den fitxategian automatikoki egiten diren aldaketen jarraipena egiten eta, gainera, zure aplikazioa automatikoki berriro kargatu konfigurazioak aldatzen direnean. Oro har, aukera ezin hobea izango litzateke.
Berriz ere, honetaz hitz egin nuen dagoeneko: informazio sekretua ez dago konfigurazioan, informazio sekretua ez dago aldagaietan, informazio sekretua ez dago sekretuetan. Hortik aurrera, konektatu informazio sekretu hau diplomaziara. Normalean Kubernetesen objektuen, inplementazioaren, konfigurazio-mapak eta zerbitzuen deskribapen guztiak gordetzen ditugu git-en. Horren arabera, datu-baseari pasahitza git-en jartzea, nahiz eta zure git izan, enpresan barnean duzuna, ideia txarra da. Zeren eta, gutxienez, git-ek dena gogoratzen du eta hortik pasahitzak kentzea ez baita hain erraza.
Osasun azterketa
Hurrengo puntua Osasun egiaztapena izeneko gauza hau da. Oro har, Osasun egiaztapena zure aplikazioa funtzionatzen ari dela egiaztatzea besterik ez da. Aldi berean, gehienetan web-aplikazio jakin batzuei buruz ari gara, eta, horren arabera, osasun-kontrolaren ikuspegitik (hobe da hemen eta gehiago ez itzultzea) URL berezi batzuk izango dira, horrela prozesatzen dituztenak. estandar bat, normalean egiten dute /health.
URL honetara sartzean, horren arabera, gure aplikazioak "bai, ados, dena ondo dago niretzat, 200" edo "ez, dena ez dago ondo niretzat, 500 bat". Horren arabera, gure aplikazioa http ez bada, ez web aplikazio bat, orain deabru mota bati buruz ari gara, osasun-kontrolak nola egin asma dezakegu. Hau da, ez da beharrezkoa, aplikazioa http ez bada, dena funtzionatzen du osasun azterketarik gabe eta hori ezin da inola ere egin. Aldian-aldian informazio batzuk egunera ditzakezu fitxategian, zure deabruarentzat komando bereziren bat sor dezakezu, adibidez, daemon status, "bai, dena ondo dago, deabrua lanean ari da, bizirik dago" esango duena.
Zertarako da? Lehenengo eta agerikoena da ziurrenik zergatik behar den osasun-kontrola - aplikazioa funtzionatzen ari dela ulertzeko. Esan nahi dut, ergelkeria besterik ez da, orain igota dagoenean, funtzionatzen ari dela ematen du, beraz, funtzionatzen ari dela ziur egon zaitezke. Eta ematen du aplikazioa martxan dagoela, edukiontzia martxan dagoela, instantzia funtzionatzen ari dela, dena ondo dagoela - eta orduan erabiltzaileek telefono-zenbaki guztiak moztu dituzte dagoeneko laguntza teknikotik eta esaten dute "zer zara..., zu lo hartu, ezer ez dabil».
Osasun-kontrola erabiltzailearen ikuspuntutik funtzionatzen duela ikusteko modu bat besterik ez da. Metodoetako bat. Jar dezagun horrela. Kubernetes-en ikuspuntutik, hau ere aplikazioa noiz hasten den ulertzeko modu bat da, ulertzen baitugu aldea dagoela edukiontzia noiz abiarazi, sortu eta hasi zen eta aplikazioa zuzenean edukiontzi honetan abiarazi zenean. Zeren eta batez besteko java aplikazioren bat hartzen badugu eta kaian abiarazten saiatzen bagara, orduan berrogei segundoz, edo minutu batez, edo baita hamar ere, ondo has daiteke. Kasu honetan, gutxienez bere portuak jo ditzakezu, ez du han erantzungo, hau da, oraindik ez dago prest trafikoa jasotzeko.
Berriz ere, osasun azterketa baten laguntzaz eta hona bueltatzen ari garela lagunduta, Kubernetesen uler dezakegu edukiontzia aplikazioan igo ez ezik, aplikazioa bera hasi dela, dagoeneko erantzuten duela. osasun-egiaztapena, horrek esan nahi du hara trafikoa bidal dezakegula.
Orain hitz egiten ari naizena Kubernetes-en Prestasun/bizitasun-probak deitzen da; horren arabera, gure presttasun-probak aplikazioaren erabilgarritasunaz arduratzen dira balantzean. Hau da, aplikazioan prest dauden probak egiten badira, dena ondo dago, bezeroen trafikoa aplikaziora doa. Prestakuntza-probak egiten ez badira, aplikazioak ez du parte hartzen, instantzia jakin honek ez du orekan parte hartzen, orekatzetik kentzen da, bezeroen trafikoa ez da isurtzen. Horren arabera, Kubernetesen Liveness probak behar dira, aplikazioa trabatuta geratzen bada, berrabiarazi ahal izateko. Bizitasun-probak Kubernetesen deklaratutako aplikazio batean ez badu funtzionatzen, orduan aplikazioa ez da orekatik kentzen, berrabiarazi egiten da.
Eta hona hemen aipatu nahiko nukeen puntu garrantzitsu bat: ikuspuntu praktikotik, prestutasun-proba maizago erabiltzen da eta bizi-proba baino maizago behar da. Hau da, presttasun eta bizitasun probak pentsamendurik gabe deklaratzea, Kubernetes-ek hori egin dezakeelako eta erabil dezagun egin dezakeen guztia, ez da oso ideia ona. Zergatik azalduko dut. Probetan bigarren puntua denez, ideia ona litzateke osasun-kontroletan azpiko zerbitzua egiaztatzea. Horrek esan nahi du informazioren bat ematen duen web aplikazio bat baduzu, eta horrek, berez, nonbaitetik hartu behar duela. Datu-base batean, adibidez. Beno, REST API honetan sartzen den informazioa datu-base berean gordetzen du. Orduan, horren arabera, zure osasun-kontrolak slashhealth-ekin harremanetan jarritako moduan erantzuten badu, aplikazioak "200, ados, dena ondo dago" esaten du eta, aldi berean, zure aplikazioaren datu-basea eskuraezina da, eta osasun-kontrolaren aplikazioak "200, ados, dena ondo dago". ” - Hau osasun-kontrol txarra da. Ez da horrela funtzionatu behar.
Hau da, zure eskaera, eskaera bat datorrenean /health, ez du erantzuten, “200, ok”, lehenik, adibidez, datu-basera joaten da, harekin konektatzen saiatzen da, oso oinarrizko zerbait egiten du bertan, bat hautatzeko, adibidez, konexio bat dagoela egiaztatzen du. datu-basea eta datu-basea kontsulta dezakezu. Hau guztia arrakastatsua izan bada, orduan erantzuna "200, ados". Arrakasta ez bada, errore bat dagoela esaten du, datu-basea ez dago erabilgarri.
Hori dela eta, zentzu honetan, berriro itzultzen naiz presttasuna/bizitasun probetara - zergatik behar duzun ziurrenik presttasun-proba bat, baina bizitasun-proba bat zalantzan dago. Osasun-kontrolak esan berri dudan bezala deskribatzen badituzu, instantzia zatian ez dagoela eskuragarri geratuko da.в или со всех instancedatu-base batean, adibidez. Prestakuntza-proba bat deklaratu zenuenean, gure osasun-egiaztapenak huts egiten hasi ziren, eta, ondorioz, datu-basea eskuragarri ez dagoen aplikazio guztiak, orekatzetik desaktibatuta geratzen dira eta, hain zuzen ere, "zintzilikatu" egoera baztertu batean eta datu-baseak noiz arte itxaron. lana.
Bizitasun-proba bat deklaratu badugu, imajinatu gure datu-basea hautsi egin dela eta zure Kubernetes-en guztiaren erdia berrabiarazten hasten da bizitasun-probak huts egiten duelako. Horrek esan nahi du berrabiarazi behar duzula. Hau ez da batere nahi duzuna, praktikan esperientzia pertsonala ere izan nuen. JSn idatzitako txat-aplikazio bat genuen eta Mongo datu-base batean sartzen zen. Eta arazoa zen Kubernetes-ekin nire lanaren hasieran zegoela, proben prestutasuna eta bizitasuna deskribatu genuela Kubernetesek egin dezakeen printzipioaren arabera, beraz, erabiliko dugu. Horren arabera, uneren batean Mongo pixka bat "aspertu" egin zen eta lagina huts egiten hasi zen. Horren arabera, euri-probaren arabera, lekak "hiltzen" hasi ziren.
Ulertzen duzunez, "hiltzen" direnean, hau txat bat da, hau da, bezeroen konexio asko daude bertan zintzilik. Gainera, "hiltzen" dira - ez, ez bezeroak, konexioak bakarrik - ez denak aldi berean, eta aldi berean hiltzen ez direnez, batzuk lehenago, beste batzuk geroago, ez dira berdin hasten denbora. Gainera, ausazko estandarra, ezin dugu aldi bakoitzean aplikazioaren hasierako ordua milisegundoko zehaztasunarekin aurreikusi, beraz, instantzia bana egiten dute. Infospot bat igotzen da, balantzeari gehitzen zaio, bezero guztiak bertara etortzen dira, ezin du horrelako zamarik jasan, bakarrik dagoelako, eta gutxi gorabehera, dozena bat ari dira lanean han, eta jaisten da. Hurrengoa altxatzen da, zama osoa bere gainean dago, bera ere erori egiten da. Beno, jaitsiera hauek jauzika jarraitzen dute. Azkenean, nola konpondu den: aplikazio honetarako erabiltzaileen trafikoa zorrozki gelditu behar izan dugu, instantzia guztiak igotzen utzi eta gero erabiltzaileen trafiko guztia aldi berean abiarazi behar izan dugu dagoeneko hamar instantzien artean banatuta egon dadin.
Bizitasun-proba hau iragarri ez balitz, eta horrek dena berrabiarazteko behartuko luke, aplikazioak ondo kudeatuko luke. Baina balantzetik dena desgaituta dago, datu-baseak eskuraezinak direlako eta erabiltzaile guztiak "erortu" direlako. Gero, datu-base hau erabilgarri dagoenean, dena sartzen da balantzean, baina aplikazioak ez dira berriro hasi behar, eta ez dago horretan denbora eta baliabideak galdu beharrik. Dagoeneko hemen daude guztiak, trafikorako prest daude, beraz, trafikoa irekitzen da, dena ondo dago - aplikazioa martxan dago, denak funtzionatzen jarraitzen du.
Hori dela eta, presttasun eta bizitasun probak desberdinak dira, are gehiago, teorikoki osasun-kontrol desberdinak egin ditzakezu, erradio mota bat, liv mota bat, adibidez, eta gauza desberdinak egiaztatu. Prestakuntza-probetan, egiaztatu zure backend-ak. Eta bizitasun-test batean, adibidez, ez duzu egiaztatzen bizitasun-proba orokorrean erantzuten duen aplikazio bat besterik ez dela, erantzuteko gai bada.
Bizitasun-proba, oro har, "trabatuta" gaudenean gertatzen delako. Begizta amaigabe bat hasi da edo beste zerbait, eta ez da eskaera gehiago prozesatzen. Hori dela eta, zentzuzkoa da horiek bereiztea eta haietan logika desberdinak ezartzea.
Azterketa egiten duzunean, osasun-kontrolak egiten dituzunean erantzun behar duzunari buruz. Benetan mina da. Hau ezagutzen dutenek barre egingo dute ziurrenik, baina serioski, nire bizitzan kasuen %200ean "XNUMX" erantzuten duten zerbitzuak ikusi ditut. Hau da, nork duen arrakasta. Baina, aldi berean, erantzunaren gorputzean "halako akats bat" idazten dute.
Hau da, erantzunaren egoera zuregana dator - dena arrakastatsua da. Baina, aldi berean, gorputza aztertu behar duzu, gorputzak "barkatu, eskaera akats batekin amaitu da" esaten duelako eta hau errealitatea besterik ez da. Hau bizitza errealean ikusi nuen.
Eta pertsona batzuei dibertigarria izan ez dadin, eta beste batzuei oso mingarria iruditzen zaiela, merezi du oraindik arau sinple bati eustea. Osasun kontroletan, eta printzipioz web aplikazioekin lan egitean.
Dena ondo joan bada, erantzun berrehungarren erantzunarekin. Printzipioz, edozein berrehuneko erantzuna egokituko zaizu. Ragsy oso ondo irakurtzen baduzu eta badakizu erantzun-egoera batzuk besteekiko desberdinak direla, erantzun egokiak: 204, 5, 10, 15, dena dela. Oso ona ez bada, "bi zero zero" besterik ez. Dena gaizki badoa eta osasun azterketak ez badu erantzuten, erantzun bostehunen batekin. Berriz ere, nola erantzun ulertzen baduzu, erantzun-egoera desberdinak elkarren artean. Ez baduzu ulertzen, orduan 502 da zure aukera osasun-kontrolei erantzuteko zerbait gaizki gertatzen bada.
Hau beste puntu bat da, azpian dauden zerbitzuak egiaztatzeari buruz pixka bat itzuli nahi dut. Hasi bazara, adibidez, zure aplikazioaren atzean dauden azpiko zerbitzu guztiak egiaztatzen, oro har. Mikrozerbitzuen arkitekturaren ikuspuntutik lortzen duguna, "akoplamendu baxua" bezalako kontzeptua dugu, hau da, zure zerbitzuak elkarren menpekoak direnean. Horietako batek huts egiten badu, funtzionaltasun hori ez duten beste guztiek lanean jarraituko dute. Funtzionalitate batzuek ez dute funtzionatzen. Horrenbestez, osasun-kontrol guztiak elkarri lotzen badituzu, azkenean gauza bat erortzen da azpiegituran, eta erori zenez, zerbitzu guztietako osasun-kontrol guztiak ere huts egiten hasten dira - eta, oro har, azpiegitura gehiago dago. mikrozerbitzuen arkitektura osoa. Han dena ilun zegoen.
Hori dela eta, berriro errepikatu nahi dut azpian dauden zerbitzuak egiaztatu behar dituzula, horiek gabe zure aplikazioak kasuen ehuneko ehunean ezin duela bere lana egin. Hau da, logikoa da erabiltzaileak datu-basean gordetzeko edo datu-basetik berreskuratzeko REST API bat baduzu, datu-baserik ezean, ezin duzula ziurtatu zure erabiltzaileekin lan egitea.
Baina zure erabiltzaileak, datu-basetik ateratzen dituzunean, beste metadatu batzuekin aberasten badira, beste backend batekoak, frontend-era erantzuna bidali baino lehen sartzen dituzunak, eta backend hau erabilgarri ez badago, horrek esan nahi du zure datuak ematen dituzula. erantzun metadatuen zatirik gabe.
Ondoren, aplikazioak abiarazteko orduan arazo mingarrietako bat ere badugu.
Izan ere, hori ez da orokorrean Kubernetes-i soilik aplikatzen; gertatu da nolabaiteko garapen masiboaren kultura eta DevOps-a bereziki Kubernetesen garai berean hedatzen hasi zirela. Hori dela eta, orokorrean, Kubernetes gabe zure aplikazioa dotorez itxi behar duzula ematen du. Kubernetes aurretik ere, jendeak hau egiten zuen, baina Kubernetes-en etorrerarekin, masiboki horri buruz hitz egiten hasi ginen.
Itzali dotorea
Oro har, zer da Graceful Shutdown eta zergatik behar da? Hau arrazoiren batengatik zure aplikazioa huts egiten denean egin behar duzu app stop - edo, adibidez, sistema eragilearen seinale bat jasotzen baduzu, zure aplikazioak ulertu eta zerbait egin behar du. Egoerarik txarrena, noski, zure aplikazioak SIGTERM bat jasotzen duenean eta "SIGTERM, zintzilikatu, lan egin, ez egin ezer" bezalakoa da. Aukera guztiz txarra da.
Ia aukera txarra da zure aplikazioak SIGTERM bat jasotzen duenean eta "segterm esan zuten, horrek esan nahi du amaitzen ari garela, ez dut ikusi, ez dakit erabiltzaileen eskaerarik, ez dakit zer motatakoa". Oraintxe bertan lanean ditudan eskaerak, SIGTERM esan zuten, horrek esan nahi du amaitzen ari garela " Hau ere aukera txarra da.
Zein da ona? Lehenengo puntua eragiketak amaitu izana kontuan hartzea da. Aukera ona da zure zerbitzariak SIGTERM bat jasotzen badu zer egiten duen kontuan hartzea.
SIGTERM itzaltze leun bat da, bereziki diseinatuta dago, kode mailan atzeman daiteke, prozesatu daiteke, esan orain, itxaron, lehenik eta behin daukagun lana amaituko dugula, gero irtengo garela.
Kubernetesen ikuspegitik, hauxe da. Kubernetes kluster batean exekutatzen ari den pod bati esaten diogunean "gelditu, alde egin" edo berrabiarazten denean, edo Kubernetesek pod-ak birsortzen dituenean eguneraketa bat gertatzen denean, Kubernetes-ek SIGTERM mezu bera bidaltzen dio podari, itxaron egiten du. denbora pixka bat, eta , hau da itxaroten duen denbora, konfiguratuta ere badago, diplomatan hain parametro berezi bat dago eta Graceful ShutdownTimeout deitzen da. Ulertzen duzunez, ez da horrela deitzen ezertarako, eta ez da ezertarako hitz egiten ari garela.
Bertan zehazki esan dezakegu zenbat denbora itxaron behar dugun aplikaziora SIGTERM bidaltzen dugunetik aplikazioa zerbaitengatik zoratu egin dela edo "trabatuta" dagoela eta ez dela amaituko badirudi ulertzen dugunean - eta behar dugu. bidali SIGKILL, hau da, gogor bete bere lana. Hau da, horren arabera, deabru mota bat dugu martxan, eragiketak prozesatzen ditu. Ulertzen dugu, batez beste, deabruak lan egiten duen gure eragiketak ez direla aldi berean 30 segundo baino gehiago irauten. Horren arabera, SIGTERM iristen denean, ulertzen dugu gure deabruak, gehienez, SIGTERMren ondoren 30 segundora amaitu dezakeela. Idazten dugu, adibidez, 45 segundo badaezpada eta SIGTERM dela esaten dugu. Horren ostean 45 segundo itxarongo dugu. Teorian, denbora horretan deabruak bere lana amaitu eta bere burua amaitu behar zuen. Baina bat-batean ezin bada, ziurrenik itsatsita dagoela esan nahi du; jada ez ditu gure eskaerak normal prozesatzen ari. Eta 45 segundotan segurtasunez, hain zuzen ere, iltza dezakezu.
Eta hemen, hain zuzen ere, 2 alderdi ere har daitezke kontuan. Lehenik eta behin, ulertu eskaera bat jaso bazenuen, nola edo hala lan egiten hasi zinela eta erabiltzaileari erantzunik eman ez, baina SIGTERM jaso zenuela, adibidez. Zentzuzkoa da hobetzea eta erabiltzaileari erantzuna ematea. Zentzu honetan lehen puntua da. Hemen bi puntua hauxe da: zure aplikazioa idazten baduzu, orokorrean arkitektura eraiki ezazu zure aplikazioaren eskaera jasotzeko moduan, gero lanean hasten zara, nonbait fitxategiak deskargatzen hasten zara, datu-base bat deskargatzen eta beste. - Hori. Oro har, zure erabiltzailea, zure eskaera ordu erdiz zintzilikatzen da eta zuk erantzun arte itxaroten du; orduan, ziurrenik, arkitekturan lan egin beharko duzu. Hau da, kontuan izan zentzu komuna ere, zure eragiketak laburrak badira, zentzuzkoa dela SIGTERM alde batera uztea eta aldatzea. Zure eragiketak luzeak badira, ez du zentzurik kasu honetan SIGTERM alde batera uzteak. Zentzuzkoa da arkitektura birdiseinatzea horrelako eragiketa luzeak saihesteko. Erabiltzaileak ez daitezen bakarrik egon eta itxaron. Ez dakit, egin hor nolabaiteko websocket bat, egin zure zerbitzariak dagoeneko bezeroari bidaliko dizkion alderantzizko amuak, beste ezer, baina ez behartu erabiltzailea ordu erdiz zintzilikatzeko eta itxaron saio bat arte erantzun zion. Ezustekoa baita non apur daitekeen.
Zure aplikazioa amaitzen denean, irteera-kode egokia eman beharko zenuke. Hau da, zure aplikazioa ixteko, gelditzeko eskatu bazen eta bere burua normalean gelditzeko gai izan bazen, ez duzu 1,5,255 eta abar irteera-koderen bat itzuli beharrik. Zero kodea ez dena, Linux sistemetan behintzat, ziur nago, arrakastarik gabekotzat jotzen da. Hau da, kasu honetan zure eskaera akats batekin amaitu dela jotzen da. Horren arabera, modu adiskidetsuan, zure eskaera akatsik gabe osatu bada, 0 esango duzu irteeran. Zure aplikazioak arrazoiren bategatik huts egiten badu, ez-0 esango duzu irteeran. Eta informazio honekin lan egin dezakezu.
Eta azken aukera. Txarra da zure erabiltzaileak eskaera bat bidaltzen duenean eta prozesatzen duzun bitartean ordu erdiz zintzilik egotea. Baina, oro har, bezeroaren aldetik orokorrean merezi duenari buruz ere esan nahiko nuke. Berdin du mugikorretarako aplikazioa, frontend-a, etab. Kontuan izan behar da, oro har, erabiltzailearen saioa amaitu daitekeela, edozer gerta daitekeela. Eskaera bat bidal daiteke, adibidez, gutxi prozesatu eta erantzunik ez itzultzea. Zure frontend-ak edo zure mugikorreko aplikazioak -edozein frontend-ak oro har, esan dezagun horrela- kontuan hartu beharko luke. Websocketekin lan egiten baduzu, hau da, oro har, inoiz izan dudan mina larriena.
Ohiko txat batzuen garatzaileek hori ez dakitenean, websocket-a hautsi daiteke. Haientzat, proxyan zerbait gertatzen denean, konfigurazioa aldatzen dugu eta birkargatu egiten du. Berez, iraupen luzeko saio guztiak urratzen dira kasu honetan. Garatzaileak korrika etortzen zaizkigu eta esaten dute: "Mutilak, zer egiten ari zarete, txata hautsi da gure bezero guztientzat!" Guk esaten diegu: “Zer ari zarete? Zure bezeroak ezin dira berriro konektatu? Esaten dute: "Ez, saioak ez urratu behar ditugu". Laburbilduz, hau zentzugabekeria da. Bezeroaren aldea kontuan hartu behar da. Batez ere, esan bezala, websocket-ak bezalako iraupen luzeko saioekin, hautsi egin daiteke eta, erabiltzaileak ohartu gabe, horrelako saioak berriro instalatu ahal izan behar dituzu. Eta gero dena perfektua da.
baliabideak
Egia esan, hemen istorio zuzen bat kontatuko dizuet. Berriro bizitza errealetik. Baliabideei buruz inoiz entzun dudan gauzarik gaixoena.
Baliabideak kasu honetan, esan nahi dut, nolabaiteko eskaerak, zure Kubernetes klusterretan leketan jarri ditzakezun mugak. Garatzaile bati entzun diodan gauzarik dibertigarriena... Aurreko lan-leku bateko garatzaileetako batek esan zuen behin: "Nire aplikazioa ez da klusterrean hasiko". Begiratu nuen ez zela hasten, baina edo ez zen baliabideetan sartzen, edo oso muga txikiak jarri zituzten. Laburbilduz, aplikazioa ezin da hasi baliabideak direla eta. Nik diot: "Ez da baliabideengatik hasiko, zuk erabakitzen duzu zenbat behar duzun eta balio egokia ezarri". Honela dio: "Zer baliabide mota?" Kubernetes, eskaeren mugak eta bla, bla, bla ezarri behar direla azaltzen hasi nintzen. Gizonak bost minutuz entzun, baietz egin zuen eta esan zuen: «Hona etorri naiz garatzaile gisa lan egitera, ez dut ezer jakin nahi baliabideei buruz. Hona etorri nintzen kodea idaztera eta kitto”. Tristea da. Oso kontzeptu tristea da garatzaileen ikuspuntutik. Batez ere mundu modernoan, nolabait esateko, devops progresiboen.
Zergatik beharrezkoak dira baliabideak? Kubernetesen 2 baliabide mota daude. Batzuei eskaerak deitzen zaie, besteei mugak. Baliabideen arabera ulertuko dugu funtsean beti oinarrizko bi murrizketa soilik daudela. Hau da, Kubernetes-en exekutatzen den edukiontzi baten CPU denbora-mugak eta RAM mugak.
Muga batek baliabide bat zure aplikazioan erabiltzeko moduaren goiko muga jartzen du. Hau da, horren arabera, mugetan 1GB RAM esaten baduzu, orduan zure aplikazioak ezingo du 1GB RAM baino gehiago erabili. Eta bat-batean hori egiten nahi eta saiatzen bada, orduan oom killer izeneko prozesu bat, memoriarik gabe, hau da, etorriko da eta zure aplikazioa hilko du, hau da, berrabiaraziko da. Aplikazioak ez dira berrabiaraziko CPUan oinarrituta. CPUari dagokionez, aplikazio bat asko erabiltzen saiatzen bada, mugetan zehaztutakoa baino gehiago, CPUa zorrozki hautatuko da. Horrek ez du berrabiarazten. Hau da muga - hau da goiko muga.
Eta badago eskaera bat. Eskaera bat da Kubernetes-ek zure Kubernetes klusterreko nodoak aplikazioekin nola betetzen diren ulertzen duen. Hau da, eskaera zure eskaeraren konpromiso moduko bat da. Erabili nahi dudana esaten du: "Gustatuko nuke CPU eta memoria hainbeste erreserbatzea niretzat". Halako analogia sinplea. Zer gertatzen da guztira 8 CPU dituen, ez dakit, nodo bat badugu. Eta hara pod bat iristen da, eta haren eskaerek 1 CPU esaten dute, hau da, nodoari 7 CPU geratzen zaizkio. Hau da, horren arabera, nodo honetara 8 pod iritsi bezain laster, bakoitzak bere eskaeretan CPU 1 duela, nodoa, Kubernetesen ikuspuntutik, CPU gabe geratu da eta eskaerak dituzten pod gehiago ezin dira egon. nodo honetan abiarazi da. Nodo guztiak CPUrik gabe geratzen badira, Kubernetes hasiko da esaten klusterrean ez dagoela nodo egokirik zure podak exekutatzeko, CPUa agortu delako.
Zergatik behar dira eskaerak eta zergatik eskaerarik gabe, uste dut ez dagoela ezer abiarazi behar Kubernetes-en? Imajina dezagun egoera hipotetiko bat. Zure aplikazioa eskaerarik gabe abiarazten duzu, Kubernetes-ek ez daki zenbat duzuna, zein nodotara bultzatu dezakezun. Tira, nodoetara bultzatzen du. Noizbait, zure aplikaziorako trafikoa lortzen hasiko zara. Eta aplikazioetako bat bat-batean hasten da baliabideak erabiltzen mugen arabera dituen mugetaraino. Gertu egiten da beste aplikazio bat dagoela eta baliabideak ere behar dituela. Nodoa fisikoki baliabiderik gabe geratzen hasten da, adibidez, OP. Nodoa fisikoki baliabiderik gabe geratzen hasten da, adibidez, ausazko sarbide memoria (RAM). Nodo bat potentzia agortzen denean, lehenik eta behin docker-ak erantzuteari utziko dio, gero cubelet-ak eta gero OS-ak. Besterik gabe, konorterik gabe geratuko dira eta DENA behin betiko geldituko da zuretzako lanean. Hau da, horrek zure nodoa trabatu egingo du eta berrabiarazi beharko duzu. Laburbilduz, egoera ez da oso ona.
Eta eskaerak dituzunean, mugak ez dira oso desberdinak, gutxienez mugak edo eskaerak baino askoz gehiago, orduan aplikazioak betetze normal eta arrazional bat izan dezakezu Kubernetes klusterren nodoetan. Aldi berean, Kubernetes gutxi gorabehera jakitun da zenbat zer jartzen duen non, zenbat zer erabiltzen den non. Hau da, halako momentu bat besterik ez da. Garrantzitsua da ulertzea. Eta hori adierazita dagoela kontrolatzea garrantzitsua da.
Datuak biltegiratzea
Gure hurrengo puntua datuak biltegiratzeari buruzkoa da. Zer egin haiekin eta, oro har, zer egin Kubernetesen iraunkortasunarekin?
Uste dut, berriro ere, gure barruan , Kubernetes-en datu baseari buruzko gai bat zegoen. Eta iruditzen zait gutxi gorabehera badakidala zure lankideek zer esan dizuten galdetuta: "Posible al da datu-base bat Kubernetesen exekutatu?" Arrazoiren bategatik, iruditzen zait zure lankideek esan beharko luketela Kubernetes-en datu-base bat exekutatu ahal den ala ez galdetzen ari bazara, ezinezkoa dela.
Hemen logika sinplea da. Badaezpada, berriro ere azalduko dut, sare banatutako biltegiratze sistema nahiko akatsekiko tolerantzia bat eraiki dezakezun tipo oso polita bazara, ulertu datu-base bat kasu honetan nola egokitu behar den hodei-edukiontzietan. datu-base batean orokorrean. Seguruenik, ez duzu nola exekutatu buruzko zalantzarik. Halako galdera bat baduzu eta dena zabaltzen dela eta ekoizpenean hil arte iraungo duela eta inoiz erortzen dela ziurtatu nahi baduzu, ez da hori gertatzen. Planteamendu honekin oinetan tiro egingo duzula ziurtatuta zaude. Beraz, hobe da ez egitea.
Zer egin behar dugu gure aplikazioak gorde nahi dituen datuekin, erabiltzaileek igotzen dituzten argazki batzuekin, gure aplikazioak bere funtzionamenduan sortzen dituen gauza batzuekin, abiaraztean, adibidez? Zer egin haiekin Kubernetesen?
Oro har, hoberena, bai, noski, Kubernetes oso ondo diseinatuta dago eta, oro har, hasiera batean estaturik gabeko aplikazioetarako pentsatu zen. Hau da, batere informazioa gordetzen ez duten aplikazio horietarako. Hau aproposa da.
Baina, noski, aukera ideala ez da beti existitzen. Beraz, zer? Lehen eta errazena S3 motaren bat hartzea da, ez etxean egindakoa, eta hori ere ez dago argi nola funtzionatzen duen, hornitzaile batzuengandik baizik. Hornitzaile ona eta normala - eta irakatsi zure aplikazioari S3 erabiltzen. Hau da, zure erabiltzaileak fitxategi bat kargatu nahi duenean, esan "hemen, mesedez, kargatu S3-ra". Jaso nahi duenean, esan: "Hona hemen S3rako esteka bat atzera eta hartu hemendik". Hau aproposa da.
Bat-batean, arrazoiren batengatik aukera ideal hau egokia ez bada, idatzi ez duzun aplikazio bat baduzu, garatzen ez baduzu edo ondare izugarria bada, ezin du S3 protokoloa erabili, baina tokiko direktorioekin lan egin behar du. tokiko karpetak. Hartu zerbait errazago edo gutxiago, zabaldu Kubernetes. Hau da, berehala Ceph hesitzea gutxieneko zeregin batzuetarako, ideia txarra iruditzen zait. Ceph, noski, ona eta modan dagoelako. Baina benetan zer egiten ari zaren ulertzen ez baduzu, Ceph-en zerbait jarri ondoren, oso erraz eta besterik gabe ez duzu inoiz berriro atera. Zeren eta, dakizuenez, Ceph-ek bere klusterrean gordetzen ditu datuak forma bitarrean, eta ez fitxategi soiletan. Hori dela eta, bat-batean Ceph klusterra apurtzen bada, probabilitate osoa eta handia dago zure datuak ez dituzun berriro handik lortuko.
Ceph-i buruzko ikastaro bat izango dugu, ahal duzu .
Hori dela eta, hobe da NFS zerbitzari bat bezalako zerbait sinplea egitea. Kubernetes haiekin lan egin dezake, direktorio bat NFS zerbitzari baten azpian munta dezakezu - zure aplikazioa direktorio lokal bat bezalakoa da. Aldi berean, jakina, ulertu behar duzu, berriro ere, zure NFSarekin zerbait egin behar duzula, batzuetan eskuraezin bihur daitekeela ulertu behar duzu eta kasu honetan zer egingo duzun galdera kontuan hartu behar duzu. Beharbada, babeskopia egin beharko litzateke beste makina batean nonbait.
Hitz egin dudan hurrengo puntua zure aplikazioak funtzionatzen ari den bitartean fitxategi batzuk sortzen baditu zer egin da. Adibidez, abiaraztean, fitxategi estatiko batzuk sortzen ditu, aplikazioak abiarazteko unean soilik jasotzen duen informazio batzuetan oinarritzen dena. A ze momentua. Horrelako datu askorik ez badago, ez duzu batere trabarik izan behar, instalatu aplikazio hau zeure buruari eta lan egin. Hemen galdera bakarra zer da, begira. Askotan, era guztietako ondare-sistemak, hala nola, WordPress eta abar, batez ere plugin adimentsu batzuk aldatuta, PHP garatzaile burutsuak, askotan badakite nola egin behar den fitxategi motaren bat sortzeko. Horren arabera, batek fitxategi bat sortzen du, bigarrenak bigarren fitxategi bat sortzen du. Desberdinak dira. Bezeroen Kubernetes klusterrean orekatzea kasualitatez gertatzen da. Horren arabera, ikusten da ez dakitela elkarrekin nola lan egin kasu. Batek informazio bat ematen dio, besteak beste informazio bat ematen dio erabiltzaileari. Hau da saihestu behar duzuna. Hau da, Kubernetesen, abiarazten duzun guztia hainbat instantziatan funtzionatuko duela bermatuta dago. Kubernetes gauza hunkigarria delako. Horren arabera, edozer mugi dezake, nahi duenean, inori galdetu gabe. Hori dela eta, horrekin kontatu behar duzu. Instantzia batean abiarazitako guztia porrot egingo du lehenago edo geroago. Zenbat eta erreserba gehiago izan, orduan eta hobeto. Baina berriro diot, horrelako fitxategi batzuk badituzu, zure azpian jar ditzakezu, kopuru txiki bat pisatzen dute. Pixka bat gehiago badaude, ziurrenik ez dituzu edukiontzi barruan sartu behar.
Kubernetesen gauza zoragarri bat dagoela gomendatuko nuke, bolumena erabil dezakezula. Bereziki, zuzen hutsik motako bolumena dago. Hau da, Kubernetes-ek automatikoki sortuko du direktorio bat hasi zinen zerbitzarian bere zerbitzu-direktorioetan. Eta emango dizu, erabil dezazun. Puntu garrantzitsu bakarra dago. Hau da, zure datuak ez dira edukiontzi barruan gordeko, exekutatzen ari zaren ostalarian baizik. Gainera, Kubernetes-ek halako direktorio hutsak konfigurazio normalean kontrola ditzake eta haien tamaina maximoa kontrolatzeko gai da eta ez gainditzen utzi. Puntu bakarra zera da, direktorio hutsean idatzitakoa ez dela galtzen poda berrabiarazi bitartean. Hau da, zure poda hutsez erori eta berriro igotzen bada, hutsik dagoen direktorioko informazioa ez da inora joango. Berriro erabil dezake berriro hasiera batean, eta hori ona da. Zure poda nonbaitetik irteten bada, jakina da daturik gabe utziko du. Hau da, abiarazi zen nodoko pod-a helbide hutsarekin desagertzen den bezain laster, ezabatuko da.
Zer gehiago dago ona dir hutsik? Adibidez, cache gisa erabil daiteke. Imajina dezagun gure aplikazioak berehalako zerbait sortzen duela, erabiltzaileei ematen diela eta denbora luzez egiten duela. Hori dela eta, aplikazioak, adibidez, erabiltzaileei sortzen eta ematen die, eta, aldi berean, nonbait gordetzen du, horrela erabiltzailea gauza beragatik datorren hurrengoan azkarragoa izango da berehala sortutakoa ematea. Zuzen hutsik Kubernetes-i eska diezaioke memorian sortzeko. Eta horrela, zure cacheak, oro har, tximista-abiaduran funtziona dezake - diskorako sarbidearen abiadurari dagokionez. Hau da, direktorio huts bat duzu memorian, OSan memorian gordetzen da, baina zuretzat, pod barruan erabiltzailearentzat, tokiko direktorio bat besterik ez da dirudi. Ez duzu aplikazioa behar bereziki magiarik irakasteko. Zuzenean hartu eta jarri zure fitxategia direktorio batean, baina, hain zuzen ere, sistema eragilean memorian. Hau ere ezaugarri oso erosoa da Kubernetes-i dagokionez.
Zer arazo ditu Miniok? Minioren arazo nagusia zera da: gauza honek funtziona dezan, nonbait exekutatzen egon behar duela eta fitxategi-sistemaren bat egon behar duela, hau da, biltegiratzea. Eta hemen Ceph-ek dituen arazo berdinekin egiten dugu topo. Hau da, Miniok bere fitxategiak nonbait gorde behar ditu. Zure fitxategietarako HTTP interfaze bat besterik ez da. Gainera, funtzionalitatea argi eta garbi Amazon-en S3rena baino eskasagoa da. Aurretik, ezin izan zuen erabiltzaileari behar bezala baimendu. Orain, nik dakidala, dagoeneko sor ditzake baimen desberdinak dituzten kuboak, baina berriro ere, iruditzen zait arazo nagusia dela, nolabait esateko, azpian dagoen biltegiratze sistema gutxienez.
Nola eragiten die memoriako Dir hutsik mugei? Ez du inola ere mugak eragiten. Ostalariaren memorian dago, eta ez zure edukiontziaren memorian. Hau da, zure edukiontziak ez du memorian dagoen direktorio hutsa ikusten okupatutako memoriaren zati gisa. Ostalariak hori ikusten du. Horren arabera, bai, kubernetesen ikuspuntutik, hau erabiltzen hastean, ondo legoke ulertzea zure memoriaren zati bat dir hutsari eskaintzen ari zarela. Eta horren arabera, ulertu memoria agortu daitekeela aplikazioengatik ez ezik, norbaitek hutsik dauden direktorio horietan idazten duelako ere.
Hodeitasuna
Eta azken azpigaia Cloudnative zer den da. Zergatik behar da? Hodeitasuna eta abar.
Hau da, hodeiko azpiegitura moderno batean lan egiteko gai eta idatzitako aplikazio horiek. Baina, hain zuzen ere, Cloudnativek badu halako beste alderdi bat. Hodei-azpiegitura moderno baten eskakizun guztiak kontuan hartzen dituen aplikazioa ez ezik, hodei-azpiegitura moderno honekin lan egiten ere badakiela, hodei hauetan lan egitearen abantailak eta desabantailak aprobetxatu. Ez zaitez hodeietan lan egin, baina aprobetxatu hodeian lan egitearen onurak.
Har dezagun Kubernetes adibide gisa. Zure aplikazioa Kubernetesen exekutatzen ari da. Zure aplikazioak beti, edo hobeto esanda, zure aplikazioko administratzaileek beti sor dezakete zerbitzu-kontu bat. Hau da, Kubernetesen bertan baimentzeko kontu bat bere zerbitzarian. Gehitu bertan behar ditugun eskubide batzuk. Eta Kubernetesera sar zaitezke zure aplikaziotik. Zer egin dezakezu horrela? Esate baterako, aplikaziotik, jaso zure beste aplikazioak non dauden, antzeko beste instantzia batzuk eta elkarrekin nolabait Kubernetes-en gainean bildu, halako beharra badago.
Berriz ere, azkenaldian kasu bat izan dugu literalki. Ilara kontrolatzen duen kontrolatzaile bat dugu. Eta ilara honetan zeregin berri batzuk agertzen direnean, Kubernetesera joaten da, eta Kubernetesen barruan pod berri bat sortzen du. Pod honi zeregin berri bat ematen dio eta pod honen esparruan, podak zeregina egiten du, erantzun bat bidaltzen dio kontroladoreari berari, eta kontrolatzaileak informazio horrekin zerbait egiten du. Adibidez, datu-base bat gehitzen du. Hau da, berriro ere, gure aplikazioa Kubernetes-en exekutatzen ari den abantaila da. Kubernetes-en funtzionaltasuna bera erabil dezakegu, nolabait zabaldu eta gure aplikazioaren funtzionaltasuna erosoagoa izan dadin. Hau da, ez ezkutatu nolabaiteko magiarik aplikazio bat nola abiarazi, langile bat nola abiarazi. Kubernetes-en, aplikazioan eskaera bat bidaltzea besterik ez duzu aplikazioa Python-en idatzita badago.
Gauza bera gertatzen da Kubernetesetik haratago joaten bagara. Gure Kubernetes martxan dugu nonbait; ona da hodei motaren batean badago. Berriz ere, exekutatzen ari garen hodeiaren beraren gaitasunak erabili ditzakegu, eta baita ere erabili beharko genituzke, nire ustez. Hodeiak eskaintzen dizkigun oinarrizko gauzetatik. Balancing, hau da, hodeiko orekatzaileak sortu eta erabili ditzakegu. Hau erabil dezakegunaren abantaila zuzena da. Hodeien orekatzeak, lehenik eta behin, ergelkeriaz arduratzen gaitu nola funtzionatzen duen, nola konfiguratzen den. Gainera, oso erosoa da, ohiko Kubernetes hodeiekin integra daitekeelako.
Berdin gertatzen da eskalatzearekin. Kubernetes ohiko hodeiko hornitzaileekin integra daiteke. Badaki ulertzen klusterra nodorik gabe geratzen bada, hau da, nodo-espazioa agortu bada, gehitu behar duzula - Kubernetes-ek berak nodo berriak gehituko ditu zure klusterrean eta haietan pod-ak abiarazten hasiko dira. Hau da, zure zama iristen denean, sutegi kopurua handitzen hasten da. Klusterreko nodoak pod horietarako agortzen direnean, Kubernetes-ek nodo berriak abiarazten ditu eta, horren arabera, poden kopurua oraindik handitu daiteke. Eta oso erosoa da. Hau klusterra hegan eskalatzeko aukera zuzena da. Ez da oso azkarra, segundo bat ez den zentzuan, minutu bat baino gehiago nodo berriak gehitzeko.
Baina nire esperientziaren arabera, berriro ere, inoiz ikusi dudan gauzarik politena da. Cloudnative klusterrak eguneko orduaren arabera eskalatu zuenean. Backend zerbitzu bat zen, atzeko bulegoko jendeak erabiltzen zuena. Hau da, 9:8etan lanera etortzen dira, sisteman sartzen hasten dira, eta horren arabera, dena martxan dagoen Cloudnative klusterra puzten hasten da, lanera datozen guztiek aplikazioarekin lan egin dezaten. 6:30etan edo XNUMX:XNUMXetan lanetik irteten direnean, Kubernetes klusterrak aplikazioa jada inork ez duela erabiltzen ohartzen dira eta txikitzen hasten dira. Ehuneko XNUMXerainoko aurrezpena bermatuta dago. Amazonen funtzionatzen zuen garai hartan; garai hartan Errusian ez zegoen hain ondo egin zezakeen inor.
Zuzen esango dizut, aurrezpena ehuneko 30ekoa da, Kubernetes erabiltzen dugulako eta hodeiaren ahalmenak aprobetxatzen ditugulako. Orain hau Errusian egin daiteke. Ez diot inori iragarkirik egingo, noski, baina esan dezagun hornitzaileak badirela hori egin dezaketen hornitzaileak, botoi batekin berehala eman.
Bada azken puntu bat ere zure arreta erakarri nahi nukeena. Zure aplikazioa, zure azpiegitura Cloudnative izan dadin, zentzuzkoa da azkenik Infrastructure as a Code bezala deritzon ikuspegia egokitzen hastea. Hau da, horrek esan nahi du zure aplikazioa, edo hobeto esanda, zure azpiegitura, behar den modu berean behar dela. kodea Deskribatu zure aplikazioa, zure negozio-logika kode moduan. Eta kode gisa lan egin, hau da, probatu, zabaldu, gorde git-en, aplikatu CICD.
Eta horixe da, hain zuzen, aukera ematen dizuna, lehenik eta behin, zure azpiegituraren gaineko kontrola beti edukitzea, beti zein egoeratan dagoen ulertzea. Bigarrenik, akatsak eragiten dituzten eskuzko eragiketak saihestu. Hirugarrenik, saihestu fakturazioa deitzen dena, eskuzko zeregin berdinak etengabe egin behar dituzunean. Laugarrenik, hutsegite bat gertatuz gero askoz azkarrago berreskuratzeko aukera ematen du. Errusian, honetaz hitz egiten dudan bakoitzean, beti izaten da jende ugari esaten duena: “Bai, argi dago, baina planteamenduak dituzu, laburbilduz, ez dago ezer konpondu beharrik”. Baina egia da. Zure azpiegituran zerbait apurtzen bada, orduan Cloudnative ikuspegiaren ikuspuntutik eta Azpiegitura Kode gisa, konpontzea baino, zerbitzarira joatea, apurtuta dagoena irudikatzea eta konpontzea, errazagoa da. zerbitzaria ezabatu eta berriro sortzeko. Eta hori guztia berreskuratuko dut.
Gai hauek guztiak zehatzago eztabaidatzen dira hemen . Esteka jarraituz programa eta baldintzak ezagutu ditzakezu. Gauza erosoa da Kubernetes menperatu dezakezula etxetik edo lanean egunean 1-2 orduz ikasiz.
Iturria: www.habr.com