Verwenden von Containern für strenges Software-Engineering bei KI-Workloads

Wenn KI-Workloads von experimentellen Prototypen in Produktivumgebungen übergehen, stehen Unternehmen vor einer bekannten Herausforderung: Wie schützen, verwalten und steuern Sie diese neuen Komponenten mit der gleichen Sorgfalt, die Sie bei herkömmlichen Softwareanwendungen anwenden? Ein wichtiger Teil des Puzzles liegt in etwas, das Ihr Unternehmen wahrscheinlich bereits ausgiebig verwendet: Container, insbesondere OCI-Container (Open Container Initiative).

Was ist die Open Container Initiative?

Die Open Container Initiative definiert offene Spezifikationen für Image-Formate, Container-Runtimes und Distribution. So hilft sie Organisationen dabei, Vendor Lock-in zu vermeiden.  OCI-Container sind ein branchenübliches Format für das Paketieren von Softwareanwendungen. Sie können konsistent in verschiedenen Umgebungen, Container-Engines (wie Docker oder Podman) und Cloud-Plattformen ausgeführt werden.

Ein OCI-Artefakt ähnelt einem Container. Anstelle von ausführbaren Images speichern Artefakte jedoch andere Inhalte wie Dateien und Verzeichnisse.  OCI-kompatible Artefakt-Repositories (einschließlich Quay, Artifactory, Docker Hub und Registries der wichtigsten Cloud-Anbieter) können die Versionierung von OCI-Containern und -Artefakten speichern und verwalten.

OCI bietet eine standardisierte und portierbare Methode zur Paketierung und Verteilung von Software. Indem Sie Ihre KI-Modelle, Model Context Protocol (MCP) Server und KI-Agenten mithilfe von OCI-Containern paketieren, nutzen Sie Ihre vorhandenen Sicherheitsprozesse für die Softwarelieferkette, CI/CD-Pipelines und die Infrastruktur für die Container-Orchestrierung. Dieser Ansatz bringt die gleiche Governance und Auditierbarkeit für Ihren KI-Stack, die Sie bereits für Ihre Anwendungs-Workloads anwenden.

Containerisierung von KI-Modellen mit ModelCar

Large Language Models (LLMs) und andere KI-Modelle stellen besondere Herausforderungen beim Paketieren dar. Sie bestehen aus großen Binärdateien, Konfigurationsmetadaten und spezifischen Anforderungen an die Dateistruktur. In der Vergangenheit haben Unternehmen zur Verteilung von Modellen S3-kompatiblen Object Storage genutzt. Dieser Ansatz führt jedoch zu Reibungspunkten bei bestehenden containerbasierten Workflows und Sicherheitsprozessen. Wir empfehlen, Ihre KI-Modelle in OCI-Containern mit einer spezifischen Dateistruktur zu entwickeln, die wir ModelCar nennen.

Was ist ein ModelCar-Container?

Ein ModelCar-Container ist unkompliziert: KI-Modelldateien werden in einem Modellordner innerhalb des Containers abgelegt. Es sind keine zusätzlichen Pakete oder Laufzeitkomponenten erforderlich. Der Container enthält lediglich die Modellartefakte in einem OCI-konformen Format.

Dieser Ansatz bietet bedeutende Vorteile. Sobald Sie Ihr Modell als Container paketiert haben, können Sie es mit denselben Sicherheitsprozessen für die Softwarelieferkette verwalten, die Sie bereits für Ihre Anwendungscontainer verwenden. Sie können als Task in Ihrer CI/CD-Pipeline eine Software Bill of Materials (SBOM) und eine AI Bill of Materials (AIBOM) für den Container generieren. Sie können außerdem den Container signieren und validieren sowie Herkunftsnachweise generieren, die zeigen, dass Ihr vertrauenswürdiges Build-System den Container erstellt hat. Zudem können Sie den Container in Ihrem internen OCI-Artefakt-Repository speichern und Ihre Bereitstellungsrichtlinien so konfigurieren, dass sie nur Container aus genehmigten Repositories abrufen.

