Welche Beziehung haben AX und Kubernetes? Was löst Googles neue KI-Agenten-Infrastruktur eigentlich?

Ein konkreter Architekturhinweis: Das offizielle AX-Repository führt Kubernetes-Manifeste für die Bereitstellung. Daraus folgt nicht, dass AX Kubernetes ersetzt. Google AX ist als Orchestrierungsebene für Agentenaufgaben zu bewerten; der Cluster und die darunterliegenden Laufzeitdienste stellen weiterhin die Umgebung bereit. Wenn Sie bereits Kubernetes betreiben und Agenten mit Isolation, längeren Laufzeiten oder kontrollierter Wiederaufnahme ausführen müssen, kann ein begrenzter AX-Pilot sinnvoll sein. Für einfache synchrone Modellaufrufe brauchen Sie diese zusätzliche Ebene nicht automatisch.

Dieser Beitrag richtet sich an Plattformingenieurinnen und -ingenieure, die Kubernetes-Cluster betreiben und Agentenaufgaben mit längerer Laufzeit erproben.
Auch wenn Sie für Agenten Isolation, Wiederaufnahme oder verwaltete Arbeitsbereiche entwerfen, finden Sie hier Prüfpunkte für die Abgrenzung.
Wenn Ihre Anwendung nur kurze synchrone Aufrufe ausführt, erfahren Sie, woran Sie erkennen, dass Sie vorerst keine weitere Laufzeit einführen müssen.

Letzte Aktualisierung: 26.09.2026. Geprüft anhand der offiziellen AX-Dokumentation und Bereitstellungsunterlagen sowie der verlinkten Kubernetes-Dokumentation. Da sich das Projekt schnell weiterentwickelt, prüfen Sie vor einer Einführung erneut die dort genannten Funktionen, Voraussetzungen und Reifehinweise.

Die Ebenen sauber trennen

Die kurze Antwort auf die Frage nach Google AX und Kubernetes lautet: Sie liegen nicht auf derselben Abstraktionsebene. AX beschreibt laut offizieller Konzeptdokumentation Begriffe und Abläufe für Agentenaufgaben. Kubernetes verwaltet dagegen bereitgestellte Workloads und deren gewünschte Laufzeitkonfiguration. Die Kubernetes-Dokumentation zu Workload-Controllern erklärt deren Rolle beim Beobachten und Abgleichen deklarierter Zustände.

In der Praxis heißt das: AX kann ausdrücken und koordinieren, wie eine Agentenaufgabe ausgeführt werden soll. Der Cluster muss trotzdem Ressourcen bereitstellen, Prozesse starten, Netzwerkregeln umsetzen und Persistenz ermöglichen. Wird ein Agentenprozess beendet, hängt die tatsächliche Wiederherstellung außerdem davon ab, welche Zustände AX speichert und welche Zustände außerhalb des Agentenprozesses liegen. Ein deklarierter Auftrag allein erzeugt weder dauerhaft verfügbare Speicher noch eine geeignete Netzwerkkonfiguration.

Ersetzt AX Kubernetes? Nein. Die Bereitstellung von AX auf Kubernetes ist ein Hinweis auf die ergänzende Beziehung: Kubernetes bleibt eine mögliche Ausführungsbasis, während AX Agentenaufgaben darüber ordnet. Ob eine konkrete AX-Funktion in Ihrer Umgebung tatsächlich so bereitgestellt werden kann, müssen Sie anhand der jeweils aktuellen offiziellen Installationshinweise prüfen.

Damit lassen sich zwei unterschiedliche Fragen auseinanderhalten: „Wie halte ich meine Plattform und ihre Workloads in einem gewünschten Zustand?“ und „Wie beschreibe, starte und verwalte ich Agentenaufgaben?“ Ein Team kann die erste Frage bereits mit Kubernetes beantworten und trotzdem feststellen, dass sein bisheriger Anwendungsbetrieb für Agenten nicht genügt. AX wäre dann eine mögliche zusätzliche Steuerungsebene, nicht automatisch ein Ersatz für alle vorhandenen Controller oder Deployments.

Agenten-Isolation an Arbeitsbereichen prüfen

Ein Agent ist nicht immer ein kurzlebiger Prozess, der nur eine Anfrage entgegennimmt und eine Antwort zurückgibt. Je nach Aufgabe kann er Dateien anlegen, Werkzeuge ausführen oder auf externe Dienste zugreifen. Daraus entstehen Grenzen, die Sie für jede Aufgabe festlegen müssen: Welche Dateien darf der Agent sehen? Welche Zugangsdaten erhält er? Welche Ziele darf er über das Netzwerk erreichen? Welche Änderungen dürfen in einen gemeinsamen Arbeitsbereich gelangen?

