„What do you need to orchestrate high-density concurrent AI agents?“ Mit dieser Frage beginnt das Google-Cloud-Team seinen Beitrag über die Netzwerk-Dataplane von GKE. Die Antwort ist unspektakulär: Es braucht vor allem sauberes Identitätsmanagement. Kein neuer Beschleuniger, keine größere Maschine – sondern die Frage, wie ein Cluster mehrere hunderttausend Sandboxes auseinanderhält, ohne bei der Vergabe von Zutrittsrechten ins Stocken zu geraten.
Der Beitrag beschreibt den Übergang von statischen Requests zu autonomen, agentischen Workflows. Statt einer Anfrage, die genau eine Antwort erzeugt, laufen viele kleine, voneinander isolierte Programme, die selbst entscheiden, welchen Schritt sie als Nächstes gehen. Sie brauchen strikte Trennung, sonst wird aus einem Agenten schnell ein Sicherheitsproblem. Laut dem Text fordern Spitzenforschungslabore inzwischen Größenordnungen von bis zu einer Million gleichzeitig laufender Code-Sandboxes. Beim Reinforcement Learning kann das bedeuten, dass im Minutentakt Tausende Pods entstehen und wieder verschwinden.
Warum hochdichte Agenten-Umgebungen das Netzwerk unter Druck setzen
Dort wird Netzwerk zur Kostenfrage. Jede Sekunde, in der eine GPU oder ein TPU-Slice auf die Initialisierung einer Sandbox wartet, ist bezahlte Rechenzeit ohne Ergebnis. Der Beitrag nennt deshalb Subsekunden-Provisionierung und hohe Rechendichte als harte Anforderungen, nicht als Komfortmerkmal. Wer Agenten im großen Stil betreibt, bezahlt die Wartezeit doppelt: einmal für die Beschleuniger, die stillstehen, und einmal für die Infrastruktur, die diese Stille verwaltet.
Für dieses Problem stellt Google zwei Bausteine nebeneinander. Agent Sandbox auf GKE liefert die leichte, sichere Isolation einzelner Ausführungsumgebungen. Agent Substrate auf GKE setzt darauf auf und zielt auf noch dichtere Umgebungen, in denen sehr viele Sitzungen überwiegend im Ruhezustand liegen und in Sekundenbruchteilen wieder aufwachen müssen. Beide Bausteine hängen an der Netzwerkschicht darunter. Und diese Schicht hatte bisher eine Grenze, die mit Agenten-Workloads unangenehm wird.
Der Pförtner als Flaschenhals: Netzwerkidentitätsmanagement unter Last
Man kann sich das wie den Pförtner eines großen Werksgeländes vorstellen. Er führt keine Akte über jede Person, sondern prüft die Zutrittskategorie: Lieferant, Technikerin, Besucher. GKE Dataplane V2 arbeitet ähnlich. Die Dataplane baut auf eBPF auf und bildet die Labels eines Pods auf eine numerische Identität ab. Gegen diese Identität werden Netzwerkrichtlinien durchgesetzt, nicht gegen jeden Pod einzeln. Für klassische Anwendungen ist das unspektakulär, weil sich Labels kaum ändern und viele Pods dieselben teilen.
Agentische Frameworks brechen mit dieser Annahme. Sie vergeben laut dem Beitrag oft eindeutige, dynamische Labels pro Pod – eine Agenten-ID, einen Zeitstempel, eine Claim-UID. Damit bekommt jeder Besucher eine eigene Akte, statt unter einer von wenigen Kategorien geführt zu werden. Der Pförtner muss jedes Mal neu schreiben, und zwar seriell, während der Pod auf seine Freigabe wartet. Das führe zu spürbaren Pausen bei der Pod-Erstellung und zu einem zweiten, härteren Problem: Der Cluster nähert sich der Obergrenze von 65.536 Netzwerkidentitäten, die Cilium-basierte Dataplanes verwalten.
Hier endet Skalierung oft, ohne dass es jemand merkt. Die Rechenleistung wäre vorhanden, der Scheduler hätte Platz, aber die Identitätsvergabe zieht die Notbremse. Wer GKE Dataplane V2 für große KI-Agenten-Workloads plant, sollte diese Grenze kennen, bevor sie im Lasttest auftaucht.
Zwei Hebel: Labels migrieren, hochkardinale Felder herausfiltern
Googles Antwort besteht aus zwei Maßnahmen. Die erste ist eine saubere Trennung von identifizierenden und funktionalen Metadaten. Alles, was nicht aktiv für Service-Selektoren oder die Gruppierung von Ressourcen gebraucht wird, gehört nicht in die Labels eines Pods, sondern in die Annotations. Der Grund: Die Dataplane berechnet Netzwerkidentitäten aus Labels, nicht aus Annotations. Wandert die hochkardinale Information in die Annotations, entfällt die individuelle Identitätserzeugung pro Pod, ohne dass Sichtbarkeit verloren geht.
Die zweite Maßnahme ist ein Filter auf Ebene der Cilium-Konfiguration. Über eine ConfigMap in kube-system lassen sich Ausschlussregeln definieren, etwa Muster wie !agents.x-k8s.io/sandbox-name-hash oder ein Muster auf Zeitstempel. Solche Regeln weisen die Dataplane an, diese Labels bei der Berechnung der Sicherheitsidentität zu ignorieren. Selbst wenn ein Framework versehentlich hochkardinale Labels einführt, greift der Filter. Gleichartige Agenten teilen sich dann wieder eine einzige Cilium-Pod-Identität, und die Startzeit bleibt kurz.
Das ist weniger eine neue Funktion als eine Disziplin, die die Plattform erzwingbar macht. Die eBPF-Netzwerkrichtlinien für Pods bleiben unverändert wirksam – es ändert sich nur, woraus die Identität berechnet wird. Netzwerksicherheit und hohe Pod-Fluktuation sind also kein Widerspruch.
Was die Architektur in Zahlen liefert
Der Beitrag nennt konkrete Werte. Vollständig isolierte Agenten starten demnach mit 300 Sandboxes pro Sekunde bei Subsekunden-Latenz, ohne dass die Identitätszahl linear mitwächst. Ein namentlich nicht genannter Kunde betreibt laut dem Text über Agent Substrate auf GKE Hunderttausende sicherer Umgebungen über mehrere Cluster hinweg und fängt Spitzen von mehr als 30.000 Sandboxes auf einem einzelnen Cluster ab. In einer Benchmark mit 200.000 Agenten hielt das System 500 Aktivierungen pro Sekunde durch, bei weniger als 500 Millisekunden für Suspend und Resume.
Auffällig ist die Reihenfolge: erst das Identitätsproblem, dann die Skalierung der Sitzungen. Agent Substrate umgeht zusätzlich die Grenzen des Kubernetes-Schedulings und setzt auf den vorhandenen Clustern auf. Für den Betrieb heißt das: Netzwerkidentitäten lassen sich in Kubernetes skalieren, ohne dass gleich eine neue Plattform her muss.
Was das für den Betrieb bedeutet
Für Teams, die bereits GKE nutzen, ist der Aufwand überschaubar, aber nicht null. Zuerst prüfen: Welche Labels setzen die eigenen Controller und Frameworks tatsächlich? Sehr oft sind es mehr, als der Anwendungsfall verlangt: eine Request-ID, ein Erstellungszeitpunkt, ein Hash. Fürs Debugging ist das nützlich, für die Identitätsberechnung schädlich. Die Migration in Annotations ist ein mechanischer Schritt, verlangt aber Sorgfalt, weil Selektoren und Gruppierungen weiterhin auf Labels angewiesen sind.
Der zweite Schritt ist der Filter. Er ist die Versicherung gegen den Fall, dass ein Framework später wieder hochkardinale Labels einführt – ein realistisches Szenario, sobald mehrere Teams dieselbe Plattform bespielen. In hochdichten AI-Agenten-Umgebungen gehört diese Regel in die Standardkonfiguration und nicht in eine Notiz. Wer Agenten-Workloads mit Reinforcement-Learning-Schleifen fährt, merkt den Unterschied an den Leerlaufzeiten der Beschleuniger.
Nutzen und Aufwand
Der Beitrag beschreibt keine neue Produktkategorie, sondern die Korrektur einer Stelle, an der Skalierung meist unbemerkt endet: bei der Frage, wie viele Identitäten sich ein Cluster leisten kann. Die Lösung ist bewusst langweilig – Daten dorthin verschieben, wo sie nicht stören, und den Rest filtern. Das macht sie belastbar. Die Identitätsgrenze bleibt bestehen, nur wird sie nicht mehr pro Pod verbraucht.
Bevor du über weitere Knoten oder größere Maschinen nachdenkst, lohnt ein Blick auf die Labels deiner Sandboxes. Häufig steckt dort der eigentliche Engpass, und er lässt sich mit Konfiguration statt mit Hardware auflösen. Das senkt die Kosten und verkürzt die Startzeiten.
Quelle: cloud.google.com
