Noat. transl.: dit materiaal is fan in edukatyf projekt is it antwurd op in populêre fraach by it ûntwerpen fan Kubernetes-basearre ynfrastruktuer. Wy hoopje dat frij detaillearre beskriuwingen fan 'e foar- en neidielen fan elke opsje jo sille helpe om de bêste kar te meitsjen foar jo projekt.
TL; DR: deselde set wurkloads kin wurde útfierd op ferskate grutte klusters (elk kluster sil in grut oantal wurkloads hawwe) of op in protte lytse (mei in lyts oantal loads yn elk kluster).
Hjirûnder is in tabel dy't de foar- en neidielen fan elke oanpak evaluearret:
By it brûken fan Kubernetes as platfoarm foar it útfieren fan applikaasjes, komme faak ferskate fûnemintele fragen op oer de kompleksjes fan it opsetten fan klusters:
- Hoefolle klusters moat ik brûke?
- Hoe grut moat ik meitsje se?
- Wat moat elk kluster befetsje?
Yn dit artikel sil ik besykje al dizze fragen te beantwurdzjen troch de foar- en neidielen fan elke oanpak te analysearjen.
Ferklearring fan in fraach
As software-ûntwikkelder ûntwikkelje en operearje jo wierskynlik in protte applikaasjes tagelyk.
Derneist sille in protte eksimplaren fan dizze applikaasjes wierskynlik yn ferskate omjouwings rinne - dit kinne bygelyks wêze dev, toets и produksje.
It resultaat is in hiele matrix fan tapassingen en omjouwings:
Applikaasjes en omjouwings
It foarbyld hjirboppe fertsjintwurdiget 3 applikaasjes en 3 omjouwings, wat resulteart yn in totaal fan 9 mooglike opsjes.
Elke applikaasje eksimplaar is in selsstannige ynset ienheid dy't kin wurde wurke mei ûnôfhinklik fan oaren.
notysje dat applikaasje eksimplaar kin út in protte bestean Komponinten, lykas frontend, backend, database, ensfh. Yn it gefal fan in applikaasje foar mikrotsjinsten sil it eksimplaar alle mikrotsjinsten omfetsje.
As gefolch hawwe Kubernetes-brûkers ferskate fragen:
- Moatte alle applikaasje-ynstânsjes yn ien kluster pleatst wurde?
- Is it wurdich in apart kluster te hawwen foar elke applikaasje eksimplaar?
- Of miskien moat in kombinaasje fan boppesteande oanpakken brûkt wurde?
Al dizze opsjes binne frij leefber, om't Kubernetes in fleksibel systeem is dat de mooglikheden fan 'e brûker net beheint.
Hjir binne guon fan 'e mooglike manieren:
- ien grutte mienskiplike kluster;
- in protte lytse tige spesjalisearre klusters;
- ien kluster per applikaasje;
- ien kluster per omjouwing.
Lykas hjirûnder werjûn, binne de earste twa oanpakken oan tsjinoerstelde einen fan 'e skaal fan opsjes:
Fan in pear grutte klusters (lofts) oant in protte lytse (rjochts)
Yn 't algemien wurdt ien kluster as "grutter" beskôge as in oar as it in gruttere som fan knopen en pods hat. Bygelyks, in kluster mei 10 knooppunten en 100 pods is grutter as in kluster mei 1 node en 10 pods.
No, lit ús begjinne!
1. Ien grutte mienskiplike kluster
De earste opsje is om alle workloads yn ien kluster te pleatsen:
Ien grut kluster
Binnen dizze oanpak wurdt it kluster brûkt as in universele ynfrastruktuer platfoarm - jo ynsette gewoan alles wat jo nedich binne yn in besteande Kubernetes-kluster.
Kubernetes lit dielen fan it kluster logysk fan elkoar skieden wurde, sadat elke applikaasje-eksimplaar in eigen nammeromte hawwe kin.
Litte wy nei de foar- en neidielen fan dizze oanpak sjen.
+ Effisjint gebrûk fan boarnen
Mei ien kluster hawwe jo mar ien kopy fan alle boarnen nedich om it Kubernetes-kluster út te fieren en te behearjen.
Dit is bygelyks wier foar masterknooppunten. Typysk hat elk Kubernetes-kluster 3 masterknooppunten, dus foar ien inkelde kluster sil har oantal sa bliuwe (foar fergeliking sille 10 klusters 30 masterknooppunten nedich hawwe).
De boppesteande subtiliteit jildt ek foar oare tsjinsten dy't operearje oer it heule kluster, lykas loadbalancers, Ingress-controllers, autentikaasje, logging en monitoringsystemen.
Yn ien kluster kinne al dizze tsjinsten tagelyk brûkt wurde foar alle workloads (d'r is gjin needsaak om kopyen fan te meitsjen, lykas it gefal is mei meardere klusters).
+ Goedkeap
As gefolch fan boppesteande binne minder klusters meastentiids goedkeaper om't der gjin overheadkosten binne.
Dit is benammen wier foar masterknooppunten, dy't in signifikant bedrach jild kinne kostje, nettsjinsteande hoe't se wurde hosted (on-premises as yn 'e wolk).
Guon beheare Kubernetes-tsjinsten, lykas of , leverje de kontrôlelaach fergees. Yn dit gefal is it kostenprobleem minder akuut.
D'r binne ek beheare tsjinsten dy't in fêste fergoeding rekkenje foar de eksploitaasje fan elke Kubernetes-kluster (bygelyks, ).
+ Effisjinte administraasje
It behearen fan ien kluster is makliker dan it behearen fan ferskate.
Bestjoer kin de folgjende taken omfetsje:
- Kubernetes ferzje update;
- it opsetten fan in CI / CD pipeline;
- it ynstallearjen fan de CNI-plugin;
- it ynstellen fan in brûker autentikaasje systeem;
- ynstallaasje fan in tagong controller;
en in protte oaren…
Yn it gefal fan ien kluster moatte jo dit alles mar ien kear dwaan.
Foar in protte klusters sille operaasjes in protte kearen moatte wurde werhelle, wat wierskynlik wat automatisearring fan prosessen en ark sil fereaskje om konsistinsje en konsistinsje yn it proses te garandearjen.
En no in pear wurden oer de neidielen.
- Ien punt fan mislearring
Yn gefal fan wegering de ienige it kluster sil fuortendaliks ophâlde mei wurkjen allegear wurkdruk!
D'r binne in protte manieren wêrop dingen ferkeard kinne gean:
- bywurkjen fan Kubernetes liedt ta unferwachte side-effekten;
- In klusterwide komponint (bygelyks in CNI-plugin) begjint net te wurkjen lykas ferwachte;
- ien fan 'e klusterkomponinten is net goed ynsteld;
- falen yn 'e ûnderlizzende ynfrastruktuer.
Ien sa'n ynsidint kin serieuze skea feroarsaakje oan alle wurkloads dy't yn in dielde kluster wurde host.
- Gjin stive isolaasje
It rinnen yn in dielde kluster betsjut dat applikaasjes de hardware, netwurkmooglikheden en bestjoeringssysteem diele op 'e klusterknooppunten.
Yn in sin binne twa konteners mei twa ferskillende applikaasjes dy't op deselde knoop rinne, lykas twa prosessen dy't rinne op deselde masine dy't deselde OS-kernel rinne.
Linux-konteners jouwe ien of oare foarm fan isolemint, mar it is net sa sterk as dat fersoarge troch bygelyks firtuele masines. Yn essinsje is in proses yn in kontener itselde proses dat rint op it bestjoeringssysteem fan de host.
Dit kin in feiligensprobleem wêze: dizze regeling lit teoretysk net-relatearre applikaasjes mei-inoar kommunisearje (sawol opsetlik as tafallich).
Derneist diele alle wurkloads yn in Kubernetes-kluster guon klusterwide tsjinsten lykas - dit lit applikaasjes Tsjinsten fan oare applikaasjes yn it kluster fine.
Alle boppesteande punten kinne ferskillende betsjuttingen hawwe ôfhinklik fan 'e feiligenseasken fan' e applikaasje.
Kubernetes leveret ferskate ark om feiligensproblemen te foarkommen lykas и . It goed opsetten fereasket lykwols wat ûnderfining; boppedat binne se net yn steat om absolút alle befeiligingsgaten te sluten.
It is wichtich om altyd te ûnthâlden dat Kubernetes oarspronklik is ûntworpen foar dielen, net foar isolaasje en feiligens.
- Gebrek oan strange multi-tenancy
Sjoen de oerfloed fan dielde boarnen yn in Kubernetes-kluster, binne d'r in protte manieren wêrop ferskate applikaasjes elkoar op 'e teannen kinne stappe.
Bygelyks, in applikaasje kin in dielde boarne monopolisearje (lykas CPU of ûnthâld) en wegerje oare applikaasjes dy't rinne op deselde knooppunt tagong ta it.
Kubernetes leveret ferskate meganismen om dit gedrach te kontrolearjen, lykas (sjoch ek it artikel ""- ca. oerset.), и . Lykwols, lykas yn it gefal fan feiligens, harren konfiguraasje is frij net-triviale en se binne net by steat om te foarkommen absolút alle ûnfoarsjoene kant effekten.
- Grut oantal brûkers
Yn it gefal fan ien kluster moatte jo tagong krije ta it foar in protte minsken. En hoe grutter harren oantal, hoe heger it risiko dat se wat "brekke".
Binnen it kluster kinne jo kontrolearje wa't wat kin dwaan (sjoch artikel ""- ca. oerset.). It sil lykwols net foarkomme dat brûkers wat "brekke" binnen de grinzen fan har ferantwurdlikensgebiet.
- Klusters kinne net foar ûnbepaalde tiid groeie
It kluster dat wurdt brûkt foar alle workloads sil wierskynlik frij grut wêze (yn termen fan oantal knooppunten en pods).
Mar hjir ûntstiet in oar probleem: klusters yn Kubernetes kinne net foar ûnbepaalde tiid groeie.
Der is in teoretyske limyt op kluster grutte. Yn Kubernetes is it sawat .
Lykwols, yn it echte libben, problemen kinne begjinne folle earder - bygelyks, gewoan mei .
It feit is dat grutte klusters in hege lading pleatse op 'e Kubernetes-kontrôlelaach. Mei oare wurden, it hâlden fan it kluster op en effisjint te rinnen fereasket foarsichtige ôfstimming.
Dit probleem wurdt ûndersocht yn in relatearre artikel op it orizjinele blog mei de namme "".
Mar lit ús de tsjinoerstelde oanpak beskôgje: in protte lytse klusters.
2. In protte lytse, spesjalisearre klusters
Mei dizze oanpak brûke jo in apart kluster foar elk elemint dat jo ynsette:
In protte lytse klusters
Foar de doelen fan dit artikel, ûnder ynsetber elemint ferwiist nei in eksimplaar fan in applikaasje - bygelyks in dev ferzje fan in aparte applikaasje.
Dizze strategy brûkt Kubernetes as in spesjalisearre runtime foar yndividuele applikaasje-ynstânsjes.
Litte wy nei de foar- en neidielen fan dizze oanpak sjen.
+ Beheinde "blastradius"
As in kluster mislearret, binne de negative gefolgen allinich beheind ta dy wurklasten dy't yn dat kluster ynset binne. Alle oare wurkdruk bliuwe ûnoantaaste.
+ Isolaasje
Wurklêsten hosted yn yndividuele klusters diele gjin boarnen lykas prosessor, ûnthâld, bestjoeringssysteem, netwurk, of oare tsjinsten.
It resultaat is strakke isolaasje tusken net-relatearre applikaasjes, wat foardielich kin wêze foar har feiligens.
+ Lyts oantal brûkers
Sjoen dat elk kluster mar in beheinde set wurkloads befettet, wurdt it oantal brûkers mei tagong ta it fermindere.
Hoe minder minsken tagong hawwe ta it kluster, hoe leger it risiko dat der wat "brekke".
Litte wy nei de neidielen sjen.
- Ineffisjint gebrûk fan boarnen
Lykas earder neamd, fereasket elk Kubernetes-kluster in spesifike set fan behearboarnen: masterknooppunten, kontrôlelaachkomponinten, tafersjoch- en logging-oplossingen.
By in grut tal lytse klusters moat in grutter part fan de middels oan it behear tawiisd wurde.
- Djoer
Ineffisjint gebrûk fan boarnen bringt automatysk hege kosten mei.
Bygelyks, it behâld fan 30 masterknooppunten ynstee fan trije mei deselde berekkeningskrêft sil needsaaklik beynfloedzje op kosten.
- Swierrichheden yn administraasje
It behearen fan meardere Kubernetes-klusters is folle dreger dan mar ien beheare.
Jo sille bygelyks autentikaasje en autorisaasje moatte ynstelle foar elk kluster. De Kubernetes-ferzje sil ek ferskate kearen bywurke wurde moatte.
Jo sille wierskynlik automatisearring moatte brûke om al dizze taken effisjinter te meitsjen.
Litte wy no nei minder ekstreme senario's sjen.
3. Ien kluster per applikaasje
Yn dizze oanpak meitsje jo in apart kluster foar alle gefallen fan in bepaalde applikaasje:
Cluster per applikaasje
Dit paad kin wurde beskôge as in generalisaasje fan it prinsipe "apart kluster per team”, om't normaal in team fan yngenieurs ien of mear applikaasjes ûntwikkelet.
Litte wy nei de foar- en neidielen fan dizze oanpak sjen.
+ It kluster kin wurde oanpast oan 'e applikaasje
As in applikaasje spesjale behoeften hat, kinne se yn in kluster ymplementearre wurde sûnder oare klusters te beynfloedzjen.
Sokke behoeften kinne GPU-arbeiders, bepaalde CNI-plugins, in tsjinstmesh, of in oare tsjinst omfetsje.
Elk kluster kin wurde oanpast oan 'e applikaasje dy't deryn rint, sadat it allinich befettet wat nedich is.
- Ferskillende omjouwings yn ien kluster
It neidiel fan dizze oanpak is dat tapassingseksimplaren út ferskate omjouwings tegearre bestean yn itselde kluster.
Bygelyks, de prod ferzje fan 'e applikaasje rint yn itselde kluster as de dev ferzje. Dit betsjut ek dat ûntwikkelders wurkje yn itselde kluster wêryn de produksjeferzje fan 'e applikaasje wurdt eksploitearre.
As, fanwege de aksjes fan ûntwikkelders of glitches yn 'e dev-ferzje, in mislearring yn it kluster optreedt, dan kin de prod-ferzje ek potensjeel lije - in enoarm neidiel fan dizze oanpak.
En as lêste, it lêste senario op ús list.
4. Ien kluster per omjouwing
Dit senario omfettet it tawizen fan in apart kluster foar elke omjouwing:
Ien kluster per omjouwing
Jo kinne bygelyks klusters hawwe dev, toets и produksje, wêryn jo alle eksimplaren fan 'e applikaasje útfiere wijd oan in spesifike omjouwing.
Hjir binne de foar- en neidielen fan dizze oanpak.
+ Isolaasje fan 'e prod-omjouwing
Binnen dizze oanpak binne alle omjouwings fan elkoar isolearre. Yn 'e praktyk is dit lykwols benammen wichtich yn in prod-omjouwing.
Produksjeferzjes fan 'e applikaasje binne no ûnôfhinklik fan wat der bart yn oare klusters en omjouwings.
Op dizze manier, as der ynienen in probleem ûntstiet yn it dev-kluster, sille de prod-ferzjes fan 'e applikaasjes trochgean te wurkjen as wie neat bard.
+ It kluster kin wurde oanpast oan 'e omjouwing
Elk kluster kin oanpast wurde oan har omjouwing. Jo kinne bygelyks:
- ynstallearje ark foar ûntwikkeling en debuggen yn de dev kluster;
- ynstallearje testkaders en ark yn it kluster toets;
- brûk machtiger hardware- en netwurkkanalen yn it kluster produksje.
Hjirmei kinne jo de effisjinsje fan sawol applikaasjeûntwikkeling as operaasje ferheegje.
+ Beheine tagong ta it produksjekluster
De needsaak om direkt te wurkjen mei in prod-kluster komt komselden foar, sadat jo de sirkel fan minsken dy't tagong hawwe ta signifikant beheine kinne.
Jo kinne gean noch fierder en wegerje minsken tagong ta dit kluster hielendal, en útfiere alle ynset mei help fan in automatisearre CI / CD ark. Sa'n oanpak sil it risiko op minsklike flaters sa min mooglik meitsje wêr't it it meast relevant is.
En no in pear wurden oer de neidielen.
- Gjin isolaasje tusken applikaasjes
It wichtichste neidiel fan 'e oanpak is it gebrek oan hardware- en boarne-isolaasje tusken applikaasjes.
Net-relatearre applikaasjes diele klusterboarnen: de systeemkearn, prosessor, ûnthâld, en guon oare tsjinsten.
Lykas sein, dit kin wêze potinsjeel gefaarlik.
- Unfermogen om tapassingsôfhinklikens te lokalisearjen
As in applikaasje spesjale easken hat, dan moatte se oer alle klusters tefreden wêze.
Bygelyks, as in applikaasje in GPU fereasket, dan moat elk kluster op syn minst ien arbeider mei in GPU befetsje (sels as it allinich troch dy applikaasje wurdt brûkt).
As gefolch riskearje wy hegere kosten en ineffisjint gebrûk fan boarnen.
konklúzje
As jo in spesifike set fan applikaasjes, se kinne wurde pleatst yn ferskate grutte klusters of in protte lytse.
It artikel besprekt de foar- en neidielen fan ferskate oanpak, fariearjend fan ien wrâldwide kluster oant ferskate lytse en tige spesjalisearre:
- ien grutte algemiene kluster;
- in protte lytse tige spesjalisearre klusters;
- ien kluster per applikaasje;
- ien kluster per omjouwing.
Dus hokker oanpak moatte jo nimme?
Lykas altyd hinget it antwurd ôf fan 'e gebrûksgefal: jo moatte de foar- en neidielen fan ferskate oanpak weagje en de meast optimale opsje kieze.
De kar is lykwols net beheind ta de foarbylden hjirboppe - jo kinne elke kombinaasje fan har brûke!
Jo kinne bygelyks in pear klusters foar elk team organisearje: in ûntwikkelingskluster (dêr't omjouwings yn sille wêze dev и toets) en kluster foar produksje (wêr't de produksjeomjouwing lizze sil).
Op grûn fan 'e ynformaasje yn dit artikel kinne jo de foar- en neidielen neffens in spesifyk senario optimalisearje. Súkses!
PS
Lês ek op ús blog:
- «";
- «";
- «";
- «".
Boarne: www.habr.com