Kubernetes

Kubernetes 成立工作负载一致性工作组，为何对 AI 团队意义重大

Kubernetes 社区在 10 月 27 日宣布成立一个专门的工作组，要为「工作负载在 Kubernetes 上运行时的行为」制定统一标准。此前虽有测试能判断一个集群能不能跑 AI/机器学习任务，但对于具体工作负载本身没有类似标准，团队只能靠变通办法、手动摸索，或者盯着节点被清空、权限报错这类迹象来排查问题。新工作组希望补上这块空白，让不同工作负载在集群里的运行表现有一致、可检验的规范。对跑 AI 工作负载的团队来说，这意味着未来判断平台是否适合自己的任务会更有依据；不过目前只是宣布成立并征集社区意见，标准尚未发布。同期还有：TNS 与 HPE 合作发布一本关于在 Kubernetes 上运行 AI 工作负载的电子书，可立即下载；OpenTelemetry 转换语言 OTTL 达到 v1，对 traces、metrics、logs 稳定，包含在 Collector Contrib v0.164.0 及之后版本，并承诺语法和标准函数保持向后兼容。另有 AWS 架构师预告将在 KubeCon 展示用 agent 流水线实时分析工作负载并在 GPU 上共置多个模型的方案，属于演示预告，原文未说明可用时间。

GPU 繁忙会掩盖 Kubernetes 上缓慢的 AI 推理

HPE 的三位产品负责人（Marius Bogoevici、Mahesh Ramachandran、Karthik Subramanian）在一篇赞助文章中讲了怎么发现 AI 服务“机器很忙但用户体验差”的问题。原来大家常看 GPU 利用率，但它只说明显卡在干活，不代表回答够快、够准——首字快可能后面生成很慢，整体快也可能答错。他们建议上线前先用有代表性的提问和流量做一次“基准测试”，记下首字时间、每字生成速度、吞吐量和答案质量，上线后再拿实时表现跟基准对比，并把请求数据和 GPU、网络、数据库、向量库等底层指标对齐，才能分清是需求涨了还是哪里卡住了。读者可以据此建立更靠谱的监控和扩容依据；报道没有给出具体测试数字，相关方法和电子书属于推荐做法，HPE Morpheus 与 OpsRamp 是厂商产品介绍，并非已公开的独立评测结果。

outturn：多租户 Agent 平台的 Rust 运行时基础

idataconnect/outturn · A fast, secure Rust foundation for multi-tenant agent platforms

outturn 是一个用 Rust 构建的多租户 Agent 平台基础框架，面向需要让每个客户都能运行各自 Agent 的公司。它内置租户隔离、按租户用量归因、在 WebAssembly 沙箱中运行 Agent 代码、默认拒绝的出站访问规则、网关集中保管凭证、每轮签名令牌，以及防止单个租户故障影响其他租户的断路器。项目处于早期开发阶段，接口可能变动，提供本地 Kubernetes 集群的开发与演示流程，以及面向真实部署的密钥与清单生成脚本。

Kubernetes 平台为何反复重建本可共享的编排层

很多平台团队每年都会自己写 Kubernetes 控制器，用来自动创建 Deployment、Service、ConfigMap 之类的一堆对象，并在它们之间传递字段。Kubernetes 本身已经提供了 CRD、控制器、Server-side apply、CEL、OpenAPI 这些零件，却没有说明“几个资源算一个整体、谁先谁后、某个值要从另一个资源的状态里取”的说明书，所以 Helm、Argo CD、Crossplane、Operator 等每个工具都各自补这一块，成千上万的组织在重复造同一个轮子。kro（Kube Resource Orchestrator）把这段“接线”写成数据，叫 ResourceGraphDefinition：由 CEL 表达式里的引用来推断依赖顺序，并在实例创建前做类型检查，一个控制器就能解释所有定义，应用团队照样用 kubectl、RBAC 和 GitOps。它还在 2025 年 9 月进入 Kubernetes SIG Cloud Provider，定位成别人可以搭建的底层原语；0.10 版本新增的 Graph 只保留组合部分、不需要 CRD 和实例，适合“给打了标签的 Service 自动生成 Ingress”这类一次性场景。读者可以少写一堆粘合控制器，但要意识到 API 一旦发布就是承诺，成本从“写”变成“长期维护”。

一个 Pod 一个节点：AWS 无服务器 Kubernetes 背后的架构

