Googles GKE-Migrationsagent: KI-Vorschläge statt ungeprüfter Cluster-Änderungen

Eine KI kann Kubernetes-Konfigurationen für eine andere Cloud umschreiben. Ob danach Berechtigungen stimmen, Anfragen beim richtigen Dienst landen und genügend Rechenkapazität bereitsteht, ist eine andere Frage. Genau an dieser Vertrauenslücke setzt Googles am 24. September 2026 vorgestelltes Open-Source-Projekt GKE agentic migration an: Laut Google verbindet das Agenten-Plugin die Schlussfolgerungen eines großen Sprachmodells mit deterministischen Werkzeugen und Schutzmechanismen. Es soll damit mehr bieten als eine Folge frei formulierter Prompts. 2

Entscheidend ist die Funktion, nicht die YAML-Syntax

Beim Wechsel von Amazon Elastic Kubernetes Service (EKS) zu Google Kubernetes Engine (GKE) müssen Teams Infrastrukturcode und Kubernetes-Manifeste auf die Zielumgebung übertragen. Eine formal gültige Datei belegt jedoch nicht, dass die Anwendung dort dasselbe tut. Googles allgemeine Migrationsleitlinien beginnen deshalb mit einer Bestandsaufnahme der Workloads und ihrer Abhängigkeiten. 19

Besonders sorgfältig zu prüfen sind drei Arten der Übersetzung:

• Identitäten und Zugriffsrechte: Erhalten Workloads in GKE nur die Berechtigungen, die sie benötigen?
• Lastverteilung und Routing: Erreichen Anfragen nach einer Umstellung auf die Gateway API weiterhin die vorgesehenen Dienste?
• Bereitstellung von Rechenknoten: Bleiben die Voraussetzungen für Platzierung und Kapazität der Workloads erhalten?

Das sind Prüffragen zu den beschriebenen Migrationszuordnungen, keine nachgewiesene Zusage, dass das Werkzeug jeden Sonderfall korrekt abdeckt. Auch das Model Context Protocol (MCP), über das einem Agenten Werkzeuge zugänglich gemacht werden können, garantiert für sich genommen keine richtige Konvertierung. Der vorliegende Auszug aus Googles Ankündigung erläutert die Kombination aus Sprachmodell und deterministischen Werkzeugen, aber nicht sämtliche Konvertierungsregeln. 2

Schutzmechanismen brauchen einen klaren Geltungsbereich

Deterministische Offline-Prüfungen können vorgeschlagene Dateien wiederholt nach denselben Regeln kontrollieren. Das ist etwas anderes, als wenn ein Sprachmodell seine eigene Ausgabe für plausibel erklärt. Solche Prüfungen können aber nur Fehler erkennen, für die Regeln vorhanden sind. Google spricht von deterministischen Schutzmechanismen; wie weit die Offline-Validierung im Einzelnen reicht, geht aus dem verfügbaren Ankündigungsauszug nicht hervor. 2

Der beschriebene Ansatz mit Pull Requests würde KI-generierte Änderungen zunächst zur Prüfung vorlegen, statt sie unmittelbar in einem laufenden Cluster umzusetzen. Teams könnten Unterschiede im Code einsehen und ihre üblichen Tests, Richtlinien und Freigaben in der CI/CD-Pipeline anwenden. Das entspricht Googles dokumentierter Empfehlung, GKE-Deployments über Versionsverwaltung und CI/CD zu steuern. Der verfügbare Ankündigungsauszug bestätigt allerdings nicht jeden Schritt dieses konkreten Pull-Request-Ablaufs. 172

Persistent-Manager Rahul Shrivastava bezeichnet den Ansatz in Googles Ankündigung als „provable, compiler-grade migration factory“. Als Bild für das Erzeugen und Prüfen von Migrationsartefakten ist das griffig. Ein mathematischer Beweis für eine sichere Gesamtmigration ist es nicht: Laufzeitverhalten, Zugriffe, Leistung, Abhängigkeiten und die eigentliche Umschaltung müssen weiterhin getestet werden. 2

Der Bezug zu Intrinsic Core

Zwei Tage vor Googles GKE-Ankündigung stellte Intrinsic auf der ROSCon 2026 in Toronto Intrinsic Core vor. Die Open-Source-Basis für Industrierobotik ist mit dem Robot Operating System (ROS) kompatibel und umfasst wiederverwendbare Funktionen unter anderem für Steuerung, Bewegungs- und Greifplanung, Simulation und Posenschätzung. Berichte nennen Apache 2.0 als Lizenz; Intrinsic beschreibt außerdem eine hardwareunabhängige Echtzeitsteuerung und Digital-Twin-Funktionen. 403337

Die Verbindung zwischen beiden Veröffentlichungen ist strategisch, nicht technisch: Der GKE-Agent könnte den Aufwand für einen Cloud-Wechsel senken, Intrinsic Core den Einstieg in die Entwicklung von Robotikanwendungen. Berichte vergleichen den zweiten Ansatz mit einem „Android für Roboter“ – einer frei verfügbaren Grundlage, um ein Ökosystem aufzubauen. Ob daraus zusätzliche Kunden für Google Cloud oder KI-Dienste werden, belegt keine der beiden Veröffentlichungen. 230

Fazit: Der GKE-Ansatz kann KI-generierte Migrationsvorschläge besser in bestehende Prüf- und Freigabeprozesse einfügen. Er nimmt Unternehmen die Verantwortung für die Verifikation ihrer Workloads nicht ab. Messwerte zu sinkenden Migrationskosten oder weniger Fehlschlägen liefern die vorliegenden Quellen nicht. 219