Red Hat Trusted Artifact Signer bietet Ihnen die Möglichkeit, Modelle zu signieren und die Authentizität sowie Transparenz eines Modells mit Sigstore und Rekor zu validieren. 

Red Hat OpenShift AI 2.14 und neuere Versionen unterstützen das direkte Bereitstellen von Modellen aus ModelCar-Containern mit KServe. Dadurch entfällt die Abhängigkeit von S3-kompatiblem Storage vollständig. Dies vereinfacht das Deployment und verbessert die Startzeiten des Inferenzservers, insbesondere wenn der Knoten den Container zwischenspeichert. Außerdem bietet dies einen einheitlichen Ansatz für das Artefaktmanagement in Ihrem Unternehmen.

Ein Katalog mit Beispiel-ModelCar-Containern ist im GitHub-Repository verfügbar. Er enthält Vorlagen und Best Practices für das Paketieren verschiedener Modelltypen.

Überlegungen zur Modellgröße

Obwohl die OCI-Spezifikation keine harten Beschränkungen für die Image-Größen vorschreibt, existieren praktische Beschränkungen. Container-Registries unterstützen in der Regel Images zwischen mehreren GB bis zu mehreren zehn GB. Die meisten Enterprise-Registries handhaben Images mit einer Größe von bis zu 15 bis 20 GB problemlos. Bei sehr großen Modellen, die diese praktischen Grenzen überschreiten, müssen Sie möglicherweise Modell-Quantisierungstechniken zur Reduzierung der Dateigrößen oder alternative Verteilungsmechanismen in Betracht ziehen. Für die meisten Produktionsmodelle – insbesondere quantisierte Varianten wie 8-Bit Floating Point (FP8) oder 4-Bit Integer (INT4) – ist die Containerisierung mit ModelCar jedoch sowohl praktisch als auch empfehlenswert.

OCI-Artefakte für Modelle

ModelCar verwendet OCI-Container für maximale Kompatibilität mit älteren Systemen, die OCI-Artefakte nicht vollständig unterstützen. Für die Modellspeicherung sind OCI-Artefakte jedoch eine bessere und effizientere Wahl. 

Build-Engineers können ihre Modelle in OCI-Artefakte statt in Container paketieren und sie in ihrem OCI-Artefakt-Repository speichern. Zum Zeitpunkt des Deployments können Sie das OCI-Artefakt mit einem Kubernetes Image Volume direkt in Ihrem Modellbereitstellungs-Pod als Storage mounten. Das Mounten von OCI-Artefakten ist heute in neueren Versionen von podman und der CRI-O Container Runtime implementiert. Die Arbeit an weiteren Runtimes einschließlich Containerd ist bereits im Gange.

Containerisierung von MCP-Servern für unternehmensgerechte Deployments

MCP hat sich als Standardmethode etabliert, um KI-Assistenten und -Agenten mit externen Tools, Datenquellen und APIs zu verbinden. MCP-Server fungieren als Brücken zwischen KI-Systemen und Ihren Unternehmensressourcen. Daher sind deren Sicherheit und Governance von entscheidender Bedeutung.

Für MCP-Server, die Teams gemeinsam nutzen oder die Sie in Produktionsumgebungen bereitstellen, empfehlen wir die Erstellung in Containern. Verwenden Sie hierfür dieselben Build-Tools und Prozesse wie für Ihre anderen Anwendungen. Dieser Ansatz sorgt für Konsistenz bei der Verwaltung, Bereitstellung und Sicherung dieser Komponenten. Jeder, der mit containerisierten Anwendungen arbeitet, ist mit diesem Prozess vertraut: Sie schreiben ein Containerfile, erstellen das Image, übertragen es in Ihre Registry und stellen es mit Red Hat OpenShift, Kubernetes, Podman oder Docker bereit.  Sie können Ihre typischen Build-Tools verwenden, um MCP-Server zu signieren und zu verifizieren, eine SBOM zu generieren, sie in OCI-Artefakt-Repositories zu speichern und so weiter.

