Let wel. vertaal.: hierdie materiaal is van 'n opvoedkundige projek - die antwoord op 'n gewilde vraag by die ontwerp van infrastruktuur gebaseer op Kubernetes. Ons hoop dat voldoende gedetailleerde beskrywings van die voor- en nadele van elk van die opsies jou sal help om die beste keuse vir jou projek te maak.
TL; DR: dieselfde stel werkladings kan op verskeie groot groepe uitgevoer word (elke groepering sal 'n groot aantal werkladings hê) of op baie kleintjies (met 'n klein aantal werkladings in elke groepering).
Hieronder is 'n tabel wat die voor- en nadele van elke benadering evalueer:
Wanneer Kubernetes as 'n platform gebruik word om toepassings te laat loop, is daar dikwels verskeie fundamentele vrae oor die ingewikkeldheid van die opstel van groepe:
- Hoeveel groepe om te gebruik?
- Hoe groot moet jy hulle maak?
- Wat moet elke groep insluit?
In hierdie artikel sal ek probeer om al hierdie vrae te beantwoord deur die voor- en nadele van elke benadering te ontleed.
Verklaring van 'n vraag
As 'n sagteware-ontwikkelaar sal jy waarskynlik baie toepassings in parallel ontwikkel en bedryf.
Daarbenewens sal baie gevalle van hierdie toepassings waarskynlik in verskillende omgewings loop - dit kan byvoorbeeld wees dev, toets и prod.
Die resultaat is 'n hele matriks van toepassings en omgewings:
Toepassings en omgewings
In die voorbeeld hierbo is daar 3 toepassings en 3 omgewings, wat 'n totaal van 9 moontlike opsies tot gevolg het.
Elke toepassingsinstansie is 'n selfstandige ontplooiingseenheid waarmee jy onafhanklik van die ander kan werk.
Let asseblief daarop dat toepassing instansie kan uit baie bestaan komponentesoos frontend, backend, databasis, ens. In die geval van 'n mikrodienstoepassing sal die instansie alle mikrodienste insluit.
As gevolg hiervan het Kubernetes-gebruikers verskeie vrae:
- Moet alle toepassinggevalle op dieselfde groepering gehuisves word?
- Is dit die moeite werd om 'n aparte groepie vir elke toepassingsinstansie te begin?
- Of moet 'n kombinasie van bogenoemde benaderings dalk gebruik word?
Al hierdie opsies is lewensvatbaar, aangesien Kubernetes 'n buigsame stelsel is wat nie die gebruiker se opsies beperk nie.
Hier is 'n paar van die moontlike maniere:
- een groot gemeenskaplike tros;
- baie klein hoogs gespesialiseerde trosse;
- een tros per toediening;
- een groep per omgewing.
Soos hieronder getoon, is die eerste twee benaderings aan die teenoorgestelde punte van die skaal van opsies:
Van 'n paar groot trosse (links) tot baie kleintjies (regs)
Oor die algemeen word dit beskou dat een groep "groter" as 'n ander is as dit meer as die som van nodusse en peule het. Byvoorbeeld, 'n groep met 10 nodusse en 100 peule is groter as 'n groep met 1 nodusse en 10 peule.
Wel, kom ons begin!
1. Een groot gedeelde groep
Die eerste opsie is om alle werkladings in een groep te plaas:
Een groot groepie
Binne hierdie benadering word die cluster as 'n universele gebruik infrastruktuur platform - jy ontplooi eenvoudig alles wat jy nodig het in 'n bestaande Kubernetes-kluster.
Kubernetes laat jou toe om dele van 'n groep logies van mekaar te skei, sodat elke toepassingsinstansie sy eie naamruimte kan gebruik.
Kom ons kyk na die voor- en nadele van hierdie benadering.
+ Doeltreffende gebruik van hulpbronne
In die geval van 'n enkele groepering, sal slegs een kopie van al die hulpbronne nodig wees om die Kubernetes-kluster te bestuur en te bestuur.
Byvoorbeeld, dit is waar vir meester nodusse. Tipies is daar 3 meesternodusse per Kubernetes-kluster, so vir 'n enkele cluster sal hul getal so bly (ter vergelyking sal 10 clusters 30 meesternodusse benodig).
Bogenoemde subtiliteit is ook van toepassing op ander dienste wat oor die hele groep werk, soos lasbalanseerders, ingangbeheerders, verifikasie, aanteken en moniteringstelsels.
In 'n enkele groepering kan al hierdie dienste gelyktydig vir alle werkladings gebruik word (nie behoefte om kopieë daarvan te skep nie, soos in die geval van veelvuldige groeperings).
+ goedkoop
As gevolg van bogenoemde is minder klusters gewoonlik goedkoper omdat daar geen koste vir oortollige hulpbronne is nie.
Dit is veral waar vir meesternodes, wat 'n aansienlike bedrag geld kan kos, hetsy dit op die perseel of in die wolk aangebied word.
Sommige bestuurde Kubernetes-dienste soos of , verskaf die beheerlaag gratis. In hierdie geval is die kostekwessie minder akuut.
Daar is ook bestuurde dienste wat 'n vaste fooi hef vir die werking van elke Kubernetes-kluster (byvoorbeeld, ).
+ Doeltreffende administrasie
Dit is makliker om een groep te bestuur as verskeie.
Administrasie kan die volgende take insluit:
- die opdatering van die weergawe van Kubernetes;
- die opstel van die CI/CD-pyplyn;
- die installering van die CNI-inprop;
- die opstel van 'n gebruikersverifikasiestelsel;
- installering van die toelatingsbeheerder;
en vele ander...
In die geval van 'n enkele groep, sal jy dit alles net een keer moet doen.
Vir baie groepe sal bewerkings baie keer herhaal moet word, wat waarskynlik 'n mate van outomatisering van prosesse en gereedskap sal verg om 'n sistematiese en eenvormige proses te verseker.
En nou 'n paar woorde oor die nadele.
− Enkelpunt van mislukking
In geval van weiering die enigste een clusters sal onmiddellik ophou werk alle werkladings!
Daar is baie opsies vir wanneer iets verkeerd kan loop:
- Kubernetes-opgradering lei tot onverwagte newe-effekte
- 'n groepwye komponent (byvoorbeeld 'n CNI-inprop) begin nie werk soos verwag nie;
- een van die groepkomponente is verkeerd opgestel;
- mislukking in die onderliggende infrastruktuur.
Een so 'n voorval kan ernstige skade veroorsaak aan alle werkladings wat in 'n gemeenskaplike groepering gehuisves word.
− Gebrek aan rigiede isolasie
Om in 'n gedeelde groepering te hardloop, beteken dat toepassings die hardeware, netwerkvermoëns en bedryfstelsel op die groepnodusse deel.
In 'n sekere sin is twee houers met twee verskillende toepassings wat op dieselfde gasheer loop, soos twee prosesse wat op dieselfde masjien loop met dieselfde OS-kern.
Linux-houers bied een of ander vorm van isolasie, maar dit is nie naastenby so sterk soos wat, sê, virtuele masjiene bied nie. In wese is 'n proses in 'n houer dieselfde proses wat op die gasheerbedryfstelsel loop.
Dit kan 'n sekuriteitsprobleem wees: hierdie organisasie laat teoreties toe dat onverwante toepassings met mekaar kommunikeer (opsetlik of per ongeluk).
Daarbenewens deel alle werkladings in 'n Kubernetes-kluster 'n paar groepwye dienste soos - dit laat toepassings toe om dienste van ander toepassings in die groepie te vind.
Al die bogenoemde punte kan verskillende betekenisse hê, afhangende van die toepassingsekuriteitsvereistes.
Kubernetes bied verskeie instrumente om sekuriteitskwessies te voorkom, soos и . Hulle benodig egter 'n bietjie ervaring om behoorlik te konfigureer, en hulle is nie in staat om absoluut alle sekuriteitsgate toe te maak nie.
Dit is belangrik om altyd te onthou dat Kubernetes oorspronklik ontwerp is om deel, nie vir isolasie en sekuriteit.
− Gebrek aan harde multi-huur
Gegewe die oorvloed van gedeelde hulpbronne in 'n Kubernetes-kluster, is daar baie maniere waarop verskillende toepassings op mekaar se tone kan trap.
Byvoorbeeld, 'n toepassing kan 'n gedeelde hulpbron (soos 'n verwerker of geheue) monopoliseer en ander toepassings wat op dieselfde gasheer loop toegang daartoe weier.
Kubernetes verskaf verskeie meganismes om hierdie gedrag te beheer, soos (sien ook die artikel ""- ongeveer. vertaal.), и . Soos in die geval van sekuriteit, is hul konfigurasie egter taamlik nie-triviaal en is hulle nie in staat om absoluut alle onvoorsiene newe-effekte te voorkom nie.
− Groot aantal gebruikers
In die geval van 'n enkele groepering, moet jy toegang daartoe vir baie mense oopmaak. En hoe groter hulle getal, hoe groter is die risiko dat hulle iets sal “breek”.
Binne die cluster kan jy beheer wie waarmee kan doen (sien artikel ""- ongeveer. vertaal.). Dit sal egter nie gebruikers verhinder om iets binne hul verantwoordelikheidsgebied te "breek" nie.
− Klusters kan nie onbepaald groei nie
Die groep wat vir alle werkladings gebruik word, sal waarskynlik redelik groot wees (in terme van aantal nodusse en peule).
Maar hier duik 'n ander probleem op: trosse in Kubernetes kan nie onbepaald groei nie.
Daar is 'n teoretiese beperking op die groepgrootte. In Kubernetes is dit ongeveer .
In die werklike lewe kan probleme egter baie vroeër begin - byvoorbeeld net wanneer .
Die feit is dat groot trosse 'n hoë las op die Kubernetes-beheerlaag plaas. Met ander woorde, noukeurige afstemming is nodig om die groep doeltreffend aan die gang te hou.
Hierdie kwessie word ondersoek in 'n verwante artikel op die oorspronklike blog getiteld "".
Maar kom ons kyk na die teenoorgestelde benadering: baie klein trosse.
2. Baie klein, gespesialiseerde trosse
Met hierdie benadering gebruik jy 'n aparte groepie vir elke item wat jy ontplooi:
Baie klein trosse
Vir die doeleindes van hierdie artikel onder ontplooibare element word verstaan as 'n geval van die toepassing - byvoorbeeld die dev-weergawe van 'n aparte toepassing.
In hierdie strategie word Kubernetes as 'n gespesialiseerde gebruik looptyd vir individuele toepassingsgevalle.
Kom ons kyk na die voor- en nadele van hierdie benadering.
+ Beperkte "ontploffingsradius"
Wanneer 'n groepering "breek", is die negatiewe gevolge beperk tot slegs daardie werkladings wat in hierdie groep ontplooi is. Alle ander werkladings bly onaangeraak.
+ Isolasie
Werkladings wat in individuele groepe gehuisves word, deel nie gemeenskaplike hulpbronne soos verwerker, geheue, bedryfstelsel, netwerk of ander dienste nie.
As gevolg hiervan kry ons 'n sterk isolasie tussen onverwante toepassings, wat voordelig kan wees vir hul sekuriteit.
+ Klein aantal gebruikers
Aangesien elke groep slegs 'n beperkte stel werkladings bevat, word die aantal gebruikers met toegang daartoe verminder.
Hoe minder mense toegang tot die groep het, hoe laer is die risiko dat iets sal “breek”.
Kom ons kyk na die nadele.
− Ondoeltreffende gebruik van hulpbronne
Soos vroeër genoem, benodig elke Kubernetes-kluster 'n sekere stel bestuurshulpbronne: meesternodusse, beheerlaagkomponente, monitering- en logoplossings.
In die geval van 'n groot aantal klein klusters moet 'n groter deel van hulpbronne aan bestuur toegewys word.
− Duur
Ondoeltreffende gebruik van hulpbronne bring outomaties hoë kostes mee.
Byvoorbeeld, die instandhouding van 30 meesternodes in plaas van drie met dieselfde rekenaarkrag sal beslis die koste beïnvloed.
− Probleme van administrasie
Die administrasie van verskeie Kubernetes-klusters is baie moeiliker as om een te bestuur.
Byvoorbeeld, jy sal stawing en magtiging vir elke groep moet opstel. Die opgradering van die Kubernetes-weergawe sal ook verskeie kere gedoen moet word.
Heel waarskynlik sal jy outomatisering moet toepas om die doeltreffendheid van al hierdie take te verhoog.
Oorweeg nou minder ekstreme scenario's.
3. Een tros per toediening
Met hierdie benadering skep jy 'n aparte groepering vir alle gevalle van 'n spesifieke toepassing:
Groepering per toepassing
Hierdie manier kan beskou word as 'n veralgemening van die beginsel "aparte groepie per span” want gewoonlik is ’n span ingenieurs betrokke by die ontwikkeling van een of meer toepassings.
Kom ons kyk na die voor- en nadele van hierdie benadering.
+ Cluster kan aangepas word vir die toepassing
As 'n toepassing spesiale behoeftes het, kan dit in 'n groepering geïmplementeer word sonder om ander groepe te beïnvloed.
Sulke behoeftes kan GPU-werkers, sekere CNI-inproppe, 'n diensnetwerk of 'n ander diens insluit.
Elke groepering kan aangepas word vir die toepassing wat daarop loop om net te bevat wat nodig is.
− Verskillende omgewings in een groep
Die nadeel van hierdie benadering is dat toepassingsgevalle uit verskillende omgewings in dieselfde groepie saam bestaan.
Byvoorbeeld, die prod-weergawe van 'n toepassing loop op dieselfde cluster as die dev-weergawe. Dit beteken ook dat die ontwikkelaars in dieselfde groep werk as die produksieweergawe van die toepassing.
As die groep misluk as gevolg van die optrede van ontwikkelaars of foute in die dev-weergawe, dan kan die prod-weergawe ook ly - 'n groot nadeel van hierdie benadering.
En uiteindelik, die laaste scenario op ons lys.
4. Een groep per omgewing
Hierdie scenario maak voorsiening vir die toekenning van 'n aparte groepering vir elke omgewing:
Een groep per omgewing
Byvoorbeeld, jy kan trosse hê dev, toets и prod, waarin jy alle gevalle van die toepassing sal laat loop wat vir 'n spesifieke omgewing bedoel is.
Hier is die voor- en nadele van hierdie benadering.
+ Isolasie van die prod-omgewing
Binne hierdie benadering is alle omgewings van mekaar geïsoleer. In die praktyk is dit egter veral belangrik vir die prod-omgewing.
Produksieweergawes van die toepassing is nou onafhanklik van wat in ander groepe en omgewings gebeur.
Dus, as 'n probleem skielik in die dev cluster opduik, sal die prod weergawes van die toepassings aanhou werk asof niks gebeur het nie.
+ Cluster kan by die omgewing aangepas word
Elke groepering kan aangepas word vir sy omgewing. Byvoorbeeld, jy kan:
- installeer gereedskap vir ontwikkeling en ontfouting in die dev-groepering;
- installeer toetsraamwerke en gereedskap op die groepering toets;
- gebruik kragtiger hardeware en netwerkskakels in die groepering prod.
Dit verbeter die doeltreffendheid van beide toepassingsontwikkeling en bedryf.
+ Beperk toegang tot die produksiekluster
Die behoefte om direk met 'n produkgroepering te werk, kom nie gereeld voor nie, so jy kan die kring van mense wat toegang daartoe het aansienlik beperk.
Jy kan selfs verder gaan en mense heeltemal van toegang tot hierdie groepering ontneem, en alle ontplooiings doen met behulp van 'n outomatiese CI / CD-instrument. So 'n benadering sal die risiko van menslike foute verminder presies waar dit die relevantste is.
En nou 'n paar woorde oor die nadele.
− Gebrek aan isolasie tussen toepassings
Die grootste nadeel van die benadering is die gebrek aan hardeware en hulpbron-isolasie tussen toepassings.
Onverwante toepassings deel groephulpbronne: stelselkern, verwerker, geheue en sommige ander dienste.
Soos reeds genoem, kan dit potensieel gevaarlik wees.
− Onvermoë om toepassingsafhanklikhede te lokaliseer
As die aansoek spesiale vereistes het, moet daar in alle groepe aan hulle voldoen word.
Byvoorbeeld, as 'n toepassing 'n GPU benodig, moet elke groep ten minste een werker met 'n GPU bevat (selfs al word dit slegs deur hierdie toepassing gebruik).
Gevolglik waag ons hoër koste en ondoeltreffende gebruik van hulpbronne.
Gevolgtrekking
As jy 'n sekere stel toepassings het, kan hulle in verskeie groot groepe of in baie kleins geplaas word.
Die artikel bespreek die voor- en nadele van verskeie benaderings, wat wissel van een globale groepering tot verskeie klein en hoogs gespesialiseerdes:
- een groot gemeenskaplike tros;
- baie klein hoogs gespesialiseerde trosse;
- een tros per toediening;
- een groep per omgewing.
So watter benadering moet jy kies?
Soos gewoonlik hang die antwoord af van die gebruiksgeval: jy moet die voor- en nadele van verskillende benaderings weeg en die beste opsie kies.
Die keuse is egter nie beperk tot die voorbeelde hierbo nie - jy kan enige kombinasie daarvan gebruik!
Byvoorbeeld, jy kan 'n groep groepe vir elke span organiseer: 'n groep vir ontwikkeling (wat omgewings sal hê dev и toets) en 'n groepie vir produksie (waar die produksie-omgewing sal wees).
Op grond van die inligting in hierdie artikel, sal u die voor- en nadele dienooreenkomstig vir 'n spesifieke scenario kan optimaliseer. Sterkte!
PS
Lees ook op ons blog:
- «»;
- «»;
- «»;
- «".
Bron: will.com