背景与目标
本文将带领大家深入探索如何利用 agent-sandbox 控制器，在 Kubernetes 集群中高效调度 AIO (All-In-One) 容器。
我们要构建的是一个集成了 OpenCode（深度编程专家）与 OpenClaw（全能助理）的智能沙箱环境。这个环境不仅能够理解复杂的业务逻辑，还能执行跨平台的自动化任务，是未来云原生智能体（Agent）运行的理想基座。
架构解析：打造智能沙箱
我们的核心架构由以下关键组件构成：
- 控制器:
kubernetes-sigs/agent-sandbox
- 职责: 全权负责 Sandbox 的生命周期管理与资源隔离，是整个系统的指挥官。
- 容器镜像:
runzhliu/sandbox-openclaw-opencode:1.0.0.152
- 核心: 内置了 Runtime、OpenClaw 和 OpenCode，实现了“开箱即用”的强大能力。
- OpenCode:
- 能力: 专注于代码重构、YAML 校验以及复杂的 CMDB 接口集成调试。
- OpenClaw:
- 能力: 负责 IM 联动（打通微信/Slack）、生成自动化日报以及精细化的定时任务调度。
技术深挖：Agent Sandbox 原理
agent-sandbox 项目致力于在 Kubernetes 上安全、高效地运行沙箱化工作负载。它采用了优雅的分层架构设计：
1. 核心层 (Core Layer)
这是地基，负责直接管理 Kubernetes 原生资源。
- CRD:
Sandbox
- 定义了沙箱的运行实体，包含 Pod 模板、存储卷（PVC）及生命周期策略。
- 支持 Pod 接管 (Adoption)：通过 Annotation 直接接管已存在的 Pod，为“热池”秒级启动提供了基础。
2. 扩展层 (Extensions Layer)
这是上层建筑，提供了更高级的用户接口和性能优化。
- CRD:
SandboxTemplate (蓝图)
- CRD:
SandboxClaim (申请单)
- 用户的直接接口。控制器会自动创建 NetworkPolicy 进行网络隔离，并尝试从 Warm Pool 中“偷取”闲置 Pod 实现极速启动。
- CRD:
SandboxWarmPool (热池)
- 维护一组预热好的闲置 Pod。一旦有 Pod 被“偷走”用于新的 Sandbox，它会立即自动补货。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
|
+-----------------------------------------------------------------------------+
| PHASE 1: SETUP (管理员配置) |
+-----------------------------------------------------------------------------+
| |
| [Admin] |
| | |
| +---> [SandboxTemplate] (蓝图: 镜像, 资源限制) <-------. |
| | | |
| `---> [SandboxWarmPool] (热池配置: 数量=5) | (引用) |
| | | |
| (Reconciles / 调和) | |
| v | |
| [WarmPool Controller] -----------------------------+ |
| | |
| `---> 预先启动 5x [Pod (Warm/Idle)] |
| (状态: Running, 归属: WarmPool) |
| |
+-----------------------------------------------------------------------------+
|
| 等待用户请求...
v
+-----------------------------------------------------------------------------+
| PHASE 2: USER REQUEST (用户请求) |
+-----------------------------------------------------------------------------+
| |
| [User] ----> 提交 [SandboxClaim] |
| (申请: "给我一个 Python 环境") |
| | |
| (Reconciles) |
| v |
| [Claim Controller] |
| | |
| +---> 创建 [NetworkPolicy] (默认拒绝所有入站流量) |
| | |
| [?] 检查热池 (WarmPool) 是否有可用 Pod ? |
| / \ |
| / (YES - 极速启动/Fast Path) \ (NO - 冷启动/Cold Path) |
| / \ |
| v v |
+---------------------------+ +---------------------------+ |
| PHASE 3A: ADOPTION (接管) | | PHASE 3B: COLD START (创建)| |
+---------------------------+ +---------------------------+ |
| | | | |
| 1. 锁定并 "偷取" Pod: | | 1. 创建 [Sandbox] 对象 | |
| 修改 Owner: Claim | | | |
| 修改 Label: ClaimID | | 2. [Sandbox Controller] | |
| | | 检测到新 Sandbox | |
| 2. [Pod (Warm)] 变更为 | | | |
| [Pod (Active)] | | 3. 从头开始创建 Pod | |
| | | (拉镜像 -> 启动) | |
| 3. 创建 [Sandbox] 对象 | | | |
| Annotation: | | 4. 等待 Pod Ready... | |
| "pod-name: pod-xyz" | | (耗时较长) | |
| | | | |
+-------------+-------------+ +---------------------------+ |
| |
v |
+-----------------------------------------------------------------------------+
| PHASE 4: CORE & MAINTENANCE |
+-----------------------------------------------------------------------------+
| |
| [Sandbox Controller] (核心控制器) |
| | |
| +---> 发现 Sandbox 带有 "pod-name" 注解? |
| | | |
| | +-- (YES) --> 直接纳管现有 [Pod (Active)] -> 状态 Ready |
| | |
| `-----> 创建 Service (Headless) 暴露服务 |
| |
| ----------------------------------------------------------------------- |
| |
| [WarmPool Controller] (补货逻辑) |
| | |
| `---> 检测到 Pod 被 "偷走" (当前副本数 4 < 期望值 5) |
| (Replenish) |
| `---> 立即启动一个新的 [Pod (Warm)] 补充库存 |
| |
+-----------------------------------------------------------------------------+
|
环境准备
安装 kubernetes-sigs/agent-sandbox 非常简单，直接应用官方 Manifest 即可：
1
2
3
4
5
|
# 1. 安装核心组件
kubectl apply -f https://github.com/kubernetes-sigs/agent-sandbox/releases/download/v0.1.0/manifest.yaml
# 2. 安装扩展组件 (支持 Warm Pool 等高级特性)
kubectl apply -f https://github.com/kubernetes-sigs/agent-sandbox/releases/download/v0.1.0/extensions.yaml
|
实战演练：部署 AIO 容器
接下来是重头戏。我们将部署一个定制的 AIO Sandbox，其中包含了 OpenClaw 和 OpenCode。
注意: 下方的 YAML 中包含了一段特殊的启动命令，用于在容器启动前强制清理 Nginx 的 IPv6 配置。这是因为演示环境的宿主机禁用了 IPv6，如果您的环境支持 IPv6，可以移除 command 和 args 部分。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
|
apiVersion: agents.x-k8s.io/v1alpha1
kind: Sandbox
metadata:
name: aio-sandbox-example
spec:
podTemplate:
metadata:
labels:
sandbox: aio-sandbox-example
spec:
containers:
- name: aio-sandbox
image: runzhliu/sandbox-openclaw-opencode:1.0.0.152
# --- 启动脚本开始 ---
# 使用 sh -c 执行复合命令，解决环境兼容性问题
command: ["/bin/bash", "-c"]
args:
- |
echo "Initializing AIO Sandbox..."
# 1. 强制清理主配置目录中的 IPv6 监听
find /etc/nginx -type f -name "*.conf" -exec sed -i '/listen.*\[::\]/d' {} +
# 2. 源头治理：清理动态配置目录及模板
find /opt/gem -type f \( -name "*.conf" -o -name "*.template" \) -exec sed -i '/listen.*\[::\]/d' {} +
# 3. 验证清理结果
echo "Checking for leftover IPv6 listeners..."
grep -r "\[::\]" /etc/nginx /opt/gem/nginx || echo "No IPv6 listeners found."
# 4. 启动核心服务
/opt/gem/run.sh
# --- 启动脚本结束 ---
securityContext:
allowPrivilegeEscalation: false
ports:
- containerPort: 8080
resources:
limits:
memory: "8Gi"
cpu: "4000m"
|
效果展示
部署成功后，你将拥有一个全功能的云端工作台。如下图所示，不仅可以直接使用浏览器和 VSCode，OpenClaw 和 OpenCode 也已就绪，随时待命。
深度思考：容器 vs 虚拟化
在 Sandbox 技术的选型上，选择基于 Docker/Containerd 的传统容器架构，最大的优势在于生态集成速度快，对于大多数传统企业来说，学习和迁移成本极低。
然而，如果场景对强隔离性有极高要求（例如多租户运行不可信代码），FireCracker 或 Kata Containers 这类基于微虚拟机的方案会是更好的选择。当然，随之而来的是更复杂的 Runtime 替换和运维挑战。技术选型往往就是在这两者之间寻找平衡点。
延伸阅读
- Kubernetes Agent Sandbox 官方仓库
- Sandbox 项目主页