Wie bei jeder Software kann bösartiger Code in einen MCP-Server gelangen. Analysieren und validieren Sie Ihre MCP-Server kontinuierlich mit Red Hat Trusted Profile Analyzer, um Schwachstellen, bösartige Abhängigkeiten und Richtlinienverstöße zu identifizieren.

Vorteile von containerisierten MCP-Servern

Containerisierte MCP-Server lassen sich zur Bewältigung einer erhöhten Last horizontal skalieren, mit standardmäßigen Beobachtbarkeits-Tools überwachen und über Ihre vorhandenen Sicherheitsrichtlinien steuern.

Der OpenShift Kubernetes MCP-Server veranschaulicht dieses Muster. Er kann lokal für die Entwicklung ausgeführt oder in einem Cluster mit dem Streamable HTTP-Transport für den Teamzugriff bereitgestellt werden. Der Server unterstützt konfigurierbare Zugriffsmodi (schreibgeschützt, nicht-destruktiv oder vollständiger Zugriff) und ist für die Autorisierung in die Role-based Access Control (RBAC) von Kubernetes integriert.

Um containerisierte MCP-Server wächst bereits ein IT-Ökosystem. Der MCP Lifecycle Operator erleichtert beispielsweise das Deployment containerisierter MCP-Server und deren Verbindung mit Ihren Agenten über eine Kubernetes-native Konfiguration. Das Kuadrant MCP Gateway bietet erweiterte Sicherheitsfunktionen für Unternehmen. Andere gängige Tools wie Docker funktionieren ebenfalls mit MCP-Servern in Containern.

Wann Sie Ihre MCP-Server nicht containerisieren sollten

Nicht alle MCP-Server profitieren von einer Containerisierung. Die MCP-Spezifikation unterstützt 2 primäre Transportmechanismen: stdio (Standard Input/Output) und HTTP-basierte Transporte (einschließlich Streamable HTTP und des veralteten Server-Sent Events (SSE)-Transportes). Dieser Unterschied ist für Deployment-Entscheidungen wichtig.

Stdio-basierte MCP-Server kommunizieren über Prozess-Streams, wobei der KI-Client den Server als untergeordneten Prozess erzeugt. Dieses Modell eignet sich gut für Szenarien mit Einzelnutzenden – ein Coding-Assistent für Entwicklungsteams, ein lokales Produktivitätstool oder ein persönliches Automatisierungsskript. In diesen Fällen wird der MCP-Server auf dem Laptop der Nutzenden ausgeführt, greift auf lokale Dateien sowie Ressourcen zu und wird beendet, wenn er nicht mehr benötigt wird. Die Containerisierung von stdio MCP-Servern erhöht die Komplexität, ohne wesentliche Vorteile für diese lokalen Use Cases mit Einzelnutzenden zu bieten.

Im Gegensatz dazu werden HTTP-basierte MCP-Server als unabhängige Prozesse ausgeführt, die mehrere Client-Verbindungen gleichzeitig verarbeiten können. Sie stellen Netzwerkendpunkte bereit und agieren eher wie traditionelle Webservices. Diese Server eignen sich hervorragend für die Containerisierung und profitieren von zentralisiertem Deployment, Skalierung sowie Management.

Das Framework für Entscheidungen sieht wie folgt aus: 

• Für geteilte Umgebungen oder Produktivumgebungen: Wenn Ihr Team Ihren MCP-Server gemeinsam nutzt, der Zugriff über ein Netzwerk erfolgt oder die Bereitstellung in einer Serverumgebung stattfindet, sollten Sie ihn containerisieren.
• Für containerisierte Agenten: Wenn Ihr Agent in einem Container ausgeführt wird, sollte ein stdio-basierter MCP-Server im selben Container wie der Agent ausgeführt werden, während ein HTTP-basierter MCP-Server in einem separaten Container laufen sollte.
• Für die lokale Verwendung durch Einzelnutzende: Wenn ein MCP-Server lokal auf dem Rechner von einzelnen Entwickelnden mit dem stdio-Transport ausgeführt wird, ist die Containerisierung optional und kann zu unnötigem Aufwand führen. 

Containerisierung von Agent Skills

