1. 多租户集群跑 AI Agent真正的难点不在模型把 AI Agent 塞进 Kubernetes 这件事2024 年之后已经不算新鲜了。真正让一线运维和平台团队头疼的是多租户这三个字。单租户集群里跑一个 Agent你随便给它一个 Deployment、挂个 ServiceAccount、开个 NodePort能跑起来就算成功。可一旦这个集群要同时服务十几个业务线、几十个团队每个团队都有自己的 Agent 要跑问题就全冒出来了A 团队的 Agent 能不能读到 B 团队的 Secret某个 Agent 跑飞了把节点 CPU 打满会不会拖垮隔壁的在线服务Agent 要执行 shell、要装依赖、要访问外部 API这些权限怎么收口我所在的平台团队在过去大半年里把一套多租户 AI Agent 运行平台从零搭到了生产可用中间踩的坑足够写一本小册子。这篇就把整个思路和关键实现拆开讲重点放在隔离、调度、权限、可观测这四件事上而不是模型本身——模型选型是业务团队的事平台要解决的是怎么让几十个 Agent 安全地共存在一个集群里。先明确一下本文说的 AI Agent 是什么。它不是一个单纯的推理服务而是一个能自主规划、调用工具、执行代码、多轮循环的程序。典型形态是一个主进程接收任务调用 LLM 做规划然后通过工具调用去执行 shell 命令、读写文件、访问数据库或外部 API根据结果再决定下一步。这意味着它比普通微服务危险得多——普通微服务的行为是确定的Agent 的行为是运行时才决定的它可能执行任意命令、访问任意网络地址。这就是为什么多租户场景下隔离必须做到内核级别光靠 namespace 和 RBAC 远远不够。关键词里的Kata VM和Sandbox正是解决这个问题的核心手段。下面我会从架构选型一路讲到落地细节包括为什么最终选了 Kata Containers 而不是 gVisor为什么调度器要改造以及那些文档里不会写的坑。2. 隔离层级的选择为什么 namespace 和 RBAC 挡不住 Agent2.1 从信任边界重新理解多租户很多人对多租户的理解停留在用 Namespace 隔开就行。这在传统微服务场景下勉强成立因为微服务的行为是开发时确定的你 review 过代码知道它只会访问哪些资源。但 Agent 不一样它的工具调用是 LLM 在运行时生成的你今天给它一个执行 Python 脚本的工具明天它可能就写出os.system(curl ...)这样的代码。你没法在开发阶段穷举它的行为。所以多租户隔离的第一原则是把每个租户的 Agent 当成不可信代码来对待。这个心态转变很关键。一旦你接受了Agent 可能执行任意代码这个前提Namespace、RBAC、NetworkPolicy 这些 K8s 原生隔离手段的定位就清楚了——它们是管理面隔离管的是谁能创建什么资源而不是运行面隔离管不了进程能干什么。我见过有团队用 Pod Security Admission 的 restricted 策略就以为万事大吉结果 Agent 通过一个允许的 syscall 组合做了容器逃逸。restricted 策略能挡住 privileged、hostPath 这些明显危险项但挡不住内核漏洞利用。容器共享内核这个事实决定了它的隔离强度上限。2.2 Kata Containers、gVisor、Firecracker 的取舍运行面隔离的主流方案有三个方向我们逐个评估过方案隔离原理隔离强度启动开销兼容性运维复杂度runc普通容器Namespace Cgroup低极低完美低gVisor用户态内核拦截 syscall中高中部分 syscall 不支持中Kata Containers轻量 VM 独立内核高较高好真内核中高Firecracker微 VM高低需专门适配高我们最终选 Kata Containers核心理由是兼容性。Agent 要执行各种用户代码Python、Node、Go 编译出来的二进制都可能跑gVisor 对某些 syscall 的支持不完整实测中遇到过 numpy 的某些操作直接报错、某些 JIT 编译场景崩溃。这类问题排查起来极其痛苦因为报错信息往往指向底层 syscall 而不是业务代码。Kata 用的是真实内核跑在轻量 VM 里兼容性和普通容器几乎一致代价是启动慢一点、内存开销大一点。Firecracker 隔离强度也很好启动快但它对设备模型做了大量裁剪网络和存储的适配工作量大而且它本身是给函数计算场景设计的长驻的 Agent 进程用起来并不顺手。如果你的 Agent 是短任务型、秒级生命周期Firecracker 值得考虑如果是长驻的、要维持会话状态的Kata 更合适。提示Kata 的启动开销在 200ms 到 1s 之间取决于镜像和节点配置。如果你的 Agent 需要频繁冷启动这个开销要提前评估必要时用预热池warm pool来摊薄。2.3 RuntimeClass 的落地配置选定 Kata 之后落地其实很简单K8s 用 RuntimeClass 来声明。先在节点上装好 Kata 的 containerd shim然后定义一个 RuntimeClassapiVersion: node.k8s.io/v1 kind: RuntimeClass metadata: name: kata-agent handler: kata overhead: podFixed: cpu: 250m memory: 160Mi scheduling: nodeSelector: katacontainers.io/kata-runtime: trueoverhead这个字段很多人会忽略但它很重要。Kata 每个 Pod 都要起一个 VMVM 本身要占 CPU 和内存如果你不声明 overhead调度器会按容器声明的资源来算结果就是节点实际负载远超预期出现 OOM 或者 CPU 争抢。我们一开始没配节点上明明还有 2 核空闲调度器却认为满了或者反过来调度上去了但节点直接被打爆。加上 overhead 之后调度器的账才算得准。然后在 Agent 的 Pod spec 里引用spec: runtimeClassName: kata-agent containers: - name: agent-runtime image: registry.internal/agent-runtime:1.4.2 resources: requests: cpu: 500m memory: 512Mi limits: cpu: 2 memory: 2Gi这里有个经验Agent 的 resources 一定要设 limits而且 requests 和 limits 不要差太多。Agent 的行为不可预测一个死循环就能把节点吃干。我们给所有 Agent 强制加了 LimitRange禁止不设 limits 的 Pod 进入 Agent 命名空间。同时 CPU limit 不要设得太死Agent 做推理和数据处理时对 CPU 敏感设太低会导致任务超时反而引发重试风暴。3. 调度与资源治理让几十个 Agent 不互相踩踏3.1 为什么默认调度器不够用K8s 默认调度器是给无状态微服务设计的它假设 Pod 之间是同质的、可互换的。但 Agent 场景有几个特殊之处第一Agent 有状态一个会话可能持续几十分钟甚至几小时中途不能被随意驱逐第二Agent 的资源需求波动极大规划阶段几乎不占资源执行代码阶段可能瞬间吃满第三Agent 之间有亲和性同一个租户的 Agent 可能共享缓存、共享向量库连接放太散会放大延迟。我们试过纯默认调度器问题很快暴露高峰期节点负载严重不均有的节点 90% 利用率有的只有 20%因为默认调度器只看 requests而 Agent 的实际用量和 requests 偏差很大。后来我们引入了两级调度默认调度器负责粗粒度放置再叠加一个自定义的调度扩展Scheduler Plugin做二次打分。3.2 用 Scheduler Plugin 做租户感知打分K8s 1.19 之后调度框架Scheduling Framework已经稳定写一个自定义 Plugin 比早年改调度器源码优雅得多。我们实现了一个TenantSpread插件核心逻辑是同一租户的 Agent 尽量分散到不同节点不同租户的 Agent 尽量混布以提高资源利用率。func (p *TenantSpread) Score(ctx context.Context, state *framework.CycleState, pod *v1.Pod, nodeName string) (int64, *framework.Status) { tenant : pod.Labels[tenant-id] nodeInfo, err : p.handle.SnapshotSharedLister().NodeInfos().Get(nodeName) if err ! nil { return 0, framework.AsStatus(err) } count : 0 for _, p : range nodeInfo.Pods { if p.Pod.Labels[tenant-id] tenant { count } } // 同租户 Pod 越多得分越低 score : int64(100 - count*20) if score 0 { score 0 } return score, nil }这个插件配合PodTopologySpread使用效果更好。PodTopologySpread 能保证同租户的 Pod 在拓扑域比如可用区、节点上均匀分布但它是硬约束配置不当会导致 Pod 一直 Pending。我们的做法是用 PodTopologySpread 做软约束whenUnsatisfiable: ScheduleAnyway用自定义 Plugin 做精细打分两者互补。3.3 资源超卖与 QoS 分级Agent 的资源画像很特殊大部分时间低负载偶尔尖峰。如果按峰值来分配集群利用率会低得可怜如果按均值分配尖峰时又会互相踩踏。我们的方案是分级 QoS 有限超卖。把 Agent 分成三档交互式 Agent用户实时等待结果延迟敏感requests 接近 limitsQoS 为 Guaranteed。批处理 Agent后台跑任务可以容忍排队和降级requests 远小于 limitsQoS 为 Burstable。实验性 Agent内部测试用BestEffort随时可被驱逐。节点上通过 kubelet 的--system-reserved和--kube-reserved预留系统资源再配合 cgroup v2 的cpu.weight做软限流。实测下来交互式 Agent 的 P99 延迟在混布场景下能稳定在 800ms 以内批处理 Agent 的吞吐则提升了近 40%因为批处理任务填满了交互式 Agent 留下的资源空隙。注意超卖一定要配合驱逐策略。我们给批处理和实验性 Agent 的命名空间配了 PriorityClass交互式 Agent 优先级最高。节点资源紧张时kubelet 会先驱逐低优先级的 Pod保证交互式 Agent 不受影响。4. 权限收口Agent 的最小权限到底怎么落地4.1 ServiceAccount 不是权限边界很多团队给每个租户建一个 ServiceAccount就以为权限隔离做完了。这是个危险的误解。ServiceAccount 管的是Agent 访问 K8s API 的权限但 Agent 真正危险的地方在于它能访问集群外的东西——数据库、对象存储、第三方 API、内网服务。这些都不在 K8s RBAC 的管辖范围内。我们的做法是三层权限模型第一层是 K8s API 权限用 RBAC 严格限制每个租户的 ServiceAccount 只能操作自己命名空间内的资源而且只给必要的 verb。Agent 通常只需要读 ConfigMap、写自己的 Job其他一律不给。第二层是网络权限用 NetworkPolicy 做默认拒绝。每个租户命名空间默认拒绝所有入站和出站流量然后按需放行。Agent 要访问外部 API必须显式声明 egress 规则并且经过 DNS 白名单。第三层是凭证权限这是最容易被忽略的。Agent 要访问数据库、要调外部 API就需要凭证。我们禁止把长期凭证直接挂进 Pod而是用 Vault 的 sidecar 注入短期 tokentoken 有效期 15 分钟自动轮换。这样即使 Agent 被攻破攻击者拿到的凭证也很快失效。4.2 NetworkPolicy 的默认拒绝与 DNS 陷阱默认拒绝的 NetworkPolicy 写起来简单但有个经典陷阱拒绝所有 egress 之后DNS 也断了。Agent 解析不了域名所有外部调用全挂。所以必须显式放行 DNSapiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-egress namespace: tenant-a spec: podSelector: {} policyTypes: - Egress egress: - to: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: kube-system ports: - protocol: UDP port: 53 - protocol: TCP port: 53放行 DNS 之后还要注意 DNS 本身可能被滥用做数据外泄。我们额外部署了 DNS 审计记录所有查询对异常域名比如随机字符串、已知的隧道域名做告警。这个手段在真实攻防里救过我们一次——某个租户的 Agent 被注入恶意代码后试图通过 DNS 查询外泄数据被审计规则拦下了。4.3 工具调用的权限代理Agent 的工具调用是权限收口的关键点。我们不让 Agent 直接持有数据库密码或 API key而是通过一个**权限代理Tool Proxy**来中转。Agent 调用工具时请求先到代理代理校验租户身份、校验工具白名单、注入真实凭证再转发到目标服务。这个代理的价值在于第一凭证不落地到 Agent 进程泄露风险大幅降低第二所有工具调用都有审计日志谁在什么时候调了什么工具、传了什么参数一清二楚第三可以做细粒度的限流和配额防止某个 Agent 疯狂调用外部 API 把配额打爆。代理本身用 mTLS 双向认证Agent 侧持有的是短期证书由集群内的 CA 签发。证书轮换周期 24 小时配合 cert-manager 自动管理。5. 可观测性Agent 的黑盒怎么打开5.1 Agent 的可观测性和微服务不一样普通微服务的可观测性三板斧——Metrics、Logging、Tracing——在 Agent 场景下都要改造。Metrics 方面Agent 的指标不只是 CPU、内存、QPS更重要的是任务维度的指标任务成功率、平均轮次、工具调用次数、LLM token 消耗、单任务成本。这些指标业务团队关心平台团队也关心因为它们是容量规划和成本分摊的依据。Logging 方面Agent 的日志量极大一次任务可能产生几万行日志因为每一轮 LLM 交互、每一次工具调用都要记录。全量采集成本太高我们的策略是分级采样错误日志全采正常日志按 1% 采样关键节点任务开始、任务结束、工具调用全采。这样既控制了成本又保证了问题可追溯。Tracing 方面Agent 的调用链是动态的、可能循环的传统的 trace 模型一个请求一条链不完全适用。我们用 OpenTelemetry 的 span 来表达每一轮交互用 trace 来表达整个任务循环通过 span 的父子关系体现。这样在 Jaeger 里能看到一个任务完整的执行树包括每一轮 LLM 调用和工具调用的耗时。5.2 用 eBPF 做运行面监控Agent 跑在 Kata VM 里传统的 sidecar 采集方式有局限因为 VM 内部对宿主机是半透明的。我们引入了 eBPF 做运行面监控在宿主机层面采集 Agent 的系统调用、网络连接、文件访问。这样即使 Agent 在 VM 里做了什么可疑操作宿主机也能看到。eBPF 的另一个用途是异常行为检测。我们定义了一组规则Agent 进程如果尝试连接非白名单地址、尝试访问敏感文件路径、尝试执行危险 syscall就触发告警并可选地阻断。这套机制和 Kata 的隔离形成纵深防御——Kata 保证即使逃逸也逃不出 VMeBPF 保证在逃逸之前就能发现异常。提示eBPF 程序要针对内核版本做兼容性测试。我们线上节点内核版本不统一踩过 eBPF 程序在旧内核上加载失败的坑。建议用 libbpf 的 CO-RE 特性一次编译到处运行减少维护成本。5.3 成本分摊与配额多租户平台绕不开成本分摊。Agent 的成本主要来自三块计算资源、LLM token、外部 API 调用。计算资源可以通过 namespace 的 ResourceQuota 统计LLM token 和外部 API 调用则要通过工具代理的日志来统计。我们做了一个成本看板按租户、按项目、按天聚合数据来源是 Prometheus 加工具代理的审计日志。每个租户有月度预算超预算自动降级——批处理 Agent 排队交互式 Agent 限流。这个机制上线后整体成本下降了约 25%因为很多团队发现自己有大量低效的 Agent 在空跑。6. 那些文档里不会写的坑6.1 Kata 和 GPU 的兼容性问题如果 Agent 要用 GPU 做推理Kata 的配置会复杂不少。Kata 支持 GPU 直通但需要节点上正确配置 VFIO、正确绑定设备而且不同厂商的 GPU 配置方式不一样。我们用的是 NVIDIA需要装nvidia-container-toolkit的 Kata 适配版本并且在 Kata 配置里声明 GPU 设备。踩过的坑是GPU 直通后VM 内的驱动版本必须和宿主机匹配否则会出现设备可见但无法使用的情况。排查这个问题花了整整两天因为报错信息非常隐晦。6.2 镜像拉取的性能瓶颈Kata 每个 Pod 都要起 VMVM 启动时要挂载 rootfs如果镜像很大启动会非常慢。我们一开始用普通镜像一个 Agent 镜像 2GB冷启动要 8 秒以上。后来做了两件事一是镜像分层优化把不常变的基础层和常变的业务层分开基础层预拉到节点二是引入镜像加速用 Dragonfly 做 P2P 分发大镜像的拉取时间从分钟级降到秒级。6.3 租户误删资源的防护多租户平台最怕的是租户误操作把别人的资源删了。RBAC 能防住跨命名空间的操作但防不住租户在自己命名空间里误删关键资源。我们加了删除保护关键资源比如租户的 Agent 配置、凭证打上protection.finalizer标签删除时先走审批流程。同时用 OPA Gatekeeper 做准入控制禁止删除带有特定标签的资源。6.4 升级 K8s 版本时的 RuntimeClass 兼容性K8s 升级是个大工程Kata 的 RuntimeClass 在跨版本升级时出过问题。1.24 到 1.25 升级时containerd 的配置格式有变化Kata shim 的路径变了导致所有 Agent Pod 起不来。教训是升级前一定要在预发环境完整验证 Kata 的运行时链路包括 Pod 创建、VM 启动、网络连通、存储挂载。我们后来把这条加进了升级 checklist再没出过类似问题。7. 从能跑到好用中间隔着工程化回头看这套平台的建设过程最大的体会是多租户 AI Agent 平台的难点从来不是能不能跑起来而是能不能安全、稳定、可计量地跑起来。Kata 解决了隔离调度插件解决了资源分配权限代理解决了凭证安全eBPF 和 OpenTelemetry 解决了可观测性成本看板解决了计量。每一块单独看都不复杂但组合起来就是一个完整的工程体系。如果让我给正在做类似事情的团队一个建议那就是先把隔离和权限做扎实再考虑性能和成本优化。我见过太多团队一上来就追求高密度、低成本结果隔离没做好一个租户的 Agent 把整个集群搞挂或者出了数据泄露后面补窟窿的成本远高于一开始就做对。隔离是地基地基不牢上面盖什么都是危房。最后分享一个实操小技巧给每个租户的 Agent 加一个熔断器。当某个租户的 Agent 在短时间内触发大量异常工具调用失败、资源超限、网络拒绝自动把该租户的新任务排队同时告警。这个机制能防止单个租户的问题扩散到整个集群我们在一次真实故障中靠它把影响范围控制在了单个租户内其他租户完全无感。