250个AI智能体同时在线你猜我们用了多少个Pod答案是8个。这个方案说出来很多人第一反应是疯了但它在我的生产环境里已经稳定跑了两个多月。这篇不是概念科普是一份实战复盘为什么放弃一Pod一Agent的标准姿势、250个Agent怎么塞进8个Pod、塞进去之后又踩了哪些坑全部摊开讲。先交代一下背景。我负责的业务线需要部署250个垂直场景的AI智能体包括售前咨询、售后答疑、内容审核、合同初审、竞品情报采集、舆情监控等。这些Agent本身不做大模型推理它们的核心工作是把用户请求拆解成多步任务、按需调用外部LLM API和工具、维护各自的上下文记忆。也就是说Agent更像是大脑皮层的外围神经负责编排和调度真正的算力消耗在云端推理接口那边。明确了这一点整个容量规划就立在了一个非常扎实的基础上单个Agent的运算压力并不大真正吃资源的是数量本身。1. 8个Pod装250个Agent这个容量方案是怎么算出来的1.1 一Pod一Agent看起来很美但集群先扛不住了刚开始团队讨论时最自然的方案就是常规的一Pod一Agent250个Agent直接开250个Pod隔离干净、互不干扰、扩容方便。这个方案本身没有错但把事情放到真实集群环境里看问题就来了。首先是Kubernetes集群的承载上限。默认配置下单个节点能跑的Pod数量是110个250个Pod即使只分到5个节点上也会把一个非专业的大集群压得很难受。每多一个Podetcd里就多一组元数据kubelet的watch连接数、集群DNS的QPS都在涨。业务高峰期一波动经常出现Pod调度Pending、API Server响应变慢这类次生问题。其次是资源浪费。我们实测过单个Agent在空闲状态只占大约80MB内存处理一次完整任务流的峰值内存也就600MB左右CPU平均占用更是只有0.15到0.25核。如果按一Pod一Agent去分配资源为了留足单Pod的缓冲空间每个Pod至少得给0.5核和1GB内存结果就是大量资源被闲置。最后一根稻草是IP地址。250个Pod意味着250个Pod IP加上Service的ClusterIP很快就摸到了VPC网段的规划上限。我们不想为这个事再去动底层网络架构。1.2 从资源实测数据反推出的Pod规格在确定8个Pod之前我先做了一周的压测把业务上要跑的250个Agent按类型抽样了20个放在测试环境里做全量任务流模拟采集真实资源占用。指标空闲单任务峰值连续任务均值CPU0.05核0.6核0.21核内存80MB620MB310MB文件描述符12个47个23个对外连接数2个9个4个按照均值估算250个Agent合在一起大约是52核CPU和80GB内存。但均值只是一个参考不能直接照搬因为Agent触发任务的时间是随机的峰值可能集中在同一秒。我当时的判断是按峰值的20%余量来规划总资源也就是需要约65核CPU和100GB内存。8个Pod是我试出来的中间值。在一Pod装全部Agent的方案里单个Pod要挂250个进程炸一个Pod等于全线崩溃爆炸半径太大。而如果拆成20个Pod每个Pod只放12个左右Agent看起来更稳健但Pod数量又上去了。8个Pod刚好是分界点每个Pod平均挂31个Agent既保留了Pod级故障隔离能力又把元数据和网络开销压到了可接受范围。按31个Agent平均分摊每个Pod需要大约8核CPU和12GB内存。考虑到Pod内还有运维Sidecar和监控进程我给每个Pod的原则是requests 8核/12GBlimits 16核/32GB。8个Pod总共要了128核和256GB资源上限实际上平均只用了一半不到。1.3 为什么选大Pod而不是小Pod横向堆有人会问那为什么不拆成32个小Pod每个Pod挂8个Agent不是更灵活吗我的回答是灵活性是要付钱买单的而且买券还不一定换得来稳定性。小Pod多意味着调度单元多、端口资源占用多、DNS记录多、日志采集任务多。Kubernetes的调度器本来就是一个中心化组件Pod越多它的决策压力越大。我见过不少集群因为Pod数量暴涨导致调度器在节点间玩命搬运工作负载最后整体性能还不如少而精的大Pod方案。大Pod方案把资源管理的复杂度从集群层下沉到了进程层也就是我们常说的把压力放在应用内部。这样做的前提是你有一套可靠的进程级治理机制比如后面的supervisor框架和隔离策略。如果没有这套机制大Pod确实是火葬场但如果你能掌控它收益非常明显运维对象从250个Pod降到8个Pod排查问题时的视角一下子清爽了很多。2. Pod内部的宿舍布局31个Agent如何在一个Pod里共处2.1 多容器还是单容器多进程我最终选了后者决定一个Pod放31个Agent之后紧接着的问题就是这31个Agent是以容器为单位拆分还是全部塞进一个容器里我的选择是单容器多进程Pod里除了主Agent容器只有两个Sidecar一个是日志采集一个是监控指标暴露。理由有三个第一资源利用效率。容器本身不是免费的每个容器都会启动一个单独的用户态进程树还有自己的监控和日志重定向。31个容器意味着同一份依赖要加载31次光是Python解释器和Agent运行时基础镜像里的公共库就能吃掉好几个GB的重复内存。第二网络拓扑复杂度。同一Pod内的容器共享网络命名空间端口确实不冲突但容器间的进程间通信、共享内存、信号通知都会绕一层。而单容器多进程可以直接用Unix Socket、共享内存、进程信号这些最朴素高效的机制延迟能压到微秒级。第三故障排查直觉。多容器场景下一个Agent出问题你得先判断是哪个容器、再进入容器、再看进程链路太长。单容器多进程里我直接ps aux就能看到全部31个进程谁CPU高、谁内存涨、谁僵死一眼就定位了。2.2 进程资源隔离cgroup和OOMScoreAdj的组合拳同一容器内的多个进程共享同一个cgroup如果不做额外隔离就很容易出现一个Agent内存泄漏把整个Pod的可用内存吃光最后OOM Killer随机挑进程杀掉运气不好就是全场陪葬。解决办法是双层的。第一层我给每个Agent进程单独分配一对CPU绑定和内存阈值。具体做法是用systemd的scope或者直接cgroup v2子目录给每个Agent挂一个独立的子cgroup。CPU方面用cpuset做物理核绑定31个进程均匀分配到Pod申请的8个核上避免进程在核间频繁迁移导致缓存命中率下降。内存方面通过memory.high设置软上限超过阈值就回收page cache而不是直接进OOM。第二层是设置OOMScoreAdj优先级。我把核心Agent的OOMScoreAdj调低把非核心的辅助进程调高。这样即使整个容器内存真的耗尽OOM Killer优先杀的是辅助进程而不是核心业务Agent相当于给系统留了弃车保帅的余地。2.3 目录、配置与启动参数的命名规范31个Agent共用一个容器最怕的是各自配置串味。我写了一个强制规范每个Agent拥有独立目录比如/agent/run/agent-001下面分config、data、log、tmp四个子目录。通用配置通过Kubernetes ConfigMap注入后挂载到/agent/shared每个Agent自己的覆盖配置则放在config/agent.yaml。这样既保证了公共配置能批量更新又允许每个Agent有独立的密钥和参数。启动参数这块我踩过一个小坑一开始图省事一个Agent进程用--port这种命令行参数指定端口后来31个进程要维护31套端口号手写容易出错。后来改成统一从环境变量读取配置端口分配完全由启动脚本里的声明式映射决定agent-001 - 9101、agent-002 - 9102依次类推到agent-255。规则一旦固定写脚本和排查都轻松了。3. 高密度Pod里的通信设计250个Agent不是孤岛3.1 内部通信走本地Socket外部走网关250个Agent之间是有协作的。比如一个客户投诉处理的Agent需要调用工单创建Agent和话术生成Agent来完成任务。这种复杂度通信设计搞不好整个系统就是一团乱麻。Agent之间的通信我分成两类跨Pod的走消息队列Pod内部优先走本地Unix Socket。跨Pod通信直接依赖Pod间的网络但这里有个细节我不建议250个Agent直接互相通过Service的DNS名访问因为连接太多、DNS解析压力太大。正确的做法是Agent之间的消息全部异步化通过Redis Stream或Kafka转发。一个Agent需要另一个Agent协作时只要往对应的消息队列topic里投递消息接收方订阅自己的topic两边不需要建立长连接互相之间也别管对方的Pod IP。Pod内部的通信则更进一步。我把31个Agent之间的高频协作全部改成本地Unix Socket。每个Agent监听一个socket文件比如/agent/run/agent-009/agent.sock另一个Agent通过这个socket直接给它发JSON命令。实测下来单次内部调用的P99延迟在1ms以内比走网络至少快5倍而且完全不占用Pod外部的网络带宽。3.2 对外暴露统一入口加路由分发外部系统要调用这250个Agent总不能让它们各自暴露一个Service。我的做法是8个Pod共享一个Service入口Service背后是8个Pod IP然后在网关层根据Agent ID做路由分发。具体逻辑是请求进入网关时带上目标Agent ID网关通过一致性哈希或直接查映射表找到这个Agent当前所在的Pod IP再把请求转发过去。Pod内的Agent则通过本地路由表接收请求。这里要特别提醒一个点由于一个Pod里有31个AgentService的TargetPort必须聪明一点。我用的方案是让Pod里的总入口进程统一监听容器的80端口收到请求后根据路径前缀/agent/{id}/*再转发到对应的本地Agent进程。外部看是8个Pod在承接流量内部看其实是一个35层分的微型路由器。3.3 消息队列的并发控制与幂等设计异步消息化带来了另一个问题消息队列的并发消费。250个Agent如果每个都开4个并发消费线程高峰期瞬间就是1000个并发任务在跑底层LLM API和外部工具很可能被直接打爆。我的解决方案是每个Agent的消费并发数默认设为2smooth粘贴如果该Agent的QPS超过预设阈值自动将剩余消息放回队列延迟3秒再投递。这个有点像削峰填谷用时间换稳定。还有一个所有高并发系统都必须面对的坑是消息重复投递。Agent在处理任务过程中可能崩溃崩溃前消费的消息会重新入队导致同一个任务被处理两遍。我在消息结构里强制加入request_id每个Agent处理任务前先查一次本地去重表命中就直接返回上一次的结果。这个设计看着不起眼但在Agent相互协作的场景里省了不知道多少重复的LLM调用费用。4. 生命周期管理31个Agent挂了Pod不能挂4.1 启动序列先宿舍长再室友250个Agent同时重启的场面是我不想再经历第二次的。那是一个线上事故某次发版把所有Pod滚动重启后8个Pod里6个在一分钟内同时触发内存峰值原因是所有Agent进程都在同一时间建立各自的HTTP连接池、加载各自的知识索引资源争抢异常激烈。后来我在每个Pod里加了一个宿舍长进程也就是supervisor。它的职责是管理同一个Pod内31个Agent的完整生命周期包括启动、停止、重启、状态上报。启动序列被我强制改成三段式第一阶段supervisor起来后先按顺序启动10个核心基础Agent比如统一的记忆管理Agent、配置中心Agent。这类Agent是所有其他Agent依赖的基础设施必须先就绪。第二阶段等前10个全部通过健康检查后再启动11到20号Agent这批是高频业务Agent。第三阶段剩下的Agent分批每10秒启动3个直到全部就绪。整个过程约90秒但资源峰值比一次性全拉起降低了60%。4.2 健康检查的粒度Pod级探针加上进程级看门狗Kubernetes的liveness和readiness探针是Pod级别的它们无法感知Pod内部哪个进程挂了。我有一次遇到的情况是一个Pod里31个Agent挂了5个Pod本身还活着但外部请求到这几个Agent时全部超时监控整整一小时没报警因为Pod级别的探针始终是绿的。痛定思痛我做了两层检查第一层Pod级livenessProbe的接口不再只是返回ok而是由supervisor动态汇总31个Agent的健康状态。只要挂掉的Agent数超过5个这个接口就返回500Kubernetes会自动重启整个Pod。对于挂掉不超过5个的情况不需要惊动Pod因为supervisor自己就能把子进程拉起来。第二层supervisor内部每5秒做一次进程级心跳检查对每个Agent执行kill -0加状态戳验证。连续3次失败就自动重启该Agent并把事件写到容器的本地事件日志里。4.3 Agent进程的原地拉起策略就地重启Agent有一个窗口期风险正在处理中的任务怎么办。我的选择是优雅关闭加状态外置。Agent收到SIGTERM后先把当前任务的中间结果和进度写入持久卷再退出。新进程启动后读取持久化的中间状态从断点继续执行。有一个细节值得说明这个持久卷是所有8个Pod共享的读写卷所以一个Pod里的Agent挂了甚至整个Pod被删了另一台Pod里的Agent可以无缝接管任务。最终效果是在用户视角里任务只是稍微慢了一点但没有任何一个任务会真的丢失。5. 踩坑实录高密度部署下的CPU节流、OOM与连接耗尽5.1 CPU Throttling所有接口突然集体变慢的元凶上线第一周我们遇到过一个非常诡异的现象所有Agent的响应时间在业务高峰期过了某个阈值后集体变慢但看监控CPU使用率才60%。这个问题的根因是CPU限流。我把每个Pod的CPU limits设成了16核Kubernetes的CPU quota是按CFS周期时间片来算的。每个周期内Pod内所有进程可以使用的时间是16 * 100ms 1600ms。31个Agent各自的使用时间累加后一旦超过这个配额Pod就会进入Throttling状态进程被强制休眠直到下一个周期。也就是说在那一秒单个Agent的CPU使用率看起来只有60%但整个Pod的CPU时间片已经用完了后续的请求全部在排队等待下个周期的时间片。越是高密度部署这个问题越隐蔽因为单进程打不满但集体合起来远超配额。解决办法是把CPU limits从16核提高到24核同时把requests从8核降到6核让调度器有更多空间。但更关键的是我在监控里加了CPU Throttling时间的指标一旦这个值持续超过10%就说明进程在频繁被限流必须立刻调整。5.2 进程OOM但Pod健康检查仍然正常另一个让我半夜爬起来的问题是内存OOM。有个Agent因为一个隐蔽的内存泄漏RSS涨到了1.8GB突破了我在cgroup里设置的memory.high软上限。理论上它应该触发page cache回收但因为泄漏的是匿名内存没办法回收只能一路涨到cgroup硬上限最终被OOM Killer杀掉。诡异的是Pod和进程都没被Kubernetes重启。为什么因为我的Pod级livenessProbe是从supervisor拉健康状态而supervisor还活着livenessProbe返回的还是200。但那个Agent确实死了。后来我加了见双重保险supervisor会在Agent死亡事件里标记异常状态并把这个状态写进一个本地心跳文件livenessProbe除了拉超时节点还要检查心跳文件里最近一次异常事件的时间戳。如果发现最近5分钟内有OOM事件直接触发Pod重启。5.3 文件描述符和临时端口耗尽高密度部署的隐形天花板31个Agent共用一个容器的网络命名空间不出意外地碰到了两个硬限制。第一个是文件描述符。每个Agent都要和外部LLM API建立HTTP连接连接池默认长连接。31个Agent外加supervisor和监控fd数量轻松破千。容器默认的ulimit -n只有1024跑起来不到10分钟就全部连接错误。我把Pod级ulimit -n调整为65535才解决问题。第二个是临时端口。由于31个Agent共享一个Pod IP所有向外发起的TCP连接都来自这个IP。内核的ip_local_port_range默认是32768到60999也就是约28000个可用端口。高并发下250个Agent的对外连接加起来很容易把临时端口耗尽导致新建连接直接报错。解决办法是双管齐下一方面把所有对外HTTP请求的连接空闲超时缩短及时释放临时端口另一方面把net.ipv4.ip_local_port_range扩大到15000到65535。这两个调整在高密度部署里几乎是必做的。6. 抄作业专用8个Pod部署250个Agent的关键配置参考6.1 Deployment级别的几个关键参数这里给出我配置的核心片段不一定适用于所有人但大方向值得参考。apiVersion: apps/v1 kind: Deployment metadata: name: agent-matrix spec: replicas: 8 selector: matchLabels: app: agent-matrix template: metadata: labels: app: agent-matrix spec: nodeSelector: agent-matrix: true containers: - name: agent-supervisor image: agent-runtime:2024.06 ports: - containerPort: 80 env: - name: AGENTS_PER_POD value: 31 resources: requests: cpu: 6 memory: 12Gi limits: cpu: 24 memory: 32Gi livenessProbe: httpGet: path: /healthz port: 80 initialDelaySeconds: 120 periodSeconds: 10 readinessProbe: httpGet: path: /readyz port: 80 initialDelaySeconds: 30 periodSeconds: 5 securityContext: capabilities: add: [SYS_RESOURCE] affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: app operator: In values: [agent-matrix] topologyKey: kubernetes.io/hostnamenodeSelector和podAntiAffinity的组合是为了保证8个Pod尽量分布在不同的物理机上避免一台宿主机宕机把所有Agent全部带走。6.2 supervisor脚本要点启动、守护、自愈每个Pod内的supervisor本质上是一个常驻的守护进程我用Python写核心逻辑就三个函数start()、watch()、rebuild()。start()负责按预配置的三段式顺序拉起31个Agent进程。watch()每5秒扫描一次进程表比对预期的Agent列表和实际存活列表。rebuild()负责优雅重启失联Agent并同步更新健康状态。这里有一个细节值得写出来给每个Agent分配全局唯一ID这个ID不仅用于文件名和端口号也直接落到Pod的label和日志字段里。这样的话从Kubernetes到容器内到Agent进程整条链路都能用同一个ID查问题。日志查询的效率提升了不止一个量级。6.3 监控体系不能只知道Pod活着还要知道每个Agent好用不好用高密度部署的监控维度必须下沉到进程级。我在容器里内置了一个指标暴露器每个Agent每10秒上报一次五项核心指标CPU使用率、内存RSS、在途任务数、平均响应时间、错误率。这些指标通过Prometheus的文本暴露格式输出到/metrics端口再由监控Sidecar抓走。报警规则我也写好了三级错误率连续3分钟超过10%就是Warning超过20%直接触发进程自动重启平均响应时间超过5秒就告警说明Pod可能进入了CPU Throttling内存RSS超过预设阈值的90%就要立刻拉日志查泄漏了。6.4 这个方案的适用边界与最后的扩展建议这套方案能不能直接照搬取决于Agent本身的形态。如果你家的Agent是重负载的每个都要独立跑一个embedding模型甚至本地微调模型那8个Pod装250个就是开玩笑物理资源完全撑不住。但如果Agent只是做任务编排、工具调用、提示词管理推理全部走外部API那高密度部署完全可行。我目前这个集群的资源利用率从原来的12%提升到了46%同时运维对象从250个Pod缩减到了8个光etcd的查询压力就减轻了一大截。如果下一步要继续优化我会考虑在Pod内增加基于任务优先级的抢占式调度让低优先级Agent在资源紧张时主动让位。这个逻辑和CPU时间片调度很像但放在业务层面能显著提升核心Agent的稳定性。最后说点真心话。高密度部署不是炫技它是在资源、稳定、运维复杂度三者之间做平衡的结果。如果你正在做的Agent数量也上了百建议先花一周做资源摸底再决定Pod规格。数据不会骗人只要你一开始就把进程级治理做扎实8个Pod装250个Agent并不是什么疯狂的事它只是把Kubernetes的能力用到了更细的颗粒度上。