Agent Skills haben sich als Alternative und Ergänzung zu MCP-Servern etabliert. Dabei handelt es sich um „Ordner mit Anweisungen, Skripten und Ressourcen, die Agenten finden und verwenden können, um Aufgaben genauer sowie effizienter auszuführen“. Die Spezifikation für Skills sieht vor, dass diese als ZIP-Dateien gepackt werden. 

Sie können Ihr Build-System so erweitern, dass Ihre Skills in OCI-Containern oder -Artefakten paketiert werden, genau wie Modelle und MCP-Server. Anschließend können Sie die Skills signieren sowie verifizieren, eine SBOM generieren, sie in OCI-Artefakt-Repositories speichern, herunterladen und genau wie Modelle an Pods anhängen. Da Skills Skripte enthalten können, die möglicherweise plattformspezifisch sind, bietet OCI auch Möglichkeiten, für jede Plattform einen anderen Satz von Dateien bereitzustellen. Wenn Ihre für Skills aktivierten Anwendungen noch nicht mit OCI-Containern oder -Artefakten arbeiten können, können Sie das ORAS-Befehlszeilenprogramm verwenden, um einen Skill in das richtige Verzeichnis zu extrahieren. 

Alternativ könnten Skills in Zukunft mithilfe von Paketmanagern verwaltet werden, ähnlich wie andere gemeinsam genutzte Bibliotheken für verschiedene Programmiersprachen. In diesem Fall würden Skills importiert und in Containern verwendet, aber nicht unbedingt als Container selbst verteilt. 

Da es sich dabei um eine neue Technologie handelt, sollten Sie auf zukünftige Entwicklungen achten. 

Containerisierung von KI-Agenten

KI-Agenten – autonome Systeme, die mithilfe von KI-Modellen und anderen Tools mehrstufige Aufgaben planen sowie ausführen können – stellen die nächste Entwicklungsstufe von KI-Anwendungen dar. Wenn Agenten von Prototypen in die Produktion übergehen, benötigen Unternehmen einen strukturierten Ansatz für deren Entwicklung, Bereitstellung und Verwaltung.

Das Projekt Kagenti bietet ein Kubernetes-natives Framework für genau diesen Zweck. Kagenti unterstützt jedes Agenten-Framework oder SDK und bietet modulare Komponenten für die Produktionsbereitstellung. Im Kern behandelt Kagenti Agenten als containerisierte Workloads, die deklarativ mit benutzerdefinierten Kubernetes-Ressourcen definiert werden können.

Kagenti verwendet Shipwright und Buildah, um Agenten in Containern zu erstellen. Wenn Ihr Unternehmen Tekton oder Jenkins für CI/CD verwendet, können Sie Ihren vorhandenen Pipelines eine ähnliche Buildah-Task hinzufügen. Wie bei KI-Modellen und MCP-Servern können Sie Ihre üblichen Build-Tools verwenden, um Agent-Container zu signieren und zu verifizieren, SBOMs zu generieren, sie in OCI-Artefakt-Repositories zu speichern und so weiter.

Wie MCP-Server lassen sich containerisierte Agenten horizontal skalieren, um eine höhere Last zu bewältigen, mit standardmäßigen Beobachtbarkeits-Tools überwachen und mithilfe Ihrer vorhandenen Sicherheitsrichtlinien steuern.  Sie können Ihre Agenten auch mit Red Hat Trusted Profile Analyzer analysieren und kontinuierlich validieren, um Schwachstellen, bösartige Abhängigkeiten und Richtlinienverstöße zu identifizieren.

Agenten für Einzelnutzende und Unter-Agenten

Ähnlich wie bei MCP-Servern erfordern nicht alle Agenten eine Containerisierung. Agenten, die lokal auf dem Laptop einer einzelnen nutzenden Person ausgeführt werden – wie etwa von Coding-Assistenten erstellte Unter-Agenten oder persönliche Automatisierungs-Agenten – benötigen möglicherweise nicht den Aufwand einer Container-Paketierung und eines Kubernetes-Deployments. Diese leichtgewichtigen Agenten werden häufig als untergeordnete Prozesse einer übergeordneten Anwendung ausgeführt und teilen sich den Sicherheitskontext dieser Anwendung.

