Espejote (grosser Spiegel auf Spanisch) verwaltet beliebige Ressourcen in einem Kubernetes-Cluster. Von Grund auf entwickelt, um Server-Side Apply und Jsonnet-Templating optimal zu nutzen.

Wir betreiben bei VSHN eine grosse Anzahl von Kubernetes-Clustern für unsere Kunden und wir versuchen, so viel wie möglich zu automatisieren, um unsere Betriebsabläufe effizient und nachhaltig zu gestalten. Wir nutzen GitOps-Prinzipien, aber manchmal muss externer Zustand mit dem in Git definierten Zielzustand zusammengeführt werden. Diese GitOps-Reise führte uns von Ansible-Playbooks, die direkt YAML anwenden, über verschiedene Operatoren, hin zu Bash-„Reconcilern“ und schliesslich zu Espejote, unserem neuen GitOps-Operator.

Kapitel 1: Die Ansible-Ära und erste Operator-Versuche

Am Anfang nutzten wir Ansible-Playbooks und eigene Rollen, um unsere OpenShift 3 Kubernetes-Cluster zu verwalten. Wir hatten eine Sammlung von YAML-Dateien, die den gewünschten Zustand unserer Cluster definierten und führten Ansible-Playbooks aus, um diese auf die Cluster anzuwenden. Das funktionierte, war aber nicht besonders effizient. Wir mussten die Playbooks manuell ausführen, und wenn wir das vergassen, drifteten die Cluster vom gewünschten Zustand ab.

Die Sammlung von Rollen erhielt den Spitznamen „mungg“, das schweizerdeutsche Wort für „Murmeltier“. Niemand weiss genau warum, aber der Name blieb.

Wir begannen gerade erst damit, Operatoren zu entwickeln und entwickelten espejo, um Ressourcen schnell zwischen Namespaces zu synchronisieren. Es war die sehr frühe Phase unserer Operator-Reise.

Kapitel 2: Das Meer der Operatoren und der Tränen

Um das Problem der manuellen Eingriffe zu lösen (und weil wir auf OpenShift 4 migrierten, wo das Installationsverfahren kein Ansible mehr nutzt), begannen wir, uns mit Kubernetes-Operatoren zu beschäftigen. So schwer kann es doch nicht sein, ein Kubernetes-Manifest zu patchen. Oder? Falsch.
Einige Operatoren waren fehlerhaft, andere nicht flexibel genug, manche gerieten zufällig in Reconcile-Loops und die meisten verbrauchten zu viele Ressourcen. Einige brachten sogar unsere API-Server zum Absturz. Wir begannen mit resource-locker-operator, migrierten zu patch-operator, verursachten Ausfälle mit Kyverno und testeten alle Policy-Engines, die wir finden konnten. Kubewarden war die einzige, die uns wirklich gefiel, aber die Cluster-Context-API war noch nicht flexibel genug für unsere Anwendungsfälle.

Espejo war ein guter Anfang, aber wir hatten noch nicht die Erfahrung, gut designte Operatoren zu bauen. Das zeigte sich. Jedes Event löste eine vollständige Reconciliation aller Ressourcen aus, wodurch die Synchronisation in grösseren Clustern drastisch langsamer wurde. Uns fehlte viel Flexibilität.

Kapitel 3: Verzweifelte Suche nach stabilen Landungen

Wir hatten genug von den ständigen Bugs und Breaking Changes in Kyverno und patch-operator wurde kaum gepflegt. Espejo war an seine Grenzen gestossen.

Verzweifelte Zeiten erfordern verzweifelte Massnahmen, also begannen wir, eine Mischung aus Bash-„Reconcilern“ – Hacks mit Cronjobs, kleinen eigenen Controllern und Vorverarbeitung von Ressourcen in Project Syn.

Wir nutzten zunehmend Jsonnet. Project Syn-Komponenten verwenden hauptsächlich Jsonnet. Wir setzen Jsonnet für unseren cloudscale machine-api provider, für unsere SSO-Lösung und viele weitere Projekte ein.

Ein wachsendes Problem waren unsere stark angepassten OpenShift-Alerting-Regeln. Wir kuratieren Upstream-Regeln und aktivieren nur diejenigen, die wir benötigen. Einige sind stark modifiziert. Mit jeder OpenShift-Version werden die Upstream-Definitionen verschoben und sind teilweise nur noch in Go-Code eingebettet verfügbar. Wir brauchten etwas, das bereits im Cluster deployte Regeln patchen kann, da dies die einzige stabile Schnittstelle war.

