OpenClaw on Kubernetes: agent-sandbox and gVisor

This tutorial explains how Kubernetes agent-sandbox manages an AI agent session and how a separate runtime supplies its isolation boundary. The speaker walks through SandboxTemplate, Sandbox, SandboxWarmPool and SandboxClaim, then demonstrates OpenClaw with a self-hosted model through its browser interface.

Warm pools keep pods running ahead of requests, trading idle hardware use for faster session starts. Persistent volume claims retain workspace files when a pod is recreated. The speaker describes full filesystem and memory snapshots as platform-dependent, with the demonstrated support limited to GKE and the Python SDK.

The runtime comparison covers gVisor's userspace kernel and Kata Containers' lightweight virtual machines with a guest Linux kernel. It weighs syscall compatibility, memory and startup overhead, and deployment requirements. The gVisor installation shown requires control over node runtime configuration; Kata requires hardware virtualization, including nested virtualization when needed on cloud VMs.

The observability section separates controller metrics and logs from SDK tracing. Two configuration problems receive particular attention: claim-specific environment settings can bypass a warm pool, and missing memory limits can make a gVisor sandbox report the host's available memory. The speaker recommends collecting controller logs and resource usage alongside the fleet gauge.