Bei diesen Einzelnutzende-Szenarien sollte der Schwerpunkt darauf liegen, die übergeordnete Anwendung (die IDE, den Coding-Assistenten oder das Automatisierungstool) angemessen zu schützen, anstatt jede Unterkomponente zu containerisieren. Die Verwaltung dieser lokalen Agenten im Unternehmen ist ein sich entwickelnder Bereich, und Organisationen sollten die Entwicklungen bei Agent-Frameworks und -Tools überwachen.

Container für Sandbox-Funktionen

Da Agenten, MCP-Server und Modelle, die Code schreiben und ausführen, neue Schwachstellen einführen, empfiehlt es sich, deren Zugriff auf Systeme zu beschränken und den möglichen Schaden einzudämmen. Dies wird manchmal als „Agent Sandbox“ oder „Code Sandbox“ bezeichnet. 

Containerisierte Software lässt sich mit Netzwerkrichtlinien bereitstellen, die die Kommunikation mit externen Services einschränken – vom Öffnen und Blockieren von Ports bis hin zur Aufnahme bestimmter Websites und Services in Zulassungslisten. Kubernetes RBAC und Service Mesh-Funktionen bieten eine feingranulare Zugriffskontrolle. OpenShift Container werden in der Regel ohne Root-Berechtigungen ausgeführt, was deren Zugriff auf Daten und Rechenressourcen einschränkt.  

Container haben zudem Beschränkungen für ihre CPU- und Arbeitsspeichernutzung. Auf Entwicklungs-Workstations führt Podman seine Container standardmäßig ohne Root-Berechtigungen aus und schränkt außerdem den Zugriff des Containers auf Ihr Netzwerk und Dateisystem ein. OpenShift bietet bereits seit langer Zeit Container-Isolierung an, und Red Hat build of Podman Desktop ermöglicht die Container-Isolierung auch auf Entwicklungs-Workstations.

Eine weitere Gefahr ist die unkontrollierte Verarbeitung durch Agenten, die zu einem Denial-of-Service-Angriff führen kann. Mit OpenShift können Cluster-Administrierende für jeden Namespace Resource Quotas festlegen und so die GPU-, CPU-, Arbeitsspeicher- und Storage-Ressourcen begrenzen, die ein einzelnes Projekt verbrauchen kann. Mit angemessenen Ressourcenkontingenten kann ein unkontrollierter Agent anderen Workloads keine Cluster-Ressourcen entziehen.

Obwohl sie auf einem persönlichen Laptop ausgeführt werden können, lohnt sich der Aufwand für Coding-Assistenten und persönliche Agenten in einem Container oft. Wenn ein Agent in einem Sandbox-Container ausgeführt wird, kann er keine wertvollen Dokumente auf Ihrem Laptop beschädigen oder auf Daten zugreifen, die er nicht verwenden soll. Dies bedeutet, dass Sie gängige Aktionen wie das Lesen/Schreiben von Dateien vorab genehmigen, den Agenten dann mit weniger Überwachung ausführen lassen und einfach das Endergebnis der zugewiesenen Aufgabe überprüfen.

Sie können auch mehrere Agenten gleichzeitig starten und sie parallel arbeiten lassen, ohne dass sie sich gegenseitig beeinträchtigen. Sie können Agenten mit langer Ausführungszeit in Ihrem persönlichen Namespace in OpenShift bereitstellen, Ihren Laptop schließen und nach Hause gehen, während die Agenten weiterhin für Sie arbeiten. Sie können sogar den Container des Agenten speichern, um seinen Zustand beizubehalten und ihn später fortzusetzen. 2 neue Projekte in diesem Bereich sind paude für Coding-Agenten und openclaw-installer für OpenClaw.

Vorteile der Containerisierung von KI-Workloads

Die Containerisierung Ihrer KI-Komponenten – Modelle, MCP-Server und Agenten – bietet erhebliche Vorteile, die sich auf die meisten Bereiche Ihres Unternehmens auswirken.