Die AX-Konzepte helfen dabei, Agentenarbeit als verwaltete Aufgabe mit zugehörigem Arbeitsbereich und Ausführungsanforderungen zu betrachten. Das ist ein anderes Modell als ein einzelner Aufruf an einen zustandslosen Dienst. Bevor Sie die Designabsicht als Betriebsverhalten werten, sollten Sie jedoch konkret nachvollziehen, wie die aktuell dokumentierte AX-Version diese Objekte erstellt, voneinander trennt und wieder entfernt. Aus einer Konzeptbeschreibung allein folgt noch kein nachgewiesenes Sicherheitsniveau.

Kubernetes kann die darunterliegenden Grenzen unterstützen, übernimmt aber nicht automatisch die komplette Agenten-Sicherheitslogik. Beispielsweise beschreibt die Dokumentation zu NetworkPolicy, wie Netzwerkzugriffe über Richtlinien begrenzt werden können. Ob diese Regeln wirken, hängt auch von der eingesetzten Cluster-Netzwerklösung ab. Prüfen Sie daher im Pilot, ob ein Agent tatsächlich nur die vorgesehenen Ziele erreichen kann und ob ein neu gestarteter Arbeitsbereich dieselben Regeln erhält.

Auch Geheimnisse und Identitäten sind ein eigener Prüfpunkt. Die Kubernetes-Dokumentation begrenzt ein Secret auf 1 MiB; zugleich sollten Sie nicht annehmen, dass das Speichern eines Geheimnisses im Cluster bereits dessen vollständige Verschlüsselung oder sichere Verwendung im Agentenprozess gewährleistet. Die Dokumentation zu Kubernetes Secrets erläutert das Ressourcenmodell. Legen Sie zusätzlich fest, wie Zugangsdaten bereitgestellt, rotiert, protokolliert und nach Abschluss einer Aufgabe entzogen werden.

Behandeln Sie Isolation als überprüfbares Ergebnis: Eine getrennte Bezeichnung oder ein eigener Arbeitsbereich beweist für sich genommen weder getrennte Zugangsdaten noch eine wirksame Netzwerkgrenze.

Lange Aufgaben mit Unterbrechungen testen

Eine kurze Webanfrage kann beendet sein, sobald sie eine Antwort zurückgibt. Eine längere Agentenaufgabe kann dagegen auf eine Freigabe warten, auf ein Werkzeugergebnis angewiesen sein oder später fortgesetzt werden müssen. Das verändert die Betriebsanforderungen: Sie müssen wissen, welcher Zustand dauerhaft erhalten bleibt, wie eine Unterbrechung erkannt wird und wer nach einer Wiederaufnahme entscheidet, ob der nächste Schritt noch zulässig ist.

Die AX-Dokumentation beschreibt einen Ansatz, Agentenaufgaben und deren Ausführung strukturierter zu verwalten. Das ist für ein Team interessant, wenn Aufgaben nicht sauber in einen einzelnen synchronen Aufruf passen. Es ist aber kein Beleg für eine bestimmte Wiederherstellungszeit, eine garantierte Zustellungssemantik oder eine bestimmte Ausfallsicherheit. Solche Kennzahlen sollten Sie weder aus Begriffen wie „stateful“ noch aus einem erfolgreichen Einzeltest ableiten, wenn sie nicht ausdrücklich für die jeweilige Version dokumentiert und in Ihrer Umgebung geprüft sind.

Für den Versuch sollten Sie mindestens drei Ausfallarten getrennt testen: Der Agentenprozess wird beendet, die Verbindung zu einem benötigten Werkzeug fällt aus oder eine Aufgabe wartet länger als erwartet auf eine menschliche Entscheidung. Notieren Sie für jeden Fall, welcher Zustand nach einem Neustart sichtbar ist und ob die Aufgabe fortgesetzt, wiederholt oder manuell bereinigt werden muss. Wiederholte Werkzeugaufrufe können Nebenwirkungen verursachen; deshalb braucht jede Aufgabe eine Regel dafür, wie doppelte Aktionen erkannt oder verhindert werden.

Wie teilen sich AX und Kubernetes beim Ausführen eines Agenten auf? AX ist für die Agentenaufgabe und ihren Ausführungsablauf relevant; Kubernetes stellt die Laufzeitressourcen und Clustermechanismen bereit, auf denen die Bereitstellung aufsetzt. Der genaue Übergang zwischen beiden Ebenen muss aus den aktuellen AX-Unterlagen und Ihrem Versuch hervorgehen. Prüfen Sie insbesondere, welche Komponente einen Neustart veranlasst und welche Komponente über den fachlichen Zustand der Aufgabe entscheidet.

