Bemærk. overs.: dette materiale er fra et uddannelsesprojekt er svaret på et populært spørgsmål, når man designer Kubernetes-baseret infrastruktur. Vi håber, at ret detaljerede beskrivelser af fordele og ulemper ved hver mulighed vil hjælpe dig med at træffe det bedste valg til dit projekt.
TL; DR: det samme sæt arbejdsbelastninger kan køres på flere store klynger (hver klynge vil have et stort antal arbejdsbelastninger) eller på mange små (med et lille antal belastninger i hver klynge).
Nedenfor er en tabel, der vurderer fordele og ulemper ved hver tilgang:
Når du bruger Kubernetes som en platform til at køre applikationer, opstår der ofte flere grundlæggende spørgsmål om forviklingerne ved at oprette klynger:
- Hvor mange klynger skal jeg bruge?
- Hvor store skal jeg lave dem?
- Hvad skal hver klynge indeholde?
I denne artikel vil jeg forsøge at besvare alle disse spørgsmål ved at analysere fordele og ulemper ved hver tilgang.
Erklæring af et spørgsmål
Som softwareudvikler udvikler og driver du sandsynligvis mange applikationer på samme tid.
Derudover vil mange forekomster af disse applikationer sandsynligvis køre i forskellige miljøer - det kan disse f.eks dev, prøve и prod.
Resultatet er en hel matrix af applikationer og miljøer:
Applikationer og miljøer
Eksemplet ovenfor repræsenterer 3 applikationer og 3 miljøer, hvilket resulterer i i alt 9 mulige muligheder.
Hver applikationsforekomst er en selvstændig implementeringsenhed, der kan arbejdes med uafhængigt af andre.
Bemærk, at ansøgningsinstans kan bestå af mange komponenter, såsom frontend, backend, database osv. I tilfælde af en mikroserviceapplikation vil instansen inkludere alle mikroservices.
Som et resultat har Kubernetes-brugere flere spørgsmål:
- Skal alle applikationsforekomster placeres i én klynge?
- Er det værd at have en separat klynge for hver applikationsforekomst?
- Eller måske en kombination af ovenstående tilgange skal bruges?
Alle disse muligheder er ganske levedygtige, da Kubernetes er et fleksibelt system, der ikke begrænser brugerens muligheder.
Her er nogle af de mulige måder:
- en stor fælles klynge;
- mange små højt specialiserede klynger;
- en klynge pr. applikation;
- en klynge pr. miljø.
Som vist nedenfor er de to første tilgange i hver sin ende af skalaen af muligheder:
Fra nogle få store klynger (venstre) til mange små (højre)
Generelt betragtes en klynge som "større" end en anden, hvis den har en større sum af noder og pods. For eksempel er en klynge med 10 noder og 100 pods større end en klynge med 1 node og 10 pods.
Nå, lad os komme i gang!
1. En stor fælles klynge
Den første mulighed er at placere alle arbejdsbelastninger i én klynge:
Én stor klynge
Inden for denne tilgang bruges klyngen som en universal infrastruktur platform — du implementerer simpelthen alt, hvad du har brug for i en eksisterende Kubernetes-klynge.
Kubernetes tillader dele af klyngen at blive logisk adskilt fra hinanden, så hver applikationsforekomst kan have sit eget navneområde.
Lad os se på fordele og ulemper ved denne tilgang.
+ Effektiv brug af ressourcer
Med en enkelt klynge behøver du 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 masterknudepunkter. Typisk har hver Kubernetes-klynge 3 masterknuder, så for en enkelt klynge vil deres antal forblive på den måde (til sammenligning vil 10 klynger have brug for 30 masternoder).
Ovenstående finesse gælder også for andre tjenester, der opererer på tværs af hele klyngen, såsom belastningsbalancere, Ingress-controllere, autentificering, logning og overvågningssystemer.
I en enkelt klynge kan alle disse tjenester bruges på én gang til alle arbejdsbelastninger (der er ingen grund til at oprette kopier af dem, som det er tilfældet med flere klynger).
+ Billig
Som en konsekvens af ovenstående er færre klynger normalt billigere, fordi der ikke er nogen faste omkostninger.
Dette gælder især for masterknudepunkter, som kan koste et betydeligt beløb, uanset hvordan de hostes (on-premises eller i skyen).
Nogle administrerede Kubernetes-tjenester, som f.eks eller , giv kontrollaget gratis. I dette tilfælde er omkostningsproblemet mindre akut.
Der er også administrerede tjenester, der opkræver et fast gebyr for driften af hver Kubernetes-klynge (f.eks. ).
+ Effektiv administration
Det er nemmere at administrere én klynge end at administrere flere.
Administration kan omfatte følgende opgaver:
- Kubernetes version opdatering;
- opsætning af en CI/CD-pipeline;
- installation af CNI plugin;
- opsætning af et brugergodkendelsessystem;
- installation af en adgangscontroller;
og mange andre…
I tilfælde af en klynge skal du kun gøre alt dette én gang.
For mange klynger vil operationer skulle gentages mange gange, hvilket sandsynligvis vil kræve en vis automatisering af processer og værktøjer for at sikre konsistens og konsistens i processen.
Og nu et par ord om ulemperne.
− Enkelt fejlpunkt
I tilfælde af afslag den eneste klyngen stopper med det samme alle arbejdsbyrder!
Der er mange måder, hvorpå tingene kan gå galt:
- opdatering af Kubernetes fører til uventede bivirkninger;
- En klyngeomfattende komponent (f.eks. et CNI-plugin) begynder ikke at fungere som forventet;
- en af klyngekomponenterne er ikke konfigureret korrekt;
- fejl i den underliggende infrastruktur.
En sådan hændelse kan forårsage alvorlig skade på alle arbejdsbelastninger, der er hostet i en delt klynge.
− Ingen stiv isolering
At køre i en delt klynge betyder, at applikationer deler hardware, netværkskapaciteter og operativsystem på klyngeknuderne.
På en måde er to containere med to forskellige applikationer, der kører på den samme node, som to processer, der kører på den samme maskine, der kører den samme OS-kerne.
Linux-containere giver en eller anden form for isolation, men den er ikke nær så stærk som den, der leveres af f.eks. virtuelle maskiner. I bund og grund er en proces i en container den samme proces, der kører på værtsoperativsystemet.
Dette kan være et sikkerhedsproblem: Dette arrangement tillader teoretisk set ikke-relaterede applikationer at kommunikere med hinanden (enten med vilje eller ved et uheld).
Derudover deler alle arbejdsbelastninger i en Kubernetes-klynge nogle klyngedækkende tjenester som f.eks - dette giver applikationer mulighed for at finde tjenester fra andre applikationer i klyngen.
Alle ovenstående punkter kan have forskellige betydninger afhængigt af applikationens sikkerhedskrav.
Kubernetes leverer forskellige værktøjer til at forhindre sikkerhedsproblemer som f.eks и . Det kræver dog en vis erfaring at opsætte dem korrekt, og desuden er de ikke i stand til at lukke absolut alle sikkerhedshuller.
Det er vigtigt altid at huske, at Kubernetes oprindeligt blev designet til deling, ikke til isolation og sikkerhed.
− Mangel på streng flerleje
I betragtning af overfloden af delte ressourcer i en Kubernetes-klynge er der mange måder, hvorpå forskellige applikationer kan træde hinanden over tæerne.
For eksempel kan en applikation monopolisere en delt ressource (såsom CPU eller hukommelse) og nægte andre applikationer, der kører på den samme node, adgang til den.
Kubernetes giver forskellige mekanismer til at kontrollere denne adfærd, som f.eks (se også artiklen ""- ca. oversættelse), и . Men som i tilfældet med sikkerhed er deres konfiguration ret ikke-triviel, og de er ikke i stand til at forhindre absolut alle uforudsete bivirkninger.
− Stort antal brugere
I tilfælde af en enkelt klynge skal du åbne adgang til den for mange mennesker. Og jo større antal de er, jo større er risikoen for, at de "bryder" noget.
Inden for klyngen kan du styre, hvem der kan gøre hvad ved hjælp af (se artiklen ""- ca. oversættelse). Det vil dog ikke forhindre brugere i at "bryde" noget inden for grænserne af deres ansvarsområde.
− Klynger kan ikke vokse i det uendelige
Den klynge, der bruges til alle arbejdsbelastninger, vil sandsynligvis være ret stor (i form af antal noder og pods).
Men her opstår et andet problem: klynger i Kubernetes kan ikke vokse i det uendelige.
Der er en teoretisk grænse for klyngestørrelse. I Kubernetes er det ca .
Men i det virkelige liv kan problemer begynde meget tidligere - for eksempel bare med .
Faktum er, at store klynger lægger en høj belastning på Kubernetes kontrollag. Med andre ord kræver det omhyggelig tuning at holde klyngen oppe og køre effektivt.
Dette problem er udforsket i en relateret artikel på den originale blog kaldet "'.
Men lad os overveje den modsatte tilgang: mange små klynger.
2. Mange små, specialiserede klynger
Med denne tilgang bruger du en separat klynge for hvert element, du implementerer:
Mange små klynger
Med henblik på denne artikel, under indsætteligt element refererer til en instans af en applikation - for eksempel en udviklerversion af en separat applikation.
Denne strategi bruger Kubernetes som en specialiseret køretid for individuelle ansøgningstilfælde.
Lad os se på fordele og ulemper ved denne tilgang.
+ Begrænset "sprængningsradius"
Når en klynge fejler, er de negative konsekvenser kun begrænset til de arbejdsbelastninger, der blev implementeret i den klynge. Alle andre arbejdsbyrder forbliver uberørte.
+ Isolering
Arbejdsbelastninger, der hostes i individuelle klynger, deler ikke ressourcer såsom processor, hukommelse, operativsystem, netværk eller andre tjenester.
Resultatet er tæt isolation mellem ikke-relaterede applikationer, hvilket kan være gavnligt for deres sikkerhed.
+ Lille antal brugere
Da hver klynge kun indeholder et begrænset sæt arbejdsbelastninger, reduceres antallet af brugere med adgang til den.
Jo færre mennesker har adgang til klyngen, jo mindre er risikoen for, at noget "går i stykker".
Lad os se på ulemperne.
− Ineffektiv brug af ressourcer
Som tidligere nævnt kræver hver Kubernetes-klynge et specifikt sæt administrationsressourcer: masterknudepunkter, kontrollagskomponenter, overvågnings- og logningsløsninger.
Ved et stort antal små klynger skal der afsættes en større del af ressourcerne til ledelsen.
− Dyrt
Ineffektiv brug af ressourcer medfører automatisk høje omkostninger.
For eksempel vil vedligeholdelse af 30 masterknudepunkter i stedet for tre med samme computerkraft nødvendigvis påvirke omkostningerne.
− Vanskeligheder i administrationen
Det er meget vanskeligere at administrere flere Kubernetes-klynger end at administrere kun én.
For eksempel skal du konfigurere godkendelse og godkendelse for hver klynge. Kubernetes-versionen skal også opdateres flere gange.
Du bliver sandsynligvis nødt til at bruge automatisering for at gøre alle disse opgaver mere effektive.
Lad os nu se på mindre ekstreme scenarier.
3. Én klynge pr. applikation
I denne tilgang opretter du en separat klynge for alle forekomster af en bestemt applikation:
Klynge pr. ansøgning
Denne vej kan betragtes som en generalisering af princippet "separat klynge pr. hold”, da et team af ingeniører normalt udvikler en eller flere applikationer.
Lad os se på fordele og ulemper ved denne tilgang.
+ Klyngen kan tilpasses til applikationen
Hvis en applikation har særlige behov, kan de implementeres i en klynge uden at påvirke andre klynger.
Sådanne behov kan omfatte GPU-medarbejdere, visse CNI-plugins, et servicenetværk eller en anden service.
Hver klynge kan skræddersyes til den applikation, der kører i den, så den kun indeholder det nødvendige.
− Forskellige miljøer i én klynge
Ulempen ved denne tilgang er, at applikationsforekomster fra forskellige miljøer eksisterer side om side i den samme klynge.
For eksempel kører prod-versionen af applikationen i samme klynge som dev-versionen. Dette betyder også, at udviklere opererer i den samme klynge, som produktionsversionen af applikationen drives i.
Hvis der på grund af udviklernes handlinger eller fejl i dev-versionen opstår en fejl i klyngen, kan prod-versionen potentielt også lide - en stor ulempe ved denne tilgang.
Og endelig det sidste scenarie på vores liste.
4. Én klynge pr. miljø
Dette scenarie involverer tildeling af en separat klynge for hvert miljø:
Én klynge pr. miljø
For eksempel kan du have klynger dev, prøve и prod, hvor du vil køre alle forekomster af programmet dedikeret til et specifikt miljø.
Her er fordele og ulemper ved denne tilgang.
+ Isolering af prod-miljøet
Inden for denne tilgang er alle miljøer isoleret fra hinanden. I praksis er dette dog især vigtigt i et prod-miljø.
Produktionsversioner af applikationen er nu uafhængige af, hvad der sker i andre klynger og miljøer.
På denne måde, hvis der pludselig opstår et problem i dev-klyngen, vil prod-versionerne af applikationerne fortsætte med at fungere, som om intet var hændt.
+ Klyngen kan tilpasses miljøet
Hver klynge kan justeres til sit miljø. Du kan f.eks.:
- installere værktøjer til udvikling og debugging i dev-klyngen;
- installere testrammer og værktøjer i klyngen prøve;
- bruge mere kraftfuld hardware og netværkskanaler i klyngen prod.
Dette giver dig mulighed for at øge effektiviteten af både applikationsudvikling og drift.
+ Begrænsning af adgang til produktionsklyngen
Behovet for at arbejde direkte med en prod-klynge opstår sjældent, så du kan markant begrænse kredsen af personer, der har adgang til den.
Du kan gå endnu længere og nægte folk adgang til denne klynge helt, og udføre alle implementeringer ved hjælp af et automatiseret CI/CD-værktøj. En sådan tilgang vil minimere risikoen for menneskelige fejl, præcis hvor det er mest relevant.
Og nu et par ord om ulemperne.
− Ingen isolation mellem applikationer
Den største ulempe ved tilgangen er manglen på hardware og ressourceisolering mellem applikationer.
Ikke-relaterede applikationer deler klyngresourcer: systemkernen, processoren, hukommelsen og nogle andre tjenester.
Som nævnt kan dette være potentielt farligt.
− Manglende evne til at lokalisere applikationsafhængigheder
Hvis en ansøgning har særlige krav, så skal de være opfyldt på tværs af alle klynger.
For eksempel, hvis en applikation kræver en GPU, skal hver klynge indeholde mindst én arbejder med en GPU (selvom den kun bruges af den applikation).
Som et resultat risikerer vi højere omkostninger og ineffektiv brug af ressourcer.
Konklusion
Hvis du har et specifikt sæt applikationer, kan de placeres i flere store klynger eller mange små.
Artiklen diskuterer fordele og ulemper ved forskellige tilgange, lige fra en global klynge til flere små og højt specialiserede:
- en stor generel klynge;
- mange små højt specialiserede klynger;
- en klynge pr. applikation;
- en klynge pr. miljø.
Så hvilken tilgang skal du tage?
Som altid afhænger svaret af brugssagen: du skal afveje fordele og ulemper ved forskellige tilgange og vælge den mest optimale mulighed.
Valget er dog ikke begrænset til eksemplerne ovenfor - du kan bruge enhver kombination af dem!
For eksempel kan du organisere et par klynger for hvert team: en udviklingsklynge (hvor der vil være miljøer dev и prøve) og klynge for produktion (hvor produktionsmiljøet vil være placeret).
Baseret på oplysningerne i denne artikel kan du optimere fordele og ulemper i overensstemmelse hermed for et specifikt scenarie. Held og lykke!
PS
Læs også på vores blog:
- «";
- «";
- «";
- «'.
Kilde: www.habr.com