NVIDIA moves OpenShell to CNCF and previews new AI infrastructure
NVIDIA is moving OpenShell into the Cloud Native Computing Foundation and expanding its open infrastructure for running AI agents on Kubernetes. The November 10 announcement also introduces public previews of NVIDIA Kubernetes Engine and Kubernetes Recipes, alongside Snapshot, a tool for restoring initialized GPU workloads.
The practical value depends on which problem a team needs to solve: controlling an agent’s access, preserving its working environment, operating Kubernetes clusters or reducing model startup time. These components address different layers. Their availability also comes with limits, including explicit warnings against production use for the new cluster tools.
OpenShell moves to community governance
OpenShell’s new GitHub organization confirms that the CNCF transition is underway. Development is still moving, so contributors are directed to the existing NVIDIA repository for code, issues and pull requests. Operators should follow those instructions rather than assuming that every project component has already changed location.
The OpenShell repository describes policy enforcement around files, system calls and network connections, with isolated agent sandboxes and checks on policy changes. Its default sandbox is a minimal Ubuntu environment without an agent installed. That distinction matters: deploying the runtime does not automatically configure the agent, its tools or the permissions appropriate for a particular job.
Community governance creates a route for broader contributions and review. It does not, by itself, demonstrate that an installation is secure. The policies and surrounding deployment still determine what an agent can reach.
Agent Substrate keeps environments between turns
Agent Substrate, led by Google, tackles a separate resource problem. NVIDIA’s technical explanation describes a pool of warm Kubernetes workers that can serve many agent sessions. An idle session’s memory and filesystem are checkpointed, allowing its worker to serve another session. When work resumes, the stored environment can return on a free worker.
That design targets the gaps between useful actions, such as a coding assistant waiting for another prompt or a model response. Kubernetes scheduling and resource policies still apply to the worker pods. The proposal changes how sessions share those workers, rather than removing Kubernetes from the deployment.
GPU support needs careful reading. NVIDIA describes device support as work in progress and GPU state restoration as a proposed design. Matching hardware, and sometimes matching drivers, can constrain restoration. Teams should not read the announcement as confirmation that arbitrary GPU sessions can already pause and resume across any available machine.
NVKE operates clusters, NVKR builds their artifacts
NVIDIA Kubernetes Engine provides a management plane for operating separate workload clusters on GPU infrastructure. In preview, NVIDIA Infra Controller is its only compatible infrastructure provider. The repository explicitly advises against production workloads and warns that APIs, configuration and behavior can change.
The setup also requires deliberate security configuration. NVKE’s documentation says its API initially uses plain HTTP with authentication off. Operators must configure authentication and protected access before admitting callers. The management plane currently lacks an upgrade or backup and restore procedure. Those are meaningful evaluation constraints for anyone considering an operational deployment.
NVIDIA Kubernetes Recipes handles the build and release side: pinned inputs, component catalogs and definitions for artifacts such as images and Helm charts. Its local quickstart builds selected outputs without publishing or deploying them, and those local outputs are unsigned. Hosted workflows can produce signed releases with verification evidence. A valid signature establishes a specific claim about an artifact; it does not establish that the software is ready for production. NVKR is also a preview that is not recommended for production use.
Snapshot cuts startup work, with compatibility limits
NVIDIA Snapshot captures an initialized GPU pod, including CPU and GPU memory, and restores it on a compatible node. The aim is to avoid repeatedly loading model weights and warming up execution. Systems that manage the wider deployment still decide which workloads to checkpoint and when to restore them.
The current implementation requires matching GPU hardware and driver versions. Workloads must fit on one node, even when using multiple GPUs, and vGPU is unsupported. Installation includes a privileged node agent. The repository cautions against critical production workloads while APIs can still change.
NVIDIA reports that design partner Crusoe reduced GLM-5.3 readiness time from roughly eight minutes to 31 seconds on its tested setup. That is a partner result, not a general speed guarantee. ByteForward has not independently tested these tools.
Start with the deployment boundary
For existing agent users, this announcement should prompt a targeted evaluation rather than a blanket upgrade. ByteForward’s NemoClaw vLLM upgrade coverage explains why updating a CLI, rebuilding a sandbox and recreating a model server can affect different parts of an installation. Apply that same discipline here: identify the component you need, read its current limitations and test the exact workload before relying on it.
Featured image: AI generated conceptual illustration by ByteForward. It identifies NVIDIA OpenShell without depicting actual products or implying NVIDIA endorsement.
