Kubernetes vant container-tiåret. Nå bygger Google et eget kontrollplan for KI-agenter

Kubernetes ble bygget for å holde et fast sett langlevde tjenester i live. KI-agenter oppfører seg motsatt: en agent er en langvarig, tilstandsfull økt som sover det meste av livet, våkner for å kjøre en byks med kode, og blir stille igjen. Da Google gjorde GKE Agent Sandbox generelt tilgjengelig i mai 2026 og i samme innlegg introduserte Agent Substrate, innrømmet selskapet indirekte et poeng Kubernetes-veteraner har vegret seg for å si høyt: plattformen som vant container-tiåret er ikke rett kontrollplan for agenter. Det skriver The New Stack i en gjennomgang av de to prosjektene.

Sammenlign en agent med en prosess i et operativsystem i stedet for en tjeneste i et datasenter, så blir misforholdet tydelig. Et moderne OS kjører tusenvis av prosesser som sover mesteparten av tiden, vekker hver enkelt på en hendelse, gir den en skive CPU, og lagrer det inaktive minnet ut til disk. En kodeagent en utvikler lar stå åpen en ettermiddag kjører kanskje i ti sekunder når en prompt lander, så venter den tjue minutter på neste. Gang det med hver utvikler på et lag, og du har tusenvis av økter som lever på papiret og sover i praksis.

Problemet er at Kubernetes planlegger arbeid gjennom en sentral API-server designet for et beskjedent antall langlevde Pod-er. Agenter bryter antakelsen ved å generere en jevn strøm av finkornede planleggingshendelser. Å lagre hver agent, aktiv eller inaktiv, som et Kubernetes-objekt ville bety millioner av ressurser i et system som aldri var dimensjonert for det. Agent Substrate holder derfor de fleste agentene utenfor kontrollplanet og ruter forespørsler gjennom et eget nettverkslag som vekker riktig økt ved behov.

Agent Sandbox svarer på isolasjonsproblemet: et åpen kildekode-kjøremiljø bygget på Kubernetes som gir hver agent et herdet sted å kjøre modellgenerert kode. Mentalmodellen er et fengsel, ikke en container. Sandboxen når grensen gjennom gVisor som standard, legger på en default-deny-nettverkspolicy, og lar deg bytte inn Kata Containers for full kjerneisolasjon. Kunder som LangChain og Lovable kjører allerede millioner av agenter på det, og det var den belastningen som tvang fram ytelsesarbeidet.

Agent Substrate er kjøremiljøet som avgjør hvilken agent som kjører hvor. Trikset er virtuelt minne-overtegning brukt på compute: der et OS lar programmer adressere mer minne enn maskinen fysisk har ved å side kalde sider til disk, multiplekser Substrate et stort register av tilstandsfulle aktører på en langt mindre pool av forhåndsvarmede worker-Pod-er. To custom resources definerer oppsettet: en WorkerPool for den klare computen og en ActorTemplate for agentene. Substrate er rammeverk-agnostisk og kjører ADK, LangChain, Claude Code eller hvilken som helst OCI-container som en aktør.

For deg som bygger agent-infrastruktur er dette tre lag som gjør hver sin jobb, og de fleste reelle oppsett bruker alle tre samtidig:

1. Kjør uklarert, modellgenerert kode i Agent Sandbox, med gVisor og default-deny-nettverk som baseline.
2. Pakk millioner av mest sovende økter på begrenset maskinvare med Agent Substrate, mot litt høyere kaldstart-latens.
3. La Kubernetes provisjonere maskinene og de langlevde tjenestene under begge.

Solo.io har allerede koblet Substrate inn i kagent, sin Kubernetes-native agentplattform, slik at et agent-rammeverk kan planlegges som en aktør på en worker-pool fra ett grensesnitt. Det åpne spørsmålet er hvem som eier dette laget. Agent Substrate er et første utkast, ikke et ferdig produkt, og rivaliserende kjøremiljøer kommer etter hvert som kostnaden ved inaktive agenter blir en post platform-lag ikke lenger kan overse. Enten konsoliderer agent-kontrollplanet seg rundt ett åpent prosjekt, slik container-orkestrering til slutt samlet seg om Kubernetes, eller så sender hver hyperskalerer sitt eget og fragmenteringen agentene skulle unnslippe vender tilbake ett lag opp.