Ray Sandboxes with gVisor on GKE: Deployment Guide

Quick answer

Ray 2.58 introduced ray.experimental.sandbox, an alpha library that schedules OCI-image environments as Ray Actors and uses gVisor runsc as the initial isolation backend. Ray’s Kubernetes guide shows this running inside KubeRay worker Pods on standard Linux GKE node pools.

Do not treat the example as a production recipe. Pin versions, build and verify the worker image, bound network and capabilities, validate denial and cleanup behavior, and keep an exit path because the API can change or disappear before stability.

Current requirements

Layer	Current documented requirement	Evidence to add
Ray	2.58.0 or later with ray.experimental.sandbox	Exact pinned version, change review, and migration test
Worker OS	Linux x86_64 or arm64	Approved node image, patch path, and architecture test
gVisor	runsc available on every sandbox-capable Ray node’s PATH	Verified binary source, digest, signature, version, and startup test
Kubernetes	KubeRay-managed Ray cluster; GKE is the documented example	Operator version, namespace, service accounts, policies, quotas, and rollback
Images	OCI-compatible sandbox and Ray worker images	Registry, digest pin, scan, provenance, pull policy, cache, and revocation

The library name and backend are experimental. Re-read the release and API documentation before each upgrade.

Deployment sequence

1. Create or select a non-production GKE cluster and standard Linux node pool with approved network, identity, logging, and policy controls.
2. Install a pinned KubeRay operator through the supported path and restrict its service account.
3. Build a Ray worker image from an exact Ray version and pre-install the verified runsc binary.
4. Configure the RayCluster so sandbox-capable workers expose only the required security context and resources.
5. Submit a bounded Ray job that creates one sandbox from a digest-pinned OCI image, runs a known command, captures its result, and deletes the sandbox.
6. Test default-denied network, read-only root, working-directory writes, CPU and memory exhaustion, command timeout, node loss, actor loss, and cleanup.
7. Add autoscaling and concurrency only after single-sandbox resource and isolation evidence passes.

Ray’s example downloads runsc when a Pod starts. The guide recommends pre-baking it into a custom worker image for production so worker startup does not depend on a live external download.

GKE does not close the security design

gVisor adds a user-space application kernel between the sandboxed process and the host Linux kernel. That is stronger isolation than executing untrusted code directly in a standard container that shares the host kernel, but it is not authorization, a vulnerability guarantee, or a complete multi-tenant design.

Review:

• GKE project, cluster, node, Pod, and workload identity;
• registry and image supply chain;
• Ray head and worker exposure;
• Kubernetes and cloud network policy;
• secrets, metadata services, internal endpoints, and egress;
• host mounts, Linux capabilities, writable paths, and resource quotas;
• sandbox logs, Ray events, node telemetry, alerts, and incident access.

Use the Ray Sandbox isolation comparison to choose controls beyond gVisor.

Pilot acceptance test

Run known benign and adversarial cases:

• expected stdout, stderr, exit code, duration, and file output;
• denied egress under the default network="none" mode;
• denied write outside the configured working directory;
• CPU, memory, process, disk, and command-time limits;
• attempted host, metadata, internal DNS, and node-local access;
• malformed or malicious OCI image behavior;
• actor cancellation, worker restart, node drain, and cluster scale-down;
• complete sandbox, process, overlay, image-cache, and temporary-file cleanup.

Record the exact versions and configurations. Google Cloud and Ray report high scale and low startup overhead in their environments; those figures are vendor evidence, not your workload result.

For API and lifecycle details, use the Ray Sandbox Actor and OCI guide. Use the GKE readiness check before expanding the pilot.

Frequently asked questions

What is required to run Ray Sandboxes?

Current Ray documentation requires Ray 2.58.0 or later, Linux x86_64 or arm64 nodes, and the gVisor runsc binary on every Ray node that can run a sandbox.

Do Ray Sandboxes require GKE Sandbox node pools?

Ray’s KubeRay guide uses standard Linux GKE node pools with containerd because runsc executes inside Ray worker Pods in rootless user space. Verify the current guide and security context for your cluster.

Is ray.experimental.sandbox production-stable?

No. Ray labels the library alpha and warns that the API can change or disappear in any release before it becomes stable.

Should runsc be downloaded when each worker starts?

Ray’s example can install runsc at startup, but the documentation recommends pre-installing it in a custom worker image for production to remove a runtime download dependency and reduce startup failure and latency.

Official sources

• Google Cloud: gVisor sandboxes for Ray clusters on GKE
• Ray: Ray Sandboxes
• Ray: Deploy Ray Sandboxes with KubeRay
• Ray 2.58.0 release

Source check: August 27, 2026. Recheck alpha status, Ray and KubeRay versions, supported platforms, runsc installation, GKE configuration, security context, and examples.