AWS 的 EKS Fargate 让用户不用自己管理 worker 节点，改由平台按每个 Pod 单独准备计算环境。它先通过准入控制把匹配 Fargate 配置的 Pod 交给专用调度器，调度器再为这个 Pod 申请新容量，启动所需 Kubernetes 组件，并把用户 VPC 里的网络接口分给这个 Pod，Pod 结束后环境就被回收。这样用户不必创建、打补丁或扩缩节点，但网络接口所在的子网、安全组和 Pod 执行角色仍需在 Fargate 配置里指定；文章没有说明价格、区域可用性或与其他无服务器方案的对比。

影响 Kubernetes 控制平面可用性的隐藏故障路径

这篇文章讲的是 Kubernetes 控制平面在集群规模变大后，一些平时看起来正常的设计反而会把小问题放大成故障。作者举了三个真实例子：一个扩展 API 升级依赖后发布了不合法的 OpenAPI 模式，结果连只用普通 Kubernetes 资源、根本没用这个扩展的 Helm 部署也失败，因为 OpenAPI v2 把所有 API 的定义合并成一份文档，一个扩展出错就拖累所有人；大批 DaemonSet 代理同时重启，启动时的正常请求叠加成风暴，API 服务器扛不住；还有组件把依赖服务的短暂不可用误判成自己进程坏了，反复重启。文章建议用 OpenAPI v3 缩小影响范围、控制重启节奏、别让健康检查过度依赖下游。这是经验分享文章，没有发布新工具，文中提到的 OpenAPI v2/v3、informer、聚合 API 服务器、PR #131755 都是已有机制或改动。

KubeVirt 的下一个十年

红帽在 2016 年发起 KubeVirt 项目，目标是让 Kubernetes 在管理容器的同时也能运行虚拟机，从而让老系统和新应用共用一个平台。如今它已成为 CNCF 孵化项目，Nvidia、微软、AMD、英特尔、SUSE 等公司都有贡献者，社区正推动它从孵化阶段毕业。未来方向包括：用 Kubernetes 原生的动态资源分配统一申请 GPU、网卡和 CPU；支持机密虚拟机，让敏感数据和 AI 模型在执行时也受硬件保护，并可远程验证环境是否可信；以及让 KubeVirt 更容易被其他项目集成。对读者来说，这些还在开发和讨论中，部分功能如 AMD SEV 已进入 beta、IBM Secure Execution 已可用，其余多数尚未发布。

AI 正在改变 Kubernetes，你的平台准备好迎接 2027 年了吗？

The New Stack 与 HPE 合作发布了一本新电子书，讲的是 Kubernetes 团队在 AI 时代需要面对的新问题。以前运维主要看 Pod 有没有跑起来、模型第一个字多久出来；现在还要考虑推理流量突增而 GPU 不够用、给 AI 代理开放集群权限、审批和审计怎么管、AI 输出质量怎么评估。书里还给了一份检查清单，覆盖跨集群策略、升级前的 API 变更检查、恢复演练、证书续期和成本归属等容易掉在地上的事，适合平台、应用、安全和业务团队一起对照讨论。目前只能下载电子书，具体章节内容原文没有展开。

ReadyOn 为多租户 Amazon EKS 构建四层租户隔离

ReadyOn 公司说明了他们的 Harmony 平台在 Amazon EKS（亚马逊的托管 Kubernetes 服务）上如何把不同客户的数据和计算资源隔开。原来多租户环境里，客户之间可能互相访问或横向渗透，这次用四层防护来解决：Kubernetes 命名空间、专用 Karpenter 节点池、VPC 安全组，以及每个租户独立的 Aurora 数据库。他们还用一个分 10 个阶段的多租户威胁模型来检验这些控制措施，重点看跨租户访问和横向移动。目前文章只讲了架构设计，没有说明是否已上线或开放使用。

Kubernetes 准备好迎接 AI 智能体了吗？

传统上，Kubernetes 假设软件只会做开发者写好的事，但 AI 智能体能自己思考、选方案、调用工具、持续朝目标推进，这让它在生产环境中的运行方式与传统应用很不一样。问题是：AI 行为是概率性的，无法精确预测它会用到哪些资源，安全沙箱和监控就成了大难题；同时智能体可能只存活几秒，启动却要等好几秒，传统调度方式不够快。社区正在推动把沙箱作为约束智能体的架构元素，但开源 Kubernetes 功能尚未齐全，企业目前可借助已带沙箱能力的商业发行版；还有人提出“智能体底座”方案，让智能体在热池中休眠，实现毫秒级唤醒，而非秒级冷启动。对读者来说，这意味着想在 Kubernetes 上跑 AI 智能体还需额外注意安全隔离、监控和启动延迟，不能直接照搬普通应用的部署方式。

