GitOps für KI-Plattformen: Kultur vor Tools

TL;DR

Eine Internal Developer Platform kostet laut Studien oft rund 4,2 Millionen Euro und 18 Monate — und trotzdem umgehen 64 % der Engineers die Plattform. Der Fehler: Infrastruktur-Mindset für Infrastruktur-Leute. GitOps als vier Prinzipien (declarativ, versioniert, pull-basiert, continuous reconciliation) plus Plain Data machen Plattformen nutzbar — und AI-Agents zu Bürgern der Plattform statt zu Sonderfällen.

Vier Prinzipien, nicht ein Tool

Die Reise von Local Ops über Pipe Ops zu agent-basiertem GitOps steht auf:

1. Declarative: Du definierst den Zustand, ein Agent erfüllt ihn.
2. Versioned & Immutable: Nachvollziehbar, nach dem Lock unveränderlich.
3. Pull-based: Der Agent zieht den Zustand — keine Inbound-Credentials.
4. Continuous Reconciliation: Drift wird automatisch korrigiert.

„Argo CD installieren" ist kein GitOps. Ohne Kultur (trunk-based, Contract statt Ad-hoc) werden die Tools umgangen — genau wie die teure Plattform.

Git ist Kollaboration — OCI ist Intent

Git ist großartig für menschliche Kollaboration. Bei Skalierung (zehn, hundert, tausende Cluster) stößt reines Git an Grenzen. OCI ist für immutable Artefakte und Distribution gebaut. Moderne Praxis: CI hydriert Manifeste, legt sie als OCI-Artefakte ab, der GitOps-Engine zieht sie — „gitless GitOps" als Source of Intent.

Architektur-Muster:

• Hub & Spoke: Single Pane of Glass — in regulierten Umgebungen riskant (Hub = hohe Privilegien).
• Dedicated Instance pro Cluster: bei Banken/Versicherungen üblich.
• Hybrid/Agent-based: leichte Agents in Spokes, Hub reconcilt pull-basiert hinter Firewalls.

Warum das für KI zählt

KI ändert die Plattform-Anforderungen:

• AI troubleshooting: Agents mit Logs, Metriken und Traces können Störungen mitvollziehen — wenn der Kontext maschinenlesbar ist.
• Agentic Developer Platform: Entwickler erzeugen Komponenten/CRDs mit AI; die Plattform reviewt und applied.
• Plain Data statt Overlay-Chaos: Config as Data („write everything twice", WYSIWYG). Kryptische Overlays liefern generische AI-Antworten, die den gewünschten Zustand nicht verstehen.

GPU-Workloads, Inference und Agent-Sandboxes gehören als First-Class-Bürger in dieselbe Reconciliation-Schleife — nicht als manuelle Sonderpfade.

Progressive Delivery und DR

Rolling, Blue-Green und Canary (Argo Rollouts/Flagger) gehören zum GitOps-Betriebsmodell. Disaster Recovery in der Praxis: Wenn Troubleshooting länger als ~30 Minuten dauert, Cluster neu spinnen und GitOps umhängen — bei Stateless realistisch; Stateful braucht eine eigene DR-Strategie.

Die ehrliche Einordnung:

1. Plattform-Bau scheitert oft — ohne Nutzer-Fokus bleibt es ein teures Infrastruktur-Projekt.
2. GitOps ist Kultur, nicht Tool — vier Prinzipien statt Tool-Sammlung.
3. Git hat Grenzen — bei Skalierung ist OCI als Source of Intent überlegen.
4. Konfig-Sprawl ist real — ohne Katalog und Rendering wird es unkontrollierbar.
5. AI braucht Plain Data — sonst bleiben Agents blind für den echten Intent.

Häufige Fragen

Brauchen wir eine eigene Internal Developer Platform?

Nur bei genügend Teams und Use Cases. Die Kosten sind real — oft ist ein Managed-Pfad wirtschaftlicher als 18 Monate Eigenbau. Zuerst klären, ob Kubernetes überhaupt passt.

Git oder OCI?

Git für Kollaboration, OCI für immutable Artefakte und Skalierung. Moderne GitOps nutzt beides.

Wie vermeiden wir den 64 %-Bypass?

Die Plattform für die Nutzer bauen: Self-Service, der den Alltag löst — Kultur und Prinzipien statt Tool-Diktat.

Fazit

GitOps macht Kubernetes-Plattformen vorhersagbar — wenn es Kultur und Intent ist, nicht nur ein Controller. Für KI-Plattformen heißt das: Agents und GPU-Workloads als Bürger behandeln, Plain Data pflegen und Reconciliation ernst nehmen.

Ergänzend: Cluster-Security in Schichten und Compose vs. Kubernetes. Wir beraten ehrlich, ob eine eigene Plattform lohnt — und betreiben GitOps mit Progressive Delivery und Audit, wenn der Managed-Pfad der bessere ist.