Initiatives to Re-Engineer Kubernetes for the Agentic AI Era Are Underway

TL;DR — Key Takeaways

– Long-running AI agents can leave dedicated Kubernetes pods idle between requests, tying up resources and increasing the number of objects the control plane must manage.

– Google’s Agent Substrate saves idle agents’ state and frees their workers for other tasks. Google says it can restore a session in under 500 milliseconds.

– Google’s gVisor and NVIDIA’s OpenShell address different security needs. gVisor isolates untrusted code, while OpenShell enforces policies on what AI agents can access and do.

A significant amount of re-engineering will be required before Kubernetes will be truly optimized for the agentic artificial intelligence (AI) era.

At the KubeCon + CloudNativeCon North America 2026 conference this week, issues ranging from how efficiently infrastructure is consumed by AI agents to the performance capabilities of the Kubernetes control plane were all raised.

Additionally, there is a clear need for additional primitives to secure AI agents running on servers that host Kubernetes clusters.

Work on some of these issues has begun, but it might be a year before those efforts fully manifest themselves in distributions of Kubernetes. Google, for example, contributed an open source Agent Substrate framework that makes it possible to run long-running agent workloads at scale on Kubernetes clusters more efficiently, to the Cloud Native Computing Foundation (CNCF). That Agent Substrate makes it possible to decouple stateful agent sessions and identities from active compute in a way that creates a snapshot of idle agents that is then stored and, when needed, restored in under 500 milliseconds to reduce costs by consuming infrastructure resources more efficiently.

Right now, every active agent is given its own pod, which locks up memory and CPU resources while the agent sits idle. As a consequence, the Kubernetes control plane needs to track millions of persistent objects it was not designed to manage.

At the same time, performance enhancements for the Kubernetes control plane are needed as well, noted Mickey Boxell, a senior principal product manager for cloud native services at Oracle. As the number of calls made by AI agents to the application programming interfaces (APIs) exposed exponentially increases, the overall performance of the Kubernetes control plane becomes a significant concern, he noted.

On the plus side, Kubernetes has proven to be extensible so the issue is solvable, added Alex Zenla, CTO for Edera, a provider of a hypervisor that has been optimized to securely run containers. In fact, the Kubernetes community has proven it is able to address fundamental architectural issues before when it became apparent there was a need to deploy stateful applications on a platform that was originally designed for stateless workloads.

The Kubernetes community is also working toward securing AI agents that are deployed on Kubernetes clusters. Google has also contributed gVisor, which isolates code inside a lightweight userspace application kernel that can be deployed as a container, to the CNCF that oversees the development of Kubernetes. NVIDIA this week also revealed it has contributed OpenShell, an open source runtime for securely deploying artificial intelligence (AI) agents to the CNCF.

It’s not clear how much time will be required before all these initiatives are incorporated into the Kubernetes clusters that are deployed by IT teams in a data center, but the need for them becomes increasingly pressing with each passing day. In fact, more than a few IT teams are already exploring alternatives. The one thing that is certain, however, is that the version of Kubernetes that is ultimately optimized for running agentic AI workloads is going to be very different from the instances that IT teams are running today.