Notera. transl.: detta material är från ett utbildningsprojekt är svaret på en populär fråga när man designar Kubernetes-baserad infrastruktur. Vi hoppas att ganska detaljerade beskrivningar av för- och nackdelarna med varje alternativ hjälper dig att göra det bästa 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 litet antal belastningar i varje kluster).
Nedan finns en tabell som utvärderar för- och nackdelarna med varje tillvägagångssätt:
När du använder Kubernetes som en plattform för att köra applikationer uppstår ofta flera grundläggande frågor om krångligheterna med att sätta upp kluster:
- Hur många kluster ska jag använda?
- Hur stora ska jag göra dem?
- Vad ska varje kluster innehålla?
I den här artikeln kommer jag att försöka svara på alla dessa frågor genom att analysera för- och nackdelarna med varje tillvägagångssätt.
Uttalande av en fråga
Som mjukvaruutvecklare utvecklar och driver du sannolikt många applikationer samtidigt.
Dessutom är det troligt att många instanser av dessa applikationer körs i olika miljöer - till exempel kan de vara det dev, testa и prod.
Resultatet är en hel matris av applikationer och miljöer:
Applikationer och miljöer
Exemplet ovan representerar 3 applikationer och 3 miljöer, vilket resulterar i totalt 9 möjliga alternativ.
Varje applikationsinstans är en fristående distributionsenhet som kan arbetas med oberoende av andra.
Observera att applikationsinstans kan bestå av många komponenter, såsom frontend, backend, databas, etc. I fallet med en mikrotjänstapplikation kommer instansen att inkludera alla mikrotjänster.
Som ett resultat har Kubernetes-användare flera frågor:
- Ska alla applikationsinstanser placeras i ett kluster?
- Är det värt att ha ett separat kluster för varje applikationsinstans?
- Eller kanske en kombination av ovanstående tillvägagångssätt bör användas?
Alla dessa alternativ är ganska genomförbara, eftersom Kubernetes är ett flexibelt system som inte begränsar användarens möjligheter.
Här är några av de möjliga sätten:
- ett stort gemensamt kluster;
- många små högspecialiserade kluster;
- ett kluster per applikation;
- ett kluster per miljö.
Som visas nedan är de två första tillvägagångssätten i motsatta ändar av skalan av alternativ:
Från några få stora kluster (vänster) till många små (höger)
I allmänhet anses ett kluster vara "större" än ett annat om det har en större summa av noder och poddar. Till exempel är ett kluster med 10 noder och 100 poddar större än ett kluster med 1 nod och 10 pods.
Nåväl, 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 ett universellt infrastrukturplattform — du distribuerar helt enkelt allt du behöver i ett befintligt Kubernetes-kluster.
Kubernetes tillåter att delar av klustret logiskt separeras från varandra, så att varje applikationsinstans kan ha sin egen namnrymd.
Låt oss titta på för- och nackdelarna med detta tillvägagångssätt.
+ Effektiv användning av resurser
Med ett enda kluster behöver du bara en kopia av alla resurser som behövs för att köra och hantera Kubernetes-klustret.
Detta gäller till exempel för masternoder. Vanligtvis har varje Kubernetes-kluster 3 huvudnoder, så för ett enda kluster kommer deras antal att förbli så (för jämförelse behöver 10 kluster 30 masternoder).
Ovanstående subtilitet gäller även för andra tjänster som fungerar över hela klustret, såsom lastbalanserare, Ingress-kontroller, autentisering, loggning och övervakningssystem.
I ett enda kluster kan alla dessa tjänster användas på en gång för alla arbetsbelastningar (det finns inget behov av att skapa kopior av dem, vilket är fallet med flera kluster).
+ Billigt
Som en konsekvens av ovanstående är färre kluster vanligtvis billigare eftersom det inte finns några omkostnader.
Detta gäller särskilt för masternoder, som kan kosta en betydande summa pengar oavsett hur de är värd (på plats eller i molnet).
Vissa hanterade Kubernetes-tjänster, som t.ex eller , tillhandahåll kontrolllagret gratis. I det här fallet är kostnadsfrågan mindre akut.
Det finns också hanterade tjänster som tar ut en fast avgift för driften av varje Kubernetes-kluster (t.ex. ).
+ Effektiv administration
Att hantera ett kluster är lättare än att hantera flera.
Administration kan innefatta följande uppgifter:
- Kubernetes versionsuppdatering;
- sätta upp en CI/CD-pipeline;
- installera CNI-plugin;
- ställa in ett användarautentiseringssystem;
- installation av en åtkomstkontroller;
och många andra…
I fallet med ett kluster behöver du bara göra allt detta en gång.
För många kluster kommer operationer att behöva upprepas många gånger, vilket sannolikt kommer att kräva viss automatisering av processer och verktyg för att säkerställa konsekvens och konsekvens i processen.
Och nu några ord om nackdelarna.
− Enskild felpunkt
Vid avslag den enda klustret slutar fungera omedelbart alla arbetsbelastning!
Det finns många sätt saker kan gå fel på:
- uppdatering av Kubernetes leder till oväntade biverkningar;
- En klusteromfattande komponent (till exempel en CNI-plugin) börjar inte fungera som förväntat;
- en av klusterkomponenterna är inte korrekt konfigurerad;
- fel i den underliggande infrastrukturen.
En sådan incident kan orsaka allvarlig skada på alla arbetsbelastningar som finns i ett delat kluster.
− Ingen styv isolering
Att köra i ett delat kluster innebär att applikationer delar hårdvaran, nätverkskapaciteten och operativsystemet på klusternoderna.
På sätt och vis är två behållare med två olika applikationer som körs på samma nod som två processer som körs på samma maskin som kör samma OS-kärna.
Linux-behållare ger någon form av isolering, men den är inte alls lika stark som den som tillhandahålls av, säg, virtuella maskiner. I huvudsak är en process i en container samma process som körs på värdoperativsystemet.
Detta kan vara ett säkerhetsproblem: det här arrangemanget tillåter teoretiskt sett orelaterade applikationer att kommunicera med varandra (antingen avsiktligt eller oavsiktligt).
Dessutom delar alla arbetsbelastningar i ett Kubernetes-kluster några klusteromfattande tjänster som t.ex - detta gör att applikationer kan hitta tjänster för andra applikationer i klustret.
Alla ovanstående punkter kan ha olika betydelser beroende på applikationens säkerhetskrav.
Kubernetes tillhandahåller olika verktyg för att förhindra säkerhetsproblem som t.ex и . Men att ställa in dem korrekt kräver viss erfarenhet, dessutom kan de inte täppa till absolut alla säkerhetshål.
Det är viktigt att alltid komma ihåg att Kubernetes ursprungligen designades för delning, inte för isolering och säkerhet.
− Brist på strikt flerhyres
Med tanke på överflöd av delade resurser i ett Kubernetes-kluster finns det många sätt som olika applikationer kan trampa varandra på tårna.
Till exempel kan en applikation monopolisera en delad resurs (som CPU eller minne) och neka andra applikationer som körs på samma nod åtkomst till den.
Kubernetes tillhandahåller olika mekanismer för att kontrollera detta beteende, som t.ex (se även artikeln "" - cirka. översätt.), и . Men som i fallet med säkerhet är deras konfiguration ganska icke-trivial och de kan inte förhindra absolut alla oförutsedda biverkningar.
− Stort antal användare
När det gäller ett enskilt kluster måste du öppna åtkomst till det för många människor. Och ju större antal de är, desto större är risken att de "bryter sönder" något.
Inom klustret kan du styra vem som kan göra vad med hjälp av (se artikel "" - cirka. översätt.). Det kommer dock inte att hindra användare från att "bryta" något inom sitt ansvarsområde.
− Kluster kan inte växa i det oändliga
Klustret som används för alla arbetsbelastningar kommer sannolikt att vara ganska stort (i termer av antal noder och pods).
Men här uppstår ett annat problem: kluster i Kubernetes kan inte växa i det oändliga.
Det finns en teoretisk gräns för klusterstorlek. I Kubernetes är det ungefär .
Men i verkliga livet kan problem börja mycket tidigare - till exempel bara med .
Faktum är att stora kluster lägger en hög belastning på Kubernetes kontrollskikt. Med andra ord krävs noggrann justering för att hålla klustret igång effektivt.
Det här problemet undersöks i en relaterad artikel på den ursprungliga bloggen som heter "".
Men låt oss överväga det motsatta tillvägagångssättet: många små kluster.
2. Många små, specialiserade kluster
Med detta tillvägagångssätt använder du ett separat kluster för varje element du distribuerar:
Många små kluster
För syftet med denna artikel, under utplacerbart element hänvisar till en instans av en applikation - till exempel en utvecklarversion av en separat applikation.
Denna strategi använder Kubernetes som en specialiserad körning för enskilda applikationsinstanser.
Låt oss titta på för- och nackdelarna med detta tillvägagångssätt.
+ Begränsad "sprängradie"
När ett kluster misslyckas begränsas de negativa konsekvenserna endast till de arbetsbelastningar som distribuerades i det klustret. Alla andra arbetsbelastningar förblir orörda.
+ Isolering
Arbetsbelastningar som finns i enskilda kluster delar inte resurser som processor, minne, operativsystem, nätverk eller andra tjänster.
Resultatet är tät isolering mellan orelaterade applikationer, vilket kan vara fördelaktigt för deras säkerhet.
+ Litet antal användare
Med tanke på att varje kluster endast innehåller en begränsad uppsättning arbetsbelastningar, minskas antalet användare med åtkomst till det.
Ju färre personer som har tillgång till klustret, desto mindre är risken att något "går sönder".
Låt oss titta på nackdelarna.
− Ineffektiv användning av resurser
Som nämnts tidigare kräver varje Kubernetes-kluster en specifik uppsättning hanteringsresurser: masternoder, kontrolllagerkomponenter, övervaknings- och loggningslösningar.
Vid ett stort antal små kluster måste en större del av resurserna avsättas till förvaltningen.
− Dyrt
Ineffektiv resursanvändning medför automatiskt höga kostnader.
Till exempel, att underhålla 30 masternoder istället för tre med samma datorkraft kommer nödvändigtvis att påverka kostnaderna.
− Svårigheter i administrationen
Att hantera flera Kubernetes-kluster är mycket svårare än att hantera bara ett.
Till exempel måste du konfigurera autentisering och auktorisering för varje kluster. Kubernetes-versionen kommer också att behöva uppdateras flera gånger.
Du kommer sannolikt att behöva använda automatisering för att göra alla dessa uppgifter mer effektiva.
Låt oss nu titta på mindre extrema scenarier.
3. Ett kluster per applikation
I det här tillvägagångssättet skapar du ett separat kluster för alla instanser av en viss applikation:
Kluster per applikation
Denna väg kan betraktas som en generalisering av principen "separat kluster per lag”, eftersom vanligtvis ett team av ingenjörer utvecklar en eller flera applikationer.
Låt oss titta på för- och nackdelarna med detta tillvägagångssätt.
+ Klustret kan anpassas till applikationen
Om en applikation har särskilda behov kan de implementeras i ett kluster utan att påverka andra kluster.
Sådana behov kan inkludera GPU-arbetare, vissa CNI-plugin-program, ett servicenät eller någon annan tjänst.
Varje kluster kan skräddarsys för den applikation som körs i den så att den bara innehåller det som behövs.
− Olika miljöer i ett kluster
Nackdelen med detta tillvägagångssätt är att applikationsinstanser från olika miljöer samexisterar i samma kluster.
Till exempel körs prod-versionen av applikationen i samma kluster som dev-versionen. Detta innebär också att utvecklare arbetar i samma kluster som produktionsversionen av applikationen drivs i.
Om ett fel inträffar i klustret på grund av utvecklarnas agerande eller fel i dev-versionen, kan prod-versionen också drabbas - en stor nackdel med detta tillvägagångssätt.
Och slutligen, det sista scenariot på vår lista.
4. Ett kluster per miljö
Det här scenariot innebär att man tilldelar ett separat kluster för varje miljö:
Ett kluster per miljö
Till exempel kan du ha kluster dev, testa и prod, där du kommer att köra alla instanser av programmet dedikerade till en specifik miljö.
Här är för- och nackdelarna med detta tillvägagångssätt.
+ Isolering av prod-miljön
Inom detta synsätt är alla miljöer isolerade från varandra. Men i praktiken är detta särskilt viktigt i en prod-miljö.
Produktionsversioner av applikationen är nu oberoende av vad som händer i andra kluster och miljöer.
På det här sättet, om ett problem plötsligt uppstår i dev-klustret, kommer prod-versionerna av applikationerna att fortsätta att fungera som om ingenting hade hänt.
+ Klustret kan anpassas till miljön
Varje kluster kan anpassas till sin miljö. Du kan till exempel:
- installera verktyg för utveckling och felsökning i dev-klustret;
- installera testramar och verktyg i klustret testa;
- använda kraftfullare hårdvara och nätverkskanaler i klustret prod.
Detta gör att du kan öka effektiviteten i både applikationsutveckling och drift.
+ Begränsa åtkomsten till produktionsklustret
Behovet av att arbeta direkt med ett prodkluster uppstår sällan, så du kan avsevärt begränsa kretsen av personer som har tillgång till det.
Du kan gå ännu längre och neka människor åtkomst till detta kluster helt och hållet, och utföra alla distributioner med ett automatiserat CI/CD-verktyg. Ett sådant tillvägagångssätt kommer att minimera risken för mänskliga fel precis där det är mest relevant.
Och nu några ord om nackdelarna.
− Ingen isolering mellan applikationer
Den största nackdelen med tillvägagångssättet är bristen på hårdvara och resursisolering mellan applikationer.
Orelaterade applikationer delar klusterresurser: systemkärnan, processorn, minnet och vissa andra tjänster.
Som nämnts kan detta vara potentiellt farligt.
− Oförmåga att lokalisera applikationsberoenden
Om en ansökan har särskilda krav måste de uppfyllas för alla kluster.
Till exempel, om en applikation kräver en GPU, måste varje kluster innehålla minst en arbetare med en GPU (även om den endast används av den applikationen).
Som ett resultat riskerar vi högre kostnader och ineffektiv resursanvändning.
Slutsats
Om du har en specifik uppsättning applikationer kan de placeras i flera stora kluster eller många små.
Artikeln diskuterar för- och nackdelar med olika tillvägagångssätt, allt från ett globalt kluster till flera små och mycket specialiserade:
- ett stort allmänt kluster;
- många små högspecialiserade kluster;
- ett kluster per applikation;
- ett kluster per miljö.
Så vilket tillvägagångssätt ska du ta?
Som alltid beror svaret på användningsfallet: du måste väga för- och nackdelar med olika tillvägagångssätt och välja det mest optimala alternativet.
Valet är dock inte begränsat till exemplen ovan – du kan använda vilken kombination som helst av dem!
Till exempel kan du organisera ett par kluster för varje team: ett utvecklingskluster (där det kommer att finnas miljöer dev и testa) och kluster för produktion (där produktionsmiljön kommer att finnas).
Baserat på informationen i den här artikeln kan du optimera för- och nackdelarna för ett specifikt scenario. Lycka till!
PS
Läs även på vår blogg:
- «";
- «";
- «";
- «".
Källa: will.com