Kapitel 4: Espejote, der neue GitOps-Operator

Mit wachsender Operator-Erfahrung und unserer Begeisterung für Jsonnet entschieden wir uns, unseren eigenen Operator zu bauen – einen, der alles kann. Wir wollten etwas Flexibles, Effizientes und Einfaches. Etwas, das all unsere Anwendungsfälle abdeckt, vom Synchronisieren von Ressourcen zwischen Namespaces bis hin zum Patchen von OpenShift-Alerting-Regeln.

Espejote ist das Ergebnis dieser Reise. Es kombiniert Cluster-Zustand mit GitOps-Prinzipien und nutzt Jsonnet zur Definition des gewünschten Zustands. Es cached den Cluster-Zustand effizient, und die Reconcile-Trigger-Logik ist explizit definiert. Sinnvolle controller-runtime Rate Limits kommen zum Einsatz. Jsonnet bietet enorme Flexibilität, und natives Server-Side Apply macht das Hinzufügen und Entfernen von Schlüsseln einfach. Jeder Espejote „Resource Manager“ – also der dynamische Controller pro Konfigurationseinheit – nutzt eine eigene ServiceAccount für Least Privilege.

Espejote ist genau der Operator, den wir immer wollten und wir freuen uns, ihn mit der Welt zu teilen.

Was ist Espejote?

Espejote ist ein Kubernetes-Operator, mit dem du beliebige Ressourcen in einem Kubernetes-Cluster verwalten kannst. Er kombiniert GitOps-Prinzipien mit dem Zustand im Cluster.

Warum Espejote?

Es gibt viele ähnliche Tools (und Policy-Engines), aber Espejote hebt sich durch drei zentrale Säulen ab:

1. Powered by Jsonnet

Espejote nutzt Jsonnet als Templating-Engine. Im Gegensatz zu YAML kombiniert mit Go-Templates behandelt Jsonnet Konfigurationen als Datenstruktur. Es versteht Objekte, Arrays und Strings. Es kann nicht versehentlich fehlerhaftes YAML erzeugen, da Jsonnet sicherstellt, dass die interne Datenstruktur gültig ist, bevor überhaupt eine Datei exportiert wird.

2. Native Server-Side Apply

Espejote wurde von Grund auf für Server-Side Apply (SSA) entwickelt. Das bedeutet, dass Espejote gut mit anderen Controllern und Operatoren zusammenarbeitet. Es kann einzelne Annotationen oder komplette Ressourcen verwalten – SSA sorgt dafür, dass Änderungen sauber zusammengeführt werden, ohne andere Tools zu überschreiben.

3. Zuverlässigkeit

Zuverlässigkeit ist kein nachträglicher Gedanke. Espejote entstand aus der Frustration über Operatoren, die in Endlosschleifen geraten oder Cluster zum Absturz bringen. Es bietet:

• Sinnvolle Rate Limits und Backoff-Strategien.
• Jede Konfigurationseinheit („Resource Manager“) läuft als eigener, dynamisch erzeugter Controller, sodass fehlerhafte Einheiten andere nicht beeinflussen.
• Least Privilege: Jeder Resource Manager nutzt eine eigene ServiceAccount.
• Volle Kontrolle: Keine impliziten Watches oder „magischen“ Trigger – du bestimmst genau, was wann reconciled wird.

Praxisbeispiele

Was kannst du konkret mit Espejote machen? Hier einige Beispiele aus dem produktiven Einsatz bei VSHN:

• Secret-Synchronisation: Automatisches Replizieren von Secrets (z.B. Image Pull Secrets oder Zertifikate) über mehrere Namespaces hinweg.
• Autoscaler-Patching: Anpassung des OpenShift Cluster Autoscalers über Admission Webhooks.
• Alerting-Regel-Management: Kuratieren und Patchen von OpenShift-Alerting-Regeln über verschiedene Cluster-Versionen hinweg.

Die Zukunft: WASM und mehr

