Kies Kubernetes voor agents pas na een isolatie- en GPU-proef
Het directe antwoord: kies de kleinste aantoonbaar beheerbare route
Kies Kubernetes alleen als je voor één concrete agentworkflow kunt aantonen dat scheduling, GPU-serving, state, isolatie en fallback samen beheersbaar zijn. Dat is geen oordeel dat Kubernetes onveilig of ongeschikt is; de aangeleverde passages beoordelen Kubernetes, gVisor en specifieke netwerkpolicies niet. Ze geven wel twee relevante grenzen. Agentic workloads bestaan uit korte reasoning-action-lussen met externe calls en vereisen volgens AgentServe een balans tussen lage latency, stabiele tokenemissie en throughput bij meerdere agentverzoeken. Dezelfde passage beschrijft head-of-line blocking wanneer lange prefills en korte decodes op één GPU concurreren. Behandel bursty GPU-capaciteit dus als een te meten werkloadeigenschap, niet als een reden om een platform vooraf af te wijzen.
Isolatie is een aparte ontwerpbeslissing
De passage over Trusted AI Agents in the Cloud plaatst agents in een multiparty-ecosysteem waarin onbetrouwbare componenten kunnen leiden tot datalekken, manipulatie of onbedoeld gedrag. Zij stelt bovendien dat bestaande Confidential Virtual Machines slechts bescherming per binary bieden en geen garanties geven voor cross-principal trust, accelerator-isolatie of toezicht op agentgedrag. Daaruit volgt geen universeel voorschrift voor een sandbox of runtime, maar wel een praktische ontwerpregel: leg per uitvoerende agent vast welke code, data, tools, credentials en uitgaande bestemmingen zijn toegestaan. Persistent state hoort daarbij: bepaal welke gegevens na een run mogen blijven bestaan, wie ze kan lezen en wanneer ze worden verwijderd. Een toegestane externe bestemming blijft een expliciete route die je moet beoordelen; isolatie alleen beslist niet of een agentresultaat juist of gewenst is.
Gebruik één besliskaart vóór je uitbreidt
Maak voor een bestaande agentflow een besliskaart met vijf kolommen: werkloadpiek, uitvoergrens, state, toegestane externe acties en fallback. Meet onder een realistische piek de wachttijd en doorvoer; voer representatieve toolcalls uit in de beoogde isolatielaag; controleer welke state en credentials overblijven; en forceer een model-, tool- en netwerkfout om de fallback te verifiëren. Kies daarna pas tussen Kubernetes, een sterkere scheiding of een eenvoudiger beheerde route. De besliskaart maakt ook eigenaarschap zichtbaar: per kolom hoort één eigenaar en één acceptatiecriterium. Praktisch artefact: “Registreer per agentflow de GPU-piek, uitvoergrens, toegestane state, egress, fallbacktest, eigenaar en acceptatiecriterium.” Dit hulpmiddel is bedoeld voor deze infrastructuurkeuze en vervangt geen volledige securitybeoordeling. Beperking: “De aangeleverde passages vergelijken geen Kubernetes-runtimes, sandboxproducten, persistent-storagepatronen of fallbackimplementaties; die keuze vereist een eigen test in de beoogde omgeving.”
