Notu. transl.: ĉi tiu materialo estas el eduka projekto estas la respondo al populara demando dum desegnado de Kubernetes-bazita infrastrukturo. Ni esperas, ke sufiĉe detalaj priskriboj de la avantaĝoj kaj malavantaĝoj de ĉiu opcio helpos vin fari la plej bonan elekton por via projekto.
TL; DR: la sama aro de laborŝarĝoj povas esti rulita sur pluraj grandaj aretoj (ĉiu areto havos grandan nombron da laborŝarĝoj) aŭ sur multaj malgrandaj (kun malgranda nombro da ŝarĝoj en ĉiu areto).
Malsupre estas tabelo, kiu taksas la avantaĝojn kaj malavantaĝojn de ĉiu aliro:
Kiam oni uzas Kubernetes kiel platformon por ruli aplikojn, ofte aperas pluraj fundamentaj demandoj pri la komplikaĵoj de starigo de aretoj:
- Kiom da aretoj mi uzu?
- Kiom grandaj mi faru ilin?
- Kion ĉiu areto devus inkluzivi?
En ĉi tiu artikolo, mi provos respondi ĉiujn ĉi tiujn demandojn analizante la avantaĝojn kaj malavantaĝojn de ĉiu aliro.
Deklaro de demando
Kiel programisto, vi verŝajne disvolvas kaj funkciigas multajn aplikaĵojn samtempe.
Krome, multaj okazoj de ĉi tiuj aplikoj verŝajne funkcias en malsamaj medioj - ekzemple, ĉi tiuj povas esti dev, testo и prod.
La rezulto estas tuta matrico de aplikoj kaj medioj:
Aplikoj kaj Medioj
La supra ekzemplo reprezentas 3 aplikojn kaj 3 mediojn, rezultigante entute 9 eblajn opciojn.
Ĉiu aplikaĵo estas memstara deploja unuo kun kiu povas esti laborita sendepende de aliaj.
notu tion petskribo de aplikaĵo povas konsisti el multaj komponantoj, kiel fasado, backend, datumbazo ktp. En la kazo de mikroservo-aplikaĵo, la petskribo inkludos ĉiujn mikroservojn.
Kiel rezulto, uzantoj de Kubernetes havas plurajn demandojn:
- Ĉu ĉiuj aplikaĵkazoj estu metitaj en unu areton?
- Ĉu indas havi apartan areton por ĉiu aplikaĵa okazo?
- Aŭ eble kombinaĵo de la supraj aliroj devus esti uzata?
Ĉiuj ĉi tiuj opcioj estas sufiĉe realigeblaj, ĉar Kubernetes estas fleksebla sistemo, kiu ne limigas la kapablojn de la uzanto.
Jen kelkaj el la eblaj manieroj:
- unu granda komuna areto;
- multaj malgrandaj tre specialigitaj aretoj;
- unu areto per aplikaĵo;
- unu areto per medio.
Kiel montrite malsupre, la unuaj du aliroj estas ĉe kontraŭaj finoj de la skalo de opcioj:
De kelkaj grandaj aretoj (maldekstre) ĝis multaj malgrandaj (dekstre)
Ĝenerale, unu areto estas konsiderita "pli granda" ol alia se ĝi havas pli grandan sumon de nodoj kaj balgoj. Ekzemple, areto kun 10 nodoj kaj 100 balgoj estas pli granda ol areto kun 1 nodo kaj 10 balgoj.
Nu, ni komencu!
1. Unu granda komuna areto
La unua opcio estas meti ĉiujn laborŝarĝojn en unu areton:
Unu granda areto
Ene de tiu aliro, la areto estas utiligita kiel universalaĵo infrastruktura platformo — vi simple disfaldas ĉion, kion vi bezonas en ekzistanta Kubernetes-grupo.
Kubernetes permesas al partoj de la areto esti logike apartigitaj unu de la alia, tiel ke ĉiu aplikaĵo povas havi sian propran nomspacon.
Ni rigardu la avantaĝojn kaj malavantaĝojn de ĉi tiu aliro.
+ Efika uzo de rimedoj
Kun ununura areto, vi bezonas nur unu kopion de ĉiuj rimedoj bezonataj por funkcii kaj administri la Kubernetes-grupon.
Ekzemple, ĉi tio validas por majstraj nodoj. Tipe, ĉiu Kubernetes-areto havas 3 majstrajn nodojn, do por unu ununura areto ilia nombro restos tiel (por komparo, 10 aretoj bezonos 30 majstrajn nodojn).
Ĉi-supra subtileco validas ankaŭ por aliaj servoj funkciigantaj tra la tuta areto, kiel ŝarĝbalanciloj, Ingress-regiloj, aŭtentikigado, registrad- kaj monitoradsistemoj.
En ununura areto, ĉiuj ĉi tiuj servoj povas esti uzataj samtempe por ĉiuj laborŝarĝoj (ne necesas krei kopiojn de ili, kiel estas la kazo kun pluraj aretoj).
+ Malmultekosta
Kiel sekvo de ĉi-supra, pli malmultaj aretoj estas kutime pli malmultekostaj ĉar ekzistas neniuj superkostoj.
Ĉi tio estas precipe vera por majstraj nodoj, kiuj povas kosti gravan kvanton da mono sendepende de kiel ili estas gastigitaj (surloke aŭ en la nubo).
Iuj administris servojn de Kubernetes, kiel ekzemple aŭ , provizi la kontroltavolon senpage. En ĉi tiu kazo, la kosta problemo estas malpli akra.
Estas ankaŭ administritaj servoj, kiuj pagas fiksan kotizon por la funkciado de ĉiu Kubernetes-areto (ekzemple, ).
+ Efika administrado
Administri unu areton estas pli facila ol administri plurajn.
Administrado povas inkluzivi la sekvajn taskojn:
- Kubernetes versio ĝisdatigo;
- starigi CI/KD-dukton;
- instali la kromprogramon CNI;
- starigi uzantan aŭtentikigsistemon;
- instalado de alirregilo;
kaj multaj aliaj...
En la kazo de unu areto, vi devos fari ĉion ĉi nur unufoje.
Por multaj aretoj, operacioj devos esti ripetitaj multfoje, kio verŝajne postulos iun aŭtomatigon de procezoj kaj iloj por certigi konsistencon kaj konsistencon en la procezo.
Kaj nun kelkajn vortojn pri la malavantaĝoj.
− Ununura punkto de fiasko
En kazo de rifuzo la sola la areto ĉesos funkcii tuj ĉiuj laborŝarĝoj!
Estas multaj manieroj, kiel aferoj povas misfunkcii:
- ĝisdatigi Kubernetes kondukas al neatenditaj kromefikoj;
- Tutgrupo (ekzemple, CNI-kromaĵo) komencas ne funkcii kiel atendite;
- unu el la aretkomponentoj ne estas agordita ĝuste;
- fiasko en la subesta infrastrukturo.
Unu tia okazaĵo povas kaŭzi gravan damaĝon al ĉiuj laborkvantoj gastigitaj en komuna areto.
− Neniu rigida izolado
Kuri en komuna areto signifas, ke aplikaĵoj dividas la aparataron, interkonektajn kapablojn kaj operaciumon sur la aretnodoj.
Iasence, du ujoj kun du malsamaj aplikoj kurantaj sur la sama nodo estas kiel du procezoj kurantaj sur la sama maŝino kuranta la saman OS-kernon.
Linuksaj ujoj disponigas iun formon de izolado, sed ĝi ne estas preskaŭ tiel forta kiel tiu provizita de, ekzemple, virtualaj maŝinoj. Esence, procezo en ujo estas la sama procezo funkcianta sur la mastruma mastruma sistemo.
Tio povas esti sekurecproblemo: ĉi tiu aranĝo teorie permesas al senrilataj aplikoj komuniki unu kun la alia (ĉu intence aŭ hazarde).
Aldone, ĉiuj laborŝarĝoj en Kubernetes-areto dividas iujn tutnivelajn servojn kiel ekzemple - ĉi tio permesas al aplikaĵoj trovi Servojn de aliaj aplikoj en la areto.
Ĉiuj ĉi-supraj punktoj povas havi malsamajn signifojn depende de la aplikaj sekurecaj postuloj.
Kubernetes provizas diversajn ilojn por malhelpi sekurecajn problemojn kiel ekzemple и . Tamen, agordi ilin ĝuste postulas iom da sperto; krome, ili ne kapablas fermi absolute ĉiujn sekurecajn truojn.
Gravas ĉiam memori, ke Kubernetes estis origine desegnita por kundivido, ne por izoleco kaj sekureco.
− Manko de strikta plurluado
Konsiderante la abundo de komunaj rimedoj en Kubernetes-areto, ekzistas multaj manieroj, ke malsamaj aplikoj povas paŝi unu la alian.
Ekzemple, aplikaĵo povus monopoligi komunan rimedon (kiel CPU aŭ memoro) kaj nei aliajn aplikojn kurantajn sur la sama noda aliro al ĝi.
Kubernetes disponigas diversajn mekanismojn por kontroli ĉi tiun konduton, kiel ekzemple (vidu ankaŭ la artikolon ""- ĉ. traduk.), и . Tamen, kiel en la kazo de sekureco, ilia agordo estas sufiĉe ne bagatela kaj ili ne kapablas malhelpi absolute ĉiujn neantaŭviditajn kromefikojn.
− Granda nombro da uzantoj
En la kazo de ununura areto, vi devas malfermi aliron al ĝi al multaj homoj. Kaj ju pli granda estas ilia nombro, des pli alta estas la risko, ke ili "rompos" ion.
Ene de la areto vi povas kontroli kiu povas fari kion uzante (vidu artikolon ""- ĉ. traduk.). Tamen, ĝi ne malhelpos uzantojn "rompi" ion ene de la limoj de sia areo de respondeco.
− Aretoj ne povas kreski senfine
La areto kiu estas uzata por ĉiuj laborŝarĝoj verŝajne estos sufiĉe granda (laŭ nombro da nodoj kaj podoj).
Sed ĉi tie aperas alia problemo: aretoj en Kubernetes ne povas kreski senfine.
Ekzistas teoria limo sur aretgrandeco. En Kubernetes ĝi estas proksimume .
Tamen, en la reala vivo, problemoj povas komenciĝi multe pli frue - ekzemple, nur kun .
La fakto estas, ke grandaj aretoj metas altan ŝarĝon sur la kontroltavolo de Kubernetes. Alivorte, konservi la areton funkcianta efike postulas zorgan agordon.
Ĉi tiu afero estas esplorita en rilata artikolo en la origina blogo nomita "".
Sed ni konsideru la kontraŭan aliron: multajn malgrandajn aretojn.
2. Multaj malgrandaj, fakaj aretoj
Kun ĉi tiu aliro, vi uzas apartan areton por ĉiu elemento, kiun vi deplojas:
Multaj malgrandaj aretoj
Por la celoj de ĉi tiu artikolo, sub deplojebla elemento rilatas al kazo de aplikaĵo - ekzemple, dev-versio de aparta aplikaĵo.
Ĉi tiu strategio uzas Kubernetes kiel specialigita rultempo por individuaj aplikaj okazoj.
Ni rigardu la avantaĝojn kaj malavantaĝojn de ĉi tiu aliro.
+ Limigita "eksploda radiuso"
Kiam areto malsukcesas, la negativaj sekvoj estas limigitaj nur al tiuj laborkvantoj kiuj estis deplojitaj en tiu areto. Ĉiuj aliaj laborŝarĝoj restas netuŝitaj.
+ Izolaĵo
Laborŝarĝoj gastigitaj en individuaj aretoj ne dividas rimedojn kiel procesoro, memoro, operaciumo, reto aŭ aliaj servoj.
La rezulto estas strikta izolado inter senrilataj aplikoj, kiuj povas esti utilaj por ilia sekureco.
+ Malgranda nombro da uzantoj
Konsiderante ke ĉiu areto enhavas nur limigitan aron de laborŝarĝoj, la nombro da uzantoj kun aliro al ĝi estas reduktita.
Ju malpli da homoj havas aliron al la areto, des pli malalta estas la risko, ke io "rompiĝos".
Ni rigardu la malavantaĝojn.
− Malefika uzo de rimedoj
Kiel menciite antaŭe, ĉiu Kubernetes-areto postulas specifan aron de administraj rimedoj: majstraj nodoj, kontroltavolaj komponantoj, monitorado kaj registradsolvoj.
En la kazo de granda nombro da malgrandaj aretoj, pli granda parto de resursoj devas esti asignita al administrado.
− Multekosta
Malefika uzo de rimedoj aŭtomate kunportas altajn kostojn.
Ekzemple, konservi 30 majstrajn nodojn anstataŭe de tri kun la sama komputa potenco nepre influos kostojn.
− Malfacilaĵoj en administrado
Administri plurajn Kubernetes-aretojn estas multe pli malfacila ol administri nur unu.
Ekzemple, vi devos agordi aŭtentikigon kaj rajtigon por ĉiu areto. Ankaŭ la versio de Kubernetes devos esti ĝisdatigita plurfoje.
Vi verŝajne devos uzi aŭtomatigon por fari ĉiujn ĉi tiujn taskojn pli efikaj.
Nun ni rigardu malpli ekstremajn scenarojn.
3. Unu areto per aplikaĵo
En ĉi tiu aliro, vi kreas apartan areton por ĉiuj okazoj de aparta aplikaĵo:
Areto per aplikaĵo
Ĉi tiu vojo povas esti konsiderata kiel ĝeneraligo de la principo "aparta areto per teamo”, ĉar kutime teamo de inĝenieroj disvolvas unu aŭ plurajn aplikojn.
Ni rigardu la avantaĝojn kaj malavantaĝojn de ĉi tiu aliro.
+ La areto povas esti alĝustigita al la aplikaĵo
Se aplikaĵo havas specialajn bezonojn, ili povas esti efektivigitaj en areto sen influi aliajn aretojn.
Tiaj bezonoj povas inkluzivi GPU-laboristojn, certajn CNI-kromaĵojn, servomaŝon aŭ iun alian servon.
Ĉiu areto povas esti adaptita al la aplikaĵo kuranta en ĝi tiel ke ĝi enhavas nur tion, kio estas bezonata.
− Malsamaj medioj en unu areto
La malavantaĝo de tiu aliro estas ke aplikaĵkazoj de malsamaj medioj kunekzistas en la sama areto.
Ekzemple, la prod-versio de la aplikaĵo funkcias en la sama areto kiel la dev-versio. Ĉi tio ankaŭ signifas, ke programistoj funkcias en la sama areto, en kiu funkcias la produktadversio de la aplikaĵo.
Se, pro agoj de programistoj aŭ misfunkciadoj en la dev-versio, fiasko okazas en la areto, tiam ankaŭ la prod-versio povus suferi - grandega malavantaĝo de ĉi tiu aliro.
Kaj fine, la lasta scenaro en nia listo.
4. Unu areto per medio
Ĉi tiu scenaro implikas asigni apartan areton por ĉiu medio:
Unu areto per medio
Ekzemple, vi eble havas aretojn dev, testo и prod, en kiu vi rulos ĉiujn okazojn de la aplikaĵo dediĉita al specifa medio.
Jen la avantaĝoj kaj malavantaĝoj de ĉi tiu aliro.
+ Izoliĝo de la prod-medio
Ene de ĉi tiu aliro, ĉiuj medioj estas izolitaj unu de la alia. Tamen, en praktiko tio estas precipe grava en prod-medio.
Produktaj versioj de la aplikaĵo nun estas sendependaj de kio okazas en aliaj aretoj kaj medioj.
Tiel, se problemo subite ekestas en la dev-grupo, la prod-versioj de la aplikaĵoj daŭre funkcios kvazaŭ nenio estus okazinta.
+ La areto povas esti ĝustigita al la medio
Ĉiu areto povas esti alĝustigita al sia medio. Ekzemple, vi povas:
- instali ilojn por disvolviĝo kaj senararigado en la dev-grupo;
- instali testajn kadrojn kaj ilojn en la areto testo;
- uzu pli potencajn aparataron kaj retajn kanalojn en la areto prod.
Ĉi tio ebligas al vi pliigi la efikecon de ambaŭ aplikaj disvolviĝo kaj funkciado.
+ Limigante aliron al la produktada areto
La bezono labori rekte kun prod-grupo malofte aperas, do vi povas signife limigi la cirklon de homoj, kiuj havas aliron al ĝi.
Vi povas iri eĉ plu kaj rifuzi al homoj aliron al ĉi tiu aro entute, kaj plenumi ĉiujn disfaldiĝojn per aŭtomatigita CI/KD-ilo. Tia aliro minimumigos la riskon de homaj eraroj ĝuste kie ĝi estas plej grava.
Kaj nun kelkajn vortojn pri la malavantaĝoj.
− Neniu izolado inter aplikoj
La ĉefa malavantaĝo de la aliro estas la manko de aparataro kaj rimedizolado inter aplikoj.
Senrilataj aplikoj dividas aretresursojn: la sistemkerno, procesoro, memoro, kaj iuj aliaj servoj.
Kiel menciite, ĉi tio povas esti danĝera.
− Nekapablo lokalizi aplikajn dependecojn
Se aplikaĵo havas specialajn postulojn, tiam ili devas esti kontentigitaj tra ĉiuj aretoj.
Ekzemple, se aplikaĵo postulas GPU, tiam ĉiu areto devas enhavi almenaŭ unu laboriston kun GPU (eĉ se ĝi estas uzata nur de tiu aplikaĵo).
Kiel rezulto, ni riskas pli altajn kostojn kaj malefikan uzon de rimedoj.
konkludo
Se vi havas specifan aron da aplikoj, ili povas esti metitaj en plurajn grandajn aretojn aŭ multajn malgrandajn.
La artikolo diskutas la avantaĝojn kaj malavantaĝojn de diversaj aliroj, intervalante de unu tutmonda areto ĝis pluraj malgrandaj kaj tre specialigitaj:
- unu granda ĝenerala areto;
- multaj malgrandaj tre specialigitaj aretoj;
- unu areto per aplikaĵo;
- unu areto per medio.
Do kiun aliron vi devas preni?
Kiel ĉiam, la respondo dependas de la uzokazo: vi devas pesi la avantaĝojn kaj malavantaĝojn de malsamaj aliroj kaj elekti la plej optimuman opcion.
Tamen, la elekto ne estas limigita al la supraj ekzemploj - vi povas uzi ajnan kombinaĵon de ili!
Ekzemple, vi povas organizi kelkajn aretojn por ĉiu teamo: evoluklapo (en kiu estos medioj dev и testo) kaj areto por produktado (kie lokiĝos la produktadmedio).
Surbaze de la informoj en ĉi tiu artikolo, vi povas optimumigi la avantaĝojn kaj malavantaĝojn laŭe por specifa scenaro. Bonŝancon!
PS
Legu ankaŭ en nia blogo:
- «»;
- «»;
- «»;
- «".
fonto: www.habr.com