CNCF 2026 AI 与云原生项目落地应关注哪些接口

CNCF 2026 关于 AI 与云原生的讨论，真正值得落到项目里的不是一张“热门项目清单”，而是一组能把需求传给平台、把结果传回应用的接口。先看资源声明，再看推理流量，随后补齐遥测与治理，AI 工作负载才有机会从能跑变成可运营。

官方资料入口：https://www.cncf.io/blog/2026/06/02/cloud-native-is-now-ai-native-engineering-production-ready-ai/

落地时优先确认四层契约：资源层回答“需要什么加速器”，流量层回答“请求送给哪个模型端点”，观测层回答“延迟和成本发生了什么”，治理层回答“谁可以让系统执行什么”。

先把“接口”拆成四层

问题现场通常是这样的：团队已经有 Kubernetes 集群，也能把模型服务部署成 Pod，但一遇到 GPU 选择、模型路由、首 token 延迟或代理工具权限，就开始在业务代码里塞大量平台特例。此时先不要继续加控制器，应该先判断缺的是哪一种接口。

• 资源声明：用结构化对象描述设备类型、容量、拓扑和生命周期，避免把节点名称硬编码进工作负载。
• 推理路由：让网关理解模型名、端点能力、队列和请求优先级，而不只是按 URL 或轮询转发。
• 可观测性：把 AI 特有的首 token 延迟、生成速率、队列深度和缓存命中率放进统一遥测。
• 治理审计：为身份、策略、工具调用和人工确认留下可追踪的控制点。

这四层不是要求一次性全部引入。小型离线任务可能只需要资源声明和基础日志；在线多模型服务才需要推理路由；会让代理执行外部动作的系统，则必须把治理审计提前。

资源接口先看 DeviceClass 和 ResourceClaim

CNCF 2026 的 AI-native 讨论把动态资源分配列为重要基础能力。Kubernetes 官方 DRA 文档中的核心对象可以这样理解：DeviceClass 描述一类可匹配的设备，ResourceClaim 表达一次工作负载对设备的请求，ResourceClaimTemplate 则为每个 Pod 生成独立的声明。

读者真正需要排查的是“谁声明、谁绑定、谁消费”。不要把下面的接口形状示意直接当成任何厂商驱动的完整清单；它用于说明字段之间的关系：

apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
  name: inference-accelerator
spec:
  devices:
    requests:
      - name: serving-device
        deviceClassName: accelerator
        # 过滤显存或拓扑等设备属性，具体字段以驱动提供的属性为准。
        selectors:
          - cel:
              expression: device.attributes["example.com/memory-gb"] >= 40

核对这个接口时看三件事：设备类别是否由平台统一维护，声明是否与 Pod 位于同一命名空间，驱动是否能把分配结果以可消费的方式暴露给容器。如果直接引用的 ResourceClaim 不存在，Pod 就不能正常调度；如果资源声明只写成节点标签，后续更换设备或跨集群迁移会重新绑定业务逻辑。

对于每个副本都要独占一份类似设备的工作负载，优先评估模板化声明；需要多个 Pod 共享同一个声明时，再明确共享生命周期和回收责任。Kubernetes 版本、DRA 驱动和设备属性实现可能不同，生产落地必须把这三者的支持范围写入平台契约。

推理流量要有模型感知的入口

传统 Service 或普通反向代理知道后端地址，却不知道某个端点是否已经加载目标模型、队列是否拥堵、是否有可复用的 KV cache。Gateway API Inference Extension 的思路，是在熟悉的 Gateway API 之上增加推理场景需要的端点选择和模型感知能力。

一个完整请求链应能回答：请求带来的模型标识是什么，Gateway 如何找到对应的 InferencePool，端点选择器依据哪些实时指标挑选副本，失败或滚动发布时如何回退。可以用下面这段简化关系检查自己的实现：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: chat-route
spec:
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v1/chat/completions
      backendRefs:
        - group: inference.networking.k8s.io
          kind: InferencePool
          name: chat-model-pool
          # 这里表达模型池关系，真实字段以实现版本的 CRD 为准。
          weight: 100

验证这层接口时，先用一个只读请求观察路由结果，再逐步加入模型版本、LoRA 适配器、流式响应和优先级。不要一开始就把所有路由逻辑放在应用层；否则平台无法统一做灰度、限流和端点健康判断。

