Obs. övers.: detta material kommer frĂ„n ett utbildningsprojekt â svaret pĂ„ en populĂ€r frĂ„ga vid utformningen av infrastruktur baserad pĂ„ Kubernetes. Vi hoppas att de tillrĂ€ckligt utförliga beskrivningarna av fördelar och nackdelar med varje alternativ kommer att hjĂ€lpa dig att göra det optimala valet för ditt projekt.
TL;DR: samma uppsÀttning arbetsbelastningar kan köras pÄ flera stora kluster (varje kluster kommer att ha ett stort antal arbetsbelastningar) eller pÄ mÄnga smÄ (med ett fÄtal belastningar i varje kluster).
Nedan finns en tabell som bedömer fördelarna och nackdelarna med varje tillvÀgagÄngssÀtt:
NÀr man anvÀnder Kubernetes som plattform för driftsÀttning av applikationer uppstÄr ofta nÄgra grundlÀggande frÄgor om fininstÀllningar av kluster:
- Hur mÄnga kluster ska man anvÀnda?
- Hur stora ska de vara?
- Vad bör varje kluster innehÄlla?
I den hÀr artikeln kommer jag att försöka besvara alla dessa frÄgor genom att analysera fördelarna och nackdelarna med varje metod.
Formuleringen av frÄgan
Som mjukvaruutvecklare arbetar du förmodligen parallellt med att utveckla och driftsÀtta flera applikationer.
Dessutom körs sĂ€kert mĂ„nga instanser av dessa applikationer i olika miljöer â till exempel kan det vara dev, test och prod.
Det resulterar i en hel matris av applikationer och miljöer:
Applikationer och miljöer
I det ovanstÄende exemplet visas 3 applikationer och 3 miljöer, vilket ger 9 möjliga alternativ.
Varje instans av en applikation representerar en sjÀlvstÀndig deployment-enhet, som kan hanteras oberoende av andra.
Observera att instans av applikation kan bestÄ av flera komponenter, sÄsom frontend, backend, databas, etc. I fallet med en mikrotjÀnstapplikation kommer instansen att innehÄlla alla mikrotjÀnster.
Som ett resultat har anvÀndare av Kubernetes flera frÄgor:
- Borde alla instanser av applikationen placeras i ett och samma kluster?
- Borde man ha ett separat kluster för varje instans av applikationen?
- Eller kanske borde man anvÀnda en kombination av de ovan nÀmnda metoderna?
Alla dessa alternativ Àr fullt genomförbara, eftersom Kubernetes Àr ett flexibelt system som inte begrÀnsar anvÀndaren i sina möjligheter.
HÀr Àr nÄgra av de möjliga vÀgarna:
- ett stort gemensamt kluster;
- mÄnga smÄ nischade kluster;
- ett kluster för varje applikation;
- ett kluster för varje miljö.
Som visas nedan ligger de tvÄ första tillvÀgagÄngssÀtten i ena Ànden av variationsskalan:
FrÄn nÄgra stora kluster (till vÀnster) till mÄnga smÄ (till höger)
Generellt anses ett kluster vara "större" Àn ett annat om det har fler noder och poddar. Till exempel, ett kluster med 10 noder och 100 poddar Àr större Àn ett kluster med 1 nod och 10 poddar.
SÄ, lÄt oss börja!
1. Ett stort gemensamt kluster
Det första alternativet Àr att placera alla arbetsbelastningar i ett kluster:
Ett stort kluster
Inom detta tillvĂ€gagĂ„ngssĂ€tt anvĂ€nds klustret som en universell infrastrukturplattform â allt du behöver implementerar du helt enkelt i det befintliga Kubernetes-klustret.
Kubernetes möjliggör logisk separation av delar av klustret frÄn varandra, sÄ att varje instans av applikationen kan anvÀnda sin egen namnomrÄde.
LÄt oss titta pÄ för- och nackdelarna med detta tillvÀgagÄngssÀtt.
+ Effektiv anvÀndning av resurser
Vid en enda kluster behövs bara en kopia av alla resurser som krÀvs för att köra och hantera Kubernetes-klustret.
Till exempel gÀller detta för master-noder. Vanligtvis finns det 3 master-noder per Kubernetes-kluster, sÄ för ett enda kluster förblir antalet detsamma (för jÀmförelse, 10 kluster behöver 30 master-noder).
Den ovan nÀmnda nyansen gÀller Àven andra tjÀnster som fungerar över hela klustret, sÄsom lastbalanserare, Ingress-kontroller, autentiseringstjÀnster, loggning och övervakning.
I det enskilda klustret kan alla dessa tjÀnster anvÀndas för alla arbetsbelastningar (det Àr inte nödvÀndigt att skapa kopior av dem, som i fallet med flera kluster).
+ LĂ„g kostnad
Som en följd av ovanstÄende Àr ett fÀrre antal kluster oftast billigare, eftersom utgifterna för överflödiga resurser minskar.
Detta gÀller sÀrskilt för master-noder, som kan kosta en betydande summa pengar oavsett distributionsmetod (lokalt eller i molnet).
Vissa hanterade (managed) Kubernetes-tjÀnster, sÄsom eller , tillhandahÄller ett gratis hanteringslager. I detta fall Àr kostnadsfrÄgan mindre kritisk.
Det finns ocksÄ managed-tjÀnster som tar ut en fast avgift för varje Kubernetes-kluster (till exempel, ).
+ Effektiv administration
Att hantera ett kluster Àr enklare Àn flera.
Administrationen kan inkludera följande uppgifter:
- uppgradering av Kubernetes-version;
- instÀllning av CI/CD-pipeline;
- installera CNI-plugin;
- konfigurera anvÀndarautentisering;
- installera Ă„tkomstkontrollern;
och mĂ„nga flerâŠ
I fallet med ett kluster behöver man bara göra allt detta en gÄng.
För flera kluster mÄste operationerna upprepas flera gÄnger, vilket troligen krÀver viss automatisering av processerna och verktyg för att sÀkerstÀlla systematik och konsekvens i processen.
Och nu nÄgra ord om nackdelarna.
â En enda felpunkt
I hÀndelse av ett fel i det enda klustret slutar omedelbart alla arbetsbelastningar att fungera!
Det finns mÄnga scenarier dÀr nÄgot kan gÄ fel:
- uppgradering av Kubernetes leder till ovÀntade bieffekter;
- en gemensam klusterkomponent (som CNI-plugin) fungerar inte som förvÀntat;
- en av klusterkomponenterna Àr felkonfigurerad;
- fel i den underliggande infrastrukturen.
En sÄdan hÀndelse kan orsaka allvarlig skada pÄ alla arbetsbelastningar som placeras i det gemensamma klustret.
â Brist pĂ„ strikt isolering
Att arbeta i ett gemensamt kluster innebÀr att applikationer delar hÄrdvaruresurser, nÀtverksmöjligheter och operativsystem pÄ klusternoderna.
I viss mening Àr tvÄ containrar med tvÄ olika applikationer som körs pÄ samma nod likvÀrdiga med tvÄ processer som körs pÄ samma maskin under samma OS-kÀrna.
Linux-containrar tillhandahÄller en viss grad av isolering, men den Àr lÄngt ifrÄn sÄ stark som den som tillhandahÄlls av till exempel virtuella maskiner. I grunden Àr en process i en container samma process som körs i vÀrdoperativsystemet.
Detta kan bli ett sÀkerhetsproblem: en sÄdan organisering tillÄter teoretiskt att orelaterade applikationer interagerar med varandra (avsiktligt eller av misstag).
Dessutom delar alla arbetsbelastningar i Kubernetes-klustret vissa gemensamma klustertjĂ€nster, sĂ„som â detta gör att applikationer kan hitta tjĂ€nster frĂ„n andra applikationer i klustret.
Alla ovanstÄende punkter kan ha olika betydelse beroende pÄ sÀkerhetskraven för applikationer.
Kubernetes tillhandahÄller olika verktyg för att förhindra problem i sÀkerhetssystemet, sÄsom och . Men för att konfigurera dem korrekt krÀvs viss erfarenhet, och de kan inte stÀnga helt alla sÀkerhetshÄl.
Det Àr viktigt att alltid komma ihÄg att Kubernetes ursprungligen Àr designat för delning, istÀllet för isolering och sÀkerhet.
â Avsaknad av strikt multi-tenancy
Med tanke pÄ mÀngden gemensamma resurser i Kubernetes-klustret finns det mÄnga sÀtt som olika applikationer kan "trampa pÄ varandras tÄr".
Till exempel kan en applikation monopolera en viss gemensam resurs (som CPU eller minne) och beröva andra applikationer som körs pÄ samma nod tillgÄng till den.
Kubernetes tillhandahĂ„ller olika mekanismer för att kontrollera sĂ„dant beteende, sĂ„som (se Ă€ven artikeln "" â anm. övers.), och . Men som med sĂ€kerhet Ă€r konfigurationen relativt komplex och kan inte förhindra alla oförutsedda bieffekter.
â Ett stort antal anvĂ€ndare
I ett ensamt kluster mÄste Ätkomst ges till mÄnga personer. Ju fler de Àr, desto högre blir risken för att de "skadar" nÄgot.
Inom klustret kan man kontrollera vem som kan göra vad med hjĂ€lp av (se artikeln "" â anm. övers.). Men det förhindrar inte att anvĂ€ndare "skadar" nĂ„got inom sitt ansvarsomrĂ„de.
â Kluster kan inte vĂ€xa oĂ€ndligt
Ett kluster som anvÀnds för alla arbetsbelastningar kommer troligen att vara ganska stort (vad gÀller noder och poddar).
Men hÀr uppstÄr ett annat problem: kluster i Kubernetes kan inte vÀxa oÀndligt.
Det finns en teoretisk grÀns för storleken pÄ klustret. I Kubernetes Àr det ungefÀr .
Men i verkliga livet kan problemen börja mycket tidigare â till exempel vid .
Grejen Àr att stora kluster lÀgger en hög belastning pÄ Kubernetes kontrollplan. Med andra ord, för att hÄlla klustret i drift och anvÀnda resurserna effektivt krÀvs noggrann justering.
Detta problem tas upp i en relevant artikel i den ursprungliga bloggen med titeln "».
Men lÄt oss titta pÄ en motsatt strategi: mÄnga smÄ kluster.
2. MÄnga smÄ, specialiserade kluster
Med denna strategi anvÀnder du ett separat kluster för varje distribuerad enhet:
MÄnga smÄ kluster
För syftet med denna artikel definieras den distribuerade enheten som en instans av en applikation â till exempel dev-versionen av en specifik applikation.
I denna strategi anvÀnds Kubernetes som en specialiserad körmiljö för enskilda instanser av applikationen.
LÄt oss titta pÄ för- och nackdelarna med detta tillvÀgagÄngssÀtt.
+ BegrÀnsad "explosionsradius"
Vid "fel" i klustret begrÀnsas de negativa konsekvenserna till de arbetsbelastningar som har distribuerats i detta kluster. Alla andra arbetsbelastningar förblir opÄverkade.
+ Isolering
Arbetsbelastningar som placeras i individuella kluster har inga gemensamma resurser sÄsom CPU, minne, operativsystem, nÀtverk eller andra tjÀnster.
Som ett resultat fÄr vi stark isolering mellan orelaterade applikationer, vilket kan förbÀttra deras sÀkerhet.
+ FÄ anvÀndare
Eftersom varje kluster bara innehÄller ett begrÀnsat antal arbetsbelastningar minskar antalet anvÀndare som har tillgÄng till det.
Ju fÀrre personer som har tillgÄng till klustret, desto lÀgre Àr risken för att nÄgot "gÄr fel".
LÄt oss titta pÄ nackdelarna.
â Ineffektiv resursanvĂ€ndning
Som nÀmnts tidigare krÀver varje Kubernetes kluster en viss uppsÀttning kontrollerande resurser: master-noder, kontrollplanens komponenter, lösningar för övervakning och loggning.
I fallet med ett stort antal smÄ kluster mÄste en större del av resurserna allokeras för hantering.
â Kostnader
Ineffektiv resursanvÀndning innebÀr automatiskt höga kostnader.
Till exempel kommer innehÄllet med 30 masternoder istÀllet för tre med samma berÀkningskraft att pÄverka kostnaderna.
â SvĂ„righeter med administration
Att administrera flera Kubernetes-kluster Àr mycket svÄrare Àn att arbeta med ett enda.
Till exempel mÄste autentisering och auktorisering konfigureras för varje kluster. Uppgradering av Kubernetes-versionen mÄste ocksÄ göras flera gÄnger.
Det Àr troligt att automatisering kommer att behövas för att förbÀttra effektiviteten i alla dessa uppgifter.
LÄt oss nu titta pÄ mindre extrema scenarier.
3. Ett kluster för varje applikation
Inom det hÀr tillvÀgagÄngssÀttet skapar du ett separat kluster för alla instanser av en specifik applikation:
Kluster per applikation
Denna vĂ€g kan ses som en generalisering av principen âett separat kluster för ett teamâ, eftersom ett team av ingenjörer vanligtvis arbetar med utveckling av en eller flera applikationer.
LÄt oss titta pÄ för- och nackdelarna med detta tillvÀgagÄngssÀtt.
+ Kluster kan anpassas efter applikationen
Om en applikation har sÀrskilda behov kan de tillgodoses inom klustret utan att pÄverka andra kluster.
SÄdana behov kan inkludera GPU-arbetare, specifika CNI-plugin, service mesh eller nÄgon annan tjÀnst.
Varje kluster kan anpassas för den applikation som körs i det, sÄ att det innehÄller endast det som behövs.
â Olika miljöer i ett kluster
Nackdelen med detta tillvÀgagÄngssÀtt Àr att instanser av applikationer frÄn olika miljöer samexisterar i ett och samma kluster.
Till exempel körs prod-versionen av applikationen i samma kluster som dev-versionen. Det betyder ocksÄ att utvecklarna arbetar i samma kluster som den produktionsversion av applikationen som körs.
Om ett fel uppstĂ„r i klustret pĂ„ grund av utvecklarnas Ă„tgĂ€rder eller buggar i dev-versionen kan ocksĂ„ prod-versionen potentiellt pĂ„verkas â en stor nackdel med detta tillvĂ€gagĂ„ngssĂ€tt.
Och slutligen, det sista scenariot i vÄr lista.
4. Ett kluster för varje miljö
Detta scenario innebÀr att ett separat kluster tilldelas varje miljö:
Ett kluster per miljö
Till exempel kan du ha kluster dev, test och prod, dÀr du kör alla instanser av applikationen avsedda för en specifik miljö.
HÀr Àr fördelarna och nackdelarna med detta tillvÀgagÄngssÀtt.
+ Isolering av prod-miljö
Inramverket för denna strategi innebÀr att alla miljöer blir isolerade frÄn varandra. Detta Àr sÀrskilt viktigt för produktionsmiljön.
Produktionsversioner av applikationen Àr nu oberoende av vad som hÀnder i andra kluster och miljöer.
Om det uppstÄr ett problem i dev-klustret kommer produktionsversionerna av applikationerna att fortsÀtta fungera som om ingenting har hÀnt.
+ Klustret kan anpassas efter miljön
Varje kluster kan anpassas efter sin miljö. Till exempel kan man:
- installera utvecklings- och felsökningsverktyg i dev-klustret;
- installera testverktyg och ramverk i klustret test;
- anvÀnda kraftfullare hÄrdvara och nÀtverkskanaler i klustret prod.
Detta ökar bÄde effektiviteten vid utveckling och drift av applikationer.
+ BegrÀnsad Ätkomst till produktionsklustret
Det Àr sÀllan nödvÀndigt att arbeta direkt med produktionsklustret, sÄ man kan i stor utstrÀckning begrÀnsa antalet personer som har tillgÄng till det.
Man kan gÄ Ànnu lÀngre och helt beröva mÀnniskor Ätkomst till detta kluster, och istÀllet utföra alla distributioner med hjÀlp av ett automatiserat CI/CD-verktyg. Denna strategi minimerar risken för mÀnskliga misstag dÀr det Àr som mest kritiskt.
Och nu nÄgra ord om nackdelarna.
â Brist pĂ„ isolering mellan applikationer
En av huvudsakliga nackdelarna med denna strategi Àr avsaknaden av hÄrdvaru- och resursisolering mellan applikationerna.
Orelaterade applikationer delar resurser i klustret: kÀrnan, processor, minne och vissa andra tjÀnster.
Som redan nÀmnts kan detta vara potentiellt farligt.
â OförmĂ„ga att lokalisera applikationernas beroenden
Om en applikation har speciella krav, behöver de uppfyllas i alla kluster.
Om en applikation krÀver GPU, mÄste varje kluster innehÄlla minst en worker med GPU (Àven om den endast anvÀnds av denna applikation).
Som ett resultat riskerar vi att fÄ högre kostnader och ineffektiv resursanvÀndning.
Slutsats
Med ett visst antal applikationer kan de placeras i flera stora kluster eller mÄnga smÄ.
Artikeln diskuterar fördelar och nackdelar med olika strategier, allt frÄn ett globalt kluster till flera smÄ och specialiserade:
- en stor gemensam kluster;
- mÄnga smÄ nischade kluster;
- ett kluster för varje applikation;
- ett kluster för varje miljö.
SÄ vilken metod ska man vÀlja?
Som vanligt beror svaret pÄ anvÀndningsscenariot: man mÄste vÀga fördelar och nackdelar med olika tillvÀgagÄngssÀtt och vÀlja det mest optimala alternativet.
Men valet Ă€r inte begrĂ€nsat till exemplen ovan â man kan anvĂ€nda vilken kombination som helst!
Till exempel kan man organisera ett par kluster för varje team: ett kluster för utveckling (dÀr miljöer dev och test) och ett kluster för production (dÀr produktionsmiljön kommer att finnas).
Baserat pÄ informationen i denna artikel kan du optimera fördelar och nackdelar utifrÄn det specifika scenariot. Lycka till!
P.S.
LÀs Àven i vÄr blogg:
- «»;
- «»;
- «»;
- «».
KĂ€lla: habr.com
