Multi-Cloud GPU-Orchestratie met TrueFoundry: Een Referentiearchitectuur voor Hyperscalers en Gespecialiseerde Clouds

GPU-capaciteit is momenteel een van de moeilijkste knelpunten voor AI-teams. Het provisionen van Amazon EC2 P5-instances of Azure ND H100 v5-serie VM's kan stuiten op quotalimieten, regionale capaciteitsbeperkingen of commerciële verplichtingen die lastig op te vangen zijn. Dat heeft gespecialiseerde GPU-clouds — CoreWeave, Lambda, Fluidstack en diverse anderen — tot levensvatbare productiedoelen gemaakt, en niet slechts tot uitwijkcapaciteit. Elk van deze providers biedt een beheerd Kubernetes-pad voor GPU-workloads: CoreWeave Kubernetes Service (CKS), Lambda Managed Kubernetes (MK8s) op een 1-Click Cluster, en Fluidstack managed Kubernetes.

Het draaien op deze platforms naast een hyperscaler-footprint zorgt voor serieuze operationele complexiteit: afzonderlijke dashboards, afzonderlijke identiteitssystemen, afzonderlijke observability en afzonderlijke deployment-flows. De rol van TrueFoundry hierin is om elk van deze Kubernetes-clusters te koppelen aan één enkel Control Plane, ze als deployment-doelen te tonen in één UI, en een consistente K8s-operationele laag bovenop te bieden — zonder de cluster-native automatisering te vervangen die elke provider al meelevert.

In deze blogpost behandelen we hoe dat er in de praktijk uitziet: de architectuur, wat het koppelen van een cluster vereist, waar de automatisering van het platform ophoudt en die van de provider begint, en de praktische patronen die wij aanbevelen.

De Architectuur: Eén Control Plane, Meerdere Compute Planes

TrueFoundry gebruikt een split-plane architectuur. Het Control Plane (door TrueFoundry beheerd of self-hosted) bevat metadata, RBAC, deployment-manifesten en de UI. Het Compute Plane is uw eigen Kubernetes-cluster. Meerdere Compute Planes kunnen verbinding maken met één Control Plane — wat betekent dat een EKS-cluster, een AKS-cluster, een CKS-cluster, een MK8s-cluster en een Fluidstack managed K8s-cluster allemaal aan hetzelfde dashboard kunnen rapporteren.

De tfy-agent draait in elk cluster en opent een veilige uitgaande WebSocket-verbinding naar het Control Plane. De agent streamt de clusterstatus, terwijl de agent-proxy het Control Plane in staat stelt Kubernetes-wijzigingen toe te passen via die uitgaande verbinding, zonder dat er een inkomend eindpunt op het cluster nodig is. Workloads, data-plane verkeer en provider-credentials blijven binnen het cloudaccount van elk cluster, en er stroomt geen verkeer tussen Compute Planes via het Control Plane — het blijven onafhankelijke clouds met onafhankelijke identiteiten.

Wat "Het Koppelen van een Cluster" Daadwerkelijk Vereist

De agentinstallatie zelf is één enkel Helm-commando — maar dit volgt op een installatie die echte vereisten heeft. Om elk cluster (hyperscaler of gespecialiseerd) schoon te kunnen koppelen, heeft het cluster het volgende nodig:

• Kubernetes 1.28+ met voldoende ruimte voor ongeveer 250 nodes / 4.096 pods, afhankelijk van het beoogde workloadprofiel
• Uitgaand verkeer (egress) naar de containerregistries waaruit TrueFoundry images ophaalt: public.ecr.aws, quay.io, ghcr.io, tfy.jfrog.io, docker.io/natsio, nvcr.io, registry.k8s.io
• Een wildcard-domein (bijv. *.lambda-pool.example.com) en een TLS-certificaat — cert-manager + Let's Encrypt is het gedocumenteerde patroon
• Een werkende load balancer of ingress-pad. Beheerde hyperscale K8s biedt dit meestal via de cloud load balancer-integratie; controleer op bare-metal of gespecialiseerde clusters het door de provider ondersteunde ingress- en IP-toewijzingspad
• Ondersteuning voor permanente opslag (persistent storage) voor volumes en artefacten, doorgaans via de door CSI ondersteunde block-, filesystem- of object-storage-integraties van de provider
• Een bereikbare containerregistry en artifact store voor image pulls, build-outputs en workflow-artefacten
• Node-labels op generieke / gespecialiseerde clusters: truefoundry.com/nodepool=<pool-name> op elke node, en truefoundry.com/gpu_type=<GPU_TYPE> op GPU-nodes (TrueFoundry detecteert automatisch alleen nodepools op EKS/GKE/AKS)