为什么 Kubernetes 自动扩缩容器会互相打架（以及为什么解决方案必须是自主的）

Kubernetes 里管“该开几个副本”和“每个副本该给多少 CPU/内存”的其实是好几套独立工具：HPA 按 CPU 百分比增减副本，VPA 按历史用量调整资源申请，KEDA 按 Kafka 队列积压决定副本数，Karpenter 按声明资源申请新机器。问题是它们各自跑各自的循环，看到的都是局部信息，还同时改同一批配置字段。比如 VPA 把 CPU 申请调小，HPA 的分母就跟着变小，同样的流量会被算成利用率超高，于是猛加副本，结果副本越来越多、每个越来越小，互相把对方越推越远；KEDA 加副本、HPA 又按低 CPU 减回来；GitOps 看到副本数和 Git 不一致还会把它改回去。作者认为水平和垂直扩缩本来就是一道联立方程，应该由一个统一控制面同时看 CPU、队列、延迟、节点价格和 Git 配置，一起给出副本数和资源申请。文中也提到生产集群 CPU 平均利用率只有约 8%，但这些方案的落地细节和可用性文中没有说明。

Radar：面向 AI Agent 的开源 Kubernetes 可视化管理与诊断工具

skyhook-io/radar · The missing open-source Kubernetes UI with a built-in MCP server for AI agents. See what's broken, why, and what changed. Issues, Topology, event timeline, Helm, GitOps, live service traffic, and cluster audits - all in one Go binary.

Radar 是一个以单一 Go 二进制形式提供的开源 Kubernetes UI，可在本地或集群内运行，通过直接连接 Kubernetes API 展示拓扑、资源、事件时间线、Helm、GitOps、实时服务流量与集群审计等信息，帮助定位故障现象及其原因与变更。项目内置 MCP 服务器，使 AI Agent 能够检查和操作集群；同时支持 Helm 部署以实现团队共享访问与 RBAC 权限控制。

漏洞风险暴露：在运行时查看受监控进程的暴露情况

Dynatrace 推出了一个叫「漏洞风险暴露」的新仪表板，把漏洞到底影响哪些主机、进程和 Kubernetes 环境集中到一张图里看。原来只看漏洞数量，既不知道哪些进程受影响、漏洞扩散有多广，也看不出是不是所有该扫描的进程都扫了。这个仪表板把暴露情况、受影响对象和扫描覆盖率放在一起，还支持按团队、集群、命名空间筛选，让团队先修影响面最大的漏洞，并发现没被扫描到的盲区。该功能随文章发布，原文未说明具体开放时间或付费情况。

AI 任务排队等候，GPU 却闲置：Kubernetes 有了新方案

这篇文章是 KubeCon 前瞻专栏，讲 Kubernetes 社区怎么让 GPU 更好地服务 AI。问题在于：负责把任务分配到现有机器的调度器和负责加机器的自动扩缩器各干各的，结果任务卡在排队，昂贵的 GPU 却闲着。目前有几个方向：HPE 用开源工具自动收集 Pod 重启信息并推送到 Slack，减少人工排查；AWS 提出让扩缩器更懂调度器，并用动态资源分配、工作负载感知调度和 provisioning requests 衔接两边；SIG-Autoscaling 已有公开提案，让两个环节直接对话。另外 CNCF 沙箱项目 llm-d 发布 v1.0，IBM 测试中智能体任务推理成本降低 11.5 倍、缓存复用约 98%。这些多数是提案或演示，尚未说明何时默认可用。

AI Runway：在 Kubernetes 上部署与管理大模型推理的多提供商平台

ai-runway/airunway · ✈️ Kubernetes-native platform for deploying and managing AI inference across multiple providers

AI Runway 是一个 Kubernetes 原生平台，提供 Web UI 和统一的 ModelDeployment CRD，用于跨多个推理提供商部署和管理大语言模型。它支持浏览 HuggingFace 模型、一键部署、实时状态与日志监控、Prometheus 指标、GPU 成本估算，并集成 Gateway API 推理扩展和 Headlamp 插件。它兼容 vLLM、SGLang、TensorRT-LLM、llama.cpp 等推理引擎，通过提供商适配集成 NVIDIA Dynamo、KubeRay、KAITO、LLM-D 和直连 vLLM。

