AI Agent 应该独占一个 Kubernetes Pod 吗？

在 kagent 的早期架构里，Agent 并没有各自占用一个 Pod、Service 和 ServiceAccount，而是直接运行在统一的 kagent runtime 中。这种设计实现快、资源开销小，但随着 Agent 的权限、资源需求和生命周期逐渐分化，一个关键问题就浮出水面：Pod 究竟是不是 Agent 合适的部署单元？

答案通常不是简单的“是”或“否”。Pod 很适合承载需要独立隔离、伸缩和身份的 Agent，但如果把每个轻量 Agent 都变成一套 Kubernetes 工作负载，也可能制造大量运维成本。

两种部署模型解决的是不同问题

多个 Agent 共享一个 runtime

共享 runtime 的模型可以抽象成：一个常驻进程加载多个 Agent，根据请求中的 Agent ID 选择提示词、工具和模型配置。

它的优势很直接：

• Agent 启动不需要等待 Pod 调度和镜像拉取。
• 多个 Agent 可以共享模型客户端、连接池和缓存。
• 不必为每个 Agent 创建 Deployment、Service 和 ServiceAccount。
• 本地开发、调试和批量注册 Agent 更简单。

代价也集中在同一个进程边界内：

• 一个 Agent 的内存泄漏或阻塞可能影响其他 Agent。
• 很难为不同 Agent 设置独立的 CPU、内存和副本数。
• 如果 runtime 只有一个 Kubernetes 身份，Agent 之间的权限边界容易变得模糊。
• 发布一个 Agent 的新版本，可能需要重启整个 runtime。

因此，共享 runtime 更接近一个多租户应用平台。它适合数量多、负载轻、权限相近，而且由同一团队统一管理的 Agent。

一个 Agent 对应一个 Pod

把 Agent 放进独立 Pod 后，Kubernetes 原生能力就可以直接作用于 Agent：

• 通过 requests 和 limits 隔离计算资源。
• 通过 Deployment 独立发布、回滚和扩容。
• 通过 ServiceAccount 分配最小权限身份。
• 通过 NetworkPolicy 限制网络访问。
• 分别收集日志、指标和健康状态。

这并不意味着 Pod 天然等于 Agent。Pod 是进程与资源的调度边界，而 Agent 还包含提示词、工具授权、模型配置、会话状态和任务协议。如果这些内容仍散落在外部数据库或共享服务中，创建独立 Pod 只能解决部分隔离问题。

判断部署边界时看四个维度

与其根据“每个 Agent 一个 Pod”制定硬规则，不如逐项检查 Agent 的运行特征。

权限是否不同。 一个只读取文档的 Agent 和一个能修改生产集群的 Agent，不应默认共享同一个 ServiceAccount。权限差异通常是拆分 Pod 的强信号。

资源曲线是否不同。 调用远程模型的轻量 Agent 可能只消耗少量 CPU；运行浏览器、代码沙箱或本地推理模型的 Agent 则可能需要大量内存甚至 GPU。把它们放在同一个 Pod 中，很难准确调度和扩容。

生命周期是否独立。 如果某个 Agent 需要频繁发布，或者只在任务到来时短暂运行，那么独立 Deployment、Job 或按需创建的 Pod 会更自然。

故障是否允许互相影响。 面向生产变更、支付或安全操作的 Agent，通常需要更严格的进程、网络和身份隔离。内部问答类 Agent 则可能接受共享 runtime 带来的故障域。

可以这样实践：为高权限 Agent 创建独立工作负载

下面是一个可以直接改造的最小示例。假设 Agent 暴露 HTTP 服务，并从环境变量读取模型地址；运行前需要把 ghcr.io/example/cluster-agent:1.0.0 替换成实际镜像，把模型端点改成环境中的地址。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: cluster-agent
  namespace: agents
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: cluster-agent
  namespace: agents
spec:
  replicas: 1
  selector:
    matchLabels:
      app: cluster-agent
  template:
    metadata:
      labels:
        app: cluster-agent
    spec:
      serviceAccountName: cluster-agent
      containers:
        - name: agent
          image: ghcr.io/example/cluster-agent:1.0.0
          ports:
            - name: http
              containerPort: 8080
          env:
            - name: MODEL_ENDPOINT
              value: http://model-gateway.models.svc.cluster.local:8080
            - name: AGENT_NAME
              value: cluster-agent
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 1
              memory: 512Mi
          readinessProbe:
            httpGet:
              path: /readyz
              port: http
            initialDelaySeconds: 2
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /healthz
              port: http
            initialDelaySeconds: 10
            periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: cluster-agent
  namespace: agents
spec:
  selector:
    app: cluster-agent
  ports:
    - name: http
      port: 80
      targetPort: http

应用并检查工作负载：

kubectl create namespace agents --dry-run=client -o yaml | kubectl apply -f -
kubectl apply -f agent.yaml
kubectl -n agents rollout status deployment/cluster-agent
kubectl -n agents get pods,service,serviceaccount

ServiceAccount 本身没有权限。只有 Agent 确实需要访问 Kubernetes API 时，才应额外创建最小范围的 Role 和 RoleBinding。例如，只允许读取同一命名空间中的 Pod：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: agents
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: cluster-agent-pod-reader
  namespace: agents
subjects:
  - kind: ServiceAccount
    name: cluster-agent
    namespace: agents
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: pod-reader

不要为了方便直接绑定 cluster-admin。Agent 可能接收不可信输入，提示注入、工具参数错误或模型误判都可能把过大的权限转化为真实的生产事故。

Service 也不一定要一对一

即使决定每个 Agent 使用独立 Pod，也不代表必须为每个 Agent 创建 Service。部署方式应该取决于调用模式：

• Agent 需要长期接收同步 HTTP 请求时，可以使用 Deployment 和 Service。
• Agent 只消费队列任务时，通常只需要 Deployment，不需要 Service。
• Agent 执行一次性任务时，可以使用 Job。
• Agent 生命周期很短且由控制器调度时，可以按任务创建 Pod，并在结束后清理。
• 大量同构、低风险 Agent 仍可共享 runtime，通过配置注册不同能力。

这能避免把“独立执行边界”误解成“每个 Agent 必须拥有一整套网络对象”。Kubernetes 对象越多，控制器、监控系统、策略引擎和运维人员需要处理的状态也越多。

采用建议：从共享 runtime 开始，按风险拆分

对多数团队而言，合理路径是先保留简单架构，再根据可观察到的压力拆分。出现以下情况时，可以优先把 Agent 移到独立 Pod：

• Agent 需要不同的 Kubernetes 或云端身份。
• Agent 的 CPU、内存、GPU 或伸缩策略明显不同。
• Agent 需要独立发布、回滚或故障隔离。
• Agent 会运行浏览器、代码执行器等高风险工具。
• 合规要求需要明确的网络、审计和租户边界。

如果这些条件都不存在，共享 runtime 往往更经济。Pod 是一个有力的隔离和调度工具，但不是 Agent 架构的默认答案。真正需要独立部署的不是“Agent”这个名称，而是它独立的权限、资源、生命周期和故障边界。