Ohar. itzul.: material hau hezkuntza proiektu batekoa da Kubernetes-en oinarritutako azpiegitura diseinatzerakoan galdera ezagun baten erantzuna da. Aukera bakoitzaren alde onen eta txarren deskribapen zehatzak zure proiekturako aukerarik onena egiten lagunduko dizutela espero dugu.
TL; DR: lan-karga multzo bera hainbat kluster handitan exekutatu daiteke (kluster bakoitzak lan-karga kopuru handia izango du) edo txiki askotan (kluster bakoitzean lan-karga txiki batekin).
Jarraian, ikuspegi bakoitzaren alde onak eta txarrak ebaluatzen dituen taula da:
Kubernetes aplikazioak exekutatzeko plataforma gisa erabiltzean, oinarrizko hainbat galdera sortzen dira askotan klusterrak konfiguratzeko zailtasunei buruz:
- Zenbat kluster erabili behar ditut?
- Zenbateraino egin behar ditut?
- Zer sartu behar du kluster bakoitzak?
Artikulu honetan, galdera horiei guztiei erantzuten saiatuko naiz planteamendu bakoitzaren alde onak eta txarrak aztertuz.
Galdera baten adierazpena
Software garatzaile gisa, litekeena da aplikazio asko aldi berean garatzea eta operatzea.
Gainera, litekeena da aplikazio horien instantzia asko ingurune ezberdinetan exekutatzen aritzea; adibidez, hauek izan daitezke dev, test ΠΈ prod.
Emaitza aplikazioen eta inguruneen matrize oso bat da:
Aplikazioak eta inguruneak
Goiko adibideak 3 aplikazio eta 3 ingurune adierazten ditu, guztira 9 aukera posible izan daitezen.
Aplikazio-instantzia bakoitza inplementazio-unitate autonomo bat da, besteekin batera lan egin daitekeen.
Kontuan izan aplikazio instantzia asko izan daitezke osagaiak, hala nola frontend, backend, datu-basea, etab. Mikrozerbitzuen aplikazio baten kasuan, instantziak mikrozerbitzu guztiak barne hartuko ditu.
Ondorioz, Kuberneteseko erabiltzaileek hainbat galdera dituzte:
- Aplikazio-instantzia guztiak kluster batean kokatu behar al dira?
- Merezi al du aplikazio-instantzia bakoitzerako kluster bereizia izatea?
- Edo agian goiko ikuspegien konbinazio bat erabili beharko litzateke?
Aukera hauek guztiak nahiko bideragarriak dira, Kubernetes erabiltzailearen ahalmenak mugatzen ez dituen sistema malgua baita.
Hona hemen modu posible batzuk:
- kluster komun handi bat;
- oso espezializatutako kluster txiki asko;
- kluster bat aplikazio bakoitzeko;
- kluster bat ingurune bakoitzeko.
Jarraian erakusten den bezala, lehenengo bi ikuspegiak aukeren eskalaren muturretan daude:
Multzo handi batzuetatik (ezkerrean) txiki askotara (eskuinean)
Oro har, kluster bat beste bat baino "handiagoa" da, nodoen eta lekaren batura handiagoa badu. Esate baterako, 10 nodo eta 100 leka dituen kluster bat handiagoa da 1 nodo eta 10 lek dituen kluster bat baino.
Tira, has gaitezen!
1. Kluster komun handi bat
Lehenengo aukera lan-karga guztiak kluster batean jartzea da:
Multzo handi bat
Ikuspegi honen barruan, klusterra unibertsal gisa erabiltzen da azpiegitura plataforma β Lehendik dagoen Kubernetes kluster batean behar duzun guztia zabaldu besterik ez duzu.
Kubernetes-ek klusterraren zatiak logikoki bereiztea ahalbidetzen du, aplikazio-instantzia bakoitzak bere izen-espazioa izan dezan.
Ikus ditzagun ikuspegi honen alde onak eta txarrak.
+ Baliabideen erabilera eraginkorra
Kluster bakarrarekin, Kubernetes klusterra exekutatu eta kudeatzeko behar diren baliabide guztien kopia bakarra behar duzu.
Adibidez, hau egia da nodo nagusientzat. Normalean, Kubernetes-eko kluster bakoitzak 3 nodo nagusi ditu, beraz, kluster bakarrerako haien kopurua horrela mantenduko da (konparazio baterako, 10 klusterek 30 nodo nagusi beharko dituzte).
Goiko sotiltasuna kluster osoan funtzionatzen duten beste zerbitzu batzuei ere aplikatzen zaie, hala nola karga-orekatzaileak, Ingress kontrolagailuak, autentifikazio-, erregistro- eta monitorizazio-sistemetan.
Kluster bakarrean, zerbitzu horiek guztiak aldi berean erabil daitezke lan-karga guztietarako (ez dago horien kopiarik sortu behar, hainbat klusterrekin gertatzen den bezala).
+ Merkea
Aurrekoaren ondorioz, kluster gutxiago izan ohi dira merkeagoak, gastu orokorrik ez dagoelako.
Hau bereziki egia da nodo nagusientzat, diru kopuru handia kosta daiteke nola ostatatuta dauden (lokalean edo hodeian).
Kubernetes zerbitzu batzuk kudeatzen zituzten, adibidez edo , eman kontrol-geruza doan. Kasu honetan, kostuen arazoa ez da hain zorrotza.
Kubernetes kluster bakoitzaren funtzionamenduagatik kuota finko bat kobratzen duten kudeatutako zerbitzuak ere badaude (adibidez, ).
+ Administrazio eraginkorra
Kluster bat kudeatzea errazagoa da hainbat kudeatzea baino.
Administrazioak honako zeregin hauek izan ditzake:
- Kubernetes bertsioaren eguneratzea;
- CI/CD kanalizazioa ezartzea;
- CNI plugina instalatzea;
- erabiltzaileen autentifikazio-sistema konfiguratzea;
- sarbide-kontrolagailu bat instalatzea;
eta beste askoβ¦
Kluster baten kasuan, hori guztia behin bakarrik egin beharko duzu.
Kluster askorentzat, eragiketak askotan errepikatu beharko dira, eta horrek prozesuen eta tresnen nolabaiteko automatizazioa beharko du ziurrenik prozesuaren koherentzia eta koherentzia bermatzeko.
Eta orain txarrei buruzko hitz batzuk.
β Porrot puntu bakarra
Ezezko kasuan bakarra klusterrak berehala geldituko da lanean guztiak lan kargak!
Gauzak gaizki atera daitezkeen modu asko daude:
- Kubernetes eguneratzeak ezusteko albo-ondorioak dakartza;
- Kluster osoko osagai bat (adibidez, CNI plugin bat) ez da espero bezala funtzionatzen;
- klusterreko osagaietako bat ez dago behar bezala konfiguratuta;
- azpiegituren porrota.
Horrelako gertakari batek kalte larriak eragin ditzake partekatutako kluster batean ostatatutako lan-karga guztietan.
β Isolamendu zurrunik ez
Partekatutako kluster batean exekutatzen aritzeak esan nahi du aplikazioek hardwarea, sareko gaitasunak eta sistema eragilea kluster nodoetan partekatzen dituztela.
Zentzu batean, nodo berean exekutatzen diren bi aplikazio ezberdin dituzten bi edukiontzi makina berean exekutatzen ari diren bi prozesu bezalakoak dira OS kernel bera dabiltzan.
Linux edukiontziak nolabaiteko isolamendua eskaintzen du, baina ez da ia sendoa, esate baterako, makina birtualek eskaintzen dutena. Funtsean, edukiontzi bateko prozesu bat ostalariaren sistema eragilean exekutatzen den prozesu bera da.
Hau segurtasun-arazo bat izan daiteke: antolamendu honek teorikoki zerikusirik ez duten aplikazioak elkarren artean komunikatzea ahalbidetzen du (nahita edo ustekabean).
Gainera, Kubernetes klusterreko lan-karga guztiek kluster osoko zerbitzu batzuk partekatzen dituzte, esaterako - horri esker, aplikazioek klusterrean beste aplikazio batzuen Zerbitzuak aurki ditzakete.
Aurreko puntu guztiek esanahi desberdinak izan ditzakete aplikazioaren segurtasun-baldintzen arabera.
Kubernetes-ek hainbat tresna eskaintzen ditu segurtasun-arazoak saihesteko, esaterako ΠΈ . Hala ere, behar bezala konfiguratzeak esperientzia pixka bat behar du; gainera, ezin dira segurtasun-zulo guztiak erabat ixteko.
Garrantzitsua da beti gogoratzea Kubernetes jatorriz diseinatu zela partekatzea, ezrentzat isolamendua eta segurtasuna.
β Errentamendu anitzeko zorrotzik eza
Kubernetes kluster batean partekatutako baliabideen ugaritasuna kontuan hartuta, hainbat modu daude aplikazio ezberdinek elkarren behatzak zapaltzeko.
Adibidez, aplikazio batek partekatutako baliabide bat monopoliza dezake (adibidez, CPU edo memoria) eta nodo berean exekutatzen diren beste aplikazio batzuetarako sarbidea ukatu.
Kubernetes-ek hainbat mekanismo eskaintzen ditu portaera hori kontrolatzeko, adibidez (ikusi ere " artikulua"- gutxi gorabehera. itzul.), ΠΈ . Hala ere, segurtasunaren kasuan bezala, haien konfigurazioa ez da hutsala eta ezin dira guztiz aurreikusi ez diren albo-ondorio guztiak saihesteko.
β Erabiltzaile kopuru handia
Kluster bakarraren kasuan, jende askorentzat sarbidea ireki behar duzu. Eta zenbat eta handiagoa izan, orduan eta arrisku handiagoa izango dute zerbait "hausteko".
Kluster barruan kontrola dezakezu nork egin dezakeen zer erabiliz (ikus artikulua β"- gutxi gorabehera. itzul.). Hala ere, ez du eragotziko erabiltzaileek beren erantzukizun-eremuan zerbait "haustea" dezatela.
β Klusterrak ezin dira mugagabe hazi
Lan-karga guztietarako erabiltzen den klusterra nahiko handia izango da (nodo eta pod kopuruari dagokionez).
Baina hemen beste arazo bat sortzen da: Kubernetes-en klusterrak ezin dira mugagabe hazi.
Klusterren tamainaren muga teoriko bat dago. Kubernetes-en gutxi gorabehera .
Hala ere, bizitza errealean arazoak askoz lehenago has daitezke, adibidez, besterik gabe .
Kontua da kluster handiek karga handia jartzen dutela Kubernetes kontrol-geruzan. Beste era batera esanda, klusterra modu eraginkorrean martxan mantentzeak arretaz doitzea eskatzen du.
Arazo hau jatorrizko blogean erlazionatutako artikulu batean aztertzen da "'.
Baina kontuan har dezagun kontrako ikuspegia: multzo txiki asko.
2. Kluster txiki eta espezializatu asko
Planteamendu honekin, inplementatzen duzun elementu bakoitzeko kluster bereizi bat erabiltzen duzu:
Multzo txiki asko
Artikulu honen ondorioetarako, azpian heda daitekeen elementua aplikazio baten instantzia bati egiten dio erreferentzia, adibidez, aplikazio bereizi baten garapenerako bertsioa.
Estrategia honek Kubernetes erabiltzen du espezializatu gisa exekuzioa aplikazio-instantzia indibidualetarako.
Ikus ditzagun ikuspegi honen alde onak eta txarrak.
+ "Leherketaren erradioa" mugatua
Kluster batek huts egiten duenean, ondorio negatiboak kluster horretan zabaldutako lan-karga horietara soilik mugatzen dira. Gainerako lan-karga guztiak ukitu gabe jarraitzen dute.
+ Isolamendua
Kluster indibidualetan ostatatutako lan-kargak ez dituzte prozesadorea, memoria, sistema eragilea, sarea edo beste zerbitzu batzuk bezalako baliabideak partekatzen.
Ondorioz, zerikusirik ez duten aplikazioen arteko isolamendu estua da, hauen segurtasunerako onuragarria izan daitekeena.
+ Erabiltzaile kopuru txikia
Kluster bakoitzak lan-karga multzo mugatu bat baino ez daukala kontuan hartuta, bertara sarbidea duten erabiltzaileen kopurua murrizten da.
Zenbat eta jende gutxiago izan klusterra, orduan eta arrisku txikiagoa izango da zerbait "hausteko".
Ikus ditzagun txarrak.
β Baliabideen erabilera ez eraginkorra
Lehen esan bezala, Kubernetes kluster bakoitzak kudeaketa-baliabide multzo zehatz bat behar du: nodo nagusiak, kontrol-geruzaren osagaiak, monitorizazio eta erregistro-soluzioak.
Kluster txikien kopuru handian, baliabideen parte handiagoa bideratu behar da kudeaketara.
β Garestia
Baliabideen erabilera ez eraginkorrak kostu handiak dakartza automatikoki.
Adibidez, 30 nodo nagusi mantentzeak konputazio-potentzia bera duten hiruren ordez, kostuetan eragingo du nahitaez.
β Administrazioan zailtasunak
Kubernetes kluster anitz kudeatzea askoz zailagoa da bakarra kudeatzea baino.
Adibidez, kluster bakoitzaren autentifikazioa eta baimena konfiguratu beharko dituzu. Kubernetes bertsioa ere hainbat aldiz eguneratu beharko da.
Ziurrenik automatizazioa erabili beharko duzu zeregin horiek guztiak eraginkorragoak izateko.
Orain ikus ditzagun muturreko ez diren eszenatokiak.
3. Aplikazio bakoitzeko kluster bat
Planteamendu honetan, aparteko kluster bat sortzen duzu aplikazio jakin baten instantzia guztientzat:
Aplikazio bakoitzeko multzoa
Bide hau printzipioaren orokortzetzat har daiteke βtalde bakoitzeko kluster bereiziaβ, normalean ingeniari talde bat aplikazio bat edo gehiago garatzen ari baita.
Ikus ditzagun ikuspegi honen alde onak eta txarrak.
+ Klusterra aplikaziora egokitu daiteke
Aplikazio batek behar bereziak baditu, kluster batean inplementa daitezke beste kluster eraginik gabe.
Behar horiek GPU langileak, CNI plugin batzuk, zerbitzu sare bat edo beste zerbitzuren bat izan ditzakete.
Kluster bakoitza bertan exekutatzen den aplikaziora egokitu daiteke, behar dena soilik eduki dezan.
β Ingurune desberdinak kluster batean
Ikuspegi honen desabantaila da ingurune ezberdinetako aplikazio-instantziak elkarrekin bizi direla kluster berean.
Adibidez, aplikazioaren prod bertsioa garatzaileen bertsioaren kluster berean exekutatzen da. Horrek esan nahi du garatzaileek aplikazioaren ekoizpen-bertsioa lantzen den kluster berean funtzionatzen dutela.
Garatzaileen ekintzen edo garatzaileen bertsioan akatsen ondorioz, klusterrean hutsegite bat gertatzen bada, prod bertsioak ere jasan dezake - ikuspegi honen eragozpen handia.
Eta azkenik, gure zerrendako azken eszenatokia.
4. Ingurune bakoitzeko kluster bat
Egoera honek ingurune bakoitzerako kluster bereizi bat esleitzea dakar:
Ingurune bakoitzeko kluster bat
Adibidez, klusterrak izan ditzakezu dev, test ΠΈ prod, eta bertan ingurune zehatz bati eskainitako aplikazioaren instantzia guztiak exekutatuko dituzu.
Hona hemen planteamendu honen alde onak eta txarrak.
+ Prod ingurunearen isolamendua
Planteamendu horren barruan, ingurune guztiak elkarrengandik isolatuta daude. Hala ere, praktikan hori bereziki garrantzitsua da produktuen ingurune batean.
Aplikazioaren ekoizpen-bertsioak beste kluster eta ingurune batzuetan gertatzen denarekiko independenteak dira orain.
Horrela, bat-batean arazoren bat sortzen bada garatzaileen klusterrean, aplikazioen produktuen bertsioek ezer gertatuko ez balitz bezala funtzionatzen jarraituko dute.
+ Klusterra ingurunera egokitu daiteke
Kluster bakoitza bere ingurunera egokitu daiteke. Adibidez, egin dezakezu:
- garapenerako eta arazketarako tresnak instalatu garatzaileen klusterrean;
- instalatu proba-esparruak eta tresnak klusterrean test;
- erabili hardware eta sareko kanal indartsuagoak klusterrean prod.
Horri esker, aplikazioen garapenaren eta funtzionamenduaren eraginkortasuna areagotu dezakezu.
+ Produkzio-klustererako sarbidea mugatzea
Produkzio-kluster batekin zuzenean lan egin beharra oso gutxitan sortzen da, beraz, sarbidea duten pertsonen zirkulua nabarmen mugatu dezakezu.
Are urrunago joan eta jendeari kluster honetara sarbidea ukatu eta inplementazio guztiak egin ditzakezu CI/CD tresna automatizatu bat erabiliz. Ikuspegi horrek giza akatsen arriskua gutxituko du garrantzitsuen den tokian.
Eta orain txarrei buruzko hitz batzuk.
β Aplikazioen arteko isolamendurik ez
Planteamenduaren desabantaila nagusia aplikazioen arteko hardware eta baliabideen isolamendu falta da.
Loturarik gabeko aplikazioek kluster baliabideak partekatzen dituzte: sistemaren nukleoa, prozesadorea, memoria eta beste zenbait zerbitzu.
Esan bezala, hau arriskutsua izan daiteke.
β Aplikazioen mendekotasunak lokalizatzeko ezintasuna
Aplikazio batek baldintza bereziak baditu, kluster guztietan bete behar dira.
Adibidez, aplikazio batek GPU bat behar badu, kluster bakoitzak gutxienez GPU duen langile bat eduki behar du (nahiz eta aplikazio horrek bakarrik erabiltzen duen).
Ondorioz, kostu handiagoak eta baliabideen erabilera ez eraginkorra arriskuan jartzen ditugu.
Ondorioa
Aplikazio multzo zehatz bat baduzu, hainbat multzo handitan edo txiki askotan jar daitezke.
Artikuluak hainbat ikuspegiren alde onak eta txarrak aztertzen ditu, mundu mailako kluster batetik hasita hainbat txiki eta oso espezializatuetara:
- multzo orokor handi bat;
- oso espezializatutako kluster txiki asko;
- kluster bat aplikazio bakoitzeko;
- kluster bat ingurune bakoitzeko.
Beraz, zein ikuspegi hartu behar duzu?
Beti bezala, erantzuna erabilera kasuaren araberakoa da: ikuspegi ezberdinen alde onak eta txarrak neurtu eta aukerarik egokiena aukeratu behar duzu.
Hala ere, aukera ez da goiko adibideetara mugatzen - horien edozein konbinazio erabil dezakezu!
Adibidez, talde bakoitzerako pare bat kluster antola ditzakezu: garapen kluster bat (inguruak egongo diren horretan dev ΠΈ test) eta kluster for ekoizpen (non kokatuko den ekoizpen ingurunea).
Artikulu honetako informazioan oinarrituta, abantailak eta txarrak optimiza ditzakezu eszenatoki zehatz baterako. Zorte on!
PS
Irakurri ere gure blogean:
- «»;
- «»;
- «»;
- Β«'.
Iturria: www.habr.com