Skip to content

The rise of agentic AI on Kubernetes:释放新一代基础设施层 ​

“Agentic AI 不是 Kubernetes 的新 workload,而是其新的 control plane —— 它不再被动响应事件,而是主动建模、推理、决策并闭环执行。当一个 Pod 能自主诊断节点资源争用、重调度自身、动态扩缩 vLLM 推理服务的 GPU 分片,并在 SLA 降级前 47 秒触发模型热切换,K8s 就从 orchestration platform 进化成了 AI-native infrastructure。”


背景动机:为什么是现在?—— 从 LLM Ops 到 Agentic Infra 的范式跃迁 ​

过去两年,Kubernetes 生态对 AI 的支持聚焦于 deployment 层:kubeflow 管理训练任务、kserve/vLLM 部署推理服务、kueue 调度 GPU Job。这本质仍是「AI as workload」——把大模型当黑盒应用塞进现有 infra。

但 2026 年的拐点已至:Agentic AI(具身智能体)正突破单次 prompt 响应范式,转向持续感知-规划-行动(Perceive-Plan-Act)的闭环系统。典型场景包括:

  • 智能 SRE Agent:持续监控 Prometheus + OpenTelemetry 数据流,识别 kubelet 内存泄漏模式 → 自动 patch DaemonSet 配置 → 注入 eBPF 探针验证修复效果 → 向 Slack channel 发送带 diff 的 RCA 报告;
  • 自适应推理网格:基于实时 QPS、P99 延迟、GPU 显存碎片率,动态重组 vLLM 的 tensor_parallel_size 和 pipeline_parallel_size,甚至跨 Node 迁移 KV Cache;
  • 安全合规 Agent:扫描所有 Pod 的 securityContext、imagePullPolicy、hostPath 挂载,结合 NIST SP 800-190 生成风险热力图,并按优先级自动提交 PR 到 GitOps 仓库。

这些行为已远超 HorizontalPodAutoscaler 的标量阈值逻辑——它需要多源异构状态建模、因果推理(如区分 “GPU OOM” 是模型显存泄漏还是批处理过大)、可验证的行动链(Action Chain)与回滚能力。Kubernetes 原生 API 的声明式语义(Declarative API)与 Agentic AI 的意图驱动(Intent-driven)范式天然契合:Agent 不需写 YAML,而是声明 desired state(如 latency < 200ms, cost < $0.3/req),由 infra layer 自动编译为具体操作。

🔍 技术判断:当前 90% 的 “AI on K8s” 方案仍停留在「胶水层」(Glue Layer)——用 Python 脚本调用 kubectl 或 kubernetes-client。这是反模式。真正的 Agentic Infra 必须将 Agent 的 planning engine 深度集成到 K8s control plane 中,使其成为 kube-controller-manager 的对等扩展,而非外部进程。


核心技术:构建 Agentic Control Plane 的三大支柱 ​

1. Agent-native CRD:让意图可声明、可版本化、可审计 ​

我们定义 AgentPolicy CRD,作为 Agent 行为的契约载体:

yaml
# agentpolicy.yaml
apiVersion: infra.ai/v1alpha1
kind: AgentPolicy
metadata:
  name: vllm-autotuner
  namespace: ai-infra
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: vllm-prod
  intent:
    # 声明业务目标(非技术指标)
    businessObjective: "maximize throughput under $0.25/req"
    # 可观测性锚点
    observability:
      metrics:
        - name: vllm_request_latency_seconds
          query: 'histogram_quantile(0.99, sum(rate(vllm_request_latency_seconds_bucket[5m])) by (le))'
        - name: gpu_memory_utilization
          query: '100 - (gpu_memory_free{device="0"} / gpu_memory_total{device="0"}) * 100'
    # 约束条件(硬性边界)
    constraints:
      maxGpuCount: 4
      minReplicas: 2
      maxCostPerRequest: 0.25
  # 行动空间(允许 Agent 执行的操作集)
  actionSpace:
    - type: "vllm.scale"
      parameters:
        tensorParallelSize: [1,2,4]
        pipelineParallelSize: [1,2]
    - type: "pod.restart"
    - type: "configmap.update"

该 CRD 的关键设计:

  • intent 字段解耦业务目标与实现细节,避免 Agent 被绑定到特定技术栈;
  • actionSpace 显式声明权限边界,满足 SRE 的最小权限原则(Principle of Least Privilege);
  • 全字段支持 kubectl get agentpolicies -o wide 审计,符合 SOC2 合规要求。

2. 控制器架构:Reconciler + LLM Planner 的分层协同 ​

传统控制器是 Watch → Compare → Patch 三步。Agentic Controller 引入 Planner-Executor 分离架构:

go
// pkg/controller/agentpolicy/reconciler.go
func (r *AgentPolicyReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    // 1. 获取当前状态(Observation)
    obs := r.observe(ctx, policy)
    
    // 2. 调用 LLM Planner(本地运行,无外网依赖)
    plan, err := r.planner.GeneratePlan(ctx, policy.Spec.Intent, obs)
    if err != nil { return ctrl.Result{}, err }
    
    // 3. Executor 验证计划安全性 & 执行
    if ok := r.executor.Validate(plan); !ok {
        r.eventRecorder.Eventf(policy, corev1.EventTypeWarning, "PlanRejected", "Unsafe action: %s", plan.Action.Type)
        return ctrl.Result{RequeueAfter: 30*time.Second}, nil
    }
    
    return r.executor.Execute(ctx, plan), nil
}

关键实践:

  • Planner 使用 本地量化 LLM(如 Qwen2.5-7B-Instruct-GGUF),通过 llama.cpp 在 CPU 上运行,规避网络延迟与数据出境风险;
  • 所有 plan 输出必须包含 reasoning_trace 字段(JSON Schema 验证),供 SRE 审查决策逻辑;
  • Validate() 阶段执行静态策略检查(如禁止 hostPath 修改、限制 kubectl delete --all-namespaces)。

3. 状态同步:Kubernetes as the Source of Truth for Agents ​

Agentic AI 最大陷阱是「状态漂移」(State Drift)——Agent 认知的世界 ≠ 实际集群状态。我们采用 双向状态同步协议:

组件同步方式频率保障
Prometheus MetricsPrometheus Remote Write → AgentState CR15s基于 WAL 的 Exactly-Once 语义
Pod Eventskubectl get events --watch → EventStream CRD实时事件 ID 去重 + 有序交付
GitOps 状态fluxcd Webhook → GitCommitState CR每次 commitSHA256 校验

示例 AgentState CR:

yaml
apiVersion: infra.ai/v1alpha1
kind: AgentState
metadata:
  name: vllm-prod-state
  namespace: ai-infra
spec:
  observedAt: "2026-09-27T08:12:33Z"
  metrics:
    vllm_request_latency_p99: 187.2
    gpu_memory_utilization: 82.4
  conditions:
    - type: Ready
      status: "True"
      lastTransitionTime: "2026-09-27T08:12:01Z"
  gitRevision: "a1b2c3d4e5f6..."

✅ 运维启示:不要让 Agent 直接调用 kubectl get!所有状态必须经 CRD 缓存并签名,否则无法满足金融级审计要求。


运维建议:SRE 如何驾驭 Agentic Infra? ​

  1. 永远保留人工干预通道
    在 AgentPolicy 中强制配置 humanApprovalWindow: 300s,任何涉及 delete 或 scaleDown 的 Action 必须经 kubectl approve agentpolicy.v1alpha1/vllm-autotuner 确认。生产环境默认开启。

  2. 建立 Agent 行为基线(Behavior Baseline)
    使用 kubectl get agentpolicies -o json | jq '.items[].status.lastPlan.reasoning_trace' 提取历史决策链,用 sentence-transformers 计算余弦相似度,当连续 3 次相似度 < 0.6 时触发告警——可能意味着 Agent 出现认知退化。

  3. GPU 资源的「可编程隔离」
    Agentic 调度需细粒度 GPU 控制。推荐方案:

    • 使用 NVIDIA Device Plugin + k8s-device-plugin 的 nvidia.com/gpu extended resource;
    • 配合 vLLM 的 --gpu-memory-utilization 0.85 参数,避免显存碎片;
    • 禁用 nvidia-docker,改用 containerd + nvidia-container-runtime,确保 cgroup v2 下 GPU memory accounting 准确。
  4. 可观测性升级:从 Metrics 到 Reasoning Trace
    在 Grafana 中新建面板,聚合 AgentState 的 reasoning_trace 字段,用 Loki 日志分析提取高频关键词(如 "OOM"、"latency_spike"、"cost_overrun"),实现「决策健康度」可视化。


延伸阅读 ​

💡 结语:Agentic AI 不会取代 SRE,但会淘汰只懂 kubectl apply 的 SRE。未来三年,最稀缺的能力不是写 Helm Chart,而是能设计 AgentPolicy 的意图模型、能审计 reasoning_trace 的逻辑漏洞、能在 planner 输出 {"action": "scaleDown", "reasoning_trace": "GPU utilization dropped to 32% for 120s, but cost per request remains >$0.3..."} 时,一眼看出其隐含的 batch size 误判——这才是 AI-native infra 时代 SRE 的新内功。