Deklarative Aufgaben in den vorhandenen Betrieb einordnen

Deklarative Konfiguration ist wertvoll, wenn Teams Ausführungsanforderungen wiederholbar beschreiben, prüfen und ändern wollen. Für Agenten kann das bedeuten, Aufgabe, Arbeitsbereich und Modellkonfiguration nicht nur als undokumentierte Befehlsfolge zu behandeln. Die AX-Unterlagen und die bereitgestellten Kubernetes-Manifeste sind deshalb gute Ausgangspunkte, um den vorgesehenen Installationsweg zu untersuchen.

Das ähnelt Kubernetes-Arbeitsweisen, ist aber nicht mit ihnen identisch. Kubernetes-Deployments beschreiben den gewünschten Zustand für eine Anwendung und unterstützen die Verwaltung zugehöriger ReplicaSets. In der Deployment-Dokumentation ist außerdem festgehalten, dass eine nicht angegebene Replikazahl standardmäßig 1 beträgt. Das ist ein nützlicher konkreter Konfigurationshinweis, aber keine Aussage darüber, wie viele Agenten AX parallel ausführen kann: Diese Kapazität müssen Sie für die konkrete Version und Umgebung gesondert feststellen.

Deklarative Aufgaben können zudem Versionskontrolle, Review und reproduzierbare Änderungen erleichtern. Sie lösen jedoch nicht von selbst Fragen wie: Welche Konfiguration ist geheim? Welche Änderungen dürfen in die Produktion? Wie unterscheiden Sie eine geänderte Aufgabendefinition von einem geänderten Modellverhalten? Planen Sie für den Pilot eine Prüfung, die Konfiguration und Laufzeitprotokolle zusammen betrachtet, ohne geheime Eingaben oder personenbezogene Daten unnötig zu speichern.

Für Datenflüsse mit personenbezogenen Informationen gehört auch die Speicherung von Eingaben, Ausgaben und Protokollen in Ihre Prüfung. Die Datenschutzhinweise von ZavCloud können Ihnen als ergänzende Orientierung für Fragen zu Datenschutz und Datenverarbeitung dienen; sie ersetzen keine Prüfung Ihrer eigenen Cluster- und Agentenarchitektur nach DSGVO.

Betriebsgrenzen vor dem Pilot festlegen

Eine zusätzliche Orchestrierungsebene bringt nicht nur Funktionen, sondern auch neue Zuständigkeiten. Ihr Team muss die AX-Version beobachten, Installations- und Aktualisierungsschritte verstehen sowie klären, wer Fehler zwischen Agentenlaufzeit, AX und Kubernetes diagnostiziert. Wenn AX zusätzliche Speicher-, Identitäts- oder Netzwerkkomponenten voraussetzt, müssen diese ebenfalls in Bereitschafts- und Änderungsprozesse aufgenommen werden.

Die offiziellen Bereitstellungsdateien sind kein Nachweis dafür, dass jede Produktionsanforderung bereits abgedeckt ist. Vor dem Einsatz sollten Sie deshalb in den aktuellen Unterlagen klären, welche Installationswege ausdrücklich unterstützt werden, welche Funktionen als Vorschau oder experimentell gekennzeichnet sind und welche Betriebsgrenzen genannt werden. Ist für eine Funktion kein Reifegrad ausgewiesen, sollten Sie sie nicht stillschweigend als produktionsreif einstufen.

Für Verantwortlichkeiten bietet sich eine einfache Zuordnung an: Das Plattformteam verantwortet Clusterkapazität, Updates und Netzwerkrichtlinien; das Agententeam verantwortet Aufgabenlogik, Werkzeugrechte und fachliche Wiederholbarkeit; gemeinsam legen Sie Aufbewahrung, Protokollierung und Freigabeprozesse fest. Damit vermeiden Sie, dass ein Agentenfehler als Clusterproblem behandelt wird oder ein Infrastrukturfehler fälschlich eine Wiederholung fachlicher Aktionen auslöst.

Wenn Datenschutz, Zugriff auf Testumgebungen oder die Einordnung der Zuständigkeiten für Sie noch offen sind, kann das Hilfezentrum von ZavCloud als allgemeiner Einstieg dienen. Für AX-spezifische Funktionen bleiben jedoch die offiziellen Projektunterlagen maßgeblich.

Kontrollierten Pilot statt Plattformwechsel wählen

