OpenKruise Agents v0.6.0新增哪些 Agent Sandbox 运维能力

如果 Agent Sandbox 同时遇到“不能让它随便访问内网”“暂停后还要批量升级”“暖池容量要跟着时段变化”和“空闲实例继续耗费 CPU”这四类问题，OpenKruise Agents v0.6.0 的变化可以概括为一句话：它开始把安全、运维和成本控制都做成 Kubernetes 资源，而不是留给脚本拼接。

官方地址：https://openkruise.io/kruiseagents/

这次版本不只是增加几个 CRD。更重要的是，Agent 的网络边界、升级连续性、暖池容量和休眠策略有了可以声明的落点。下面按运维压力拆开看。

v0.6.0先解决了哪四类运维压力

先建立一个判断框架：安全问题看“能访问什么、凭据从哪里来”；升级问题看“暂停实例能不能纳入批次、数据层是否保留”；容量问题看“暖池是否按水位和时段调节”；成本问题看“闲置 Sandbox 如何暂停、何时恢复”。

对应到 v0.6.0，TrafficPolicy、GlobalTrafficPolicy 和 SecurityProfile 负责把 L3/L4 目的地控制、L7 请求检查和 MCP 工具访问控制放进策略层；凭据由出口代理从 Kubernetes Secret 解析，避免把长期 API Key 直接交给 Agent。SandboxUpdateOps、PoolAutoscaler 和 AutoPausePolicy 则分别处理批量升级、暖池伸缩和空闲生命周期。

网络治理：从“能出网”变成“只到允许的目的地”

以前常见做法是给 Sandbox 一个网络出口，再把权限和令牌交给运行时。问题在于，提示注入或工具配置失误后，Agent 可能触达不该触达的服务，凭据也会随着进程生命周期暴露。

v0.6.0 把这个问题拆成两层：

• TrafficPolicy / GlobalTrafficPolicy：描述 L3/L4 的入口、出口和目的地范围，集群级策略可以提供统一底线。
• SecurityProfile：继续向 L7 下沉，支持请求检查、MCP 工具级 ACL、Header 处理和凭据注入。

运维上要注意“网络允许”与“身份允许”不是一回事。先用 TrafficPolicy 缩小可达范围，再用 SecurityProfile 限定请求和工具，最后让出口代理从 Secret 取凭据并支持轮换。这样 Agent 只拿到完成任务所需的能力，不必把平台密钥塞进业务容器。

批量升级：暂停的 Sandbox 也不必先全部唤醒

SandboxUpdateOps 的关键变化有两个。第一，新增 CheckpointRestore 策略，可以在升级前保存可写 rootfs，升级后恢复它；第二，stateFilter 可以把 Paused 实例纳入批量操作。

两种策略的取舍很明确：

这里有一个容易误判的边界：CheckpointRestore 的价值是保留文件系统状态，不代表进程内存和网络身份都能原样恢复；同时它不适合在同一批次里更换业务容器镜像。若必须换镜像又要保留业务数据，应使用 Recreate 配合升级前后的备份与恢复钩子。

当 stateFilter 同时选择 Running 和 Paused 时，控制器会处理暂停实例，并在成功后保持其暂停形态。对有大量闲置 Sandbox 的团队来说，这比“逐个唤醒、升级、再暂停”的人工循环更可控。

PoolAutoscaler：暖池容量也进入声明式管理

Agent Sandbox 的暖池解决的是冷启动，但一直保留太多未领取实例又会浪费资源。PoolAutoscaler 把这件事从定时执行 kubectl scale 变成声明式容量策略，可以按水位调节，也可以用 cron 设定时段。

# 用水位表达暖池目标，避免把固定副本数写死
apiVersion: agents.kruise.io/v1alpha1
kind: PoolAutoscaler
metadata:
  name: agent-warm-pool
spec:
  # 这里的水位负责让未领取 Sandbox 保持在可接受范围
  minReplicas: 2
  maxReplicas: 20
  # 真实字段以当前 CRD 文档为准，示例只表达容量策略意图
  targetPendingClaims: 5

它适合和自动暂停配合使用，但两者管理的对象不同：暖池里的未领取 Sandbox 由 PoolAutoscaler 负责，已被 Claim 且长时间无活动的 Sandbox 才进入自动暂停判断。把两种对象混在一起，容易出现“暖池缩小了，已领取会话却被误暂停”的错误预期。

自动暂停恢复为什么不只是一个开关

自动暂停由探针和策略共同决定。探针报告活跃或空闲状态，AutoPausePolicy 再按阈值安排暂停；另一条探针可以输出下一次任务时间，用于提前唤醒；面向用户的 Sandbox 还可以在授权的入站流量到达时唤醒。

容量规划时不要只看阈值。例如探针每 30 秒运行一次，探针内部用 15 分钟判断最近活动，再设置 10 分钟的空闲阈值，实际暂停时间大约是最后一次真实活动后的 25 分钟。等待窗口越长，误暂停越少，但空闲成本也会更高。

入站流量唤醒也有三个边界：未授权请求不会打开暂停实例；触发唤醒的第一次请求可能仍返回 503，需要结合 Sandbox 状态重试；暖池中的未领取实例不等同于某个已拥有的 Sandbox，不能靠请求“唤醒一个指定暖池实例”。

怎么判断是否值得升级

可以用四个问题做快速决策：

1. 安全边界是否需要按目的地、请求或 MCP 工具细分？如果需要，优先评估 TrafficPolicy 与 SecurityProfile。
2. 升级时是否必须保留 Sandbox 内的可写文件？若只升级 sidecar，CheckpointRestore 更合适；若要换业务镜像，仍要走 Recreate 和数据恢复。
3. 未领取实例是否会随业务高峰变化？如果固定暖池不经济，用 PoolAutoscaler 管水位或时段。
4. 闲置 Sandbox 是否占用明显 CPU，而恢复又不能接受冷启动？再配置探针、定时唤醒或入站流量唤醒，并给重试留出空间。

所以，OpenKruise Agents v0.6.0 的重点不是“多了四个功能”，而是把 Agent Sandbox 从一个可创建、可暂停的工作负载，推进成一个能治理访问、批量运维、按需保温并主动休眠的资源单元。真正落地时，应先从边界和状态模型入手，再决定是否启用自动化策略。

相关问题

CheckpointRestore 能不能同时更换业务镜像？

不适合。它的目标是恢复可写 rootfs，因此业务镜像变化会破坏这条连续性；需要更换业务镜像时，应使用 Recreate 并设计数据备份与恢复。

自动暂停是否会暂停暖池中的未领取 Sandbox？

不会。未领取暖池主要由 PoolAutoscaler 管容量，自动暂停策略面向已经被 Claim、存在活动状态的 Sandbox。

参考资料

• https://www.cncf.io/blog/2026/11/03/openkruise-agents-v0-6-0-leaping-ahead-in-agent-sandbox-security-and-automation/
• https://openkruise.io/blog/2026%2F10%2F07/agents-v0.6.0
• https://openkruise.io/kruiseagents/installation