Kubernetes 刚刚成立了工作负载一致性工作组。这对 AI 团队为何重要。
内容提要
本文是KubeCon前瞻系列终篇，聚焦Kubernetes应对AI工作负载的新动向：TNS与HPE发布AI平台指南；Kubernetes社区成立工作负载一致性工作组；OTel转换语言OTTL发布v1并承诺向后兼容；AWS将演示多LLM共享GPU的智能调度；GKE用VPC流日志解决临时Pod排障难题；AGNTCon会议警示AI代理被诱导安装恶意软件，并指出授权规则应置于服务端。核心主题是云原生生态正为大规模AI运行而深刻变革。
延伸解读
工作负载一致性：从“能跑”到“跑得规范”
Kubernetes 已有 AI Conformance 测试判断集群能否运行 AI/ML 工作负载，但工作负载本身在运行时如何表现，此前没有统一标准，团队只能靠变通、手动探索或监控节点排空、权限问题等迹象。新成立的工作负载一致性工作组旨在为工作负载运行时行为制定共享标准，这有助于减少不同环境下的行为差异，但标准仍在制定中，需要社区输入，短期内不会立即改变现有运维方式。
AI 代理安全：授权规则应放在服务端
AGNTCon + MCPCon 上的分享显示，AI 代理可能被 SKILL.md 等指令诱导安装恶意软件；同一电商 MCP 服务器在四个不同主机上让代理尝试购买时，行为差异显著。这提示允许或禁止代理执行不可逆操作的授权规则，应放在服务端而非本地，因为本地规则更容易被绕过或与代理实际运行环境脱节。云原生运维者在为代理搭建基础设时，需关注这类非预期后果。
GPU 共享调度：用代理流水线减少人工试错
AWS 的 Ratnopam Chakrabarti 将在 KubeCon 上演示一个代理流水线，实时分析工作负载并处理 GPU 上的模型共置。文章指出整卡 GPU 分配成本高且效率低，而把多个 LLM 安全地打包到共享 GPU 上，目前仍缺乏简单方案。该演示属于早期预览，实际效果和适用范围尚待会议披露，读者可将其视为优化方向而非成熟方案。
可观测性补丁：临时 Pod 排障有了网络流日志
GKE 内置的 VPC Flow Logs 会记录采样流的元数据，包括 Pod、工作负载、命名空间和服务，弥补了标准云网络流日志只记录 IP、端口和协议、而 Kubernetes Pod 转瞬即逝难以追踪的短板。这是云平台围绕 Kubernetes 增强可见性的一个具体例子，但文章仅以 GKE 为例，其他环境是否有同等能力需另行确认。
Q&A
Kubernetes 新成立的工作负载一致性工作组是做什么的？
该工作组旨在为工作负载在 Kubernetes 上的运行时行为编写共享标准。目前已有 Kubernetes AI 一致性测试来判断集群能否运行 AI/ML 工作负载，但还没有针对工作负载本身的标准，导致需要变通方法、手动探索或监控节点排空、权限问题等迹象。新工作组将填补这一空白。
为什么说这个工作负载一致性工作组对 AI 团队很重要？
因为 AI 工作负载种类繁多且行为独特（如代理式 AI 具有突发性、不可预测性），缺乏统一标准会增加运维复杂性和生产风险。该工作组制定的运行时行为标准能帮助 AI 团队更可靠地在 Kubernetes 上运行大规模 AI 工作负载，减少手动排查和变通方案。
如何安全地在共享 GPU 上运行多个 LLM？
AWS 的解决方案架构师 Ratnopam Chakrabarti 将在 KubeCon 上展示一种代理驱动的 GPU 共置方案：通过代理管道实时分析工作负载特征，并自动处理模型在 GPU 上的共置，从而避免昂贵的整卡分配和手动猜测。
GKE 如何解决临时 Pod 难以排障的问题？
GKE 内置的 VPC 流日志利用 Google 的虚拟化网络记录每个采样流的元数据，包括 Pod、工作负载、命名空间和服务信息。由于 Pod 是临时的、消失后难以追踪，这些日志提供了排查问题所需的连接记录。
AI 代理被诱导安装恶意软件的风险该如何防范？
根据 AGNTCon + MCPCon 上的分享，代理可能被恶意指令（如 SKILL.md）欺骗而运行恶意软件。防范建议包括：将允许或禁止代理执行不可逆步骤的授权规则放在服务端而非本地，并警惕赋予代理过大权限的后果。
OTTL 发布 v1 版本带来了什么重要承诺？
OpenTelemetry 转换语言 OTTL 达到 v1，对 traces、metrics 和 logs 均稳定，并包含在 Collector Contrib v0.164.0 及更高版本中。重要承诺是向后兼容：编写的 OTTL 语句的语法和标准函数将保持向后兼容。
