多租户Kubernetes上安全部署AI Agent：隔离、调度与实操指南

在多租户 Kubernetes 集群上大规模安全部署 AI Agent这个话题我带着团队在真实生产环境里磕了小半年。刚接到任务时觉得没什么难的毕竟 Kubernetes 部署早就是常规操作了可真把 Agent 这种“会自己调用自己、能自主行动”的负载放进去原有的那套隔离、调度、安全模型全被冲得七零八落。这篇文章我把从方案选型、资源画像、安全加固到故障排查的完整过程整理出来权当给准备上车的同学一份可以参考的路线图也顺便说说我踩过哪些不该踩的坑。1. 多租户场景下的架构设计与隔离方案选型1.1 为什么多租户集群是 AI Agent 部署的必然选择先说背景。公司内部做 AI 应用的不止一个团队客服部要对话机器人运营部要内容生成助手研发部要做代码审查 Agent还有财务、法务都在排队提需求。如果每个团队都自己搭一套 Kubernetes 集群再去单独管理 GPU 资源池和模型服务成本很快会失控。我们当时粗算过一笔账分开部署的话光 GPU 闲置率就能到 40% 以上更不用说每套环境都要安排人运维。共享一套多租户 Kubernetes 集群就成了唯一合理的选择。所有团队的 Agent 工作负载运行在同一批节点上由平台团队统一管理底层资源、镜像仓库、模型存储和网络出口各租户之间通过逻辑边界隔离开。这个思路和 SaaS 化改造的底层逻辑是一样的基础设施共享数据与权限隔离错峰填补资源缺口。但 AI Agent 和普通微服务不一样它不是单纯的“处理请求-返回结果”它有状态、有推理上下文、可能要长时间运行、还要动态调用各种工具和外部 API。这就导致集群里跑的不再是“一批无状态 Pod”而是一批“带大脑、会动手的逻辑单元”。隔离方案如果选得不对后面所有事情都会跟着别扭。1.2 隔离方案选型Namespace 逻辑隔离、虚拟集群还是物理集群常见的多租户隔离方案有三级我逐一评估过。第一级是纯 Namespace 逻辑隔离。每个租户一个 Namespace配上 ResourceQuota、LimitRange、RBAC 和 NetworkPolicy。这套方案的好处是轻量、易管理一个集群全部搞定资源利用率最高。缺点也明显租户之间跑在同一套内核上如果某个 Pod 炸了波及宿主机整个集群都会受影响。此外 Kubernetes 原生的 RBAC 对象是集群级的要做“租户管理员只能管自己 Namespace”的权限模型需要写一堆 Role 和 RoleBinding初期配置工作量不小。第二级是虚拟集群方案比如用 vcluster 这类工具在每个租户里再拉起一个轻量级 Kubernetes 控制面。租户看到的是“自己有一个集群”可以自己定义 CRD、装 Operator互不影响。但虚拟集群会引入额外的控制面开销对大规模比如几百个 Agent场景会产生性能损耗而且和底层网络插件的适配偶尔会出问题。第三级是物理隔离每个租户独占一套集群或一批节点。安全性最强但成本最高和我们共享资源池的初衷完全违背。我最终选了第一级作为主方案所有租户共享一个 Kubernetes 集群用 Namespace 划分边界用 ResourceQuota 限制消耗用 NetworkPolicy 阻断跨租户网络流量用自定义 RBAC 收敛权限。同时为高安全等级租户单独划出一个节点池配合节点污点Taint实现物理层面的隔离兜底。用表格看更直观方案隔离强度资源利用率运维复杂度适用场景Namespace 逻辑隔离中最高低多数企业内部多团队共享虚拟集群中高高中租户需要自定义 CRD / Operator节点池物理隔离高中中高安全等级租户、合规要求严格提示不建议一开始就追求所谓“绝对隔离”。多租户安全的本质是把风险控制到可接受范围而不是在物理上把所有东西分开。先想明白你的威胁模型是防内部误操作还是防恶意攻击还是满足审计合规要求再决定方案。1.3 租户资源边界设计配额配置与命名规范选定 Namespace 方案后第一步就是把“租户”这个抽象概念落成具体对象。我按“一个业务团队 一个租户 一个 Namespace 集合”来建模。注意高压租户和普通租户的资源配额完全不能一样否则必然出现某个团队把 GPU 全占了、其他团队排队等推理的情况。ResourceQuota 是资源边界的第一道闸门。以一个中型租户为例我给出的初始配置是apiVersion: v1 kind: ResourceQuota metadata: name: quota-agent-team namespace: team-a spec: hard: requests.cpu: 8 requests.memory: 16Gi limits.cpu: 16 limits.memory: 32Gi requests.nvidia.com/gpu: 0 persistentvolumeclaims: 5 count/deployments.apps: 20 count/pods: 80这里有两个细节值得注意。一个是 requests 和 limits 必须分开设置而且差距不能太小也不能太大。差距太小租户没法应对突发流量差距太大会造成严重的资源闲置浪费。我们内部的经验是 CPU limits 控制在 requests 的 1.5 到 2 倍之间内存 limits 控制在 1.5 倍左右因为内存是不可压缩资源超卖太多容易触发 OOM。另一个是 GPU 配额我故意没有写死在 ResourceQuota 里只给了个 0 作为占位。原因是 GPU 这种稀缺资源如果写死在配额里调度的灵活性会大打折扣——某个租户如果临时不跑推理任务剩余的 GPU 权就全部被浪费了。我稍后会在调度章节专门讲这部分怎么处理。命名规范同样重要。我采用租户名-环境名的格式比如team-a-prod、team-a-staging并通过标签tenant: team-a和env: prod标记所有资源。这样后面做 NetworkPolicy 选择器、日志检索、成本分摊的时候都方便得多。这个看似不起眼的细节在实际运维中帮我们省了大把时间。2. AI Agent 负载画像与调度策略设计2.1 AI Agent 工作负载的资源画像它和普通 Web 服务的差异有多大给 AI Agent 做调度策略之前必须先搞清楚它的资源消耗规律。我和很多同行聊过发现大家都容易犯一个同样的错误把 Agent 当成普通高并发 Web 服务来配资源结果要么扩容姗姗来迟要么 OOMKilled 一路狂飙。从负载类型来看Agent 大体分为三类。对话型 Agent比如智能客服特点是请求频率高、单次推理短、对延迟极度敏感GPU 和内存的消耗呈脉冲状执行型 Agent比如代码生成 Agent、自动化测试 Agent特点是长任务居多单次执行要反复调用大模型往往要跑十几分钟甚至几小时资源占用呈平台期决策型 Agent比如多 Agent 协作的调度中枢除了推理还要做大量工具调用和上下文管理内存占用最高。我和一个做客服系统的朋友交流过他们的对话 Agent 白天高峰期每个实例要同时维持 50 多路会话上下文内存直接飙到 8GB 以上而到深夜又能降到 2GB 以下。这种“白天高水位、夜间低水位”的模式如果用传统微服务的固定副本数去部署要么白天疯狂排队要么晚上白白烧钱。从调度角度看AI Agent 还带着两个普通工作负载没有的特性。第一它是带状态推理的同一个用户的多轮对话要尽量路由到同一个实例上否则上下文切换会带来极高的额外成本第二它对故障恢复的容忍度极低推理进行到一半实例挂了重启之后如果上下文没有持久化整个对话就断了。所以调度策略不能只看 CPU 内存还得兼顾会话亲和性和恢复效率。2.2 从节点池到 GPU 资源调度器配置实战集群节点我按用途拆成了三个池子通用 CPU 池、GPU 推理池和 GPU 高优池。每个池子的节点都打上不同的标签画成一张心智图的话大概是这样的控制面节点跑系统组件CPU 节点池跑 Agent 运行业、API 网关、向量数据库等轻量组件GPU 推理池跑常规对话类推理任务允许超卖GPU 高优池专门跑核心业务 Agent节点数少但全部预留 GPU。调度策略的核心是让 Pod 精确落到对应的池子里。我拿 GPU 推理池举例节点上的标签是node-typegpu-infer同时打了 Taintgputrue:NoSchedule。对应的 Deployment 配置tolerations: - key: gpu operator: Equal value: true effect: NoSchedule nodeSelector: node-type: gpu-infer这样普通无 GPU 需求的 Pod 就算被调度器看上也会因为 Taint 无法落到 GPU 节点上避免把珍贵的 GPU 节点资源白白吃掉。GPU 分配这个环节我试过好几种方案最后把结论分享出来。早期我图省事给每个 Agent Pod 直接申请完整 GPU 卡即nvidia.com/gpu: 1结果显存利用率非常难看很多 Agent 的推理模型只占了 GPU 显存的三分之一剩下全空着。后来我尝试过 MIG 切片让多个 Agent 共享一块物理 GPU但在一些老型号卡上驱动和 MIG 的兼容性不好Agent 推理性能波动很大。MPS 模式我没有上生产因为它在多个租户同时跑时容易互相抢占算力稳定性风险太高。最终我采用的折中是常规租户按整卡分配 GPU但对显存占用较小的 Agent 配两个 Pod 共享一张卡前一个 Agent 配nvidia.com/gpu: 0走 GPU 节点池但不用卡后一个配nvidia.com/gpu: 1靠调度器的 binpack 策略尽量挤到同一节点。这样既不牺牲稳定性又能把 GPU 利用率从 35% 拉到 60% 左右。2.3 会话亲和性、优先级与自动伸缩调度器还有一个容易踩坑的点是会话亲和性。对话型 Agent 的上游服务通常是无状态的Kubernetes Service 的负载均衡会随机把请求打到不同 Pod 上。如果 Agent 没有把会话上下文放到 Redis 之类的共享存储里那么第二句话就可能落到另一个没有上下文记忆的实例上用户得到的就是牛头不对马嘴的回答。我给的解决方案分两层。第一层是尽量在 Agent 应用层做状态外置把多轮对话的上下文交给外部的向量数据库或 Redis 维护让每个实例都能快速重建上下文这是最彻底的解法第二层是在 Service 层配置会话亲和性让同一个来源 IP 的会话尽量路由到同一个 Pod用sessionAffinity: ClientIP加上超时时间来兜底。注意如果 Agent 前面还挂了网关做负载由网关透传的真实客户端 IP 才能对齐否则亲和性会失效。优先级和抢占策略用在跨租户的节点资源竞争场景。我给核心业务租户的 Agent Pod 设置了更高的 priorityClassapiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: high-priority value: 1000 globalDefault: false description: 核心业务 Agent 专用优先级然后通过priorityClassName: high-priority让核心租户的 Pod 在资源紧缺时优先被调度。这里要小心一个副作用如果低优先级 Pod 已经把节点资源占满高优先级 Pod 到来时会触发抢占被抢占的 Pod 会被重新调度。如果同时有几十个低优先级 Pod 被挤掉集群会经历一次“调度风暴”CPU 消耗会瞬时时升高。所以在开启抢占前我先通过 ResourceQuota 把每个租户的资源上限压住让“配额内调度”优先于“优先级抢占”发生减少抢占频率。自动伸缩方面HPA 的指标不能只用 CPU。Agent 这种负载CPU 使用率和 QPS 之间相关性很弱高峰期往往是内存先爆。我建议把 HPA 的触发指标从 CPU 换成 QPS由外部 metrics API 提供和内存双维度同时设置一个最小副本数兜底避免冷启动把第一个用户活活卡死。3. 安全部署AI Agent 带来的安全模型冲击3.1 Agent 自主性带来的安全边界问题传统 Kubernetes 的安全模型我总结成一句话容器内的进程被当做一个“不会主动出格的程序”安全重点在于防止外部入侵。但 AI Agent 完全不一样它被设计成“会主动调用工具、会读写数据、会访问外部 API”的执行者。一个看起来无害的 Agent为了完成“帮用户整理今天的工作日志”的任务可能会自动去拉取邮件、访问文档系统、调用内部 BI 接口、甚至执行一段自动生成的代码。在多租户环境下这就成了一个大问题一个租户的 Agent 如果被提示注入攻击诱导完全有可能拿着它自己的合法权限去访问另一个租户的数据接口。传统的“一个 Pod 绑定一个 ServiceAccount”模型根本没考虑到这种“内部员工带着合法工牌搞破坏”的场景。我做的第一道防御是收敛 ServiceAccount 权限。默认的 default ServiceAccount 必须禁用每个 Agent 配一个只读的专用 ServiceAccount且权限范围严格限定在自身 Namespace 内。我把这个要求直接写进了平台规范任何 Agent 的 Deployment 不允许使用默认 ServiceAccount这成了日常安全审计的第一检查项。第二道防御是给 Agent 的“自主行动范围”套护栏。凡是需要调用外部服务的 Agent必须在应用层配置允许清单只放行目标域名或目标 API 前缀。像内部文档系统、代码仓库这类敏感数据源一律先过一层代理由平台统一鉴权后再放行。等于说 Agent 可以“想得多”但不许“走太远”。3.2 RBAC 权限模型设计租户管理员应该拥有什么多租户模式下 RBAC 的设计核心原则是租户管理员只拥有他自己 Namespace 的管理权限不能触碰集群级别的对象。我创建了三种角色平台管理员管整个集群只有平台 team 的人能拿到租户管理员可以管理指定 Namespace 下的 Deployment、Service、ConfigMap、Secret 等资源但删不了 ResourceQuota更碰不了 Node租户只读成员只能查看资源状态和日志用于开发排查问题。具体实现时用 Role 和 RoleBinding 绑定到租户自己的 NamespaceapiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: team-a name: tenant-admin rules: - apiGroups: [apps, ] resources: [deployments, pods, services, configmaps, secrets] verbs: [get, list, watch, create, update, patch, delete] - apiGroups: [, events.k8s.io] resources: [events] verbs: [get, list, watch]注意 Role 里我刻意没有给 secrets 的 delete 权限。有个租户管理员曾经误删了正在被 Agent 引用的模型 API Key导致生产 Agent 集体罢工半小时。从那以后所有高危操作删除 Secret、修改 ResourceQuota、修改 NetworkPolicy的权限都收到平台层租户管理员要变更必须提工单由平台执行。租户之间的跨 Namespace 访问在 Kubernetes 里默认就是禁止的RBAC 按 Namespace 隔离但要注意别被容器镜像里的“隐藏需求”绕过去如果你的 Agent 需要访问共享的模型服务 Namespace不要直接给租户管理员开通跨 Namespace 权限而是在模型服务 Namespace 里创建一个专用的只读 ServiceAccount把凭证作为 Secret 挂载到租户 Namespace 里。这样模型服务被访问的权限是固定的、可控的而不是泛化的。3.3 网络策略、镜像供应链与密钥管理NetworkPolicy 是隔离租户网络的第二道关键闸门。默认的 Kubernetes 集群 Pod 之间是全部互通的这和裸地把所有租户丢进同一个大房间没有区别。我在每个租户 Namespace 里都配置了“白名单”模式的 NetworkPolicy拒绝所有入站流量只放行从网关 Namespace 和同租户 Pod 进来的流量。一个典型的配置apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny namespace: team-a spec: podSelector: {} policyTypes: - Ingress - Egress --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-gateway namespace: team-a spec: podSelector: {} policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: name: ingress-gateway注意第二段策略里我用的是 namespaceSelector而不是 ipBlock。原因是网关服务后面如果做弹性扩容Pod 的 IP 会频繁变化用 namespace 标签选择器可以自动适配新扩出来的 Pod不用手动维护 IP 列表。镜像供应链这一块多租户集群里最容易出问题的是镜像拉取凭据管理。如果有租户把私有镜像仓库的认证 Secret 直接放到他们的 Namespace 里这个凭证就相当于给了租户访问整个仓库的权限哪怕是没拉过的其他租户镜像也能拉。我的做法是统一侧用镜像仓库的“项目级”权限每个租户对应仓库里的一个项目只授权拉取该项目下的镜像。如果 Agent 需要跨项目引用公共基础镜像由平台把这些基础镜像同步到租户项目里而不是给租户开跨项目权限。密钥管理上我不建议把模型 API Key、数据库密码这类敏感信息直接写进 ConfigMap 或明文 env。Kubernetes 的 Secret 本身只是 base64 编码不是加密需要配合外部密钥管理系统如 Vault或云厂商的 KMS 加密。我的最低要求是所有敏感信息必须放 SecretSecret 必须开启字段级加密且禁止任何非平台成员查看明文。最后补一条经验多租户环境务必开启 Kubernetes 的审计日志并采集到独立的 SIEM 平台。Agent 部署后最大的风险是“自导自演”的异常行为——一个 Agent 静默调用了某个内部系统接口如果没有审计出了问题根本无从追溯。开启审计日志会带来少量性能开销但相比事后排查的成本这笔开销太值了。4. 从 0 到 1 实操记录一套可复现的部署路径4.1 集群基础环境与多租户初始化我拿一套中等规模集群做演示3 台控制面节点、6 台 CPU 节点、4 台 GPU 节点每卡 32GB 显存Kubernetes 版本选 1.28 以上对 GPU 调度和 NetworkPolicy 的支持更成熟容器运行时用 containerd网络插件用 Calico开启 NetworkPolicy 支持存储用 Longhorn 提供 ReadWriteMany 卷。集群装好之后第一步是把多租户的基础设施铺好。我写了个初始化脚本对一个新租户执行四件事创建 Namespace 并打标签写入 ResourceQuota 和 LimitRange创建专用 ServiceAccount 和 RBAC 绑定部署默认拒绝的 NetworkPolicy。命令大概是这样kubectl create namespace team-a --dry-runclient -o yaml | kubectl apply -f - kubectl label namespace team-a tenantteam-a envprod kubectl apply -f quota-team-a.yaml kubectl apply -f sa-team-a.yaml kubectl apply -f rbac-team-a.yaml kubectl apply -f netpol-team-a.yaml这一套流程跑通后租户管理员拿到的就是一个“被圈住”的 Namespace他可以在里面自由部署自己的 Agent 应用但无法越界。我在这里特别强调一下 LimitRange 的必要性ResourceQuota 管的是总量LimitRange 管的是单 Pod 的上下限。如果只有配额没有 LimitRange一个粗心的租户可能提交一个请求 100Gi 内存的 Pod——配额可能拦得住但在那之前调度器已经因为这个离谱请求浪费了资源评估的时间。4.2 一个标准 Agent 工作负载的完整部署示例Agent 工作负载的典型架构是三层前端入口负责会话接收、Agent 运行时负责意图识别、工具调用编排、模型推理服务LLM 后端通常跑 GPU 池。我贴一段核心的运行时 Deployment稍作简化但保留了最关键的安全和调度配置apiVersion: apps/v1 kind: Deployment metadata: name: agent-runtime-team-a namespace: team-a labels: app: agent-runtime tenant: team-a spec: replicas: 4 strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 selector: matchLabels: app: agent-runtime tenant: team-a template: metadata: labels: app: agent-runtime tenant: team-a spec: serviceAccountName: agent-runner-sa automountServiceAccountToken: false securityContext: runAsNonRoot: true seccompProfile: type: RuntimeDefault containers: - name: agent-runtime image: registry.example.com/team-a/agent-runtime:1.2.0 imagePullPolicy: IfNotPresent ports: - containerPort: 8080 resources: requests: cpu: 500m memory: 1Gi limits: cpu: 1 memory: 1.5Gi env: - name: LLM_BASE_URL value: http://llm-inference-gateway.default.svc.cluster.local - name: AGENT_API_KEY valueFrom: secretKeyRef: name: agent-secrets key: api-key readinessProbe: httpGet: path: /healthz port: 8080这里有几个我特别坚持的配置。一是automountServiceAccountToken: false只有当 Agent 确实需要调 Kubernetes API 时才把它置为 true否则一律不自动挂载 token。二是 securityContext 里强制runAsNonRoot和 seccomp 限制Agent 一旦被攻破能做的事情会被大幅压缩。三是环境变量里的密钥走 Secret 引用而不是明文写入镜像。模型推理服务我单独跑在 GPU 池Deployment 里声明nvidia.com/gpu: 1并通过 nodeSelector 确保落在 GPU 节点上。为了让三个层之间的调用链清晰可控我在模型推理服务前挂了一个独立的 ServiceAgent 运行时只能通过它访问模型不允许直连 GPU Pod 的 IP。4.3 部署后的自检清单上线前必须确认的 10 项很多团队 Agent 上线翻车不是部署失败而是上线前的自检没做到位。我整理了一份自检清单Agent 上线前逐条打勾命名空间标签和 NetworkPolicy 选择器匹配跨租户连通性测试通过ServiceAccount 配置正确没有用 default如果 Agent 需要调 Kubernetes API确认权限是最小集SecurityContext 已设置 runAsNonRoot 和 seccomp 限制镜像来自私有仓库的白名单项目且已经过漏洞扫描ResourceQuota 配额充足LimitRange 的请求值在合理范围GPU Pod 能正常调度到 GPU 节点显存申请量与实际推理需要匹配会话上下文已外置或者 Service 已配置 ClientIP 会话亲和所有敏感信息都存 Secret 并开启字段级加密日志采集和审计日志已配置Agent 的工具调用记录能查到灰度发布策略就绪异常回滚路径畅通这十项看起来很多但真正落下去之后后续维护的压力会小一个量级。自检清单不是流程走形式是救命的东西。有一次一个租户上线前没做跨租户连通性测试结果他们的 Agent 呼叫另一个租户的模型服务被 NetworkPolicy 静静挡掉生产环境立刻白屏排查花了四个小时。后来把自检清单立成硬规矩这种事故再也没有发生过。5. 常见问题与排查技巧实录5.1 Agent 集体 OOMKilled资源配额设计失衡的典型案例我们遇到过最典型的生产事故客服部门上线了新版对话 Agent上线一小时之内 8 个副本全部 OOMKilled。排查时先看 Pod 事件发现反复重启然后在节点上查 dmesg确认是内存配额被顶穿。问题出在 ResourceQuota 的设计上当初给租户的内存 limits 设置的 32Gi看似够用但 Agent 的每个 Pod 声明的内存 limits 只有 1.5Gi4 个副本加起来 6Gi按理说远没有触顶。真正的原因是模型推理时的临时峰值内存新版 Agent 在长上下文对话时单 Pod 内存能冲到 3GB 以上直接超过了 Pod 自身的 limits被 cgroup 杀掉。调优方向有两个。一是把 Pod 内存 limits 提高到正常峰值的 1.5 倍比如 4Gi二是给租户的总配额也相应上调。同时我引入了hpa按内存使用率弹性伸缩让高峰期的会话能分布在更多副本上而不是堆在少数几个胖副本里。这个案例给我的教训是Agent 的内存模型和普通 API 服务差异很大上下文长度和并发数共同影响内存消耗配 resource 时不能凭感觉拍脑袋一定要做压测拿到真实曲线。5.2 跨租户网络不通NetworkPolicy 选择器匹配的坑另一个高频问题是跨租户访问模型服务失败。现象很诡异明明 Model Service 在 default Namespace 里可以通Agent 换到租户 Namespace 后调用就超时。排查了半天发现是 NetworkPolicy 的 namespaceSelector 没匹配上。Kubernetes 的 namespaceSelector 匹配的是 Namespace 的标签而不是 Namespace 的名字。我一开始写的是matchLabels: name: default结果 default Namespace 没有name: default这个标签策略自然失效。正确的做法是给所有涉及跨租户访问的 Namespace 都打上统一的标签比如name: model-serving然后 selector 里精确匹配这个标签。这类问题隐蔽性很强因为策略配置是生效的只是一直在拒绝流量而不是报错。我的排查方法是先临时创建一个测试 Pod把它放到源租户 Namespace手动 curl 目标服务地址再用kubectl describe networkpolicy查看策略命中情况定位是选择器写错还是策略顺序写反。5.3 GPU 显存碎片化与调度失败靠什么解决GPU 资源相关的调度失败是让人最头疼的。我们早期遇到过一个现象GPU 节点的显存明明还有剩余但新 Pod 一直 Pending提示nvidia.com/gpu: insufficient。原因是几个 Pod 各占了一部分的 GPU 显存通过 MIG 或共享模式但这些显存分散在不同的物理卡上没有一张卡剩余显存能凑够新 Pod 申请的量。Kubernetes 的设备插件调度是按整卡或整设备的粒度来算的不会自动“拼凑”不同卡上的空闲显存。我给了两个解决方案。第一个是三思后统一到整卡分配所有 Agent 推理 Pod 一律申请整张 GPU显存不够就直接拒绝该 Pod避免“挤牙膏式”的分配方式。第二个是启用调度器扩展用自定义调度插件实现“显存凑量”能力这个技术门槛高、维护成本大小团队不建议上手。长期看真正的解法是把 GPU 节点池按型号统一。不要在同一个池里混用 A100、A10、RTX 3090 这种显存差异巨大的卡否则调度器面临的约束会复杂得多。统一型号之后继续用 binpack 策略把 Pod 尽量压实到少数节点上让空闲节点能整节点掉电或休眠省电又省心。5.4 提示注入攻击与模型服务滥用AI Agent 特有的安全事件最后说一个和传统 Kubernetes 安全截然不同的场景多租户下 Agent 被提示注入攻击拿合法权限干了“不该干的事”。有次审计日志发现某个租户的 Agent 在凌晨两点频繁调用内部代码仓库的查询接口每次调用间隔均匀像是自动化脚本。排查后确定是有人构造了恶意请求诱导该 Agent 的模型上下文让它把内部代码搜索接口当成普通工具去反复调用。传统 WAF 和网络策略对这类攻击基本没用因为流量的来源是 Agent 自己的逻辑IP 合法、账号合法、接口调用也合法。应对策略有三道。第一Agent 应用层要对工具调用做权限和频控不能无限制调用任何系统工具尤其要限制写操作类工具的调用次数。第二模型推理层要加输出过滤和敏感操作复核。凡是 Agent 要执行“写库、改配置、发消息、执行代码”这类高风险动作必须经过一个人工审批或者二次确认机制这是多租户环境下的底线。第三模型服务的入口要限流。Agent 的模型调用端点独立限流防止某个 Agent 被攻击后把共享的模型服务流量打满影响其他租户。这个领域的防护还在快速演进中我也一直在调整策略。但有一个原则是确定的Agent 的权限设计必须遵循最小权限而且在执行任何有副作用的操作前默认要“停下来问一下”这比任何静态安全规则都可靠。最后分享一点我的实际体会这套多租户 Kubernetes 集群跑起来之后我最大的感受是AI Agent 的安全部署难点不在“部署”而在“对人性的预判”——你永远不知道哪个租户会在凌晨提交一个占满全集群资源的怪物请求也永远不能假设 Agent 不会在中途突然干出让你瞠目结舌的事情。把所有的不确定性用配额、策略、审计和流程约束起来让系统在多数情况下即使受损也能快速恢复这才是可持续的多租户运营思路。如果你正准备把 Agent 大规模搬上集群我的建议是从小规模试点开始把配额、网络安全、权限模型和自检清单全部跑顺再放开给所有团队用这会让你少踩很多坑。