Die Roadmap umfasst einen kro-ähnlichen API-Builder zur einfachen Erstellung eigener Ressourcen sowie Unterstützung für WebAssembly-Plugins. Damit können Entwickler eigene Logik in nahezu jeder Sprache schreiben und sicher im Espejote-Controller ausführen.

Erste Schritte

• Website: espejote.io
• GitHub: vshn/espejote
• Dokumentation: Schau dir die kommentierten Beispiele an, um reale Anwendungsfälle zu verstehen.
• Praxisbeispiele: Network Policy Management, ein Gateway Listener Manager, HTTPRoute-Zertifikatsverwaltung und viele weitere.

Beispiel

Dieses Beispiel ManagedResource patcht die RedHat OperatorHub-Konfiguration, um alle Standardquellen zu deaktivieren. Es zeigt den einfachsten Anwendungsfall: ein statisches Manifest bedingungslos patchen. Komplexere Anwendungsfälle findest du im Abschnitt „Erste Schritte“.

apiVersion: espejote.io/v1alpha1
kind: ManagedResource
metadata:
  annotations:
  name: disable-default-sources
  namespace: openshift-marketplace
spec:
  serviceAccountRef:
    name: disable-default-sources
  triggers:
    - name: operatorhub
      watchResource:
        apiVersion: config.openshift.io/v1
        kind: OperatorHub
        name: cluster
  template: |-
    {
        "apiVersion": "config.openshift.io/v1",
        "kind": "OperatorHub",
        "metadata": {
            "name": "cluster"
        },
        "spec": {
            "disableAllDefaultSources": true
        }
    }

Large Language Models (LLMs) werden zunehmend Teil moderner Softwaresysteme. Von Chatbots und Copilots über Retrieval-Systeme bis hin zu AI-Agenten – immer mehr Organisationen integrieren generative AI in echte Produktionsumgebungen. Während es heute einfacher denn je geworden ist, AI-Prototypen zu bauen, bleibt der zuverlässige Betrieb von LLMs in Produktion eine grosse Herausforderung.

Auf den Kubernetes Community Days New York teilte Aarno Aukia praktische Einblicke, was es braucht, um LLMs mit bewährten DevOps-Praktiken zu betreiben. Sein Vortrag machte eine wichtige Realität deutlich: AI-Systeme benötigen weiterhin starke DevOps-Fundamente – möglicherweise sogar mehr als klassische Softwaresysteme.

Aarno Aukia’s Talk am KCD New York

DevOps trifft auf AI

DevOps war schon immer darauf ausgerichtet, die Lücke zwischen Entwicklung und Betrieb zu schliessen. Entwickler konzentrieren sich auf die Anwendungslogik und Daten, während Operations-Teams dafür sorgen, dass Software zuverlässig in Produktion läuft. In den letzten zehn Jahren haben sich DevOps-Praktiken rund um Automatisierung, Observability und Continuous Delivery stark weiterentwickelt.

In vielen Organisationen folgt Software heute einer etablierten Pipeline: Entwickler committen Code in Git, automatisierte CI/CD-Pipelines bauen und paketieren die Anwendung, und Kubernetes deployt und betreibt sie in Produktion. Monitoring- und Logging-Systeme schaffen Transparenz darüber, wie sich die Anwendung verhält, sodass Entwickler sie kontinuierlich verbessern können.

Diese Feedback-Schleife ist zum Rückgrat moderner Cloud-Native-Entwicklung geworden.

Wenn jedoch AI ins Spiel kommt, verändert sich dieses Modell in mehreren wichtigen Punkten.

AI-Systeme verhalten sich anders

Einer der grössten Unterschiede zwischen klassischen Anwendungen und AI-basierten Systemen ist die Deterministik. Traditionelle Software verhält sich vorhersehbar: Bei gleichem Input entsteht immer derselbe Output. LLMs funktionieren dagegen völlig anders.

Large Language Models sind probabilistische Systeme. Sie erzeugen Antworten, indem sie das nächste Token basierend auf dem Kontext vorhersagen und damit statistische Entscheidungen darüber treffen, was als Nächstes folgt. Das bedeutet, dass selbst kleine Änderungen im Prompt oder in der Eingabe zu sehr unterschiedlichen Ergebnissen führen können.

Eine scheinbar harmlose Anpassung eines System-Prompts kann das Verhalten eines Modells komplett verändern. In einem Beispiel führte bereits das Hinzufügen eines saisonalen Themas zu einem Chatbot-Prompt dazu, dass das Modell grundlegende Fragen nicht mehr korrekt beantworten konnte.

