LLMs architecturen op OpenShift: SCC's en hybride identiteit oplossen

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
Enterprise-architecten kennen de realiteit van het uitrollen op Red Hat OpenShift: je voert niet zomaar kubectl apply uit op standaard manifests. Of je nu on-premise draait, op IBM Cloud Satellite, of via Azure Red Hat OpenShift (ARO), de security-primitieven—specifiek Security Context Constraints (SCC's)—zullen standaard upstream Kubernetes-deployments onmiddellijk laten mislukken.
TrueFoundry fungeert als een orchestratie-overlay. We ontkoppelen de developer experience van de infrastructuurcomplexiteit, waardoor je LLMs kunt uitrollen terwijl je je houdt aan de strenge grenzen van het Red Hat-ecosysteem. Dit artikel beschrijft hoe we integreren met de netwerkmogelijkheden van OpenShift, IBM Cloud IAM en watsonx.ai.
Het Deployment-model: Split-Plane Architectuur
We gebruiken een split-plane architectuur om te voldoen aan eisen rondom dataresidentie. Jij hebt de strikte controle over het Compute Plane; wij beheren de metadata in het Control Plane.
- Control Plane (SaaS of VPC): Beheert identiteitsbeheer, modelcatalogi en job scheduling.
- Compute Plane (Jouw Cluster): De TrueFoundry Agent draait rechtstreeks op jouw Red Hat OpenShift Container Platform.
De Agent zet een uitgaande WebSocket-verbinding op naar het Control Plane. Je hoeft geen inkomende firewallpoorten te openen. Dit voldoet aan air-gapped of hoog-beveiligde eisen die gebruikelijk zijn in de financiële en gezondheidszorgsector.

Afb 1: TrueFoundry werkt binnen het lokale compute plane en respecteert de beveiligingsperimeter.
Beveiliging: SCC's en RBAC automatiseren
Het wrijvingspunt in OpenShift is de handhaving van Security Context Constraints (SCC's). In tegenstelling tot upstream Kubernetes voorkomt OpenShift standaard dat pods als root draaien of toegang krijgen tot host-paden.
Restricted-v2 afhandelen
We architectureren de TrueFoundry agent om te werken binnen de restricted-v2 SCC.
- UID-injectie: We hardcoden geen User ID's. De agent detecteert het geannoteerde UID-bereik van de namespace en injecteert dynamisch het juiste runAsUser ID in de inference pod-spec tijdens runtime.
- Volume-abstractie: We omzeilen hostPath-vereisten door gebruik te maken van Persistent Volume Claims (PVC's) die worden ondersteund door IBM Cloud Block Storage of vSphere CSI voor on-premise omgevingen.
Identiteitsfederatie: IBM Cloud IAM
Gehardcodeerde authenticatiegegevens in secrets vormen een beveiligingsrisico. Voor deployments op IBM Cloud implementeren we identiteitsfederatie met behulp van IBM Cloud Trusted Profiles.
Hiermee kunnen je OpenShift-workloads een dynamische identiteit aannemen. De pod ruilt zijn lokale Service Account Token in voor een IBM Cloud IAM-token, wat tijdelijke toegang verleent tot IBM Cloud Object Storage (COS) of IBM Key Protect.

Afb 2: Authenticatieflow met gebruik van Trusted Profiles om statische langlopende authenticatiegegevens te elimineren.
Netwerk: Integreren met OpenShift Routes
Standaard Kubernetes Ingress-resources vereisen vaak vertaling in Red Hat-omgevingen. TrueFoundry integreert rechtstreeks met de OpenShift Ingress Controller (HAProxy).
- Ingress: Wanneer je een model uitrolt, provisionen we automatisch een OpenShift Route, waarbij SSL-terminatie aan de edge wordt afgehandeld.
- Air-Gapped Egress: Voor losgekoppelde omgevingen ondersteunen we image pulls uit interne Red Hat Quay registries. Je kunt modelgewichten vooraf cachen in een interne S3-compatibele opslag om runtime-afhankelijkheden van het internet te elimineren.
Compute: GPU Scheduling & Watsonx.ai
We maken verbinding met de NVIDIA GPU Operator om hardwareversnelling af te handelen.
MIG-partitionering
Voor A100- of H100-clusters ondersteunen we NVIDIA Multi-Instance GPU (MIG). De TrueFoundry-scheduler identificeert beschikbare MIG-profielen en richt pods op de juiste logische partitie, wat de dichtheid van het hardwaregebruik verhoogt zonder handmatige affinity-configuratie.
De Unified Gateway
Voor teams die IBM watsonx.ai gebruiken, bieden we een uniforme AI Gateway.
- Protocolvertaling: Ontwikkelaars gebruiken een standaard OpenAI-compatibel schema. De Gateway handelt de transformatie naar de watsonx.ai API af.
- Uniforme Telemetrie: We loggen requests naar zowel self-hosted modellen (Llama 3, Mistral) als SaaS-modellen (Granite, Watsonx) in één enkel overzicht voor kosten- en audit-observability.

Afb 3: De Gateway harmoniseert verkeer tussen self-hosted pods en beheerde IBM-services.
Operationele vergelijking
De onderstaande tabel geeft de specifieke operationele veranderingen weer wanneer TrueFoundry over native OpenShift wordt gelegd.
Architecturale continuïteit
Door TrueFoundry te integreren met IBM Cloud en Red Hat OpenShift kun je de strenge compliance-houding van het Red Hat-ecosysteem behouden terwijl je de uitrol van modellen versnelt. Je behoudt dataresidentie op OpenShift—of dit nu on-premise is of in de IBM Cloud—en biedt je engineeringteams een uniforme interface die de onderliggende infrastructuurbeperkingen abstraheert.
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)