把 AI 指标放进统一的观测接口

“请求成功”不能说明推理服务健康。传统 HTTP 延迟可能正常，但队列已经排长，或者首 token 很慢、后续生成速度下降。CNCF 相关材料建议把 OpenTelemetry、Prometheus 等已有观测能力与 AI 指标放在同一套平台里。

至少应为每次推理请求留下以下字段，维度要控制在可聚合范围内：

追踪数据要能把入口请求、端点选择和模型服务串起来，但不要把完整提示词、密钥或敏感业务 payload 当成普通 span 属性。日志、指标和追踪各自保留适合的粒度，才能同时满足排障、容量规划和隐私要求。

代理和工具调用要补上治理接口

AI 项目一旦开始调用数据库、工单、搜索或部署工具，风险就从“模型回答错了”变成“模型提出了一个未经授权的动作”。CNCF 的云原生代理标准讨论把安全、可观测性、可用性和容器化基础都列为需要持续治理的内容。

应用侧至少要把动作拆成四个可审计阶段：身份确认、策略判断、工具执行、结果回传。模型输出的工具名和参数只是请求，不是授权；写操作需要幂等键、超时、人工确认或可回滚方案。

{
  "request_id": "req_example",
  "principal": "service-account:ai-worker",
  "tool": "ticket.create",
  "policy": "allowed-with-approval",
  "execution": "pending",
  "audit": {
    "argument_digest": "sha256:脱敏摘要",
    "review_required": true
  }
}

这段严格 JSON 不插入注释；字段含义放在代码外说明。principal 用于识别调用主体，policy 记录决策而不是让模型自行决定权限，execution 区分尚未执行、执行成功和执行失败，摘要字段用于关联排查而不保存完整敏感参数。

从一个小场景开始复查

如果要把一项 AI 能力从试验推到生产，可以按下面顺序做一次小范围复查：

1. 先选一个明确模型和一类加速器，确认资源声明能表达需求，且失败时不会落到错误设备。
2. 再让请求经过 Gateway 和模型池，记录模型选择、排队时间和端点返回状态。
3. 接入指标、日志和追踪，分别观察首 token 延迟、生成速率、队列深度和异常原因。
4. 为一个只读工具加身份与审计，再考虑写操作、人工确认和幂等策略。
5. 最后做故障演练：设备不可用、端点过载、模型版本切换、遥测中断和工具拒绝都应有可解释结果。

如果项目只是离线批处理，不需要为了追赶趋势引入完整推理网关；如果项目服务多个模型、多个租户或多个硬件池，才值得把模型感知路由和统一策略提前做成平台接口。接口的价值不在于名词更多，而在于让输入、选择、结果和责任边界都能被复查。

相关问题

DRA 和节点标签有什么本质区别？

节点标签通常只描述“节点看起来有什么”，DRA 试图把设备请求、选择、绑定和消费过程变成结构化资源生命周期，适合需要设备属性、拓扑或更细粒度调度的场景。

InferencePool 是否等于模型服务本身？

不是。模型服务负责推理，InferencePool 更接近一组可被推理网关选择的端点集合；端点选择还可以结合队列、能力和健康状态。

为什么不能只看 HTTP 200？

HTTP 200 只说明请求在协议层得到响应，无法说明首 token、排队、生成速率、成本和模型版本是否符合目标。AI 服务需要把这些指标纳入观测接口。

哪些接口可以暂时不做？

单模型、低并发、离线运行且没有外部工具动作的项目，可以先做好资源声明、基础日志和失败重试；多模型路由、跨租户策略和代理治理应在真正出现对应复杂度时引入。

参考资料

CNCF AI-native 讨论：https://www.cncf.io/blog/2026/06/02/cloud-native-is-now-ai-native-engineering-production-ready-ai/

CNCF 生产化平台分析：https://www.cncf.io/blog/2026/03/26/the-platform-under-the-model-how-cloud-native-powers-ai-engineering-in-production/

Kubernetes DRA 文档：https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/

Gateway API Inference Extension：https://github.com/kubernetes-sigs/gateway-api-inference-extension

CNCF 云原生代理标准：https://www.cncf.io/blog/2026/03/23/cloud-native-agentic-standards/