Bem. overs.: dette materiale fra det uddannelsesprojekt — svar på et populært spørgsmål ved design af infrastruktur baseret på Kubernetes. Vi håber, at de tilstrækkeligt udførlige beskrivelser af fordele og ulemper ved hver løsning vil hjælpe med at træffe det optimale valg for dit projekt.
TL;DR: det samme sæt arbejdsbelastninger kan køre på adskillige store klynger (hvor hver klynge har mange arbejdsbelastninger) eller på mange små (med få arbejdsbelastninger i hver klynge).
Nedenfor er en tabel, der vurderer fordele og ulemper ved hver tilgang:
Når Kubernetes bruges som platform til drift af applikationer, opstår der ofte flere grundlæggende spørgsmål om nuancerne ved konfiguration af klynger:
- Hvor mange klynger skal der bruges?
- Hvor store skal de være?
- Hvad skal hver klynge inkludere?
I denne artikel vil jeg forsøge at besvare alle disse spørgsmål ved at analysere fordele og ulemper ved hver tilgang.
Problemstillingen
Som softwareudvikler udvikler du sandsynligvis samtidig mange applikationer.
Desuden bliver mange forekomster af disse applikationer sandsynligvis kørt i forskellige miljøer — for eksempel kan det være dev, test og prod.
Som resultat får man en hel matrix af applikationer og miljøer:
Applikationer og miljøer
I det ovenstående eksempel vises 3 applikationer og 3 miljøer, hvilket giver i alt 9 mulige kombinationer.
Hver applikationsinstans udgør en selvstændig deploymentsenhed, som kan arbejdes med uafhængigt af de andre.
Bemærk venligst, at applikationsinstans kan bestå af mange komponenter, såsom front-end, back-end, database osv. I tilfælde af en mikrotjenesteapplikation vil instansen inkludere alle mikrotjenester.
Som et resultat har brugere af Kubernetes flere spørgsmål:
- Burde alle applikationsinstanser placeres i én klynge?
- Bør der oprettes en separat klynge for hver applikationsinstans?
- Eller måske skulle man bruge en kombination af de ovennævnte tilgange?
Alle disse muligheder er helt levedygtige, da Kubernetes er et fleksibelt system, der ikke begrænser brugeren i sine muligheder.
Her er nogle af de mulige veje:
- en stor fælles klynge;
- en masse af små specialiserede klynger;
- én klynge pr. applikation;
- én klynge pr. miljø.
Som vist nedenfor befinder de første to tilgange sig i hver ende af skalaen:
Fra et par store klynger (til venstre) til mange små (til højre)
Generelt antages det, at én klynge er "større" end en anden, hvis den har flere noder og pods samlet. For eksempel er en klynge med 10 noder og 100 pods større end en klynge med 1 node og 10 pods.
Godt, lad os komme i gang!
1. Én stor fælles klynge
Den første mulighed er at placere alle arbejdsbyrder i én klynge:
Én stor klynge
I denne tilgang anvendes klyngen som en generel infrastrukturplatform — alt, hvad du behøver, implementerer du bare i den eksisterende Kubernetes-klynge.
Kubernetes gør det muligt at adskille dele af klyngen logisk fra hinanden, så hver applikationsinstans kan bruge sit eget namespace.
Lad os se på fordele og ulemper ved denne tilgang.
+ Effektiv ressourceudnyttelse
I tilfælde af én enkelt klynge kræves der kun én kopi af alle de ressourcer, der er nødvendige for at køre og administrere Kubernetes-klyngen.
For eksempel gælder dette for master-noder. Normalt er der 3 master-noder per Kubernetes-klynge, så for én enkelt klynge forbliver antallet sådan (til sammenligning vil 10 klynger have brug for 30 master-noder).
Den ovenfor nævnte nuance gælder også for andre tjenester, der fungerer på tværs af hele klyngen, såsom load balancers, Ingress-controllere, autentificerings-, lognings- og overvågningstjenester.
I en enkelt klynge kan alle disse tjenester bruges direkte til alle arbejdsbyrder (der er ikke behov for at oprette kopier af dem, som ved flere klynger).
+ Billighed
Som en konsekvens af ovenstående er færre klynger normalt billigere, da der ikke er omkostninger til overflødige ressourcer.
Dette gælder især for master-noder, som kan koste betydelige penge uanset placering (on-premises eller i skyen).
Nogle administrerede Kubernetes-tjenester, såsom eller , de giver et gratis administrationslag. I dette tilfælde er omkostningsspørgsmålet ikke så presserende.
Der findes også managed-tjenester, der opkræver et fast gebyr for driften af hver Kubernetes-klynge (for eksempel, ).
+ Effektiv administration
Det er lettere at administrere én klynge end flere.
Administration kan inkludere følgende opgaver:
- opdatering af Kubernetes-version;
- opsætning af CI/CD-pipeline;
- installation af CNI-plugin;
- opsætning af brugerautentifikationssystem;
- installation af adgangskontrolcontroller;
og mange andre...
I tilfælde af én klynge skal man kun gøre alt dette én gang.
For mange klynger skal operationerne gentages mange gange, hvilket sandsynligvis kræver nogen automatisering af processerne og værktøjer for at sikre konsistens og ensartethed i processen.
Lad os nu tale om ulemperne.
− Enkelt punkt for fejl
I tilfælde af, at den eneste klynge fejler, vil alle arbejdsbyrderne straks stoppe med at fungere!
Der findes mange scenarier, hvor noget kan gå galt:
- opdatering af Kubernetes medfører uventede bivirkninger;
- en fælles klyngekomponent (for eksempel CNI-plugin) fungerer ikke som forventet;
- en af klyngekomponenterne er forkert konfigureret;
- fejl i den underliggende infrastruktur.
En sådan hændelse kan forårsage betydelig skade på alle arbejdsbyrder, der er hostet i den fælles klynge.
− Manglende streng isolation
At arbejde i en fælles klynge betyder, at applikationer deler hardware, netværksressourcer og operativsystemet på klyngeknuderne.
I en vis forstand er to containere med to forskellige applikationer, der kører på den samme knude, ligesom to processer, der kører på den samme maskine under det samme OS-kernel.
Linux-containere giver en vis form for isolation, men den er langt fra så stærk som den, virtualiserede maskiner tilbyder. I bund og grund er processen i en container den samme proces, der kører i værtsoperativsystemet.
Dette kan blive et problem med hensyn til sikkerhed: en sådan opbygning tillader teoretisk set urelaterede applikationer at interagere med hinanden (bevidst eller ubevidst).
Desuden deler alle arbejdsbyrder i Kubernetes-klusteret nogle fælles klaseservices, såsom — dette gør det muligt for applikationer at finde tjenester fra andre applikationer i klusteret.
Alle de ovennævnte punkter kan have forskellige betydninger afhængigt af de sikkerhedskrav, der stilles til applikationerne.
Kubernetes leverer forskellige værktøjer til at forhindre sikkerhedsproblemer, såsom og . Men for at konfigurere dem korrekt kræves der en vis erfaring; desuden kan de ikke lukke alle sikkerhedshuller.
Det er vigtigt altid at huske, at Kubernetes oprindeligt er designet til fælles brug, og ikke til isolering og sikkerhed.
− Mangel på streng multi-tenancy
I betragtning af de mange fælles ressourcer i Kubernetes-klusteret er der mange måder, hvorpå forskellige applikationer kan "træde hinanden over tæerne".
For eksempel kan en applikation monopolisere en fælles ressource (som CPU eller hukommelse) og berøve andre applikationer, der kører på den samme node, adgangen til den.
Kubernetes leverer forskellige mekanismer til at kontrollere sådan adfærd, såsom (se også artiklen "" - red.), og . Men ligesom med sikkerheden er deres opsætning ret kompleks, og de kan ikke forhindre alle uforudsete bivirkninger.
− Stort antal brugere
I tilfælde af et enkelt kluster skal der gives adgang til mange mennesker. Og jo flere de er, jo højere er risikoen for, at de kan "bryde noget".
Inden for klusteret kan man kontrollere, hvem der kan gøre hvad ved hjælp af (se artiklen "" - red.). Det vil dog ikke forhindre brugere i at "bryde" noget inden for deres ansvarsområde.
− Kluster kan ikke vokse uendeligt
Et kluster, der bruges til alle arbejdsbyrder, vil sandsynligvis være ret stort (i antal noder og pods).
Men her opstår et andet problem: klustre i Kubernetes kan ikke vokse uendeligt.
Der er en teoretisk grænse for størrelsen af et kluster. I Kubernetes er den cirka .
Men i virkeligheden kan problemer opstå meget tidligere — for eksempel efter kun .
Problemet er, at store klynger lægger et højt pres på Kubernetes kontrolplanet. Med andre ord kræver det omhyggelig konfiguration for at holde klyngen i drift og bruge ressourcer effektivt.
Dette problem diskuteres i den relevante artikel på den oprindelige blog med titlen «».
Men lad os overveje den modsatte tilgang: mange små klynger.
2. Mange små, specialiserede klynger
I denne tilgang bruger du en separat klynge til hver deployerede enhed:
Mange små klynger
For formålet med denne artikel henviser til den deployerede enhed som en instans af applikationen — for eksempel en dev-version af en separat applikation.
I denne strategi bruges Kubernetes som en specialiseret runtime for individuelle applikationsinstanser.
Lad os se på fordele og ulemper ved denne tilgang.
+ Begrænset 'explosionsradius'
Ved en 'nedbrud' af klyngen begrænses de negative konsekvenser kun til de arbejdsbelastninger, der blev deployeret i denne klynge. Alle andre arbejdsbelastninger forbliver urørte.
+ Isolation
Arbejdsbelastninger, der er placeret i individuelle klynger, deler ikke ressourcer som CPU, hukommelse, operativsystem, netværk eller andre tjenester.
Som et resultat får vi en stram isolation mellem ikke-relaterede applikationer, hvilket kan have en positiv indvirkning på deres sikkerhed.
+ Få brugere
Da hver klynge kun indeholder et begrænset antal arbejdsbelastninger, reduceres antallet af brugere med adgang til den.
Jo færre personer der har adgang til klyngen, desto lavere er risikoen for, at noget 'går i stykker'.
Lad os se på ulemperne.
− Ineffektiv ressourceanvendelse
Som nævnt tidligere kræver hver Kubernetes klynge et bestemt sæt styringsressourcer: master-noder, kontrolplane komponenter, overvågnings- og logningsløsninger.
Ved et stort antal små klynger skal der tildeles en større andel ressourcer til administration.
− Omkostninger
Ineffektiv ressourceanvendelse fører automatisk til høje udgifter.
For example, the presence of 30 master nodes instead of three with the same computing power will inevitably reflect on costs.
− Challenges of administration
Managing multiple Kubernetes clusters is much more complicated than working with a single one.
For example, you will need to configure authentication and authorization for each cluster. Upgrading the Kubernetes version will also have to be done multiple times.
It is likely that automation will need to be applied to increase the efficiency of all these tasks.
Now let's look at less extreme scenarios.
3. One cluster for each application
In this approach, you create a separate cluster for all instances of a specific application:
Cluster per application
This path can be seen as a generalization of the principle of "a separate cluster for each team", since typically a team of engineers works on developing one or more applications.
Lad os se på fordele og ulemper ved denne tilgang.
+ The cluster can be tailored to the application
If the application has specific needs, they can be implemented in the cluster without affecting other clusters.
Such needs may include workers with GPUs, specific CNI plugins, service mesh, or some other service.
Each cluster can be tailored to the application it runs, containing only what is necessary.
− Different environments in one cluster
The downside of this approach is that application instances from different environments coexist in one cluster.
For example, the production version of the application runs in the same cluster as the development version. This also means that developers operate in the same cluster as the production version of the application.
If a failure occurs in the cluster due to developers' actions or bugs in the dev version, the prod version could potentially be affected — a significant drawback of this approach.
And finally, the last scenario on our list.
4. One cluster for each environment
This scenario provides for allocating a separate cluster for each environment:
One cluster per environment
For instance, you might have clusters dev, test og prod, where you will run all instances of the application intended for a specific environment.
Here are the pros and cons of this approach.
+ Isolation of the production environment
Denne tilgang sikrer, at alle miljøer er isolerede fra hinanden. Dette er særligt vigtigt for produktionsmiljøet.
Produktionsversionerne af applikationen er nu uafhængige af, hvad der sker i andre klynger og miljøer.
Så hvis der pludselig opstår et problem i udviklerklyngen, vil produktionsversionerne af applikationerne fortsætte med at fungere, som om intet er sket.
+ Klyngen kan tilpasses til miljøet
Hver klynge kan tilpasses sit miljø. For eksempel kan man:
- installere udviklings- og fejlfindingværktøjer i udviklerklyngen;
- installere testværktøjer og frameworks i klyngen; test;
- bruge kraftigere hardware og netværksforbindelser i klyngen; prod.
Dette øger effektiviteten i både udviklingen og driften af applikationerne.
+ Adgangsbegrænsning til produktionsklyngen
Behovet for at arbejde direkte med produktionsklyngen opstår sjældent, så man kan betydeligt begrænse antallet af personer, der har adgang til den.
Man kan gå endnu længere og helt fjerne personers adgang til denne klynge, og alle implementeringer udføres med et automatiseret CI/CD værktøj. Denne tilgang vil maksimalt reducere risikoen for menneskelige fejl, hvor det er mest kritisk.
Lad os nu tale om ulemperne.
− Manglende isolation mellem applikationer
Den største ulempe ved tilgangen er den manglende hardware- og ressourceisolering mellem applikationerne.
Ikke-relaterede applikationer deler ressourcerne i klyngen: systemkernel, processor, hukommelse og nogle andre tjenester.
Som nævnt kan dette være potentielt farligt.
− Manglende mulighed for at lokalisere applikationsafhængigheder
Hvis en applikation har særlige krav, skal de opfyldes i alle klynger.
For eksempel, hvis en applikation kræver GPU, skal hver klynge have mindst én worker med GPU (selv hvis den kun bruges af denne applikation).
Som resultat risikerer vi højere omkostninger og ineffektiv ressourceudnyttelse.
Konklusion
Når der er et bestemt sæt applikationer, kan de placeres i flere store klynger eller i mange små.
Artiklen diskuterer fordele og ulemper ved forskellige tilgange, fra én global klynge til flere små og specialiserede:
- én stor fælles klynge;
- en masse af små specialiserede klynger;
- én klynge pr. applikation;
- én klynge pr. miljø.
Så hvilken tilgang skal man vælge?
Som altid afhænger svaret af brugsscenariet: det er nødvendigt at veje fordele og ulemper ved de forskellige tilgange og vælge den mest optimale variant.
Men valget er ikke begrænset til de nævnte eksempler - man kan bruge enhver kombination af dem!
For eksempel kan man organisere et par klynger til hvert team: en klynge til udvikling (hvor der vil være miljøer dev og test) og en klynge til production (hvor produktionsmiljøet vil være).
Ved at basere sig på oplysningerne fra denne artikel kan du optimere fordele og ulemper til det specifikke scenarie. Held og lykke!
P.S.
Læs også på vores blog:
- «»;
- «»;
- «»;
- «».
Kilde: habr.com