Für Operations-Teams entsteht dadurch eine neue Kategorie von Komplexität. Anstatt deterministische Systeme zu debuggen, müssen sie nun Systeme betreiben, deren Ergebnisse sich je nach Kontext subtil verändern können.

Testing wird dadurch deutlich komplexer.

Die Herausforderung beim Testen von AI

Klassisches Software-Testing ist vergleichsweise einfach. Ein Test liefert einen Input und überprüft, ob der Output exakt dem erwarteten Wert entspricht.

AI-Systeme passen nicht in dieses Modell. Wenn ein LLM eine Antwort generiert, kann diese korrekt sein, auch wenn sie sich in der Formulierung vom erwarteten Ergebnis unterscheidet. Gleichzeitig kann sie subtile sachliche Fehler oder Halluzinationen enthalten.

Zu bestimmen, ob eine Antwort akzeptabel ist, erfordert daher oft eine semantische Bewertung statt eines strikten Vergleichs. In manchen Fällen verwenden Organisationen sogar ein weiteres LLM, um die Ausgabe des ersten Modells zu bewerten. Dadurch entsteht ein völlig neues Testing-Paradigma, das viele Teams erst noch lernen zu beherrschen.

Mehr Artefakte zu verwalten

AI-Systeme bringen ausserdem zusätzliche Artefakte mit sich, die verwaltet und versioniert werden müssen.

In klassischen DevOps-Pipelines bestehen die wichtigsten Artefakte aus Source Code und Container Images. Bei AI-Workloads kommen jedoch weitere Komponenten hinzu: Datensätze, Trainingsartefakte, Prompts und Modelldateien. Diese Modelle sind oft sehr gross – teilweise mehrere Dutzend Gigabyte – und müssen sorgfältig gespeichert und versioniert werden.

Ohne saubere Versionierung wird es extrem schwierig, Probleme zu debuggen oder Ergebnisse später zu reproduzieren. Wenn sich ein Modell unerwartet verhält, müssen Teams genau wissen, welche Modellversion, welcher Datensatz und welche Konfiguration beim Deployment verwendet wurden.

Das erhöht die operative Komplexität von AI-Systemen erheblich.

Observability wird kritisch

Da LLMs nicht deterministisch sind, wird Observability noch wichtiger als in klassischen Systemen.

Logging muss deutlich mehr Kontext erfassen als bisher. Statt nur Anwendungsereignisse zu protokollieren, müssen Teams möglicherweise den vollständigen Prompt, die Modellantwort, die Modellversion und weitere Konfigurationsparameter speichern. Nur so können Betreiber später nachvollziehen, was genau passiert ist.

Ohne detaillierte Observability kann das Debugging von AI-Systemen schnell unmöglich werden.

Offene Modelle vs. gehostete APIs

Eine weitere wichtige operative Entscheidung ist die Wahl zwischen geschlossenen und offenen Modellen.

Gehostete AI-APIs bieten Komfort und leistungsstarke Funktionen, bringen aber auch Einschränkungen mit sich. In vielen Fällen haben Organisationen keine Kontrolle darüber, wann Modellupdates stattfinden oder welche Minor-Version gerade aktiv ist. Das kann Debugging und Reproduzierbarkeit erschweren.

Open-Weight- oder Open-Source-Modelle bieten dagegen mehr Kontrolle im Betrieb. Sie können heruntergeladen, versioniert, lokal getestet und auf eigener Infrastruktur betrieben werden. Organisationen können so selbst entscheiden, wann und wie Updates ausgerollt werden.

Gerade für regulierte Branchen wie Finanzwesen, Gesundheitswesen oder öffentliche Verwaltung ist dieses Mass an Kontrolle entscheidend.

Kubernetes als Fundament

Hier kommt Kubernetes als zentraler Bestandteil der AI-Infrastruktur ins Spiel.

Kubernetes löst bereits viele operative Herausforderungen beim Betrieb verteilter Systeme. Es bietet Mechanismen für Container-Orchestrierung, Ressourcenmanagement, Autoscaling und Fehlertoleranz. Für AI-Workloads besonders wichtig ist die Fähigkeit, auch GPU-Ressourcen zu verwalten.

