LLM-Architektur auf OpenShift: Lösung von SCCs und Hybrididentität

Unternehmensarchitekten kennen die Realität der Bereitstellung auf Red Hat OpenShift: Sie wenden nicht einfach Kubectl Standardmanifeste an. Egal, ob Sie vor Ort arbeiten, auf IBM Cloud-Satellitoder über Azure Red Hat OpenShift (ARO), werden die Sicherheitsprimitiven — insbesondere Security Context Constraints (SCCs) — die standardmäßigen Upstream-Kubernetes-Bereitstellungen sofort durchbrechen.

TrueFoundry fungiert als Orchestrierungs-Overlay. Wir entkoppeln die Erfahrung der Entwickler von der Komplexität der Infrastruktur, sodass Sie LLMs bereitstellen und gleichzeitig die strengen Grenzen des Red Hat-Ökosystems einhalten können. In diesem Beitrag wird detailliert beschrieben, wie wir uns in das Netzwerk von OpenShift integrieren. IBM Cloud IAM, und watsonx.ai.

Das Bereitstellungsmodell: Split-Plane-Architektur

Wir verwenden eine Split-Plane-Architektur, um die Anforderungen an die Datenresidenz zu erfüllen. Sie kontrollieren strikt die Ebene berechnen; wir verwalten die Metadaten in der Kontrollebene.

1. Steuerungsebene (SaaS oder VPC): Kümmert sich um Identitätsmanagement, Modellkataloge und Auftragsplanung.
2. Compute Plane (Ihr Cluster): Der TrueFoundry Agent läuft direkt auf Ihrem RedHat OpenShift Container Platform.

Der Agent initiiert eine reine ausgehende WebSocket-Verbindung zur Control Plane. Sie öffnen keine eingehenden Firewall-Ports. Damit werden die im Finanz- und Gesundheitssektor üblichen Sicherheitsanforderungen oder hohen Sicherheitsanforderungen erfüllt.

Bild 1: TrueFoundry arbeitet innerhalb der lokalen Rechenebene und respektiert dabei den sicheren Perimeter.

Sicherheit: Automatisierung von SCCs und RBAC

Der Reibungspunkt in OpenShift ist die Durchsetzung von Sicherheitskontextbeschränkungen (SCCs). Im Gegensatz zu Upstream-Kubernetes verhindert OpenShift standardmäßig, dass Pods als Root ausgeführt werden oder auf Hostpfade zugreifen.

Umgang mit Restricted-v2

Wir entwickeln den TrueFoundry-Agenten so, dass er innerhalb des Restricted-v2-SCC funktioniert.

• UID-Injektion: Wir codieren keine Benutzer-IDs fest. Der Agent erkennt den kommentierten UID-Bereich des Namespaces und fügt zur Laufzeit dynamisch die richtige RunAsUser-ID in die Inferenz-Pod-Spezifikation ein.
• Volumenabstraktion: Wir umgehen die HostPath-Anforderungen, indem wir Persistent Volume Claims (PVCs) verwenden, unterstützt durch IBM Cloud-Blockspeicher oder vSphere CSI für On-Premise-Installationen.

Identitätsverbund: IBM Cloud IAM

Fest codierte Anmeldeinformationen in Geheimnissen stellen ein Sicherheitsrisiko dar. Für Bereitstellungen in der IBM Cloud implementieren wir den Identitätsverbund mithilfe von Vertrauenswürdige IBM Cloud-Profile.

Dadurch können Ihre OpenShift-Workloads eine dynamische Identität annehmen. Der Pod tauscht sein lokalisiertes Service Account Token gegen ein IBM Cloud IAM-Token aus und gewährt so temporären Zugriff auf IBM Cloud-Objektspeicher (COS) oder IBM Key Protect.

Abbildung 2: Authentifizierungsablauf unter Verwendung vertrauenswürdiger Profile, um statische, langlebige Anmeldeinformationen zu eliminieren.

Netzwerk: Integration mit OpenShift-Routen

Standard-Kubernetes-Ingress-Ressourcen müssen in Red Hat-Umgebungen häufig übersetzt werden. TrueFoundry lässt sich direkt integrieren in OpenShift-Eingangskontroller (HAProxy).

• Zutritt: Wenn Sie ein Modell bereitstellen, stellen wir automatisch eine OpenShift-Route bereit und kümmern uns um die SSL-Terminierung am Edge.
• Ausgang mit Luftspalt: Für Umgebungen, in denen keine Verbindung besteht, unterstützen wir das Abrufen von Bildern aus dem internen Netzwerk Red Hat Quay Register. Sie können Modellgewichte vorab in einem internen S3-kompatiblen Speicher zwischenspeichern, um Internetabhängigkeiten zur Laufzeit zu vermeiden.

Compute: GPU-Scheduling und Watsonx.ai

Wir verbinden uns mit dem NVIDIA-GPU-Betreiber um die Hardwarebeschleunigung zu handhaben.

MIG-Partitionierung

Für A100- oder H100-Cluster unterstützen wir NVIDIA Mehrinstanzen-GPU (MIG). Der TrueFoundry-Scheduler identifiziert verfügbare MIG-Profile und ordnet Pods der richtigen logischen Partition zu, wodurch die Hardwarenutzungsdichte ohne manuelle Affinitätskonfiguration erhöht wird.

Das Unified Gateway

Für Teams mit IBM watsonx.ai, wir bieten ein einheitliches KI-Gateway.

• Protokollübersetzung: Entwickler verwenden ein OpenAI-kompatibles Standardschema. Das Gateway kümmert sich um die Transformation zur API watsonx.ai.
• Vereinheitlichte Telemetrie: Wir protokollieren Anfragen sowohl an selbst gehostete Modelle (Llama 3, Mistral) als auch an SaaS-Modelle (Granite, Watsonx) in einem einzigen Fenster, um Kosten- und Audit-Beobachtbarkeit zu gewährleisten.

Abbildung 3: Das Gateway vereinheitlicht den Verkehr zwischen selbst gehosteten Pods und verwalteten IBM-Services.

Operativer Vergleich

In der folgenden Tabelle werden die spezifischen betrieblichen Veränderungen beschrieben, wenn TrueFoundry auf nativem OpenShift überlagert wird.

Architektonische Kontinuität

Die Integration von TrueFoundry mit IBM Cloud und Red Hat OpenShift ermöglicht es Ihnen, die strikte Compliance-Haltung des Red Hat-Ökosystems aufrechtzuerhalten und gleichzeitig die Modellbereitstellung zu beschleunigen. Sie behalten die Datenresidenz auf OpenShift — ob vor Ort oder in der IBM Cloud — bei und bieten Ihren Entwicklungsteams eine einheitliche Oberfläche, die die zugrunde liegenden Infrastruktureinschränkungen abstrahiert.

‍