OpenKruise Agents version 0.6.0 expands Kubernetes-based Agent Sandbox management with network policy enforcement, credential injection, paused-instance upgrades, warm-pool autoscaling and automatic pause and resume. The project, a sub-project of OpenKruise, is designed to manage the lifecycle of Agent Sandboxes at scale, including their networking, storage and identity.
The release adds a traffic-control data plane and makes traffic inspection, policy distribution and identity core parts of the system. Since version 0.3.0, the project has merged 283 pull requests and welcomed 27 new contributors, according to the release announcement.
Traffic policy and credential handling
Two new components support the network controls: traffic-control-plane distributes configuration, while traffic-proxy provides an in-pod enforcement point for outbound traffic. The existing sandbox-gateway handles ingress and egress traffic; an Egress Policy Enforcer applies request-level rules and credential transformations.
Enforcement is split between Layer 4 and Layer 7. The in-pod proxy can block traffic based on destination, while the gateway and policy engine inspect requests for more detailed decisions. TrafficPolicy supports peers identified by fully qualified domain name, CIDR, Kubernetes service or workload. Once a policy selects a Pod, traffic that does not match an allow rule is denied. The announcement also cautions that rules missing a peer field are skipped by the compiler, so an incorrectly formed rule may weaken the intended policy.
SecurityProfile and GlobalSecurityProfile provide request-level controls, including blocking and audit actions. For Model Context Protocol traffic, an MCP tool policy can restrict JSON-RPC tool calls by matching the requested tool name. The project also supports injecting API credentials from Kubernetes Secrets as requests leave the cluster. That approach keeps the upstream credential out of Sandbox specifications, environment variables and Agent code, and allows Secret rotation without restarting the Sandbox.
The project describes these controls as applying to gateway-routed traffic, not as a complete security boundary. It warns that containers running with root privileges or capabilities such as NET_ADMIN or SYS_ADMIN may bypass in-pod controls. It recommends combining the policies with Kubernetes NetworkPolicy, host firewalls or cloud security groups.
Upgrades and warm-pool capacity
SandboxUpdateOps adds support for including paused Sandboxes in batch upgrades. The new stateFilter can select both Running and Paused instances; the controller wakes a paused instance for its upgrade and pauses it again, leaving it paused when the operation completes. This lets operators update hibernating fleets without manually waking each instance.
The release also adds CheckpointRestore, which preserves a Sandbox’s writable root filesystem during an upgrade. Unlike the default Recreate mode, it can retain filesystem data, but does not preserve memory or the instance IP and does not support changing the business image. The project positions it as an option for updating components such as agent-runtime or traffic-proxy when retaining user data matters.
PoolAutoscaler provides declarative control of SandboxSet warm-pool replicas. Operators can set minimum and maximum replicas, target available capacity, stabilization windows and cron-based replica targets. The release example uses faster scale-up and slower scale-down windows, and scheduled policies can adjust capacity ahead of expected demand. The controller updates SandboxSet.spec.replicas.
Another cost-control option is in-place CPU and memory resizing when a SandboxClaim takes an instance from a warm pool. The announcement says this can let pools hold smaller instances and resize them for a task, while noting that this is slower than claiming an instance that already has the required resources. In-place resizing of a running Pod requires Kubernetes 1.33 or later; the SandboxInPlaceResourceResize feature gate is enabled by default, according to the project.
Automatic pause and resume
SandboxSet can now use probes and an autoPausePolicy to pause instances after a configured idle period, wake them on a schedule or resume them when traffic arrives. Probes are exec-based and report activity or a future activation time. The project says wake-on-traffic requires authentication: an unauthorized request returns 401 and does not wake the Sandbox. A successful wake may still accompany a failed request, such as a 503, so clients may need to check the Sandbox phase and retry. Failed or timed-out probes do not trigger a pause or wake.
OpenKruise Agents says future work will include exploring open-source checkpointing with the Kata community, on-demand mounting for open-source storage such as MinIO, and integration with identity systems such as Keycloak. Version 0.6.0 is available through the project’s GitHub releases and major image registries.
