Opmerking. vert.: dit materiaal is afkomstig van een educatief project is het antwoord op een populaire vraag bij het ontwerpen van op Kubernetes gebaseerde infrastructuur. We hopen dat vrij gedetailleerde beschrijvingen van de voor- en nadelen van elke optie u zullen helpen de beste keuze voor uw project te maken.
TL; DR: dezelfde set werkbelastingen kan worden uitgevoerd op verschillende grote clusters (elk cluster heeft een groot aantal werkbelastingen) of op veel kleine werkbelastingen (met een klein aantal belastingen in elk cluster).
Hieronder vindt u een tabel waarin de voor- en nadelen van elke aanpak worden geëvalueerd:
Bij het gebruik van Kubernetes als platform voor het uitvoeren van applicaties rijzen er vaak verschillende fundamentele vragen over de complexiteit van het opzetten van clusters:
- Hoeveel clusters moet ik gebruiken?
- Hoe groot moet ik ze maken?
- Wat moet elk cluster bevatten?
In dit artikel zal ik proberen al deze vragen te beantwoorden door de voor- en nadelen van elke aanpak te analyseren.
Verklaring van een vraag
Als softwareontwikkelaar ontwikkelt en beheert u waarschijnlijk veel applicaties tegelijkertijd.
Bovendien zullen veel exemplaren van deze applicaties waarschijnlijk in verschillende omgevingen draaien, bijvoorbeeld deze dev, proef и por.
Het resultaat is een hele matrix van applicaties en omgevingen:
Toepassingen en omgevingen
Het bovenstaande voorbeeld vertegenwoordigt 3 applicaties en 3 omgevingen, wat resulteert in een totaal van 9 mogelijke opties.
Elke toepassingsinstantie is een op zichzelf staande implementatie-eenheid waarmee onafhankelijk van anderen kan worden gewerkt.
Houd er rekening mee dat toepassingsexemplaar kan uit velen bestaan onderdelen, zoals frontend, backend, database, enz. In het geval van een microservicestoepassing zal de instance alle microservices bevatten.
Als gevolg hiervan hebben Kubernetes-gebruikers verschillende vragen:
- Moeten alle applicatie-instanties in één cluster worden geplaatst?
- Is het de moeite waard om voor elke toepassingsinstantie een afzonderlijk cluster te hebben?
- Of moet misschien een combinatie van de bovenstaande benaderingen worden gebruikt?
Al deze opties zijn redelijk haalbaar, aangezien Kubernetes een flexibel systeem is dat de mogelijkheden van de gebruiker niet beperkt.
Hier zijn enkele van de mogelijke manieren:
- één groot gemeenschappelijk cluster;
- veel kleine, zeer gespecialiseerde clusters;
- één cluster per applicatie;
- één cluster per omgeving.
Zoals hieronder blijkt, bevinden de eerste twee benaderingen zich aan de tegenovergestelde uiteinden van de schaal van opties:
Van enkele grote clusters (links) tot vele kleine clusters (rechts)
Over het algemeen wordt het ene cluster als ‘groter’ beschouwd dan het andere als het een grotere som knooppunten en peulen heeft. Een cluster met 10 knooppunten en 100 peulen is bijvoorbeeld groter dan een cluster met 1 knooppunt en 10 peulen.
Nou, laten we beginnen!
1. Eén groot gemeenschappelijk cluster
De eerste optie is om alle workloads in één cluster te plaatsen:
Eén grote cluster
Binnen deze aanpak wordt het cluster als universeel gebruikt infrastructuurplatform — u implementeert eenvoudig alles wat u nodig heeft in een bestaand Kubernetes-cluster.
Kubernetes maakt het mogelijk delen van het cluster logisch van elkaar te scheiden, zodat elke applicatie-instantie zijn eigen naamruimte kan hebben.
Laten we eens kijken naar de voor- en nadelen van deze aanpak.
+ Efficiënt gebruik van hulpbronnen
Met één cluster heeft u slechts één kopie nodig van alle bronnen die nodig zijn om het Kubernetes-cluster uit te voeren en te beheren.
Dit geldt bijvoorbeeld voor masterknooppunten. Normaal gesproken heeft elk Kubernetes-cluster drie hoofdknooppunten, dus voor één cluster blijft hun aantal zo (ter vergelijking: voor 3 clusters zijn 10 hoofdknooppunten nodig).
De bovenstaande subtiliteit geldt ook voor andere diensten die over het hele cluster opereren, zoals load balancers, Ingress-controllers, authenticatie-, logging- en monitoringsystemen.
In één cluster kunnen al deze services in één keer worden gebruikt voor alle workloads (het is niet nodig om er kopieën van te maken, zoals bij meerdere clusters het geval is).
+ Goedkoop
Als gevolg van bovenstaande zijn doorgaans minder clusters goedkoper omdat er geen overheadkosten zijn.
Dit geldt met name voor masterknooppunten, die een aanzienlijke hoeveelheid geld kunnen kosten, ongeacht hoe ze worden gehost (on-premises of in de cloud).
Sommige beheerde Kubernetes-services, zoals of , verstrek de controlelaag gratis. In dit geval is het kostenprobleem minder acuut.
Er zijn ook beheerde services die een vast bedrag in rekening brengen voor de werking van elk Kubernetes-cluster (bijvoorbeeld ).
+ Efficiënte administratie
Het beheren van één cluster is eenvoudiger dan het beheren van meerdere.
Administratie kan de volgende taken omvatten:
- Kubernetes-versie-update;
- het opzetten van een CI/CD-pijplijn;
- het installeren van de CNI-plug-in;
- het opzetten van een gebruikersauthenticatiesysteem;
- installatie van een toegangscontroller;
en vele anderen…
Bij één cluster hoeft u dit allemaal maar één keer te doen.
Voor veel clusters zullen bewerkingen vele malen moeten worden herhaald, wat waarschijnlijk enige automatisering van processen en hulpmiddelen zal vereisen om consistentie en consistentie in het proces te garanderen.
En nu een paar woorden over de nadelen.
− Eén storingspunt
Bij weigering de enige het cluster stopt onmiddellijk met werken alle werkdruk!
Er zijn veel manieren waarop dingen fout kunnen gaan:
- het updaten van Kubernetes leidt tot onverwachte bijwerkingen;
- Een clusterbrede component (bijvoorbeeld een CNI-plug-in) begint niet te werken zoals verwacht;
- een van de clustercomponenten is niet correct geconfigureerd;
- falen in de onderliggende infrastructuur.
Eén zo’n incident kan ernstige schade veroorzaken aan alle workloads die in een gedeeld cluster worden gehost.
− Geen stijve isolatie
Het draaien in een gedeeld cluster betekent dat applicaties de hardware, netwerkmogelijkheden en het besturingssysteem op de clusterknooppunten delen.
In zekere zin zijn twee containers met twee verschillende applicaties die op hetzelfde knooppunt draaien, als twee processen die op dezelfde machine draaien en dezelfde OS-kernel draaien.
Linux-containers bieden een vorm van isolatie, maar deze is lang niet zo sterk als die van bijvoorbeeld virtuele machines. In essentie is een proces in een container hetzelfde proces dat op het hostbesturingssysteem draait.
Dit kan een beveiligingsprobleem zijn: deze opstelling maakt het theoretisch mogelijk dat niet-gerelateerde applicaties met elkaar communiceren (opzettelijk of per ongeluk).
Bovendien delen alle workloads in een Kubernetes-cluster enkele clusterbrede services, zoals - hierdoor kunnen applicaties services van andere applicaties in het cluster vinden.
Alle bovenstaande punten kunnen verschillende betekenissen hebben, afhankelijk van de beveiligingsvereisten van de applicatie.
Kubernetes biedt verschillende tools om beveiligingsproblemen zoals и . Het correct instellen ervan vereist echter enige ervaring; bovendien zijn ze niet in staat om absoluut alle beveiligingslekken te dichten.
Het is belangrijk om altijd te onthouden waarvoor Kubernetes oorspronkelijk is ontworpen delen, niet voor isolatie en veiligheid.
− Gebrek aan strikte multi-tenancy
Gezien de overvloed aan gedeelde bronnen in een Kubernetes-cluster zijn er veel manieren waarop verschillende applicaties elkaar op de tenen kunnen trappen.
Een applicatie kan bijvoorbeeld een gedeelde bron (zoals CPU of geheugen) monopoliseren en andere applicaties die op hetzelfde knooppunt draaien, de toegang daartoe ontzeggen.
Kubernetes biedt verschillende mechanismen om dit gedrag te controleren, zoals (zie ook het artikel “" - ca. vert.), и . Maar net als in het geval van de beveiliging is hun configuratie niet triviaal en zijn ze niet in staat om absoluut alle onvoorziene bijwerkingen te voorkomen.
− Groot aantal gebruikers
In het geval van een enkel cluster moet je de toegang daartoe voor veel mensen openstellen. En hoe groter hun aantal, hoe groter het risico dat ze iets ‘breken’.
Binnen het cluster kun je bepalen wie wat kan doen (zie artikel “" - ca. vert.). Het zal gebruikers er echter niet van weerhouden iets binnen de grenzen van hun verantwoordelijkheidsgebied te ‘breken’.
− Clusters kunnen niet oneindig blijven groeien
Het cluster dat voor alle workloads wordt gebruikt, zal waarschijnlijk behoorlijk groot zijn (in termen van het aantal knooppunten en peulen).
Maar hier doet zich een ander probleem voor: clusters in Kubernetes kunnen niet oneindig blijven groeien.
Er is een theoretische limiet voor de clustergrootte. In Kubernetes is dit ongeveer .
In het echte leven kunnen problemen echter veel eerder beginnen, bijvoorbeeld gewoon met .
Feit is dat grote clusters een hoge belasting op de Kubernetes-controlelaag leggen. Met andere woorden: het efficiënt draaiende houden van het cluster vereist een zorgvuldige afstemming.
Dit probleem wordt onderzocht in een gerelateerd artikel op de oorspronkelijke blog genaamd ".
Maar laten we eens kijken naar de tegenovergestelde aanpak: veel kleine clusters.
2. Veel kleine, gespecialiseerde clusters
Met deze aanpak gebruik je een apart cluster voor elk element dat je implementeert:
Veel kleine clusters
Voor de doeleinden van dit artikel, onder inzetbaar onderdeel verwijst naar een exemplaar van een applicatie, bijvoorbeeld een ontwikkelversie van een afzonderlijke applicatie.
Deze strategie maakt gebruik van Kubernetes als specialist looptijd voor individuele toepassingsinstanties.
Laten we eens kijken naar de voor- en nadelen van deze aanpak.
+ Beperkte “straalradius”
Wanneer een cluster faalt, blijven de negatieve gevolgen beperkt tot de workloads die in dat cluster zijn geïmplementeerd. Alle andere werklasten blijven onaangeroerd.
+ Isolatie
Werkbelastingen die in afzonderlijke clusters worden gehost, delen geen bronnen zoals processor, geheugen, besturingssysteem, netwerk of andere services.
Het resultaat is een nauwe isolatie tussen niet-gerelateerde applicaties, wat gunstig kan zijn voor de veiligheid ervan.
+ Klein aantal gebruikers
Aangezien elk cluster slechts een beperkte set workloads bevat, wordt het aantal gebruikers met toegang daartoe verminderd.
Hoe minder mensen toegang hebben tot het cluster, hoe kleiner de kans dat er iets ‘breekt’.
Laten we naar de nadelen kijken.
− Inefficiënt gebruik van hulpbronnen
Zoals eerder vermeld, vereist elk Kubernetes-cluster een specifieke set beheerbronnen: masternodes, componenten van de controlelaag, monitoring- en logoplossingen.
Bij een groot aantal kleine clusters moet een groter deel van de middelen aan het management worden toegewezen.
− Duur
Inefficiënt gebruik van hulpbronnen brengt automatisch hoge kosten met zich mee.
Als u bijvoorbeeld dertig masterknooppunten in plaats van drie met dezelfde rekenkracht in stand houdt, zal dit noodzakelijkerwijs van invloed zijn op de kosten.
− Moeilijkheden bij de administratie
Het beheren van meerdere Kubernetes-clusters is veel moeilijker dan het beheren van slechts één cluster.
U zult bijvoorbeeld voor elk cluster authenticatie en autorisatie moeten configureren. Ook de Kubernetes-versie zal meerdere malen geüpdatet moeten worden.
U zult waarschijnlijk automatisering moeten gebruiken om al deze taken efficiënter te maken.
Laten we nu eens kijken naar minder extreme scenario’s.
3. Eén cluster per applicatie
Bij deze aanpak maak je een apart cluster voor alle instances van een bepaalde applicatie:
Cluster per applicatie
Dit pad kan worden beschouwd als een generalisatie van het principe “apart cluster per team”, aangezien meestal een team van ingenieurs een of meer applicaties ontwikkelt.
Laten we eens kijken naar de voor- en nadelen van deze aanpak.
+ Het cluster kan worden aangepast aan de toepassing
Als een applicatie speciale behoeften heeft, kunnen deze in een cluster worden geïmplementeerd zonder dat dit gevolgen heeft voor andere clusters.
Dergelijke behoeften kunnen GPU-werknemers, bepaalde CNI-plug-ins, een servicemesh of een andere service omvatten.
Elk cluster kan worden afgestemd op de applicatie die erin draait, zodat het alleen datgene bevat wat nodig is.
− Verschillende omgevingen in één cluster
Het nadeel van deze aanpak is dat applicatie-instanties uit verschillende omgevingen naast elkaar in hetzelfde cluster bestaan.
De prod-versie van de applicatie draait bijvoorbeeld in hetzelfde cluster als de dev-versie. Dit betekent ook dat ontwikkelaars in hetzelfde cluster opereren waarin de productieversie van de applicatie draait.
Als er, als gevolg van de acties van ontwikkelaars of storingen in de dev-versie, een fout optreedt in het cluster, kan de prod-versie mogelijk ook te lijden hebben - een groot nadeel van deze aanpak.
En tot slot het laatste scenario op onze lijst.
4. Eén cluster per omgeving
In dit scenario wordt voor elke omgeving een afzonderlijk cluster toegewezen:
Eén cluster per omgeving
U kunt bijvoorbeeld clusters hebben dev, proef и por, waarin u alle exemplaren van de applicatie uitvoert die aan een specifieke omgeving zijn toegewezen.
Hier zijn de voor- en nadelen van deze aanpak.
+ Isolatie van de productieomgeving
Binnen deze aanpak zijn alle omgevingen van elkaar geïsoleerd. In de praktijk is dit echter vooral belangrijk in een productieomgeving.
Productieversies van de applicatie zijn nu onafhankelijk van wat er in andere clusters en omgevingen gebeurt.
Als er zich plotseling een probleem voordoet in het dev-cluster, blijven de prod-versies van de applicaties op deze manier werken alsof er niets is gebeurd.
+ Het cluster kan aangepast worden aan de omgeving
Elk cluster kan worden aangepast aan zijn omgeving. U kunt bijvoorbeeld:
- installeer tools voor ontwikkeling en foutopsporing in het ontwikkelcluster;
- installeer testframeworks en tools in het cluster proef;
- gebruik krachtigere hardware- en netwerkkanalen in het cluster por.
Hierdoor kunt u de efficiëntie van zowel de ontwikkeling als het gebruik van applicaties verhogen.
+ Beperking van de toegang tot het productiecluster
De noodzaak om rechtstreeks met een productcluster te werken komt zelden voor, dus u kunt de kring van mensen die er toegang toe hebben aanzienlijk beperken.
U kunt zelfs nog verder gaan en mensen de toegang tot dit cluster geheel ontzeggen, en alle implementaties uitvoeren met behulp van een geautomatiseerde CI/CD-tool. Een dergelijke aanpak minimaliseert het risico op menselijke fouten precies daar waar dit het meest relevant is.
En nu een paar woorden over de nadelen.
− Geen isolatie tussen applicaties
Het grootste nadeel van de aanpak is het gebrek aan hardware- en resource-isolatie tussen applicaties.
Niet-gerelateerde applicaties delen clusterbronnen: de systeemkern, processor, geheugen en enkele andere services.
Zoals gezegd kan dit potentieel gevaarlijk zijn.
− Onvermogen om applicatie-afhankelijkheden te lokaliseren
Als een applicatie speciale eisen stelt, dan moet daar in alle clusters aan worden voldaan.
Als voor een toepassing bijvoorbeeld een GPU vereist is, moet elk cluster ten minste één werker met een GPU bevatten (zelfs als deze alleen door die toepassing wordt gebruikt).
Als gevolg hiervan riskeren we hogere kosten en een inefficiënt gebruik van hulpbronnen.
Conclusie
Als u een specifieke set applicaties heeft, kunnen deze in meerdere grote clusters of in veel kleine clusters worden geplaatst.
Het artikel bespreekt de voor- en nadelen van verschillende benaderingen, variërend van één mondiaal cluster tot verschillende kleine en zeer gespecialiseerde benaderingen:
- één groot algemeen cluster;
- veel kleine, zeer gespecialiseerde clusters;
- één cluster per applicatie;
- één cluster per omgeving.
Dus welke aanpak moet je volgen?
Zoals altijd hangt het antwoord af van de gebruikssituatie: u moet de voor- en nadelen van verschillende benaderingen afwegen en de meest optimale optie kiezen.
De keuze is echter niet beperkt tot de bovenstaande voorbeelden; u kunt elke combinatie ervan gebruiken!
U kunt bijvoorbeeld voor elk team een aantal clusters organiseren: een ontwikkelcluster (waarin zich omgevingen bevinden dev и proef) en clusteren voor productie (waar de productieomgeving zich zal bevinden).
Op basis van de informatie in dit artikel kunt u de voor- en nadelen voor een specifiek scenario optimaliseren. Succes!
PS
Lees ook op onze blog:
- «";
- «";
- «";
- «.
Bron: www.habr.com