Op beheerde hyperscale K8s dekken de OpenTofu/Terraform-modules van TrueFoundry het meeste hiervan af. Op gespecialiseerde clouds gebruikt u rechtstreeks het beheerde K8s-aanbod van de provider — provisioneer via hun console, bereid de vereisten voor en koppel vervolgens. Het exacte installatiecommando voor de agent wordt gegenereerd door de platform-UI wanneer u op Attach Existing Cluster klikt; het heeft over het algemeen deze vorm:

Gespecialiseerde Cloud-Specificaties: het Addon-Overlap-Probleem

Dit is het gedeelte waar veel architectuurblogs aan voorbijgaan. De eerder genoemde gespecialiseerde clouds bieden al Kubernetes-componenten die overlappen met delen van TrueFoundry's standaard addon-stack. Als beide zijden dezelfde component installeren, kunt u conflicten krijgen die variëren van dubbele dashboards tot niet-ondersteunde GPU-operator deployments.

CoreWeave is hier expliciet over: CoreWeave beheert de NVIDIA GPU Operator op CKS-clusters en waarschuwt tegen een dubbele installatie. De door het platform beheerde deployment is de enige ondersteunde. Schakel de GPU Operator-addon van TrueFoundry uit wanneer u een CKS-cluster koppelt.

Concreet:

• CoreWeave CKS bevat op recente clusters een door CoreWeave beheerde NVIDIA GPU Operator, Cilium-netwerkverbindingen, opslagintegraties, op DPU gebaseerde infrastructuur en CoreWeave-observability. Schakel bij het koppelen de GPU Operator-addon van TrueFoundry uit en controleer eventuele overlap in observability.
• Lambda MK8s biedt GPU- en InfiniBand/RDMA-ondersteuning, gedeelde permanente opslag via de lambda-shared StorageClass, NVIDIA DCGM Grafana-dashboards en geautomatiseerd node-herstel. Schakel de GPU Operator-addon van TrueFoundry uit als Lambda de GPU-activering al beheert. Het DCGM-dashboard van de provider staat los van de observability van TrueFoundry en kan er naast draaien.
• Fluidstack managed Kubernetes biedt ondersteuning voor GPU Operator en Network Operator, Ray, Volcano en Kueue voor batch scheduling, door Atlas beheerde opslag en observability van de clustergezondheid. Schakel de GPU Operator-addon van TrueFoundry uit wanneer de provider deze al beheert. De batch scheduling-stack van de provider is complementair aan, in plaats van een vervanging voor, workflow-orchestratie.

Het formulier Attach Existing Cluster heeft een sectie Cluster Addons waarin u elke addon kunt uitschakelen die de provider al levert. Dit is een eenmalige beslissing per cluster.

Wat TrueFoundry Toevoegt over Clusters Heen

Zodra een cluster is gekoppeld, voegt het platform een consistente operationele ervaring toe bovenop de K8s die de provider heeft geleverd:

• Eén UI voor elk cluster. Elke deployment, elke job, elke service, elke workspace — zichtbaar in alle gekoppelde clusters in hetzelfde dashboard.
• Consistent formaat voor deployment-manifesten. Schrijf een service of job één keer; richt u op een ander cluster door het veld cluster_name te wijzigen — mits de vereisten op het doelcluster overeenkomen (overeenkomend GPU-type, registry-toegang, secrets, storage class).
• Versiebeheerde delivery via GitOps met ArgoCD gedeployed in elk cluster, waarbij de deployment-configuratie in Git wordt opgeslagen wanneer GitOps is ingeschakeld.
• Observability per cluster, met op Prometheus gebaseerde metrieken die worden getoond in de Control Plane UI en optioneel Grafana voor diepere dashboards op clusterniveau. (Opmerking: dit is geconsolideerde operationele zichtbaarheid, geen vervanging voor een gefedereerde langetermijn-metrics-backend.)
• Argo Workflows in elk cluster voor batch-jobs en trainingsruns, met run-historie en observability op stapniveau uniform weergegeven.
• Autoscaling voor services binnen elk cluster, inclusief schalen op basis van request-rate, tijdsgebaseerde regels, op wachtrijen gebaseerde patronen en scale-to-zero voor geschikte workloads.
• Plaatsing op capaciteitstype binnen het cluster: workloads kunnen gericht zijn op spot-, on-demand- of spot-met-on-demand-fallback-capaciteit waar de onderliggende cloud en node-provisioning dit ondersteunen.
• Op workspaces gebaseerde RBAC en SSO op het platformniveau, met consistente machtigingsmodellen ongeacht in welk cluster een workload draait.

Wat TrueFoundry (Nog) Niet Doet

Om volledig duidelijk te zijn over de omvang — dit zijn echte functionaliteiten waar klanten om vragen, maar het zijn momenteel geen platformfuncties:

• Cross-cluster scheduling. Wanneer u een job deployt, richt u zich op een specifiek cluster. Het platform kiest niet automatisch het goedkoopste cluster, routeert niet op basis van realtime capaciteit en herbalanceert draaiende workloads niet over clusters.
• Cross-cluster failover. Als een Lambda 1CC hardwareproblemen heeft of een CoreWeave-regio geen capaciteit meer heeft, probeert het platform de job niet automatisch opnieuw op een EKS-reservering. Plaatsings- en fallback-beleid binnen het cluster kunnen helpen wanneer het onderliggende cluster dit ondersteunt; cross-cluster failover is een ander probleem en wordt niet meegeleverd.
• Gefedereerde GPU-capaciteitspooling. Uw H100-capaciteit op CoreWeave, Lambda en AWS wordt bijgehouden als drie afzonderlijke clusters — niet als één samengevoegde quota-pool. De UI toont alle drie; de scheduler behandelt ze als onafhankelijk.
• Kostenbewuste automatische routing. Kiezen waar een job moet draaien op basis van realtime tarieven van de provider is momenteel geen platformfunctie.

Als uw use-case echt cross-cluster orchestratie vereist — bijvoorbeeld een trainingsjob die moet uitwijken naar de goedkoopste beschikbare cloud — bouw die beslissing dan in op de orchestratielaag (uw CI/CD-logica, een kleine aangepaste scheduler, of een workflowtool zoals Argo Workflows of Temporal) bovenop de deploy-API per cluster van TrueFoundry. Het platform biedt u de consistente deployment-primitieven over clusters heen; de routingbeslissing blijft bij u.

Een Echte Workflow: Het Koppelen van een Lambda 1-Click Cluster

Een concrete volgorde zodat de verwachtingen juist zijn ingesteld:

1. Provisioneer een 1-Click Cluster op Lambda met Managed Kubernetes ingeschakeld. Kies de grootte (16 tot 2.000+ GPU's) en de reservatieduur.
2. Verkrijg cluster-admin-toegang via de authenticatie-flow van Lambda en controleer of kubectl get nodes uw GPU-workers toont als Ready.
3. Bereid de vereisten voor in het cluster: configureer de wildcard DNS en het ingress-pad, installeer of verifieer de automatisering van TLS-certificaten, controleer of de lambda-shared StorageClass aanwezig is als u gedeelde opslag nodig heeft, en verifieer het uitgaande verkeer naar de vereiste containerregistries van TrueFoundry.
4. Klik in TrueFoundry op "Attach Existing Cluster" en vul de clusterdetails in. Schakel de GPU Operator-addon uit wanneer Lambda de GPU-activering al verzorgt.
5. Voer het gegenereerde Helm-commando uit in uw cluster. Wacht tot de agent en eventuele geselecteerde addons actief zijn — doorgaans 5–10 minuten nadat de vereisten aanwezig zijn.
6. Configureer tolerations in de TrueFoundry-workspace die gericht is op dit cluster. MK8s-nodes hebben GPU taints die getolereerd moeten worden; de toleration-configuratie op workspace-niveau past deze toe op elke job die naar dat cluster wordt verzonden.
7. Controleer of het cluster als verbonden wordt weergegeven en deploy vervolgens een kleine testjob (een vLLM-service op één GPU of een trainingsrun op één node) voordat u productieworkloads overzet.

De totale tijd op een voorbereid cluster is doorgaans 30–60 minuten, voornamelijk in beslag genomen door DNS-propagatie, certificaatuitgifte en de Helm-installatie.

Praktische Vergelijking

Conclusie

Een multi-cloud GPU-strategie is essentieel en wordt steeds praktischer nu reken-capaciteit een beperking wordt op AI-roadmaps. Het pragmatische pad is om elk cluster — of het nu gaat om EKS, AKS, GKE, CKS, MK8s of Fluidstack managed Kubernetes — te behandelen als een standaard Kubernetes-koppeling, waarbij het platform een consistente operationele laag bovenop biedt.

Wat u krijgt: één enkele UI over elk gekoppeld cluster, consistente deployment- en GitOps-patronen ongeacht de cloud, workload-portabiliteit op manifestniveau (waar de vereisten overeenkomen), en volledige datascheiding over de cloudaccounts van de klant. Wat u vandaag niet krijgt: automatische scheduling over clusters heen, capaciteitspooling of kostenbewuste routing — die beslissingen blijven bij u, gebouwd bovenop de per-cluster deploy-API van het platform.

Als u deze stack evalueert, is het natuurlijke startpunt het koppelen van twee clusters — één hyperscaler en één gespecialiseerde cloud — en het draaien van een representatieve job op elk om de operationele ergonomie te valideren voordat u verder opschaalt.