30/06/2021
Veilige toegang in jouw hybride cloud landschap
De veiligheid van de verschillende cloud platformen is in de loop der jaren sterk verbeterd en ook rondom privacy en wet- en regelgeving is de situatie nu veel beter geregeld.
Blog
Deel 2 over Kubernetes clusters: worker nodes grootte. In het vorige artikel over Kubernetes Clusters heb ik aangegeven dat je wordt geconfronteerd met enkele fundamentele vragen. Deze vragen gaan over het aantal Kubernetes-clusters en de grootte daarvan wanneer je applicaties op Kubernetes wil gaan hosten:
Zoals beloofd ga ik het tweede deel over Kubernetes cluster architectuur in op de grootte van worker nodes en het aantal worker nodes. Hierin kan je wederom twee strategieën volgen; meerdere kleine worker nodes of enkele grote in een cluster.
Over het algemeen kan een Kubernetes cluster worden gezien als de abstractie van een set nodes als één super grote node. De totale rekencapaciteit (in termen van CPU en geheugen) van deze super node is het totaal van de capaciteit van de set nodes. Er zijn meerdere manieren om de gewenste capaciteit van een cluster te bereiken.
Stel je voor dat je een cluster nodig hebt met een totale capaciteit van 40 cores en 160 GB. RAM. Hieronder tref je twee mogelijke manieren om dat cluster te ontwerpen:
Beide opties beschikken over dezelfde hoeveelheid resources. De rechter heeft 5 kleine nodes met elk 8 cores en 32 GB RAM. De linker 2 grote nodes die elk beschikken over 20 cores en 80 GB RAM. Welke van deze twee opties is nu handiger?
De waarheid ligt natuurlijk weer ergens in het midden, maar in deze tabel tref je de belangrijkste punten waarmee je kan bepalen welk type cluster het best past bij jouw situatie. Ik zoom in de rest van het artikel in op elk genoemd punt.
Tabel: Belangrijkste overwegingen
| Veel kleine nodes | Enkele grote nodes | |
|---|---|---|
| Kosten per node | 👎 | 👍 |
| Resource- en kosten efficiëntie | 🤔 | 🤔 |
| Beheer overhead | 👎 | 👍 |
| Resource-intensieve applicaties | 👎 | 👍 |
| Redundantie | 👍 | 👎 |
Hoewel een krachtigere machine duurder is dan een low-end machine, is de prijsverhoging niet per se lineair. Oftewel twee machines met 20 CPU-kernen en 80 GB RAM zijn mogelijk goedkoper dan 5 machines met 8 CPU-kernen en 32 GB RAM.
In de public cloud kun je helaas geen geld besparen door grotere machines te gebruiken, doordat het prijsmodel lineair is. In die situatie zou je ook prima voor meerdere kleinere nodes kunnen kiezen.
Als je veel kleine nodes inzet, worden er relatief gezien meer resources ingenomen door de Kubernetes-agents op de nodes.
Stel dat alle daemons op een enkele node samen 0,5 CPU core en 2 GB geheugen gebruiken. Op één node van 20 cores en 80 GB geheugen verbruiken de daemons dan 2,5% van de capaciteit van het cluster. Als je echter 10 nodes van 2 cores en 8 GB geheugen per stuk hebt, verbruiken de daemons 25 % van de capaciteit van het cluster en heb je dus veel meer overhead. In de onderstaande afbeelding zie je dit weergegeven.
Als je minder overhead kosten wenst dan is het verstandig om minder maar grotere nodes in te zetten.
Zodra je echter gaat opschalen door meer nodes in te zetten, zullen de kosten hoger uitvallen bij grote nodes. Er is dus een optimum, die voor elke casus anders is, die bereikt kan worden door vooraf de behoefte om op te schalen en de kosten van de overhead tegen elkaar af te zetten.
Het uitvoeren van dezelfde load op minder nodes betekent natuurlijk dat er meer pods op elke node leven. Dit kan een probleem worden, doordat elke pod die op een node leeft wat overhead oplevert voor de Kubernetes-agents. Als het aantal pods te groot wordt, kan dit het systeem vertragen, zelfs zodanig dat het onbetrouwbaar wordt.
Zelf geeft Kubernetes de volgende aanbeveling: niet meer dan 100 pods per node:
https://kubernetes.io/docs/setup/best-practices/cluster-large/
De meeste bedrijven zullen die grens nooit raken, maar het kan knap ingewikkeld worden om te troubleshooten met een grote hoeveelheid pods op een node.
Kubernetes biedt een Cluster Autoscaler voor cloud infrastructuur aan waarmee automatisch nodes kunnen worden toegevoegd of verwijderd op basis van de load.
Het toevoegen van een node leidt direct tot aanzienlijk meer kosten als je grote nodes gebruikt. Als je maar 2 nodes hebt, betekent het toevoegen van een extra node een verhoging van de capaciteit van het cluster met 50%.
Dit is waarschijnlijk veel meer dan dat je werkelijk nodig hebt en daardoor betaal je voor ongebruikte resources. Wanneer je van autoscaling gebruik wilt maken is het verstandig om juist van meerdere kleine nodes gebruik te maken.
Grote aantallen nodes kunnen een uitdaging vormen voor de Kubernetes masters doordat het direct voor meer belasting op de master nodes zorgt. De configuratie en status van alle resources van het cluster worden op de master nodes bijgehouden.
Hoe meer worker nodes je hebt, des te meer resources (CPU en RAM) de master nodes nodig hebben. Voor een cluster met 6 tot 10 nodes heeft de master node minimaal 2 cores en 7,5 GB RAM nodig en voor redundantie of quorum doeleinden heb je 3 masters nodig. Kubernetes zelf geeft op hun site de specificaties aan voor clusters tot en met 500 nodes.
Zie: https://kubernetes.io/docs/setup/best-practices/cluster-large/
Het beheren van een klein aantal machines is minder arbeidsintensief dan het beheren van een groot aantal machines. Updates en patches kunnen sneller worden uitgerold, de machines kunnen gemakkelijker gelijk worden gehouden. Wanneer je echter van meer nodes gebruik maakt is de kans dat tijdens updates de applicatie down gaat kleiner, doordat er meer nodes zijn waarop de pods kunnen leven. Het is eenvoudiger om de minimum vereiste cluster capaciteit te behouden.
Wanneer je over een resource-intensief type applicatie beschikt is het hebben van grote worker nodes een vereiste voor je cluster.
Als je bijvoorbeeld een machine learning applicatie op basis van Spark wil draaien in Kubernetes en die heeft 16 GB geheugen nodig (is nog aan de lage kant), dan kan je die niet op een cluster met nodes met slechts 8 GB RAM elk draaien. Een worker node moet minimaal over iets meer geheugen beschikken dan dat de applicatie of pods samen nodig hebben. Je kan het wel laten draaien op een cluster met worker nodes met 20 GB geheugen.
Met een beperkt aantal worker nodes wordt de werkelijke redundantie gereduceerd tot het aantal beschikbare nodes, ook al heb je meerdere replica’s van je pods. Als je bijvoorbeeld een hoog beschikbare applicatie hebt die uit zeven replica’s bestaat, maar je hebt twee worker nodes, dan heb je na het falen van een node nog maar een replicatie factor van drie of vier in plaats van zeven. Dit komt doordat de zeven replica’s alleen kunnen worden verdeeld over twee worker nodes, en als een node faalt, falen meerdere replica’s tegelijkertijd.
Daarnaast als je maar twee nodes beschikbaar hebt en er faalt een node, wordt ongeveer de helft van je pods op de overgebleven node opgestart mits er genoeg capaciteit over is. Wanneer de overgebleven node niet genoeg resources heeft kunnen de pods niet opgestart worden en blijven deze down.
Als je een hoog beschikbare omgeving nodig hebt ga dan uit van minimaal drie tot vijf nodes en misschien nog meer, afhankelijk van de load en extra disaster recovery eisen.
Bepaal eerst in grove lijnen wat je benodigde cluster capaciteit is en hoeveel resources een set pods nodig heeft die samen op een node moet kunnen draaien. Daarmee heb je in ieder geval de grootte een het minimum aantal van de nodes bepaald. Aan de hand van je beschikbaarheidseisen en de wens om wel of geen autoscaling te gebruiken kan je vervolgens bepalen hoeveel extra worker nodes je minimaal moet inzetten.
Je kan altijd overwegen om andere clusters ernaast te zetten, zodat die op specifieke wensen en eisen afgestemd kunnen worden, hetgeen ik sowieso aanraad voor een test- en acceptatieomgeving.
Heb je hulp nodig om je cluster(s) te ontwerpen, dan ben je bij ons aan het juiste adres.
Neem contact met ons op.
