人工智能分布式训练强化学习任务调度模型推理服务【免费下载链接】rayRay is an AI compute engine. Ray consists of a core distributed runtime and a set of AI Libraries for accelerating ML workloads.项目地址https://gitcode.com/gh_mirrors/ra/ray点击查看免费下载导读Ray Sandboxesray.experimental.sandbox是 Ray 提供的一套基于 gVisor 的轻量级内核隔离执行环境专为在 Ray 集群上安全运行不可信的模型生成代码与 Agent 工具调用而设计。本文以 sandboxes.md 为骨架结合 python/ray/experimental/sandbox 下的源码实现完整讲解环境要求、四个使用模式与代码示例、容器镜像管理、网络与 DNS 模型、架构分层、安全隔离模型与故障排查帮助你从零开始将沙箱能力接入 Agentic RL、LLM Agent 与自定义 RL 环境 Actor。::: {warning} Ray Sandboxesray.experimental.sandbox是一个 alpha 库API 在转正之前可能在任意版本中发生变化或消失。 :::背景为什么要为模型生成的代码加沙箱对智能体强化学习Agentic RL和 LLM Agent 而言沙箱化模型生成的代码能力至关重要。如果直接在 Ray worker 进程或宿主机环境中执行不可信代码会带来严重的安全与稳定性风险。Ray Sandboxes 的解法是使用 gVisorrunsc在 Ray worker 节点上直接运行轻量、内核隔离的沙箱并复用 Ray 已有的调度与资源管理原语来扩展和管理沙箱环境。什么是 gVisorgVisor 是一个用 Go 编写的开源应用内核为容器提供轻量级的纵深防御隔离。它由 Google 开发在用户态实现了 Linux 系统调用接口的绝大部分充当不可信应用与宿主操作系统内核之间的隔离屏障。与 Docker、runc等标准容器运行时不同这些运行时让容器直接共享宿主 Linux 内核gVisor 会在容器化进程的系统调用到达宿主之前将其拦截。gVisor 无守护进程、以非特权用户身份运行因此可以部署在 Kubernetes 等现有容器编排平台之上。为什么选择 gVisor缩小攻击面不可信代码与 gVisor 的用户态内核交互而非宿主 Linux 内核这大大缩小了宿主内核漏洞和容器逃逸container breakout漏洞的攻击面。无需特权gVisor 完全运行在用户态不需要宿主 root 权限、Docker 守护进程也不需要嵌套虚拟化硬件扩展因此可以直接运行在现有的 Kubernetes Ray worker Pod 和云容器环境中。成本低、密度高相比完整 VM 和 MicroVM需要引导客户机内核并管理沉重的磁盘镜像gVisor 沙箱在几十毫秒内即可启动内存开销极小、空闲 CPU 近乎为零。因此 Ray worker 节点可以在标准 Ray task/actor 旁边密集打包数百个并发沙箱支撑 RL rollout 和 Agent 工具调用所需的高频执行循环。环境要求每个运行沙箱的 Ray 节点都需要满足要求说明Linuxx86_64 或 arm64 架构gVisorrunsc在 worker 节点安装runsc二进制并确保其在系统$PATH中可被找到Ray版本 2.58.0 及以上包含ray.experimental.sandbox包slirp4netns仅networkpublicslirp4netns二进制在$PATH中且 worker 环境中有/dev/net/tun。slirp4netns 将每个沙箱的私有网络命名空间桥接到节点runsc的安装方法参考 gVisor 官方安装指南Debian/Ubuntu 可用apt-get install runsc也可下载预编译二进制放入/usr/local/bin/runsc。slirp4netns在 Debian、Ubuntu、Fedora 上作为软件包提供也有针对 x86_64 与 aarch64 的静态构建版本。使用模式与示例创建基础沙箱并执行命令使用sandbox.create()从任意容器镜像启动隔离环境函数返回一个代表沙箱 actor 的 RayActorHandleimport ray from ray.experimental import sandbox ray.init() # 创建一个拥有 1 个 CPU 核心与 512MiB 内存的沙箱 sb sandbox.create( imagepython:3.10-slim, cpu1.0, memory512Mi, workdir/workspace, timeout_seconds30.0, ) # 在沙箱内执行不可信 Python 代码 result ray.get( sb.exec.remote(python3 -c import sys; print(\Hello from sandboxed Python:\, sys.version)) ) print(fExit Code: {result.exit_code}) print(fStdout: {result.stdout.strip()}) print(fExecution Duration: {result.duration_ms:.2f} ms) # 清理沙箱资源 ray.get(sb.delete.remote())关键参数说明对应 sandbox.py 中create()的实现image沙箱使用的 OCI 容器镜像例如python:3.10-slim。cpu分配给沙箱的 CPU 核心数create()内部会将其转换为 Ray actor 的num_cpus调度选项。memory内存大小支持512Mi、1Gi、2GB等字符串格式由 config.py 中的parse_memory_bytes()解析为字节数并作为 Ray actor 的memory调度选项create()源码中actor_opts[memory] parsed_mem。workdir沙箱内的工作目录在只读 rootfs 下它同时也是沙箱唯一可写的路径宿主机回写的 scratch 空间。timeout_seconds沙箱创建超时时间默认 30.0 秒。ttl_seconds沙箱存活时间墙钟时间从创建起算而非空闲时间超时后由 runtime.py 中的守护线程定时器自动删除。执行结果ExecResult在 backend/base.py 中定义包含exit_code、stdout、stderr与duration_seconds另有duration_ms属性。读写、上传与下载文件可以把源文件直接写入沙箱也可以在执行前从宿主机上传本地文件。默认情况下根文件系统是只读的配置的workdir如/workspace是可写的临时空间import textwrap import ray from ray.experimental import sandbox ray.init() sb sandbox.create( imagepython:3.10-slim, workdir/workspace, memory1Gi, ) # 1. 将不可信的模型生成脚本写入沙箱 code textwrap.dedent(\ def fibonacci(n): a, b 0, 1 for _ in range(n): a, b b, a b return a with open(/workspace/output.txt, w) as f: f.write(ffib(30) {fibonacci(30)}) ) ray.get(sb.write_file.remote(/workspace/solution.py, code)) # 2. 在沙箱内执行脚本 exec_res ray.get(sb.exec.remote(python3 /workspace/solution.py)) print(Execution returncode:, exec_res.exit_code) # 3. 把生成的结果文件读回宿主机 output_bytes ray.get(sb.read_file.remote(/workspace/output.txt)) print(Result:, output_bytes.decode(utf-8)) # 4. 或者使用 upload_file / download_file 处理宿主机文件 # ray.get(sb.upload_file.remote(local_input.json, /workspace/input.json)) # ray.get(sb.download_file.remote(/workspace/output.txt, local_output.txt)) ray.get(sb.delete.remote())从源码看文件 I/O 由Sandboxactor 的方法转发到SandboxRuntimesandbox.pyupload_file以二进制读取本地文件再调用write_filedownload_file先read_file再在宿主机侧创建目标目录runtime.pywrite_file/read_file最终由 gVisor backend 通过runsc exec /bin/sh -c mkdir -p ... cat $1和runsc exec ... cat实现gvisor.py。使用自定义资源调度 Sandbox actor由于Sandbox就是标准的 Ray actor你可以直接用num_cpus、memory以及自定义加速器或放置约束等 Ray actor 调度选项来实例化它import ray from ray.experimental.sandbox import Sandbox ray.init() # 使用 Ray Core 资源放置选项实例化 Sandbox actor sandbox_actor Sandbox.options( num_cpus2.0, memory2 * 1024 * 1024 * 1024, # 2 GiB ).remote( imagepython:3.10-slim, workdir/workspace, ttl_seconds600, # 10 分钟后自动终止 ) # 执行带单条命令执行超时的命令 result ray.get( sandbox_actor.exec.remote( python3 -c import os; print(\Worker PID:\, os.getpid()), timeout5.0, # 5 秒执行超时 ) ) print(result.stdout) ray.get(sandbox_actor.delete.remote())值得注意的实现细节Sandbox.__init__会通过ray.get_runtime_context().get_assigned_resources()尝试读取 Ray 分配给该 actor 的资源sandbox.py当未显式传入cpu/memory时自动沿用调度配额——这意味着通过Sandbox.options()指定的资源会自动传导到 gVisor 的 cgroup 配额。exec.remote中的timeout参数在 backend 中通过proc.communicate(timeouttimeout)强制执行超时抛 SandboxTimeoutErrorgvisor.py。在自定义 actor 中用 SandboxRuntime 管理沙箱池如果你正在构建自定义 RL 环境 actor 或专门的 rollout worker可以把SandboxRuntime直接嵌入自定义 actor以获得细粒度的沙箱生命周期控制import ray from ray.experimental.sandbox.runtime import SandboxRuntime ray.remote class SandboxPool: def __init__(self, size: int 3, image: str python:3.10-slim): self.runtime SandboxRuntime() self.sandboxes [ self.runtime.create(imageimage, memory512Mi) for _ in range(size) ] def run_command(self, index: int, command: str): return self.runtime.exec(self.sandboxes[index], command) def close(self): for sb_id in self.sandboxes: self.runtime.delete(sb_id) # 部署一个管理本地沙箱池的 actor pool SandboxPool.remote(size3) result ray.get(pool.run_command.remote(0, python3 -c print(\Hello from pool!\))) print(result.stdout) ray.get(pool.close.remote())从 runtime.py 的实现看SandboxRuntime.create()返回唯一的实例 ID格式为ray-sandbox-uuid见 gvisor.py内部先经ImageManager.pull_image()拉取镜像再调用GVisorSandboxBackend.create_sandbox()启动容器并轮询runsc state直到进入running状态。exec对应同步exec_command另有异步版本exec_async基于asyncio.to_thread。向 gVisor 传递自定义 OCI 配置对高级负载你可能需要配置低层运行时选项如自定义宿主挂载、Linux capabilities、自定义网络与 DNS 设置。使用_oci_spec_transform_fn参数在 Ray 将生成的 OCI 运行时规范 字典传给 gVisorrunsc之前检查并修改它。::: note_oci_spec_transform_fn是面向高级用例的实验性钩子。Ray 项目正在为 Ray Sandboxes 设计一等公民的配置 API如更高级的卷挂载与 capability 抽象该钩子在这些 API 落地后很可能会变化。如果希望参与推动欢迎提 issue 描述你的使用场景。 :::_oci_spec_transform_fn可调用对象接收完整生成的 OCI 规范字典可以在原地修改也可以返回一个修改后的字典。常见用途包括宿主挂载Host mounts把宿主目录、只读数据集或模型权重挂载进沙箱容器。命名空间与挂载细节配置一等公民选项未覆盖的命名空间或挂载行为。互联网访问、DNS 和 Linux capabilities 各有一等公民选项network、dns和capabilities。传capabilities[]表示完全不带任何 capability。请把该钩子保留给这些选项覆盖不到的网络或 capability 配置。参见 网络与 DNS 一节。import ray from ray.experimental import sandbox ray.init() def configure_oci_spec(spec: dict) - dict: # 添加宿主 bind mount例如只读数据集或缓存目录 spec.setdefault(mounts, []).append( { destination: /mnt/dataset, source: /path/to/host/dataset, type: bind, options: [rbind, ro], } ) return spec # 创建沙箱时传入转换钩子 sb sandbox.create( imagepython:3.10-slim, workdir/workspace, _oci_spec_transform_fnconfigure_oci_spec, ) # 在定制沙箱内执行命令 result ray.get( sb.exec.remote( python3 -c print(\Sandbox initialized with custom OCI configuration!\) ) ) print(result.stdout) # 清理资源 ray.get(sb.delete.remote())从源码看该钩子的作用点在 image_manager.pycreate_oci_spec()在生成完整 spec含 rootfs、env、capabilities、mounts、cgroup 资源限制之后调用_oci_spec_transform_fn(spec)若返回非 None 字典则以其作为最终 spec。转换函数需要能被 cloudpickle 序列化因为会随 Ray actor 分发。注意 OCI spec 的基础由runsc spec命令生成image_manager.py 的get_default_oci_spec()。容器镜像沙箱从 OCI 容器镜像启动。镜像管理器直接从 registry 的 HTTP API 拉取镜像匿名方式无 Docker daemon、无凭据把根文件系统解压到节点上的/tmp/ray/sandbox/images并按镜像缓存供该节点上使用相同镜像的后续沙箱复用。对文件系统有写权限的沙箱会在缓存的根文件系统之上获得自己独立的可写 overlay。限制镜像缓存缓存是有界的这样运行大量不同镜像的节点不会把磁盘塞满。每次拉取前Ray 会逐出最近最少解压LRU的镜像直到缓存小于上限。正在被沙箱使用的镜像永远不会被逐出。默认上限是缓存所在文件系统的二分之一。在 worker 节点上设置RAY_SANDBOX_IMAGE_CACHE_MAX_BYTES可自定义上限字节数设为0则禁用逐出。从源码看该逻辑位于 image_utils.pyRAY_SANDBOX_IMAGE_CACHE_MAX_BYTES环境变量控制缓存上限pull_image()传入instance_id时镜像会被钉住pinned直到同实例调用release_image()才可被逐出——这正是“运行中沙箱使用的镜像永不逐出”的实现机制见 image_manager.py 与 gvisor.py 中删除沙箱后释放镜像的调用。通过镜像代理Mirror路由 Docker Hub 拉取由于镜像拉取是匿名的每个从 Docker Hub 拉取的节点都会消耗匿名拉取速率限制并通过公网下载镜像。在大集群中并发拉取数 GB 的镜像很容易撞上速率限制或打满网络带宽导致镜像拉取失败或变慢。设置RAY_SANDBOX_REGISTRY_MIRROR将 Docker Hub 拉取路由到 registry mirror。Ray 只改写 Docker Hub 的镜像引用来自其他 registry如 GHCR 或私有 registry的拉取保持不变。取值格式为host[:port][/repo-prefix]。Ray 会把仓库前缀拼接到仓库路径前这正是 pull-through 缓存所期望的形式Mirror示例值python:3.10-slim解析为ECR pull-through 缓存acct.dkr.ecr.region.amazonaws.com/dockerhubacct.dkr.ecr.region.amazonaws.com/dockerhub/library/pythonArtifact Registry remote repositoryregion-docker.pkg.dev/project/reporegion-docker.pkg.dev/project/repo/library/python集群内registry:2代理http://registry.default.svc.cluster.local:5000http://registry.default.svc.cluster.local:5000/library/python需要注意裸主机名意味着 HTTPS。明文 HTTP 的 mirror 要显式写http://前缀集群内registry:2代理通常就是这种情况。Mirror 是权威的。与 Docker 的 registry-mirrors 行为不同Ray 不会回退到 Docker Hub。如果 mirror 不可达或不包含该镜像拉取就会失败。Mirror 必须允许匿名拉取。Ray 与 mirror 的交互方式与任何 registry 相同走同样的匿名 bearer-token 流程。如果你的 mirror 通常要求认证请通过网络层访问如 VPC endpoint 或集群内服务将其暴露给 Ray。网络与 DNS沙箱支持四种网络模式。默认是none遵循安全默认原则。需要联网时使用public。模式网络访问/etc/resolv.conf安全属性none(默认)无保持不变无出站流量。这是不可信代码的推荐设置。public从沙箱私有的网络命名空间出网由 slirp4netns 桥接由dns生成默认8.8.8.8、1.1.1.1只读挂载端口和回环地址都是每沙箱私有的在0.0.0.0上绑定不会与其它沙箱或节点本地服务冲突、被它们访问或访问它们节点或集群也没有入站通路。沙箱不继承宿主解析器配置的任何内容。沙箱仍可到达节点可到达的任何网络地址包括其它 Ray 节点和内部服务。沙箱自身地址是198.18.0.100RFC 2544 基准测试网段选择它是为了不与 Pod 或 service 网段重叠。要求节点上安装 slirp4netns。host完整宿主网络身份宿主自己的文件只读挂载dns可覆盖严格比public更宽松。沙箱可到达节点可到达的任何内容包括内部网络和节点本地服务。sandboxgVisor netstack保持不变要求rootlessFalse。runsc 在 rootless 模式下不支持 sandbox netstack。::: warningpublic把沙箱之间、以及沙箱与节点自身服务之间隔离开但并不能与节点所在的网络隔离。slirp4netns 会通过节点中继每一个出站连接因此public沙箱可以到达其它 Ray 节点包括 head 节点的 GCS 和 dashboard 端口、其它 Kubernetes Pod 以及节点可达的任何内部服务。不可信代码请使用networknone。 :::要给沙箱联网使用networkpublic并搭配DOCKER_DEFAULT_CAPABILITIES这样标准镜像的行为与 Docker 下一致——因为apt-get、tar的所有权恢复等操作都需要这些 capabilitiesfrom ray.experimental import sandbox from ray.experimental.sandbox import DOCKER_DEFAULT_CAPABILITIES sb sandbox.create( imagepython:3.10-slim, networkpublic, capabilitiesDOCKER_DEFAULT_CAPABILITIES, readonlyFalse, )关于DOCKER_DEFAULT_CAPABILITIES它定义于 config.py包含 14 个 cap如CAP_CHOWN、CAP_SETUID、CAP_SETGID、CAP_DAC_OVERRIDE、CAP_NET_BIND_SERVICE等与 Docker 默认集一致。原因在源码注释中写得很清楚runsc spec发出的运行时默认能力集比 Docker 窄得多会弄坏常见镜像——apt-get需要CAP_SETUID/CAP_SETGIDtar以 root 恢复所有权需要CAP_CHOWN。锁定网络中的 DNS某些 VPC 会阻止到公共解析器的出站 53 端口此时public的默认 DNS 设置无法解析查询。改用networkpublic, dns[10.0.0.2]传入你的内部解析器。如果不可行退而使用networkhost使用宿主的/etc/resolv.conf代价是获得完整的宿主网络身份。更复杂的配置通过 OCI spec 完成参见 向 gVisor 传递自定义 OCI 配置。从实现看dns参数只对public/host模式有效其它模式传入会被SandboxConfig.__post_init__直接拒绝config.pypublic模式在 image_manager.py 中生成一份宿主机无关的resolv.conf默认写入8.8.8.8、1.1.1.1不泄漏宿主的 search domains、resolver VIP 或 ndots 选项并只读挂载进容器。架构Ray Sandboxes 子系统包含以下层次------------------------------------------------------------------- | Ray Application / RL Framework | | (e.g., veRL, SkyRL, RL Rollout Workers, Agents) | ------------------------------------------------------------------- | v ------------------------------------------------------------------- | ray.experimental.sandbox | | (High-level create() API Sandbox Ray Actor) | ------------------------------------------------------------------- | v ------------------------------------------------------------------- | ray.experimental.sandbox.runtime | | SandboxRuntime Interface | ------------------------------------------------------------------- | v ------------------------------------------------------------------- | ray.experimental.sandbox.backend | | GVisorSandboxBackend (runsc OCI) | ------------------------------------------------------------------- | v ------------------------------------------------------------------- | Ray Worker Node | | ----------------------- ----------------------- | | | gVisor Sandbox 1 | | gVisor Sandbox 2 | | | | (python:3.10-slim) | | (busybox:latest) | | | | CPU: 0.5, Mem: 256M | | CPU: 1.0, Mem: 512M | | | ----------------------- ----------------------- | -------------------------------------------------------------------核心组件高层辅助函数ray.experimental.sandbox.create创建一个封装沙箱生命周期的 Ray actor 并返回ActorHandle。沙箱 actorray.experimental.sandbox.Sandbox一个 Ray actor作为代理把命令执行与文件 I/O 转发给隔离的沙箱实例同时管理沙箱的调度与生命周期含__del__兜底清理。沙箱运行时ray.experimental.sandbox.SandboxRuntime管理本地沙箱生命周期、镜像拉取与缓存、以及与执行后端交互的低层抽象。gVisor 后端ray.experimental.sandbox.backend.GVisorSandboxBackend通过 gVisor 的 OCI 运行时runsc执行命令并隔离进程。每个沙箱对应一个常驻 runsc 容器实例runsc状态目录固定为/tmp/runsc沙箱目录在/tmp/ray/sandbox/下gvisor.py。镜像管理器ray.experimental.sandbox.image_manager.ImageManager自动从 Docker Hub、GHCR 或本地 tar 归档拉取容器镜像把根文件系统解压到/tmp/ray/sandbox/images并构建 OCIconfig.json运行时规范。安全与隔离模型Ray Sandboxes 实现多层纵深防御隔离系统调用拦截gVisor 的 Sentry 应用内核在用户态拦截系统调用把不可信代码与宿主 Linux 内核隔离开。只读根文件系统Ray 以只读方式挂载基础容器文件系统readonlyTrue每个沙箱有独立的写时复制copy-on-writeoverlay 目录。当readonlyFalse时整个 rootfs 通过 per-sandbox overlay 可写但镜像内容保持可见、沙箱互不干扰、基础镜像永不被修改config.py。受限工作目录只有显式的workdir如/workspace被以读写方式挂载用于放置应用产物。需要注意显式传workdir才会被挂载为只读 rootfs 上唯一的可写路径继承的镜像 WORKDIR 永远不会被静默设置为可写gvisor.py 中还有路径穿越检查。网络隔离默认networknone关闭所有出站网络接口防止不可信代码发起外部 API 调用或扫描内部集群网络。需要联网时networkpublic提供出站能力但绝不交出宿主的解析器配置或网络身份。资源配额cgroups 强制执行 CPU 配额与内存限制防止 CPU 饥饿与 OOM 影响其它 Ray actor。在 image_manager.py 中CPU 通过cpu.period100000、cpu.quotaint(cpu*100000)写入 OCI spec内存通过parse_memory_bytes()解析后写入memory.limit。public模式还有一个值得了解的隔离细节源码注释见 gvisor.py每个沙箱通过unshare --user --map-root-user --net持有私有 usernetwork 命名空间slirp4netns 从 Pod 侧挂入 tap 并做 NATslirp4netns 的标志固定为--cidr198.18.0.0/24 --mtu65520 --disable-host-loopback --disable-dns --enable-seccomp其中选择 RFC 2544 的198.18.0.0/24网段正是为了避免与 Pod/service CIDR 重叠导致本应 NAT 的流量变成 on-link 直连。API 参考详细的函数签名、参数与返回类型见 API 文档ray-sandbox-ref涵盖生命周期与执行ray.experimental.sandbox.create、Sandbox、SandboxRuntime数据结构与状态ExecResult、SandboxStatus异常SandboxError、SandboxCreationError、SandboxTimeoutError、SandboxExecError、SandboxNotFoundError故障排查runsc不在$PATH中确认 gVisor 的runsc二进制已安装到所有 Ray worker 节点且位于系统$PATH中的目录如/usr/local/bin/runsc。backend 在创建沙箱时会先检查shutil.which(runsc)找不到直接抛SandboxCreationErrorgvisor.py。cgroup 或权限错误在无 root 权限的容器化环境如 Kubernetes中保持默认的rootlessTrue。在 cgroup 受限的环境设置RAY_SANDBOX_IGNORE_CGROUPS1backend 的_runsc_base_args会据此附加--ignore-cgroups见 gvisor.py。节点磁盘被镜像占满镜像缓存默认上限为所在文件系统的一半。在 worker 节点上用RAY_SANDBOX_IMAGE_CACHE_MAX_BYTES字节调低上限或把缓存挪到更大的卷。运行中沙箱使用的镜像不会被逐出所以大量并发沙箱使用不同的大镜像时仍需要相应的磁盘空间。镜像拉取失败确认节点能访问容器 registry如 Docker Hub 或 GHCR或预填充/tmp/ray/sandbox/images缓存目录。多个节点同时拉取大镜像时Docker Hub 的匿名速率限制是常见原因参见 通过镜像代理路由 Docker Hub 拉取。networkpublic时找不到slirp4netns在 worker 节点安装 slirp4netns 软件包或其静态构建版本。backend 会同时检查slirp4netns与nsenter两个二进制gvisor.py。public沙箱启动报 tap 或命名空间错误slirp4netns 需要 worker 环境中有/dev/net/tun且 seccomp 策略允许非特权 usernetwork 命名空间创建unshare -Un true必须以 Ray 用户身份成功执行。slirp4netns 的报错会出现在沙箱的runsc.stderr.log以及创建错误信息中。下一步参考 KubeRay 的 sandboxing 文档kuberay-sandboxing在 Kubernetes 上用 KubeRay 部署 Ray Sandboxes。深入学习 gVisor 官方文档。探索资源隔离resource-isolation指南把 Ray 系统进程与 worker 进程隔离开。以上内容的配套实现与测试位于仓库的 python/ray/experimental/sandbox 目录含sandbox.py、runtime.py、backend/gvisor.py、image_manager.py、config.py与tests/下的单元测试以及 src/ray 的 C/protobuf 底层文档正文对应 doc/source/ray-core/sandboxes.md。赞分享人工智能分布式训练强化学习任务调度模型推理服务【免费下载链接】rayRay is an AI compute engine. Ray consists of a core distributed runtime and a set of AI Libraries for accelerating ML workloads.项目地址https://gitcode.com/gh_mirrors/ra/ray点击查看免费下载相关推荐Ray Sandbox API 详解基于 gVisor 在 Ray 集群中安全执行不可信代码Ray Sandbox API 详解基于 gVisor 在 Ray 集群中安全执行不可信代码 Ray Sandboxes 是 Ray 提供的一套 alpha人工智能分布式训练强化学习任务调度模型推理服务使用 Ray Cluster Launcher 在 GCP 上启动 Ray 集群的完整指南使用 Ray Cluster Launcher 在 GCP 上启动 Ray 集群的完整指南 本指南讲解如何借助 Ray 自带的集群启动器Cluster Lau人工智能分布式训练强化学习任务调度模型推理服务Hydra Ray Launcher 插件实战指南用 ray 与 ray_aws 在本地集群和 AWS EC2 上并行执行 Sweep 任务Hydra Ray Launcher 插件实战指南用 ray 与 ray_aws 在本地集群和 AWS EC2 上并行执行 Sweep 任务 Hydra 的开发工具后端CLI上一篇平衡车主板改造全攻略hoverboard-firmware-hack-FOC固件上手指南下一篇GraphQL Editor嵌入式编辑器如何在React应用中快速集成创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Ray Sandboxes 完整实战指南：用 gVisor 在 Ray 集群上安全执行不可信代码
人工智能分布式训练强化学习任务调度模型推理服务【免费下载链接】rayRay is an AI compute engine. Ray consists of a core distributed runtime and a set of AI Libraries for accelerating ML workloads.项目地址https://gitcode.com/gh_mirrors/ra/ray点击查看免费下载导读Ray Sandboxesray.experimental.sandbox是 Ray 提供的一套基于 gVisor 的轻量级内核隔离执行环境专为在 Ray 集群上安全运行不可信的模型生成代码与 Agent 工具调用而设计。本文以 sandboxes.md 为骨架结合 python/ray/experimental/sandbox 下的源码实现完整讲解环境要求、四个使用模式与代码示例、容器镜像管理、网络与 DNS 模型、架构分层、安全隔离模型与故障排查帮助你从零开始将沙箱能力接入 Agentic RL、LLM Agent 与自定义 RL 环境 Actor。::: {warning} Ray Sandboxesray.experimental.sandbox是一个 alpha 库API 在转正之前可能在任意版本中发生变化或消失。 :::背景为什么要为模型生成的代码加沙箱对智能体强化学习Agentic RL和 LLM Agent 而言沙箱化模型生成的代码能力至关重要。如果直接在 Ray worker 进程或宿主机环境中执行不可信代码会带来严重的安全与稳定性风险。Ray Sandboxes 的解法是使用 gVisorrunsc在 Ray worker 节点上直接运行轻量、内核隔离的沙箱并复用 Ray 已有的调度与资源管理原语来扩展和管理沙箱环境。什么是 gVisorgVisor 是一个用 Go 编写的开源应用内核为容器提供轻量级的纵深防御隔离。它由 Google 开发在用户态实现了 Linux 系统调用接口的绝大部分充当不可信应用与宿主操作系统内核之间的隔离屏障。与 Docker、runc等标准容器运行时不同这些运行时让容器直接共享宿主 Linux 内核gVisor 会在容器化进程的系统调用到达宿主之前将其拦截。gVisor 无守护进程、以非特权用户身份运行因此可以部署在 Kubernetes 等现有容器编排平台之上。为什么选择 gVisor缩小攻击面不可信代码与 gVisor 的用户态内核交互而非宿主 Linux 内核这大大缩小了宿主内核漏洞和容器逃逸container breakout漏洞的攻击面。无需特权gVisor 完全运行在用户态不需要宿主 root 权限、Docker 守护进程也不需要嵌套虚拟化硬件扩展因此可以直接运行在现有的 Kubernetes Ray worker Pod 和云容器环境中。成本低、密度高相比完整 VM 和 MicroVM需要引导客户机内核并管理沉重的磁盘镜像gVisor 沙箱在几十毫秒内即可启动内存开销极小、空闲 CPU 近乎为零。因此 Ray worker 节点可以在标准 Ray task/actor 旁边密集打包数百个并发沙箱支撑 RL rollout 和 Agent 工具调用所需的高频执行循环。环境要求每个运行沙箱的 Ray 节点都需要满足要求说明Linuxx86_64 或 arm64 架构gVisorrunsc在 worker 节点安装runsc二进制并确保其在系统$PATH中可被找到Ray版本 2.58.0 及以上包含ray.experimental.sandbox包slirp4netns仅networkpublicslirp4netns二进制在$PATH中且 worker 环境中有/dev/net/tun。slirp4netns 将每个沙箱的私有网络命名空间桥接到节点runsc的安装方法参考 gVisor 官方安装指南Debian/Ubuntu 可用apt-get install runsc也可下载预编译二进制放入/usr/local/bin/runsc。slirp4netns在 Debian、Ubuntu、Fedora 上作为软件包提供也有针对 x86_64 与 aarch64 的静态构建版本。使用模式与示例创建基础沙箱并执行命令使用sandbox.create()从任意容器镜像启动隔离环境函数返回一个代表沙箱 actor 的 RayActorHandleimport ray from ray.experimental import sandbox ray.init() # 创建一个拥有 1 个 CPU 核心与 512MiB 内存的沙箱 sb sandbox.create( imagepython:3.10-slim, cpu1.0, memory512Mi, workdir/workspace, timeout_seconds30.0, ) # 在沙箱内执行不可信 Python 代码 result ray.get( sb.exec.remote(python3 -c import sys; print(\Hello from sandboxed Python:\, sys.version)) ) print(fExit Code: {result.exit_code}) print(fStdout: {result.stdout.strip()}) print(fExecution Duration: {result.duration_ms:.2f} ms) # 清理沙箱资源 ray.get(sb.delete.remote())关键参数说明对应 sandbox.py 中create()的实现image沙箱使用的 OCI 容器镜像例如python:3.10-slim。cpu分配给沙箱的 CPU 核心数create()内部会将其转换为 Ray actor 的num_cpus调度选项。memory内存大小支持512Mi、1Gi、2GB等字符串格式由 config.py 中的parse_memory_bytes()解析为字节数并作为 Ray actor 的memory调度选项create()源码中actor_opts[memory] parsed_mem。workdir沙箱内的工作目录在只读 rootfs 下它同时也是沙箱唯一可写的路径宿主机回写的 scratch 空间。timeout_seconds沙箱创建超时时间默认 30.0 秒。ttl_seconds沙箱存活时间墙钟时间从创建起算而非空闲时间超时后由 runtime.py 中的守护线程定时器自动删除。执行结果ExecResult在 backend/base.py 中定义包含exit_code、stdout、stderr与duration_seconds另有duration_ms属性。读写、上传与下载文件可以把源文件直接写入沙箱也可以在执行前从宿主机上传本地文件。默认情况下根文件系统是只读的配置的workdir如/workspace是可写的临时空间import textwrap import ray from ray.experimental import sandbox ray.init() sb sandbox.create( imagepython:3.10-slim, workdir/workspace, memory1Gi, ) # 1. 将不可信的模型生成脚本写入沙箱 code textwrap.dedent(\ def fibonacci(n): a, b 0, 1 for _ in range(n): a, b b, a b return a with open(/workspace/output.txt, w) as f: f.write(ffib(30) {fibonacci(30)}) ) ray.get(sb.write_file.remote(/workspace/solution.py, code)) # 2. 在沙箱内执行脚本 exec_res ray.get(sb.exec.remote(python3 /workspace/solution.py)) print(Execution returncode:, exec_res.exit_code) # 3. 把生成的结果文件读回宿主机 output_bytes ray.get(sb.read_file.remote(/workspace/output.txt)) print(Result:, output_bytes.decode(utf-8)) # 4. 或者使用 upload_file / download_file 处理宿主机文件 # ray.get(sb.upload_file.remote(local_input.json, /workspace/input.json)) # ray.get(sb.download_file.remote(/workspace/output.txt, local_output.txt)) ray.get(sb.delete.remote())从源码看文件 I/O 由Sandboxactor 的方法转发到SandboxRuntimesandbox.pyupload_file以二进制读取本地文件再调用write_filedownload_file先read_file再在宿主机侧创建目标目录runtime.pywrite_file/read_file最终由 gVisor backend 通过runsc exec /bin/sh -c mkdir -p ... cat $1和runsc exec ... cat实现gvisor.py。使用自定义资源调度 Sandbox actor由于Sandbox就是标准的 Ray actor你可以直接用num_cpus、memory以及自定义加速器或放置约束等 Ray actor 调度选项来实例化它import ray from ray.experimental.sandbox import Sandbox ray.init() # 使用 Ray Core 资源放置选项实例化 Sandbox actor sandbox_actor Sandbox.options( num_cpus2.0, memory2 * 1024 * 1024 * 1024, # 2 GiB ).remote( imagepython:3.10-slim, workdir/workspace, ttl_seconds600, # 10 分钟后自动终止 ) # 执行带单条命令执行超时的命令 result ray.get( sandbox_actor.exec.remote( python3 -c import os; print(\Worker PID:\, os.getpid()), timeout5.0, # 5 秒执行超时 ) ) print(result.stdout) ray.get(sandbox_actor.delete.remote())值得注意的实现细节Sandbox.__init__会通过ray.get_runtime_context().get_assigned_resources()尝试读取 Ray 分配给该 actor 的资源sandbox.py当未显式传入cpu/memory时自动沿用调度配额——这意味着通过Sandbox.options()指定的资源会自动传导到 gVisor 的 cgroup 配额。exec.remote中的timeout参数在 backend 中通过proc.communicate(timeouttimeout)强制执行超时抛 SandboxTimeoutErrorgvisor.py。在自定义 actor 中用 SandboxRuntime 管理沙箱池如果你正在构建自定义 RL 环境 actor 或专门的 rollout worker可以把SandboxRuntime直接嵌入自定义 actor以获得细粒度的沙箱生命周期控制import ray from ray.experimental.sandbox.runtime import SandboxRuntime ray.remote class SandboxPool: def __init__(self, size: int 3, image: str python:3.10-slim): self.runtime SandboxRuntime() self.sandboxes [ self.runtime.create(imageimage, memory512Mi) for _ in range(size) ] def run_command(self, index: int, command: str): return self.runtime.exec(self.sandboxes[index], command) def close(self): for sb_id in self.sandboxes: self.runtime.delete(sb_id) # 部署一个管理本地沙箱池的 actor pool SandboxPool.remote(size3) result ray.get(pool.run_command.remote(0, python3 -c print(\Hello from pool!\))) print(result.stdout) ray.get(pool.close.remote())从 runtime.py 的实现看SandboxRuntime.create()返回唯一的实例 ID格式为ray-sandbox-uuid见 gvisor.py内部先经ImageManager.pull_image()拉取镜像再调用GVisorSandboxBackend.create_sandbox()启动容器并轮询runsc state直到进入running状态。exec对应同步exec_command另有异步版本exec_async基于asyncio.to_thread。向 gVisor 传递自定义 OCI 配置对高级负载你可能需要配置低层运行时选项如自定义宿主挂载、Linux capabilities、自定义网络与 DNS 设置。使用_oci_spec_transform_fn参数在 Ray 将生成的 OCI 运行时规范 字典传给 gVisorrunsc之前检查并修改它。::: note_oci_spec_transform_fn是面向高级用例的实验性钩子。Ray 项目正在为 Ray Sandboxes 设计一等公民的配置 API如更高级的卷挂载与 capability 抽象该钩子在这些 API 落地后很可能会变化。如果希望参与推动欢迎提 issue 描述你的使用场景。 :::_oci_spec_transform_fn可调用对象接收完整生成的 OCI 规范字典可以在原地修改也可以返回一个修改后的字典。常见用途包括宿主挂载Host mounts把宿主目录、只读数据集或模型权重挂载进沙箱容器。命名空间与挂载细节配置一等公民选项未覆盖的命名空间或挂载行为。互联网访问、DNS 和 Linux capabilities 各有一等公民选项network、dns和capabilities。传capabilities[]表示完全不带任何 capability。请把该钩子保留给这些选项覆盖不到的网络或 capability 配置。参见 网络与 DNS 一节。import ray from ray.experimental import sandbox ray.init() def configure_oci_spec(spec: dict) - dict: # 添加宿主 bind mount例如只读数据集或缓存目录 spec.setdefault(mounts, []).append( { destination: /mnt/dataset, source: /path/to/host/dataset, type: bind, options: [rbind, ro], } ) return spec # 创建沙箱时传入转换钩子 sb sandbox.create( imagepython:3.10-slim, workdir/workspace, _oci_spec_transform_fnconfigure_oci_spec, ) # 在定制沙箱内执行命令 result ray.get( sb.exec.remote( python3 -c print(\Sandbox initialized with custom OCI configuration!\) ) ) print(result.stdout) # 清理资源 ray.get(sb.delete.remote())从源码看该钩子的作用点在 image_manager.pycreate_oci_spec()在生成完整 spec含 rootfs、env、capabilities、mounts、cgroup 资源限制之后调用_oci_spec_transform_fn(spec)若返回非 None 字典则以其作为最终 spec。转换函数需要能被 cloudpickle 序列化因为会随 Ray actor 分发。注意 OCI spec 的基础由runsc spec命令生成image_manager.py 的get_default_oci_spec()。容器镜像沙箱从 OCI 容器镜像启动。镜像管理器直接从 registry 的 HTTP API 拉取镜像匿名方式无 Docker daemon、无凭据把根文件系统解压到节点上的/tmp/ray/sandbox/images并按镜像缓存供该节点上使用相同镜像的后续沙箱复用。对文件系统有写权限的沙箱会在缓存的根文件系统之上获得自己独立的可写 overlay。限制镜像缓存缓存是有界的这样运行大量不同镜像的节点不会把磁盘塞满。每次拉取前Ray 会逐出最近最少解压LRU的镜像直到缓存小于上限。正在被沙箱使用的镜像永远不会被逐出。默认上限是缓存所在文件系统的二分之一。在 worker 节点上设置RAY_SANDBOX_IMAGE_CACHE_MAX_BYTES可自定义上限字节数设为0则禁用逐出。从源码看该逻辑位于 image_utils.pyRAY_SANDBOX_IMAGE_CACHE_MAX_BYTES环境变量控制缓存上限pull_image()传入instance_id时镜像会被钉住pinned直到同实例调用release_image()才可被逐出——这正是“运行中沙箱使用的镜像永不逐出”的实现机制见 image_manager.py 与 gvisor.py 中删除沙箱后释放镜像的调用。通过镜像代理Mirror路由 Docker Hub 拉取由于镜像拉取是匿名的每个从 Docker Hub 拉取的节点都会消耗匿名拉取速率限制并通过公网下载镜像。在大集群中并发拉取数 GB 的镜像很容易撞上速率限制或打满网络带宽导致镜像拉取失败或变慢。设置RAY_SANDBOX_REGISTRY_MIRROR将 Docker Hub 拉取路由到 registry mirror。Ray 只改写 Docker Hub 的镜像引用来自其他 registry如 GHCR 或私有 registry的拉取保持不变。取值格式为host[:port][/repo-prefix]。Ray 会把仓库前缀拼接到仓库路径前这正是 pull-through 缓存所期望的形式Mirror示例值python:3.10-slim解析为ECR pull-through 缓存acct.dkr.ecr.region.amazonaws.com/dockerhubacct.dkr.ecr.region.amazonaws.com/dockerhub/library/pythonArtifact Registry remote repositoryregion-docker.pkg.dev/project/reporegion-docker.pkg.dev/project/repo/library/python集群内registry:2代理http://registry.default.svc.cluster.local:5000http://registry.default.svc.cluster.local:5000/library/python需要注意裸主机名意味着 HTTPS。明文 HTTP 的 mirror 要显式写http://前缀集群内registry:2代理通常就是这种情况。Mirror 是权威的。与 Docker 的 registry-mirrors 行为不同Ray 不会回退到 Docker Hub。如果 mirror 不可达或不包含该镜像拉取就会失败。Mirror 必须允许匿名拉取。Ray 与 mirror 的交互方式与任何 registry 相同走同样的匿名 bearer-token 流程。如果你的 mirror 通常要求认证请通过网络层访问如 VPC endpoint 或集群内服务将其暴露给 Ray。网络与 DNS沙箱支持四种网络模式。默认是none遵循安全默认原则。需要联网时使用public。模式网络访问/etc/resolv.conf安全属性none(默认)无保持不变无出站流量。这是不可信代码的推荐设置。public从沙箱私有的网络命名空间出网由 slirp4netns 桥接由dns生成默认8.8.8.8、1.1.1.1只读挂载端口和回环地址都是每沙箱私有的在0.0.0.0上绑定不会与其它沙箱或节点本地服务冲突、被它们访问或访问它们节点或集群也没有入站通路。沙箱不继承宿主解析器配置的任何内容。沙箱仍可到达节点可到达的任何网络地址包括其它 Ray 节点和内部服务。沙箱自身地址是198.18.0.100RFC 2544 基准测试网段选择它是为了不与 Pod 或 service 网段重叠。要求节点上安装 slirp4netns。host完整宿主网络身份宿主自己的文件只读挂载dns可覆盖严格比public更宽松。沙箱可到达节点可到达的任何内容包括内部网络和节点本地服务。sandboxgVisor netstack保持不变要求rootlessFalse。runsc 在 rootless 模式下不支持 sandbox netstack。::: warningpublic把沙箱之间、以及沙箱与节点自身服务之间隔离开但并不能与节点所在的网络隔离。slirp4netns 会通过节点中继每一个出站连接因此public沙箱可以到达其它 Ray 节点包括 head 节点的 GCS 和 dashboard 端口、其它 Kubernetes Pod 以及节点可达的任何内部服务。不可信代码请使用networknone。 :::要给沙箱联网使用networkpublic并搭配DOCKER_DEFAULT_CAPABILITIES这样标准镜像的行为与 Docker 下一致——因为apt-get、tar的所有权恢复等操作都需要这些 capabilitiesfrom ray.experimental import sandbox from ray.experimental.sandbox import DOCKER_DEFAULT_CAPABILITIES sb sandbox.create( imagepython:3.10-slim, networkpublic, capabilitiesDOCKER_DEFAULT_CAPABILITIES, readonlyFalse, )关于DOCKER_DEFAULT_CAPABILITIES它定义于 config.py包含 14 个 cap如CAP_CHOWN、CAP_SETUID、CAP_SETGID、CAP_DAC_OVERRIDE、CAP_NET_BIND_SERVICE等与 Docker 默认集一致。原因在源码注释中写得很清楚runsc spec发出的运行时默认能力集比 Docker 窄得多会弄坏常见镜像——apt-get需要CAP_SETUID/CAP_SETGIDtar以 root 恢复所有权需要CAP_CHOWN。锁定网络中的 DNS某些 VPC 会阻止到公共解析器的出站 53 端口此时public的默认 DNS 设置无法解析查询。改用networkpublic, dns[10.0.0.2]传入你的内部解析器。如果不可行退而使用networkhost使用宿主的/etc/resolv.conf代价是获得完整的宿主网络身份。更复杂的配置通过 OCI spec 完成参见 向 gVisor 传递自定义 OCI 配置。从实现看dns参数只对public/host模式有效其它模式传入会被SandboxConfig.__post_init__直接拒绝config.pypublic模式在 image_manager.py 中生成一份宿主机无关的resolv.conf默认写入8.8.8.8、1.1.1.1不泄漏宿主的 search domains、resolver VIP 或 ndots 选项并只读挂载进容器。架构Ray Sandboxes 子系统包含以下层次------------------------------------------------------------------- | Ray Application / RL Framework | | (e.g., veRL, SkyRL, RL Rollout Workers, Agents) | ------------------------------------------------------------------- | v ------------------------------------------------------------------- | ray.experimental.sandbox | | (High-level create() API Sandbox Ray Actor) | ------------------------------------------------------------------- | v ------------------------------------------------------------------- | ray.experimental.sandbox.runtime | | SandboxRuntime Interface | ------------------------------------------------------------------- | v ------------------------------------------------------------------- | ray.experimental.sandbox.backend | | GVisorSandboxBackend (runsc OCI) | ------------------------------------------------------------------- | v ------------------------------------------------------------------- | Ray Worker Node | | ----------------------- ----------------------- | | | gVisor Sandbox 1 | | gVisor Sandbox 2 | | | | (python:3.10-slim) | | (busybox:latest) | | | | CPU: 0.5, Mem: 256M | | CPU: 1.0, Mem: 512M | | | ----------------------- ----------------------- | -------------------------------------------------------------------核心组件高层辅助函数ray.experimental.sandbox.create创建一个封装沙箱生命周期的 Ray actor 并返回ActorHandle。沙箱 actorray.experimental.sandbox.Sandbox一个 Ray actor作为代理把命令执行与文件 I/O 转发给隔离的沙箱实例同时管理沙箱的调度与生命周期含__del__兜底清理。沙箱运行时ray.experimental.sandbox.SandboxRuntime管理本地沙箱生命周期、镜像拉取与缓存、以及与执行后端交互的低层抽象。gVisor 后端ray.experimental.sandbox.backend.GVisorSandboxBackend通过 gVisor 的 OCI 运行时runsc执行命令并隔离进程。每个沙箱对应一个常驻 runsc 容器实例runsc状态目录固定为/tmp/runsc沙箱目录在/tmp/ray/sandbox/下gvisor.py。镜像管理器ray.experimental.sandbox.image_manager.ImageManager自动从 Docker Hub、GHCR 或本地 tar 归档拉取容器镜像把根文件系统解压到/tmp/ray/sandbox/images并构建 OCIconfig.json运行时规范。安全与隔离模型Ray Sandboxes 实现多层纵深防御隔离系统调用拦截gVisor 的 Sentry 应用内核在用户态拦截系统调用把不可信代码与宿主 Linux 内核隔离开。只读根文件系统Ray 以只读方式挂载基础容器文件系统readonlyTrue每个沙箱有独立的写时复制copy-on-writeoverlay 目录。当readonlyFalse时整个 rootfs 通过 per-sandbox overlay 可写但镜像内容保持可见、沙箱互不干扰、基础镜像永不被修改config.py。受限工作目录只有显式的workdir如/workspace被以读写方式挂载用于放置应用产物。需要注意显式传workdir才会被挂载为只读 rootfs 上唯一的可写路径继承的镜像 WORKDIR 永远不会被静默设置为可写gvisor.py 中还有路径穿越检查。网络隔离默认networknone关闭所有出站网络接口防止不可信代码发起外部 API 调用或扫描内部集群网络。需要联网时networkpublic提供出站能力但绝不交出宿主的解析器配置或网络身份。资源配额cgroups 强制执行 CPU 配额与内存限制防止 CPU 饥饿与 OOM 影响其它 Ray actor。在 image_manager.py 中CPU 通过cpu.period100000、cpu.quotaint(cpu*100000)写入 OCI spec内存通过parse_memory_bytes()解析后写入memory.limit。public模式还有一个值得了解的隔离细节源码注释见 gvisor.py每个沙箱通过unshare --user --map-root-user --net持有私有 usernetwork 命名空间slirp4netns 从 Pod 侧挂入 tap 并做 NATslirp4netns 的标志固定为--cidr198.18.0.0/24 --mtu65520 --disable-host-loopback --disable-dns --enable-seccomp其中选择 RFC 2544 的198.18.0.0/24网段正是为了避免与 Pod/service CIDR 重叠导致本应 NAT 的流量变成 on-link 直连。API 参考详细的函数签名、参数与返回类型见 API 文档ray-sandbox-ref涵盖生命周期与执行ray.experimental.sandbox.create、Sandbox、SandboxRuntime数据结构与状态ExecResult、SandboxStatus异常SandboxError、SandboxCreationError、SandboxTimeoutError、SandboxExecError、SandboxNotFoundError故障排查runsc不在$PATH中确认 gVisor 的runsc二进制已安装到所有 Ray worker 节点且位于系统$PATH中的目录如/usr/local/bin/runsc。backend 在创建沙箱时会先检查shutil.which(runsc)找不到直接抛SandboxCreationErrorgvisor.py。cgroup 或权限错误在无 root 权限的容器化环境如 Kubernetes中保持默认的rootlessTrue。在 cgroup 受限的环境设置RAY_SANDBOX_IGNORE_CGROUPS1backend 的_runsc_base_args会据此附加--ignore-cgroups见 gvisor.py。节点磁盘被镜像占满镜像缓存默认上限为所在文件系统的一半。在 worker 节点上用RAY_SANDBOX_IMAGE_CACHE_MAX_BYTES字节调低上限或把缓存挪到更大的卷。运行中沙箱使用的镜像不会被逐出所以大量并发沙箱使用不同的大镜像时仍需要相应的磁盘空间。镜像拉取失败确认节点能访问容器 registry如 Docker Hub 或 GHCR或预填充/tmp/ray/sandbox/images缓存目录。多个节点同时拉取大镜像时Docker Hub 的匿名速率限制是常见原因参见 通过镜像代理路由 Docker Hub 拉取。networkpublic时找不到slirp4netns在 worker 节点安装 slirp4netns 软件包或其静态构建版本。backend 会同时检查slirp4netns与nsenter两个二进制gvisor.py。public沙箱启动报 tap 或命名空间错误slirp4netns 需要 worker 环境中有/dev/net/tun且 seccomp 策略允许非特权 usernetwork 命名空间创建unshare -Un true必须以 Ray 用户身份成功执行。slirp4netns 的报错会出现在沙箱的runsc.stderr.log以及创建错误信息中。下一步参考 KubeRay 的 sandboxing 文档kuberay-sandboxing在 Kubernetes 上用 KubeRay 部署 Ray Sandboxes。深入学习 gVisor 官方文档。探索资源隔离resource-isolation指南把 Ray 系统进程与 worker 进程隔离开。以上内容的配套实现与测试位于仓库的 python/ray/experimental/sandbox 目录含sandbox.py、runtime.py、backend/gvisor.py、image_manager.py、config.py与tests/下的单元测试以及 src/ray 的 C/protobuf 底层文档正文对应 doc/source/ray-core/sandboxes.md。赞分享人工智能分布式训练强化学习任务调度模型推理服务【免费下载链接】rayRay is an AI compute engine. Ray consists of a core distributed runtime and a set of AI Libraries for accelerating ML workloads.项目地址https://gitcode.com/gh_mirrors/ra/ray点击查看免费下载相关推荐Ray Sandbox API 详解基于 gVisor 在 Ray 集群中安全执行不可信代码Ray Sandbox API 详解基于 gVisor 在 Ray 集群中安全执行不可信代码 Ray Sandboxes 是 Ray 提供的一套 alpha人工智能分布式训练强化学习任务调度模型推理服务使用 Ray Cluster Launcher 在 GCP 上启动 Ray 集群的完整指南使用 Ray Cluster Launcher 在 GCP 上启动 Ray 集群的完整指南 本指南讲解如何借助 Ray 自带的集群启动器Cluster Lau人工智能分布式训练强化学习任务调度模型推理服务Hydra Ray Launcher 插件实战指南用 ray 与 ray_aws 在本地集群和 AWS EC2 上并行执行 Sweep 任务Hydra Ray Launcher 插件实战指南用 ray 与 ray_aws 在本地集群和 AWS EC2 上并行执行 Sweep 任务 Hydra 的开发工具后端CLI上一篇平衡车主板改造全攻略hoverboard-firmware-hack-FOC固件上手指南下一篇GraphQL Editor嵌入式编辑器如何在React应用中快速集成创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 RELATED READING
延伸阅读
更多一线实战笔记与深度复盘，助您持续精进