Sicherheit in der Softwarelieferkette

Sie können Container vor dem Deployment signieren, attestieren und verifizieren. Sie können festlegen, dass Ihre vertrauenswürdigen CI/CD-Systeme alle KI-Komponenten erstellen, diese auf Schwachstellen scannen und in genehmigten Registries speichern. Nachweise über die Datenherkunft bieten einen Audit-Trail, der genau zeigt, wie jedes Artefakt produziert wurde.

Versionskontrolle und Rollback

Container Images sind unveränderlich und mit Tags versehen. Sie können bestimmte Versionen bereitstellen, bei Problemen ein Rollback auf vorherige Versionen durchführen und einen klaren Verlauf führen, welche Bereitstellungen wann erfolgten.

Konsistentes Deployment

Dasselbe Container Image wird in Entwicklungs-, Staging- und Produktionsumgebungen identisch ausgeführt. Dies verringert das Risiko, dass Dateien beim Kopieren zwischen Umgebungen Fehler aufweisen.

Beobachtbarkeit

Containerisierte Workloads lassen sich in die bestehende Infrastruktur für Monitoring und Protokollierung integrieren. Kagenti unterstützt beispielsweise standardmäßig OpenTelemetry (OTEL) Tracing, sodass Sie Agent Operations mit Ihrem Standard-Stack für Beobachtbarkeit überwachen können.

Isolation und Zugangskontrolle

Schließlich bieten Container umfangreiche Funktionen für Sandboxen, mit denen Sie den Wirkungsbereich von Problemen begrenzen.

Ausblick: Workload-Identität und Zero Trust

Die Containerisierung schafft zudem die Grundlage für fortschrittlichere Sicherheitsmuster. Im Kagenti-Projekt wird die Integration mit SPIFFE/SPIRE für Workload-Identität und Zero Trust-Architektur für Agenten und MCP-Server untersucht. Diese Funktionen befinden sich zwar noch in der Entwicklung, aber die Containerisierung Ihrer KI-Komponenten auf Kubernetes vereinfacht die Einführung dieser Sicherheitsfunktionen erheblich.

Die Workload-Identität stellt sicher, dass jeder Agent oder MCP-Server eine kryptografisch verifizierbare Identität besitzt, was eine sichere Kommunikation von Service zu Service ohne gemeinsame Secrets ermöglicht. Zero Trust-Prinzipien – niemals vertrauen, immer verifizieren – lassen sich praktisch umsetzen, wenn Sie Ihre KI-Komponenten containerisieren und in Ihre vorhandene Identitäts- und Zugriffsmanagementinfrastruktur integrieren.

Zusammenfassung

OCI-Container bieten einen bewährten, standardisierten Ansatz für das Paketieren und Verteilen von Software, der sich auf natürliche Weise auf KI-Workloads ausweiten lässt. Durch die Containerisierung von KI-Modellen, MCP-Servern und Agenten übertragen Sie dieselbe Governance, Sicherheit und operative Reife auf Ihren KI-Stack, die Sie bereits für Ihre Anwendungen nutzen.

Die entscheidende Erkenntnis liegt darin, zu bestimmen, wann die Containerisierung einen Mehrwert bietet. Container sind für gemeinsam genutzte, vernetzte Produktionsumgebungen unerlässlich. Für die lokale Einzelnutzung sind Container optional, bieten jedoch Sandbox-Funktionen und Portabilität über Geräte hinweg: einmal erstellen, überall ausführen. Dieser pragmatische Ansatz ermöglicht es Ihnen, für jede Komponente das passende Maß an Governance anzuwenden und gleichzeitig unnötige Komplexität zu vermeiden.

Red Hat OpenShift AI, Red Hat Trusted Artifact Signer, Red Hat Trusted Profile Analyzer und Red Hat build of Podman bieten eine solide Basis für die Verwaltung Ihrer KI-Workloads vom Prototyp bis zur Produktion. Red Hat bietet unternehmensgerechten Support für Open Source-Tools mit aktiven Communities, damit Sie mit den neuesten Entwicklungen im Bereich KI Schritt halten können.