Agent 容器化、K8s 与云原生部署

完整 Pod 配置

apiVersion: v1
kind: Pod
metadata:
  name: agent-inference-pod
  labels:
    app: agent-inference
    version: v1.2.0
    tier: inference
  annotations:
    prometheus.io/scrape: "true"
    prometheus.io/port: "8080"
spec:
  # 节点选择与亲和性
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: gpu-type
            operator: In
            values:
            - nvidia-a100
            - nvidia-h100
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchLabels:
              app: agent-inference
          topologyKey: kubernetes.io/hostname
  
  # 容器定义
  containers:
  - name: agent
    image: myregistry/agent-inference:v1.2.0
    imagePullPolicy: IfNotPresent
    
    # 资源请求与限制
    resources:
      requests:
        cpu: "2"
        memory: "4Gi"
        nvidia.com/gpu: "1"
      limits:
        cpu: "4"
        memory: "8Gi"
        nvidia.com/gpu: "1"
    
    # 端口定义
    ports:
    - containerPort: 8080
      name: http
      protocol: TCP
    - containerPort: 9090
      name: metrics
      protocol: TCP
    
    # 环境变量
    env:
    - name: MODEL_PATH
      value: "/models/llama-3-70b"
    - name: MAX_BATCH_SIZE
      value: "32"
    - name: TEMPERATURE
      value: "0.7"
    - name: LOG_LEVEL
      value: "INFO"
    
    # 健康检查
    livenessProbe:
      httpGet:
        path: /health/live
        port: 8080
      initialDelaySeconds: 30
      periodSeconds: 10
      timeoutSeconds: 5
      failureThreshold: 3
    
    readinessProbe:
      httpGet:
        path: /health/ready
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 5
      timeoutSeconds: 3
      failureThreshold: 3
    
    startupProbe:
      httpGet:
        path: /health/startup
        port: 8080
      initialDelaySeconds: 0
      periodSeconds: 5
      failureThreshold: 30
    
    # 存储卷挂载
    volumeMounts:
    - name: model-storage
      mountPath: /models
      readOnly: true
    - name: cache-storage
      mountPath: /cache
    - name: config-storage
      mountPath: /etc/agent
      readOnly: true
    
    # 日志收集
    lifecycle:
      preStop:
        exec:
          command: ["/bin/sh", "-c", "sleep 10"]
  
  # Sidecar 容器（日志收集）
  - name: log-collector
    image: fluent/fluent-bit:latest
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"
      limits:
        cpu: "200m"
        memory: "256Mi"
    volumeMounts:
    - name: varlog
      mountPath: /var/log
    - name: containers
      mountPath: /var/lib/docker/containers
      readOnly: true
  
  # 存储卷定义
  volumes:
  - name: model-storage
    persistentVolumeClaim:
      claimName: agent-models-pvc
  - name: cache-storage
    emptyDir:
      medium: Memory
      sizeLimit: 2Gi
  - name: config-storage
    configMap:
      name: agent-config
  - name: varlog
    hostPath:
      path: /var/log
  - name: containers
    hostPath:
      path: /var/lib/docker/containers
  
  # 服务账号
  serviceAccountName: agent-service-account
  
  # 安全上下文
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 1000
  
  # 镜像拉取密钥
  imagePullSecrets:
  - name: registry-secret
  
  # 重启策略
  restartPolicy: Always
  
  # 终止宽限期
  terminationGracePeriodSeconds: 60
  
  # DNS 配置
  dnsPolicy: ClusterFirst
  dnsConfig:
    options:
    - name: ndots
      value: "5"

GPU 资源管理策略

• GPU 独占模式：
  • 每个 Pod 独占整张 GPU，避免资源争抢
  • 适用于大模型推理，保证性能稳定性
  • 资源利用率较低，但性能可预测
• GPU 共享模式：
  • 使用 NVIDIA MIG 或时间片共享
  • 多个 Pod 共享一张 GPU，提升利用率
  • 适用于小模型或低负载场景
• GPU 拓扑优化：
  • 多 GPU 场景下优化 NVLink 通信
  • 使用 nodeAffinity 确保相关 Pod 调度到同一节点
  • 减少跨节点通信延迟

高级调度配置

ArgoCD GitOps 工作流

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: agent-inference
  namespace: argocd
  finalizers:
  - resources-finalizer.argocd.argoproj.io
spec:
  # 项目配置
  project: default
  
  # 源码仓库
  source:
    repoURL: https://github.com/myorg/agent-deployments.git
    targetRevision: HEAD
    path: environments/production
    helm:
      valueFiles:
      - values-production.yaml
      parameters:
      - name: image.tag
        value: v1.2.0
      - name: replicaCount
        value: "5"
      - name: resources.requests.cpu
        value: "2"
      - name: resources.requests.memory
        value: "4Gi"
      - name: resources.limits.gpu
        value: "1"
  
  # 目标集群
  destination:
    server: https://kubernetes.default.svc
    namespace: agent-production
  
  # 同步策略
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
      allowEmpty: false
    syncOptions:
    - CreateNamespace=true
    - PrunePropagationPolicy=foreground
    - PruneLast=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m
  
  # 忽略差异
  ignoreDifferences:
  - group: apps
    kind: Deployment
    jsonPointers:
    - /spec/replicas
  
  # 健康检查
  healthChecks:
  - group: apps
    kind: Deployment
    script: |
      hs = {}
      if obj.status.readyReplicas == obj.spec.replicas then
        hs.status = "Healthy"
        hs.message = "Deployment is healthy"
      else
        hs.status = "Progressing"
        hs.message = "Waiting for rollout to complete"
      end
      return hs

