Bij het maken van een Kubernetes-cluster kunnen er vragen rijzen: hoeveel werkknooppunten moeten worden geconfigureerd en welk type? Wat is beter voor een on-premise cluster: koop meerdere krachtige servers of gebruik een tiental oude machines in uw datacenter? Is het beter om acht single-core of twee quad-core instances in de cloud te plaatsen?
De antwoorden op deze vragen staan in het artikel. in de vertaling van het bevel .
Clustercapaciteit
Over het algemeen kan een Kubernetes-cluster worden gezien als een grote ‘supernode’. De totale rekenkracht is de som van de krachten van alle samenstellende knooppunten.
Er zijn verschillende manieren om het gewenste clustercapaciteitsdoel te bereiken. We hebben bijvoorbeeld een cluster nodig met een totale capaciteit van 8 processorkernen en 32 GB RAM, omdat een reeks applicaties zoveel bronnen vereist. Vervolgens kunt u twee knooppunten met 16 GB geheugen of vier knooppunten met 8 GB geheugen, twee quad-coreprocessors of vier dual-coreprocessors installeren.
Hier volgen slechts twee mogelijke manieren om een cluster te maken:
Beide opties produceren een cluster met dezelfde capaciteit, maar de onderste configuratie heeft vier kleinere knooppunten en de bovenste configuratie heeft twee grotere knooppunten.
Wat is de beste optie?
Laten we, om deze vraag te beantwoorden, eens kijken naar de voordelen van beide opties. Wij hebben ze samengevat in een tabel.
Verschillende grote knooppunten
Veel kleine knooppunten
Eenvoudiger clusterbeheer (als het on-premise is)
Soepel automatisch schalen
Goedkoper (indien op locatie)
De prijs is weinig anders (in de cloud)
Kan resource-intensieve applicaties uitvoeren
Volledige replicatie
Bronnen worden efficiënter gebruikt (minder overhead op systeemdaemons).
Hogere clusterfouttolerantie
Houd er rekening mee dat we het alleen over werkknooppunten hebben. Het kiezen van het aantal en de grootte van hoofdknooppunten is een heel ander onderwerp.
Laten we dus elk punt uit de tabel in meer detail bespreken.
Eerste optie: meerdere grote knooppunten
De meest extreme optie is één werkknooppunt voor de gehele clustercapaciteit. In het bovenstaande voorbeeld zou dit een enkel werkknooppunt zijn met 16 CPU-kernen en 16 GB RAM.
Voors
Plus nr. 1. Eenvoudiger beheer
Het is gemakkelijker om een paar machines te beheren dan een heel wagenpark. Het is sneller om updates en fixes uit te rollen, en het is gemakkelijker om te synchroniseren. Ook het aantal storingen in absolute cijfers is kleiner.
Houd er rekening mee dat al het bovenstaande van toepassing is op uw hardware, uw servers en niet op cloudinstanties.
In de cloud is de situatie anders. Daar wordt het beheer verzorgd door de cloudserviceprovider. Het beheren van tien knooppunten in de cloud verschilt dus niet veel van het beheren van één knooppunt.
Verkeersroutering en belastingverdeling tussen pods in de cloud : verkeer dat van internet komt, wordt naar de hoofdload balancer gestuurd, die verkeer doorstuurt naar de poort van een van de knooppunten (de NodePort-service stelt de poort in het bereik 30000-32767 in elk clusterknooppunt in). De regels die door kube-proxy zijn ingesteld, leiden verkeer om van het knooppunt naar de pod. Zo ziet het eruit voor tien pods op twee knooppunten:
Pro #2: Minder kosten per knooppunt
Een krachtige auto is duurder, maar de prijsstijging is niet noodzakelijk lineair. Met andere woorden: één tien-core server met 10 GB geheugen is doorgaans goedkoper dan tien single-core servers met dezelfde hoeveelheid geheugen.
Maar houd er rekening mee dat deze regel meestal niet werkt in cloudservices. In de huidige prijsschema's van alle grote cloudproviders stijgen de prijzen lineair met de capaciteit.
In de cloud kun je dus meestal niet besparen op krachtigere servers.
Pro #3: U kunt resource-intensieve applicaties uitvoeren
Sommige applicaties vereisen krachtige servers in een cluster. Als een machine learning-systeem bijvoorbeeld 8 GB geheugen nodig heeft, kunt u het niet uitvoeren op knooppunten van 1 GB, maar alleen met ten minste één groot werkknooppunt.
Tegens
Nadeel nr. 1. Veel pods per knooppunt
Als dezelfde taak op minder knooppunten wordt uitgevoerd, heeft elk van deze uiteraard meer pods.
Dit kan een probleem zijn.
De reden is dat elke module enige overhead introduceert voor de containerruntime (bijvoorbeeld Docker), evenals voor de kubelet en cAdvisor.
Een kubelet onderzoekt bijvoorbeeld regelmatig alle containers op een knooppunt op overlevingskansen: hoe meer containers, hoe meer werk de kubelet moet doen.
CAdvisor verzamelt statistieken over het gebruik van bronnen voor alle containers op een knooppunt, en kubelet vraagt deze informatie regelmatig op en levert deze via een API. Nogmaals, meer containers betekent meer werk voor zowel cAdvisor als kubelet.
Als het aantal modules toeneemt, kan dit het systeem vertragen en zelfs de betrouwbaarheid ervan ondermijnen.
In de Kubernetes-repository enkele dat knooppunten tussen de Ready/NotReady-statussen springen omdat regelmatige kubelet-controles van alle containers op een knooppunt te lang duren.
Om deze reden Kubernetes . Afhankelijk van de prestaties van het knooppunt kunt u meer pods per knooppunt uitvoeren, maar het is moeilijk te voorspellen of er problemen zullen optreden of dat alles goed zal werken. Het is de moeite waard om het werk van tevoren te testen.
Nadeel nr. 2. Beperking op replicatie
Te weinig knooppunten beperken de effectieve omvang van applicatiereplicatie. Als u bijvoorbeeld een toepassing met hoge beschikbaarheid hebt met vijf replica's maar slechts twee knooppunten, wordt de effectieve replicatiegraad van de toepassing teruggebracht tot twee.
Vijf replica's kunnen slechts over twee knooppunten worden verdeeld, en als een van deze faalt, worden meerdere replica's tegelijk uitgeschakeld.
Als u vijf of meer knooppunten hebt, wordt elke replica op een afzonderlijk knooppunt uitgevoerd en wordt bij het falen van één knooppunt maximaal één replica verwijderd.
Hoge beschikbaarheidsvereisten kunnen dus een bepaald minimumaantal knooppunten in het cluster vereisen.
Nadeel nr. 3. Ergere gevolgen van falen
Met een klein aantal knooppunten heeft elke storing ernstiger gevolgen. Als u bijvoorbeeld maar twee knooppunten heeft en één ervan faalt, verdwijnt de helft van uw modules onmiddellijk.
Uiteraard zal Kubernetes de werklast van het mislukte knooppunt naar andere migreren. Maar als er maar weinig zijn, is er mogelijk niet voldoende vrije capaciteit. Als gevolg hiervan zijn sommige van uw toepassingen niet beschikbaar totdat u het defecte knooppunt opent.
Dus hoe meer knooppunten, hoe minder de impact van hardwarestoringen.
Nadeel #4: Meer stappen voor automatisch schalen
Kubernetes heeft een systeem voor automatisch schalen van clusters voor de cloudinfrastructuur, waarmee u automatisch knooppunten kunt toevoegen of verwijderen, afhankelijk van uw huidige behoeften. Bij grotere knooppunten wordt automatisch schalen abrupter en onhandiger. Als u bijvoorbeeld op twee knooppunten een extra knooppunt toevoegt, wordt de clustercapaciteit onmiddellijk met 50% vergroot. En je zult voor die middelen moeten betalen, zelfs als je ze niet nodig hebt.
Als u dus van plan bent automatische clusterschaling te gebruiken, geldt het volgende: hoe kleiner de knooppunten, hoe flexibeler en kosteneffectiever u kunt schalen.
Laten we nu eens kijken naar de voor- en nadelen van een groot aantal kleine knooppunten.
Tweede optie: veel kleine knooppunten
De voordelen van deze aanpak komen hoofdzakelijk voort uit de nadelen van de tegenovergestelde optie met meerdere grote knooppunten.
Voors
Pro #1: Minder impact van falen
Hoe meer knooppunten, hoe minder peulen op elk knooppunt. Als u bijvoorbeeld honderd modules per tien knooppunten heeft, heeft elk knooppunt gemiddeld tien modules.
Op deze manier verliest u slechts 10% van de werklast als een van de knooppunten uitvalt. De kans is groot dat slechts een klein aantal replica’s wordt getroffen en dat de algehele applicatie operationeel blijft.
Bovendien zullen de resterende knooppunten waarschijnlijk voldoende vrije bronnen hebben om de werklast van het defecte knooppunt af te handelen, zodat Kubernetes de pods vrijelijk opnieuw kan plannen en uw applicaties relatief snel naar een functionele status zullen terugkeren.
Pro #2: Goede replicatie
Als er voldoende knooppunten zijn, kan de Kubernetes-planner verschillende knooppunten aan alle replica's toewijzen. Op deze manier wordt, als een knooppunt uitvalt, slechts één replica getroffen en blijft de applicatie beschikbaar.
Tegens
Nadeel nr. 1. Moeilijk te controleren
Grote aantallen knooppunten zijn moeilijker te beheren. Elk Kubernetes-knooppunt moet bijvoorbeeld met alle anderen communiceren, dat wil zeggen dat het aantal verbindingen kwadratisch groeit, en al deze verbindingen moeten worden gevolgd.
De knooppuntcontroller in Kubernetes Controller Manager doorloopt regelmatig alle knooppunten in het cluster om de gezondheid te controleren: hoe meer knooppunten, hoe meer belasting op de controller.
De belasting van de etcd-database neemt ook toe: elke kubelet- en kube-proxy-oproep voor etcd (via de API), waarnaar etcd objectupdates moet uitzenden.
Over het algemeen legt elk werkknooppunt extra belasting op de systeemcomponenten van de hoofdknooppunten.
Kubernetes ondersteunt officieel clusters met . In de praktijk zijn er echter al 500 knooppunten .
Om een groot aantal werkknooppunten te beheren, moet u krachtigere hoofdknooppunten kiezen. Kube-up bijvoorbeeld de juiste VM-grootte voor het hoofdknooppunt, afhankelijk van het aantal werkknooppunten. Dat wil zeggen: hoe meer werkknooppunten, hoe productiever de hoofdknooppunten zouden moeten zijn.
Om deze specifieke problemen op te lossen zijn er speciale ontwikkelingen, zoals . Met dit systeem kunt u beperkingen omzeilen en clusters bouwen met een groot aantal werkknooppunten.
Nadeel #2: Meer overheadkosten.
Op elk werkknooppunt voert Kubernetes een reeks systeemdaemons uit, waaronder de containerruntime (zoals Docker), kube-proxy en kubelet, inclusief cAdvisor. Samen verbruiken ze een bepaalde vaste hoeveelheid hulpbronnen.
Als u veel kleine knooppunten heeft, is het aandeel van deze overhead op elk knooppunt groter. Stel je bijvoorbeeld voor dat alle systeemdaemons op één knooppunt samen 0,1 CPU-kernen en 0,1 GB geheugen gebruiken. Als u één tien-core knooppunt met 10 GB geheugen hebt, verbruiken daemons 1% van de clustercapaciteit. Aan de andere kant zullen de daemons op tien single-core knooppunten met 1 GB geheugen 10% van de clustercapaciteit in beslag nemen.
Dus hoe minder knooppunten, hoe efficiënter de infrastructuur wordt gebruikt.
Nadeel nr. 3. Inefficiënt gebruik van hulpbronnen
Op kleine knooppunten kan het zijn dat de resterende resource-brokken te klein zijn om werklast aan toe te wijzen, zodat ze ongebruikt blijven.
Elke pod heeft bijvoorbeeld 0,75 GB geheugen nodig. Als u tien knooppunten hebt, elk met 1 GB geheugen, kunt u tien pods uitvoeren, waardoor elk knooppunt 0,25 GB ongebruikt geheugen overhoudt.
Dit betekent dat 25% van het geheugen van het gehele cluster verloren gaat.
Op een groot knooppunt met 10 GB geheugen kun je 13 van deze modules draaien - en er zal slechts één ongebruikt fragment van 0,25 GB zijn.
In dit geval wordt slechts 2,5% van het geheugen verspild.
Op grotere knooppunten worden bronnen dus optimaal gebruikt.
Meerdere grote knooppunten of veel kleine?
Dus wat is beter: een paar grote knooppunten in een cluster of veel kleine? Zoals altijd is er geen duidelijk antwoord. Veel hangt af van het type toepassing.
Als een applicatie bijvoorbeeld 10 GB geheugen nodig heeft, zijn grotere knooppunten een voor de hand liggende keuze. En als een applicatie tienvoudige replicatie vereist voor hoge beschikbaarheid, is het nauwelijks het risico waard om replica's op slechts twee knooppunten te plaatsen: er moeten minimaal tien knooppunten in het cluster zijn.
Maak in tussenliggende situaties een keuze op basis van de voor- en nadelen van elke optie. Misschien zijn sommige argumenten relevanter voor uw situatie dan andere.
En het is helemaal niet nodig om alle knooppunten even groot te maken. Niets belet je om eerst te experimenteren met knooppunten van dezelfde grootte, er vervolgens knooppunten van een andere grootte aan toe te voegen en ze in een cluster te combineren. Werkknooppunten in een Kubernetes-cluster kunnen volledig heterogeen zijn. U kunt dus proberen de voordelen van beide benaderingen te combineren.
Er is niet één recept, en elke situatie heeft zijn eigen nuances, en alleen de productie zal de waarheid laten zien.
Vertaling voorbereid door het cloudplatformteam .
Meer over Kubernetes: .
Bron: www.habr.com