KubeCon 议题中 GPU 调度和可观测性如何分别落到工程任务

KubeCon 的议程里出现 GPU 调度、拓扑感知、eBPF 和推理可观测性，并不等于团队应该马上换一套平台。更有用的做法，是把每个议题翻译成“谁负责、改哪一层、拿什么证据验收”的工程任务。2026 年北美 KubeCon + CloudNativeCon 将于 11 月 9 日至 12 日在盐湖城举行，CNCF 公告把新设的 AI Inference + Agentic 轨道直接指向 GPU 调度、模型服务和生产可观测性。

先把会议热词分成两条工程线

“调度”回答的是工作负载能不能拿到合适的 GPU、何时拿到、放在哪些节点；“可观测性”回答的是拿到之后是否按预期运行，以及延迟、显存和租户成本为什么变化。两者有关联，但负责人和验收证据不同。

GPU 调度线：从“有卡可用”变成可验收的资源合同

第一张任务卡写资源模型。Kubernetes 当前 DRA 文档把 DeviceClass、ResourceClaim、ResourceClaimTemplate 和 ResourceSlice 分成不同职责：驱动发布设备，集群管理员定义可用类别，工作负载通过 claim 请求设备。这样做的重点不是把 YAML 写得更长，而是让“什么设备、能否共享、由谁维护”变成明确合同。

第二张任务卡写放置策略。GPU 数量够，不代表训练任务能启动；NVLink 域、NUMA 和机架边界可能决定一组 GPU 是否适合放在一起。把队列、配额、拓扑偏好和必需条件分开记录，并同时保留“为什么 Pending”的事件证据。

第三张任务卡写反碎片化。至少跟踪排队时长、实际分配容量、空闲但不可组合的 GPU、任务启动失败原因和节点热替换后的恢复时间。DRA 文档也提醒，当前调度器对 DRA 资源不提供抢占；高优先级工作负载可能要等冲突 Pod 结束，这应进入风险说明和回退方案。

可观测性线：不要让一张 80% 利用率图替团队下结论

可观测性任务应按四层写。硬件层采集 GPU 利用率、显存压力、温度和错误信号；Kubernetes 层补上节点、Pod、容器、命名空间和工作负载 UID；模型层记录请求延迟、首 token 延迟、吞吐、队列深度和错误；租户层再回答“是谁消耗了资源、是否能计费、是否出现邻居干扰”。

官方议程把 eBPF、Prometheus、OpenTelemetry 和推理链路放在相邻的工程问题里，真正可执行的 backlog 应是“建立关联键”，而不是简单增加 dashboard。建议规定 trace_id、Pod UID、模型名和 GPU device 标识的关联范围；高基数的请求参数、完整提示词和敏感业务字段不要直接塞进指标标签，必要信息放到受控日志或 trace 属性中。

第一版验收可以用一条脱敏请求做反向追踪：从用户响应找到模型实例，再找到 Pod、节点和 GPU 指标；如果只能看到硬件曲线，却不能解释某个租户的排队或显存压力，说明链路还没闭环。

用威胁建模补上多租户的边界

GPU 是稀缺资产，遥测数据同样可能包含模型和业务信息。先列资产：设备容量、队列配额、模型路由、trace 与成本数据。再列攻击路径：越权创建高权限 ResourceClaim、通过标签泄露租户信息、利用共享 GPU 造成邻居干扰、用高基数标签拖垮指标系统。

控制措施要落到对象和动作：DeviceClass、ResourceSlice 只给管理员和驱动；普通工作负载只获得命名空间范围的 ResourceClaim 权限；遥测采集器使用最小 RBAC；审计记录保留 claim 创建、绑定、释放、驱动异常和队列决策。每项控制都要有反向验证，例如用普通服务账号尝试读取设备切片应被拒绝，用一条脱敏 trace 检查跨租户查询是否被隔离。

把议程转成会后可排期的任务卡

会议结束后不要按演讲数量立项。按下面四个字段整理即可：负责人是平台、GPU 驱动、推理服务还是安全团队；输入是资源清单、队列策略或遥测字段；产出是 claim 模板、调度策略、指标契约或审计规则；验收是等待时间、放置成功率、归因完整度和越权测试结果。

官方核对入口：https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/program/schedule/；DRA 术语与权限边界可查看 https://kubernetes.io/docs/concepts/resource-management/dynamic-resource-allocation/。议程会变化，真正排期前应重新打开官方页面确认场次和版本语境。

常见问题

有 GPU 配额，为什么任务仍然 Pending？

配额只说明账面资源，拓扑、claim、驱动状态或不可抢占限制都可能阻止实际放置，应结合队列事件和 ResourceClaim 状态判断。

只采集 GPU 利用率够不够？

不够。它不能解释租户、模型请求、排队和首 token 延迟，至少要补上 Pod/命名空间上下文和请求链路关联。

eBPF 能替代现有 GPU 监控吗？

不应直接替代。它适合补充内核或进程侧信号，硬件指标、容器上下文和 trace 仍需组合，并先确认驱动与内核支持范围。