Een gids voor Cloud Node Auto-Provisioning

Gebouwd voor snelheid: ~10ms latentie, zelfs onder belasting
De razendsnelle manier om je modellen te bouwen, volgen en implementeren!
- Verwerkt 350+ RPS op slechts 1 vCPU — geen tuning nodig
- Productieklaar met volledige enterprise-ondersteuning
Verschillende workloads vereisen uiteenlopende hardwarespecificaties, zoals machinetype, grootte en geolocatie. Met de opkomst van ML/LLMs is het selecteren van de juiste hardware cruciaal geworden. We moeten keuzes maken op basis van hardwarespecificaties zoals OS-type, architectuur, processor, GPU-type en opslag. Kubernetes helpt bij het orchestreren en verdelen van resources over soortgelijke workloads, maar het dynamisch provisionen van deze resources op aanvraag blijft een uitdaging.
Een Kubernetes (K8s) cluster is een groepering van nodes die gecontaineriseerde applicaties op een efficiënte, geautomatiseerde, gedistribueerde en schaalbare manier uitvoeren. Elke node binnen een Kubernetes cluster heeft specifieke attributen zoals machinetype, grootte en locatie.
Deze blog verkent de noodzaak van cloud node auto-provisioners om uiteenlopende workloadvereisten binnen Kubernetes clusters automatisch te beheren. We bieden ook inzicht in oplossingen van grote cloudproviders zoals AWS, GCP en Azure. Ten slotte diepen we uit hoe TrueFoundry deze uitdagingen als platform aanpakt.
Introductie
Node auto-provisioning automatiseert het provisionen van de juiste nodegroep op basis van constraints van niet-ingeplande pods om infrastructuurkosten te optimaliseren. Node auto-provisioners in een Kubernetes cluster zijn verantwoordelijk voor de volgende acties:
- Scheduling: het starten van nodes in reactie op niet-ingeplande pods na het oplossen van scheduling constraints, door optimaal het best mogelijke machinetype en de beste grootte te bepalen.
- Disruption: Het verwijderen van nodes wanneer ze niet langer in gebruik zijn vanwege verloop, consolidation, drift of onderbreking
Waarom Node auto-provisioning?
Kubernetes gebruikt nodes als worker machines met specifieke hardwareconfiguraties zoals machinetype, grootte en capaciteitstype; node pools verwijzen naar pools van zulke gemeenschappelijke worker machines. Zonder een node auto-provisioner was de enige manier om een specifieke hardwareconfiguratie aan je workload toe te wijzen via node pool-selectie. Dit vereist dat de gebruiker een node pool met de vereiste configuratie aanmaakt in hun cloud en vervolgens node affinity toevoegt voor de specifieke node pool in de Pod spec.

Over het algemeen omvat dit mechanisme de volgende stappen:
- Het vooraf definiëren van je hardwarevereisten.
- Het zoeken en selecteren van het best mogelijke machinetype en de beste grootte voor de gegeven vereisten.
- Het provisionen van de geselecteerde node pool(s).

De combinaties van node pool-vereisten kunnen talrijk zijn, vooral tijdens de experimenteerfase voor ML/LLM workloads. Afstemming tussen afzonderlijke DevOps- en Platform-teams kan aanzienlijke tijd kosten tijdens de ontwikkeling. Daarom wordt een controller die dynamisch vereisten beoordeelt en automatisch infrastructuur voorziet cruciaal.
Hoe werkt node auto-provisioning?
Node auto-provisioning elimineert de handmatige stap van het vooraf aanmaken van node pools doordat gebruikers op hoog niveau vereisten als constraints kunnen toevoegen. Het bepaalt automatisch het beste machinetype of de best beschikbare node voor de workload.

