Kubernetes als KI-Default-OS: Cluster als Compliance-Frage

Gartner rechnet damit, dass bis Ende 2026 acht von zehn Unternehmen eine interne Entwicklerplattform betreiben. Was 2022 noch nach DevEx-Komfort klang, trägt heute KI-Inferenz, Compliance-Nachweise und Cost-Forecasting in einem einzigen Cluster-Stack. Wer den Cluster jetzt nicht als geschäftskritische Infrastruktur führt, plant für 2027 in den falschen Kategorien.

Das Wichtigste in Kürze

• Kubernetes ist das neue Server-OS: Die Diskussion verschiebt sich von „ob KI auf Kubernetes läuft“ zu „wie stabil, repetierbar und auditierbar“. 2026 ist die Frage operativ, nicht mehr strategisch.
• Compliance wandert in den Cluster: Pod-Konfiguration, Egress-Policies und Image-Provenienz sind plötzlich prüfungsrelevant. Wer das nicht zentral erzwingt, baut die Nachweispflicht in jedes Team neu nach.
• Stateful-AI bricht die alten Annahmen: Inferenz braucht GPU-Affinität, persistente Vektor-Stores und schnellen Storage. Klassische Stateless-Pattern reichen nicht mehr – das sehen Platform-Teams jetzt im Capacity-Plan.

Verwandt:Platform Engineering ist kein DevEx-Projekt mehr  /  Wenn die KI-Rechnung das Cloud-Budget sprengt

Die Inferenz-Welle ist auf Kubernetes gelandet

Wer 2024 noch über „AI-Workloads ja oder nein im Cluster“ debattiert hat, führt 2026 eine andere Diskussion: Welche Inferenz-Pipelines dürfen überhaupt noch außerhalb der Plattform stehen. Die Antworten der Teams, die ich in DACH-Audits sehe, klingen erstaunlich ähnlich. Notebook-Experimente in Sagemaker, Bedrock oder Vertex sind erlaubt. Produktive Inferenz mit Kundendaten landet im internen Cluster – oder sie wird gestoppt, bevor sie produktiv geht.

Was ist Kubernetes als KI-Default-OS? Der Begriff beschreibt den Stand, an dem produktive KI-Inferenz standardmäßig im internen Kubernetes-Cluster läuft statt in separater SaaS. Der Cluster wird damit zur geschäftskritischen Infrastruktur, die GPU-Scheduling, persistente Vektor-Stores und Compliance-Nachweise an einem Ort bündelt, statt sie über mehrere Plattformen zu verteilen.

Der Treiber ist nicht Eleganz. Der Treiber ist die Aufstellung der Prüfer. NIS2, EU AI Act und DORA verlangen Nachweise zu Datenflüssen, Modellrechten und Zugriffsketten. Wenn die KI in einer separaten SaaS lebt, muss die ganze Audit-Chain dort separat aufgebaut werden. Wer dieselben Controls schon im Cluster fährt, bekommt KI-Nachweise faktisch geschenkt. Genau das ist die operative Begründung hinter der Gartner-Zahl, nicht ein DevEx-Slogan.

Stateful-AI bricht die Stateless-Annahmen

Die alte Plattform-Doktrin war einfach: Pods sind cattle, State liegt im Backend, der Cluster orchestriert nur. Inferenz-Workloads halten sich nicht daran. Ein größeres LLM lädt sieben bis zwölf Sekunden, bevor es antwortet. Eine Vektor-Datenbank verliert Lokalität, wenn ihr Pod über die Node-Grenze wandert. GPU-Affinität bedeutet, dass derselbe Pod auf demselben Node bleiben muss – oder die Latenz wird unbrauchbar.

Platform-Teams reagieren darauf gerade auf drei Wegen. Erstens: dedizierte Node-Pools für Inferenz, mit Taints, Tolerations und garantierten GPU-Slots. Zweitens: persistente Vektor-Stores als StatefulSet, nicht als Pod. Drittens: Topology-Aware-Scheduling, damit Caches nicht jede Skalierung neu warmlaufen müssen. Wer diese drei Bausteine 2026 nicht im Stack hat, baut die Probleme in jeden neuen KI-Service nach.

Compliance wandert in die Pod-Konfiguration

Die operative Wahrheit, die Vorstände selten hören wollen: Prüfer interessieren sich für Kubernetes-Manifeste. Wer Egress-Policies, NetworkPolicies, PodSecurity und Image-Provenienz nicht als Code im Cluster fährt, kann die Frage „was redet eure KI mit welchem Endpunkt“ nicht in einer Audit-Stunde beantworten. Die meisten DACH-Teams haben das verstanden, aber das Investment hinkt der Anforderung um zwei Quartale hinterher.

Konkret heißt das: Policy-as-Code mit OPA Gatekeeper oder Kyverno gehört in jeden Cluster, der Kundendaten sieht. Sigstore-Signaturen auf Images sind keine Spielerei mehr – sie sind der einzige Beleg, dass im Cluster nur das läuft, was die Pipeline freigegeben hat. Und Verschlüsselung in transit zwischen Pods ist 2026 keine Option, sondern Default. Plattform-Teams, die diese Layer nicht standardisieren, bremsen jedes Produktteam, das die KI-Story tragen soll.

Was Platform-Teams jetzt entscheiden müssen

Drei Entscheidungen schiebe ich in Reviews seit Wochen vor mir her, weil sie in der Plattform-Roadmap unbequem sind. Sie lösen sich nicht auf, wenn man sie liegen lässt.

Erstens: die GPU-Budget-Frage. Wer GPUs zentral pooled, gewinnt Auslastung, verliert Team-Autonomie. Wer GPUs pro Team allokiert, verliert Effizienz und gewinnt Klarheit über Verursacher. Beide Modelle funktionieren, das gemischte Modell nicht. Es muss entschieden werden, nicht zerredet.

Zweitens: die Multi-Tenant-Frage für KI. Eine RAG-Pipeline mit Daten aus drei Geschäftsbereichen ist ein Vektor-Store mit drei Risiken. Namespace-Trennung allein reicht nicht – es braucht Hardening auf Storage-Klassen, Service-Mesh-Policies und ein klares Default-Deny. Wer das aufschiebt, bekommt einen Vorfall, der nicht in den Quartalsfolien geplant war.

Drittens: die Skip-AI-Frage. Manche KI-Workloads gehören nicht in den eigenen Cluster. Latenz-unkritische Batch-Inferenz auf nicht-sensiblen Daten kann in einer Managed-Plattform billiger und stabiler laufen. Wer aus Stolz alles in den eigenen Cluster zieht, beraubt sich der einfachsten Optimierung – und blockiert das Platform-Team mit Workloads, die niemand vermissen würde.

Häufige Fragen

Bildquelle: KI-generiert (Juli 2026)