Ein Pilot ist sinnvoll, wenn Sie einen konkreten Engpass benennen können: isolierte Arbeitsbereiche, Agentenaufgaben mit Unterbrechungen oder wiederholbare Verwaltung über mehrere Teams hinweg. Wählen Sie nicht zuerst ein Werkzeug und suchen Sie anschließend nach einem Einsatzfall. Vergleichen Sie die beobachtbare Verbesserung mit zusätzlicher Komplexität, Ausfallfolgen und laufendem Wartungsaufwand.

Gehen Sie für die Evaluation schrittweise vor:

1. Aufgabentyp eingrenzen. Wählen Sie einen repräsentativen Langläufer oder eine Aufgabe mit klarer Isolationsanforderung. Erfassen Sie, welche Werkzeuge, Dateien und Netzwerkziele dafür wirklich notwendig sind.
2. Unterlagen und Reifegrad prüfen. Kontrollieren Sie Repository, Konzepte und Bereitstellungsanleitung für die Version, die Sie testen. Halten Sie fest, welche Funktionen dokumentiert, als Vorschau markiert oder noch nicht ausreichend beschrieben sind.
3. Verantwortlichkeiten zuordnen. Benennen Sie Zuständige für AX, Cluster, Netzwerk, Secrets und Aufgabenlogik. Wenn niemand die zugrunde liegende Kubernetes-Umgebung betreiben kann, starten Sie nicht mit einer produktionsnahen Einführung.
4. Begrenzte Testumgebung vorbereiten. Verwenden Sie getrennte Zugangsdaten und nichtproduktive Daten. Begrenzen Sie Netzwerkzugriffe und testen Sie, ob die für den Agenten vorgesehene Grenze tatsächlich greift.
5. Unterbrechungen gezielt auslösen. Beenden Sie einen Agentenprozess, unterbrechen Sie einen Werkzeugzugriff und simulieren Sie eine ausstehende Freigabe. Dokumentieren Sie jeweils, welcher Zustand erhalten bleibt und welche manuellen Eingriffe nötig sind.
6. Erfolg und Rückbau vorab definieren. Legen Sie fest, welche Aufgaben mit AX nachvollziehbarer oder sicherer ablaufen müssen und welche Fehlerszenarien den Versuch beenden. Halten Sie außerdem fest, wie Sie Konfiguration, Ressourcen und Zugangsdaten entfernen, falls Sie zurückrollen.

Welche Agentenaufgaben rechtfertigen eine AX-Evaluation? Vor allem solche, bei denen Sie wiederholt an Isolation, längerer Ausführung, kontrollierter Wiederaufnahme oder zentral verwalteten Ausführungsanforderungen scheitern. Ein einzelner einfacher Modellaufruf liefert dagegen selten einen ausreichenden Grund, eine zusätzliche Laufzeit zu betreiben.

Benötigen Sie AX bereits, wenn Kubernetes vorhanden ist? Nicht automatisch. Ein vorhandener Cluster senkt zwar möglicherweise die Einstiegshürde für einen Versuch, beweist aber weder, dass AX zu Ihrem Aufgabenmodell passt, noch dass Ihr Team die zusätzliche Ebene ohne unverhältnismäßigen Wartungsaufwand betreiben kann.

Wenn Ihr heutiger Ansatz Agenten direkt in allgemeinen Diensten ausführt, können gemeinsame Arbeitsverzeichnisse, breite Zugangsdaten und unklare Wiederholungsregeln echte Schwachstellen sein. Ein zusätzlicher AX-Layer kann diese Punkte aber nicht ohne passende Cluster-, Speicher- und Netzwerkregeln beseitigen. Für Teams ohne Betriebsverantwortung kann er sogar eine weitere Komponente schaffen, die aktualisiert und im Fehlerfall diagnostiziert werden muss.

Wenn Ihr Engpass tatsächlich Agentenaufgaben auf Kubernetes betrifft, sollten Sie daher zuerst mit einem begrenzten Pilot und klaren Rückbaukriterien entscheiden, nicht mit einem Plattformwechsel. Ein Mac ist kein Ersatz für einen Kubernetes-Cluster und führt AX nicht an dessen Stelle aus. Benötigen Sie daneben jedoch eine getrennte macOS-Testumgebung für Apple-spezifische Werkzeuge oder Anwendungen, kann ein Mac mini zur Miete bei ZavCloud diese Prüfungen abdecken. Für Agenten, deren Anforderungen vollständig im Kubernetes-Cluster liegen, bleibt die passende Wahl eine kontrollierte Cluster-Evaluation statt einer unpassenden Hardware-Abkürzung.