演讲：超越原型——用 Ray 扩展与框架无关的 AI Agent 基础设施

两位工程师做了一场演讲，讲的是怎么把 AI Agent 从本地开发时用的 FastAPI 小原型，搬到 Kubernetes 上、用 Ray 撑起来的正式生产环境。他们分享了实际操作中的经验：Ray 集群怎么搭、有状态记忆怎么存、流量忽高忽低时怎么自动扩缩容，以及控制平面怎么设计得稳。另外还提到几道关键防线：安全护栏、多区域部署，还有让大模型当裁判来给 Agent 打分的评测流程。对做 AI 应用落地的团队来说，这些是从“能跑”到“撑得住”的参考经验。这只是一场演讲分享，相关工具和做法没有说明是否已经开源或可以直接拿来用。

规模不是一个数字：Kubernetes 控制平面不堪重负的三种方式

这篇文章讲的是 Kubernetes 控制平面的容量问题，但重点不是“集群有多大”。作者举了三个完全不同的集群：一是上万节点的训练集群，大量节点不停上报心跳，把 apiserver 和 etcd 的内存吃光；二是节点数不多但对象频繁创建、销毁的 Agent 平台，写入压力巨大；三是装了两百个 operator、对象多得每个 apiserver 都要在内存里存一份的平台集群。文章的核心观点是：这三种压力方向不同，按节点数调优往往治错病，加 apiserver 还可能因为每个都复制全量 watch 缓存而让情况更糟。作者提出从四个“接缝”入手（存储分工、节点存活上报、分片维度、缓存驻留），并说明部分能力已有现成配置，像 KEP-4743、KEP-5866 这样的改进仍在推进中，具体何时可用原文没有说明。对运维 Kubernetes 的读者来说，这是一份先分清自己属于哪种规模压力、再决定调优方向的思路清单。

AI Agent 与 Kubernetes：在控制循环中各自的位置

这篇文章讲的是 AI Agent 和 Kubernetes 运维工具各自该干什么。Kubernetes 一直靠“控制器”这类自动程序盯着集群状态、按规则把实际状态拉回目标状态，而现在的大模型 Agent 擅长的是调查问题、收集信息、给出建议，但让它直接改集群并不可靠。文章以开源项目 kagent 为例，提出一种分工方式：Agent 只负责观察、诊断和提出具体改动方案，真正执行仍交给 Kubernetes 控制器和策略系统，改动前还要人工或策略审批，改完再验证效果。文中用 Karpenter 扩容和 Argo CD 升级 Helm chart 两个例子说明好处：团队能更快找到问题原因、拿到风险说明清楚的窄范围补丁，同时集群的稳定性仍由原有确定性逻辑保证。kagent 是 CNCF Sandbox 项目，文中未说明其生产可用程度；KubeCon 相关会议信息与工具能力无关。

演讲：GPU 爆炸

Andrew Martin 做了一场演讲，主题是 AI 安全其实和 Kubernetes 安全密不可分。他谈到，AI 带来的新风险包括：智能体的行为不再完全可预测、GPU 供应链可能被做手脚、多个任务共用同一批算力会带来隐患。针对这些问题，他给出了一些实际防守办法，比如在提示词入口设置防火墙、给智能体分配独立身份。对在生产环境跑云原生 AI 应用的人来说，这些内容有助于判断该从哪些环节加固安全。

Kubernetes DRA 如何提升 GPU 利用率并降低成本

Datadog 的产品经理 Kathy Lin 和技术作者 David Lentz 写了一篇文章，讲 Kubernetes 的旧设备插件模型怎么限制 GPU 使用效率。旧模型里，团队必须提前把 GPU 切好固定的分区，请求只能写数量、看不出显存大小和连接方式，结果经常是花钱买的 GPU 容量白白闲着，或者任务排队等资源。新的动态资源分配（DRA）让 Kubernetes 按每个任务的具体需求灵活挑选和分配 GPU，还能让多个任务共用同一块 GPU，把闲置容量利用起来。读者可以了解 DRA 相比旧模型好在哪，以及用 Datadog 怎么跟踪这些改进和省下的成本。文章目前是博文介绍，没有给出具体性能数字，也没有说明 DRA 功能是否已普遍可用。