Der Betrieb von Kubernetes selbst ist jedoch nicht trivial – wie wir auch in unserem Artikel Beste Kubernetes Distributionen 2026 – und warum du sie vielleicht nicht selbst betreiben solltest beschreiben. Produktionscluster zu betreiben erfordert erhebliche operative Erfahrung.

Kubeflow und der Machine-Learning-Lifecycle

Kubeflow erweitert Kubernetes um spezialisierte Komponenten für Machine-Learning-Workflows. Es hilft dabei, den gesamten Lebenszyklus von AI-Modellen zu verwalten – vom Training bis zum Betrieb der Inferenz.

Mit Kubeflow Pipelines können Teams Workflows für die Modellentwicklung und das Training automatisieren. Diese Pipelines orchestrieren komplexe Prozesse wie Datenvorverarbeitung, Trainingsläufe, Evaluationen und das Verpacken von Modellen für Deployments.

Für viele Organisationen, die LLMs einsetzen, liegt der Fokus jedoch nicht auf dem Training eigener Modelle, sondern darauf, bestehende Modelle zuverlässig in Produktion zu betreiben.

Hier kommt KServe ins Spiel.

LLMs mit KServe betreiben

KServe ist ein Kubernetes-natives Framework für Model Serving, das das Deployment und den Betrieb von AI-Modellen vereinfacht. Es ermöglicht Teams, Inferenzservices auf Kubernetes über standardisierte APIs bereitzustellen.

Ein typisches Deployment besteht aus einem Container, der einen Model Server betreibt, häufig basierend auf Runtimes wie vLLM. Der Container lädt das Modell, nutzt GPU-Ressourcen für die Inferenz und stellt einen API-Endpunkt für Anwendungen bereit.

KServe integriert sich mit Kubernetes-Autoscaling-Mechanismen und Observability-Tools, sodass AI-Workloads dynamisch skaliert und ihr Verhalten in Produktion überwacht werden kann.

Da alles als Kubernetes-Ressource läuft, können Teams dieselben DevOps-Praktiken nutzen, die sie bereits für andere Anwendungen einsetzen.

Ein schnell wachsendes Ökosystem

Das Ökosystem rund um AI-Infrastruktur entwickelt sich derzeit extrem schnell. Neue Projekte entstehen laufend, um die besonderen Herausforderungen beim Betrieb von LLMs im grossen Massstab zu adressieren.

Ein Beispiel ist LLMD, ein Kubernetes-Operator speziell für LLM-Inferenz. Er baut auf bestehenden Technologien wie vLLM auf, ergänzt diese jedoch um zusätzliche Funktionen wie Request-Routing, Modellselektion, Caching und intelligentes Scaling.

Solche Tools zeigen, wie sich das Cloud-Native-Ökosystem an die operativen Anforderungen von AI-Workloads anpasst.

AI braucht weiterhin DevOps

Trotz des grossen Hypes rund um generative AI bleibt eine zentrale Erkenntnis bestehen: AI-Systeme brauchen weiterhin starke operative Grundlagen.

LLMs in Produktion zu betreiben bedeutet weit mehr, als einfach eine API aufzurufen. Es erfordert sorgfältiges Management von Modellen, Infrastruktur, Observability und Deployment-Prozessen.

Kubernetes und Kubeflow bieten eine leistungsfähige Plattform, um diese Herausforderungen zu bewältigen. Durch die Anwendung bewährter DevOps-Prinzipien auf AI-Systeme können Organisationen Plattformen aufbauen, die nicht nur intelligent, sondern auch zuverlässig und skalierbar sind.

Während AI zunehmend zum Standardbestandteil moderner Anwendungen wird, wird die Fähigkeit, diese Systeme effizient zu betreiben, genauso wichtig wie die Modelle selbst.

Genau hier kommen Plattformansätze ins Spiel. Anstatt dass jedes Team komplexe Stacks selbst aufbauen und betreiben muss, können Plattformen fertige Services auf Kubernetes bereitstellen. Ein Beispiel dafür ist Servala – Sovereign App Store, ein Kubernetes-nativer Marktplatz, der Organisationen mit einem Katalog von Managed Cloud-Native-Services verbindet, darunter Datenbanken, Storage, Developer Tools und AI-fähige Infrastrukturkomponenten.