Enkele veelgebruikte constraints:
- cpu: vereiste CPU bijv.
2 - memory: vereist geheugen voor de workload bijv.
1000 - gpu-type: vereist GPU-type bijv.
t4, a100 - capacity type: Aankoopoptie bijv.
on-demandofspot - zones: geografische locaties bijv.
us-east-1a - operating system: OS van de machine bijv.
linuxofwindows - architecture: de architectuur van de machine bijv.
arm64oramd64

Cloud Providers die node auto-provisioning aanbieden
Elke cloudprovider biedt zijn eigen auto-provisioningmechanismen. AWS vereist de installatie van tools zoals Karpenter, terwijl GCP een ingebouwde oplossing biedt. Azure heeft onlangs zijn auto-provisioner-project geïntroduceerd, dat zich momenteel in preview-modus bevindt.
AWS Karpenter
Karpenter, een open-source node lifecycle management-project ontworpen voor Kubernetes, verbetert de efficiëntie en kosteneffectiviteit van het uitvoeren van workloads op clusters aanzienlijk. Door rekening te houden met scheduling constraints zoals resource requests, node selectors, affinities, tolerations en topology spread constraints, voorziet en dealloceert Karpenter intelligent nodes waar nodig.
GCP Node auto-provisioning
Node auto-provisioning, geïntegreerd in de cluster autoscaler, schaalt bestaande node pools op basis van de specificaties van niet-inplanbare Pods. De auto-provisioningfunctie van GCP zorgt voor een optimaal resourcegebruik door rekening te houden met CPU, geheugen, ephemeral storage, GPU requests, node affinities en label selectors.
Azure Node auto-provisioning
Azure's Node auto-provisioning (NAP) project, dat zich momenteel in preview-modus bevindt, maakt gebruik van het open-source Karpenter-project om de optimale VM-configuratie te bepalen voor het efficiënt en kosteneffectief uitvoeren van workloads. NAP implementeert en beheert Karpenter automatisch op AKS clusters, wat gebruikers een naadloze ervaring biedt.
💡
Node auto-provisioning (NAP) voor AKS is momenteel in PREVIEW. We zijn erg enthousiast over dit nieuwe project en kijken ernaar uit om het voor onze klanten te gebruiken. Lees meer
TrueFoundry - Ervaar node auto-provisioning
TrueFoundry biedt geavanceerde filtermogelijkheden voor node pools, waarmee de ervaring van node auto-provisioning wordt gesimuleerd.

Om dit te bereiken, hebben we een paar eenvoudige stappen gefaciliteerd:
- Programmatisch node pools aanmaken met alle combinaties van machinetypes en capaciteitstypes, waarbij autoscaling wordt ingeschakeld met schalen naar nul.
- Koppel de node pool aan het bijbehorende machinetype, de CPU, het geheugen, het GPU-type en het aantal.
- We filteren vervolgens deze node pools op basis van vereisten, waardoor het voor de eindgebruiker eenvoudig wordt om de juiste infra te kiezen.
Deze aanpak stelt Developers/Data scientists in staat om de beste node pool voor hun workload te selecteren door hun vereisten te analyseren. Dit eenvoudige mechanisme stelt ons in staat om dezelfde ervaring te bieden voor elke cloud die nog geen ingebouwde ondersteuning voor auto-provisioners heeft.
Conclusie
Aangezien infrastructuurvereisten blijven evolueren, zetten cloudproviders zich in om het proces van het selecteren van de optimale infrastructuur voor uiteenlopende workloads te stroomlijnen. Bij TrueFoundry delen we deze betrokkenheid door te streven naar het empoweren van Developers met de tools en kennis die ze nodig hebben om hun workloads naadloos te deployen.
TrueFoundry AI Gateway levert een latentie van ~3–4 ms, verwerkt 350+ RPS op 1 vCPU, schaalt moeiteloos horizontaal en is klaar voor productie, terwijl LiteLLM last heeft van hoge latentie, moeite heeft boven een gemiddeld aantal RPS, geen ingebouwde schaling heeft en het meest geschikt is voor lichte workloads of prototypes.


















.png)



.webp)



.webp)








.webp)





