关于 OpenKruise Agents

OpenKruise Agents 是 OpenKruise 的子项目，后者是 CNCF 旗下的开源应用自动化与工作负载编排项目。它为在 Kubernetes 上大规模运行的 Agent Sandbox 提供全生命周期管理，并配套提供覆盖网络、存储和身份的完整运行时环境。OpenKruise Agents 同时暴露 Kubernetes 和 E2B 两套接口，因此基础设施团队、平台团队和 AI 算法工程师都能方便地操作沙箱。 v0.3.0 版本回答了一个问题：一旦把 Sandbox 交给 Agent，如何升级它、调整它的规格，以及如何对它进行计量。该版本的路线图以两项承诺收尾——通过 TrafficPolicy / SecurityProfile 实现网络治理，以及让平台凭证不进入 Agent 代码的安全身份集成。 OpenKruise Agents v0.6.0 同时兑现了这两项承诺，并围绕它们补齐了运维机制：自 v0.3.0 以来合并了 283 个 PR，新增 27 位贡献者。本文深入介绍四项能力：

• L4 与 L7 网络访问控制及 token 管理——目标可达性、逐请求检查、MCP 工具级 ACL，以及从 Kubernetes Secrets 注入凭证；
• 带 CheckpointRestore 和暂停实例升级的 SandboxUpdateOps——无需手动唤醒即可批量升级处于休眠状态的实例集合，且不丢失文件系统；
• PoolAutoscaler——通过水位线和 cron 调度实现声明式的预热池容量管理；
• 自动暂停与恢复——由探针驱动的空闲检测、定时唤醒和流量触发唤醒，让空闲的 Sandbox 停止消耗 CPU。 这些能力共同带来三类客户价值：安全加固、运维能力和成本优化。本文分为三部分：使这些能力成为可能的架构变更、四项能力的深入剖析，以及价值总结与路线图。

第一部分：架构有哪些变化

如果说 v0.3.0 是一个工作负载层，那么 v0.6.0 就是一个自带数据平面的工作负载层。流量检查、策略分发和身份都成为一等组件，而不再是外部附加项。整体架构如下： OpenKruise Agents v0.6.0 整体架构 从四个组件变为六个。v0.6.0 新增了 traffic-control-plane 和 traffic-proxy： 组件在 v0.6.0 中的角色 sandbox-manager无状态后端，提供兼容 E2B 的北向 API；负责沙箱生命周期、配额，以及路由与流量 token 的编排 sandbox-controller协调 Sandbox、SandboxSet、SandboxClaim 和预热池；承载 admission webhook；驱动自动暂停/恢复控制器 sandbox-gateway基于 Envoy Go filter 构建的数据平面。入向网关代理用户流量（host/path 路由、访问 token、流量触发唤醒）；出向网关执行由策略驱动的 L7 出向流量控制 traffic-control-plane（新增）istiod 向网关和 Pod 内代理分发 xDS 配置；Egress Policy Enforcer（EPE）在出向流量上执行 L7 策略、MCP ACL 和 token 注入 agent-runtimeSidecar，提供兼容 E2B envd 的命令、文件和端口（49983）操作 traffic-proxy（新增）Sidecar，作为出向流量策略在 Pod 内的 L4 执行点 有两个后果值得深入理解。第一，出向流量不再由 Pod 自己处理——它在 Pod 内被捕获，经出向网关路由，并由能够看到完整请求（而不只是 socket）的策略引擎作出决策。第二，入向网关可以唤醒沙箱，这正是无需外部轮询器就能实现流量触发唤醒的原因。 这正是无需外部轮询器就能实现流量触发唤醒的原因。 CRD 数量从 6 个翻倍到 12 个，新增了 PoolAutoscaler、TrafficPolicy、GlobalTrafficPolicy、SecurityProfile 和 GlobalSecurityProfile——形成了一套横跨集群、租户和沙箱三个层级的多级控制系统。

第二部分：四项核心能力

2.1 网络访问控制与 token 管理

这是本版本中最大的变更。它回答了三个问题：一个 Sandbox 可以访问什么、谁可以访问一个 Sandbox，以及——大多数平台都搞错的那个问题——上游 API key 究竟掌握在谁手里。 数据平面采用两阶段流量接管，即节点侧 L4 加中心 L7，在性能与功能之间取得平衡：

Sandbox 应用容器
  -> traffic-proxy（Pod 内 L4 捕获；Deny 规则就地拦截）
  -> 出向网关（由出向路由选定的中心网关）
  -> Envoy external processing（ext_proc）
  -> Egress Policy Enforcer 决策（L7 / MCP ACL / 凭证注入）
  -> 外部服务，或一个被拦截的响应

L4 过滤在节点侧完成，延迟极低；L7 深度检查集中在网关中，便于统一运维、可观测性和安全审计。这种拆分是刻意为之：L4 的拒绝会在流量到达网关之前就被丢弃，而 L7 永远无法覆盖 L4 的拒绝结果。 L4：这个目标究竟是否可达 TrafficPolicy 选择调用方 Pod，并持有一个有序的出向规则列表；peer 支持 fqdn、cidr、service 和 workload。有三条语义比语法本身更重要：

• 一旦某个策略选中了某个 Pod，那么不匹配任何 allow 规则的出向流量都会被拒绝——策略一旦生效即成为白名单；
• peer 字段缺失的规则会被编译器跳过，不会构成默认拒绝——to 里的一个笔误就会悄悄削弱策略；
• 必须始终放行集群 DNS Service，否则所有 FQDN 规则看起来都会是失效的。

apiVersion: agents.kruise.io/v1alpha1
kind: TrafficPolicy
metadata:
  name: sandbox-egress
spec:
  selector:
    matchLabels:
      app: traffic-sample
  egress:
    rules:
      - action: allow
        to:
          - service: {name: kube-dns, namespace: kube-system}
      - action: allow
        to:
          - fqdn: api.example.com
      - action: reject
        ports: [{protocol: TCP, port: 443}]
        to:
          - cidr: 10.0.0.0/8

L7：这个具体请求被允许做什么

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）