金丝雀发布配置

• 阶段一：5% 流量（10 分钟）
  • 部署新版本 Pod，设置权重 5%
  • 监控错误率、延迟、业务指标
  • 如果指标正常，进入下一阶段
• 阶段二：25% 流量（20 分钟）
  • 提升新版本权重到 25%
  • 持续监控关键指标
  • 收集用户反馈
• 阶段三：50% 流量（30 分钟）
  • 提升新版本权重到 50%
  • 进行 A/B 测试对比
  • 验证性能提升效果
• 阶段四：100% 流量（完成）
  • 全量切换到新版本
  • 清理旧版本 Pod
  • 更新基线配置

背景与挑战

• 背景：某大型电商平台智能客服 Agent，日均处理 1000 万 + 用户咨询
• 挑战：
  • 流量波动大：大促期间流量是平时 10 倍，需要快速扩容
  • 资源成本高：GPU 资源闲置率高，需要优化利用率
  • 部署周期长：手动部署需要 2 小时，无法快速迭代
  • 故障恢复慢：单点故障影响大，需要高可用架构

云原生解决方案

• 容器化改造：
  • 将 Agent 应用 Docker 化，镜像大小从 15GB 优化到 3GB
  • 启动时间从 10 分钟降到 90 秒
  • 实现环境一致性，消除"在我机器上能跑"问题
• K8s 编排：
  • 部署到 Kubernetes 集群，使用 HPA 自动扩缩容
  • 配置 Pod 反亲和性，确保高可用
  • 使用 GPU 共享模式，资源利用率从 30% 提升到 75%
• CI/CD 建设：
  • 基于 ArgoCD 实现 GitOps，部署时间从 2 小时降到 10 分钟
  • 实现灰度发布，降低上线风险
  • 自动化测试覆盖率 90%+，质量问题减少 80%
• 监控体系：
  • 建设 Prometheus+Grafana 监控体系
  • 实现全链路 Trace 追踪（Jaeger）
  • 日志聚合（ELK Stack），问题定位时间从小时级降到分钟级

实施成果

• 弹性能力：大促期间 5 分钟内从 50 副本扩容到 500 副本
• 资源优化：GPU 利用率从 30% 提升到 75%，成本降低 55%
• 部署效率：部署时间从 2 小时降到 10 分钟，效率提升 12 倍
• 可用性：系统可用性从 99.5% 提升到 99.99%，故障恢复时间从 30 分钟降到 2 分钟
• 迭代速度：从每周 1 次发布提升到每天 10+ 次发布

背景与挑战

• 背景：某金融机构智能风控 Agent，实时识别欺诈交易
• 挑战：
  • 合规要求：需要多地多活、数据隔离、灾备能力
  • 低延迟要求：风控决策需要在 50ms 内完成
  • 高可用要求：99.999% 可用性，不能容忍单点故障
  • 安全要求：严格访问控制、审计日志、加密传输

多集群架构设计

• 三地五中心部署：
  • 北京（主中心）：2 个集群，承载 60% 流量
  • 上海（备中心）：2 个集群，承载 30% 流量
  • 深圳（灾备中心）：1 个集群，承载 10% 流量
  • 使用 KubeFed 实现多集群联邦管理
• 流量调度：
  • 基于 DNS 的智能流量调度
  • 就近接入，降低延迟
  • 故障自动切换，保证可用性
• 数据同步：
  • 使用分布式数据库（TiDB）实现数据多活
  • 向量数据库（Milvus）主从复制
  • 消息队列（Kafka）跨集群同步
• 安全加固：
  • Istio Service Mesh 实现 mTLS 加密
  • OPA 策略引擎实现细粒度访问控制
  • 审计日志全量记录，满足合规要求

实施成果

• 可用性：系统可用性达到 99.999%，年停机时间<5 分钟
• 延迟：P99 延迟 38ms，满足 50ms SLA 要求
• 容灾能力：单数据中心故障，30 秒内自动切换，零数据丢失
• 合规：通过等保三级、金融行业合规审计
• 业务价值：年拦截欺诈交易 10 万 + 笔，保护资金 5 亿元

云原生部署最佳实践

• 容器化优先：
  • 所有应用容器化，实现环境一致性
  • 优化镜像大小，提升启动速度
  • 使用多阶段构建，减少镜像层数
• 声明式配置：
  • 使用 Helm/Kustomize 管理 K8s 配置
  • 配置版本化，支持回滚
  • 配置与代码分离，便于管理
• 自动化一切：
  • 自动化构建、测试、部署
  • 自动化扩缩容、故障恢复
  • 自动化监控、告警、报告
• 可观测性：
  • 建设 Metrics/Logs/Traces 三大支柱
  • 实现端到端追踪
  • 建立 SLO/SLI 体系
• 安全左移：
  • 安全扫描集成到 CI/CD
  • 镜像漏洞扫描、依赖检查
  • 最小权限原则、零信任网络