登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  科技周边 >  业界新闻

CNCF 新调查关注虚拟机与 AI,共存工作负载透露哪些部署需求

来源:17golang原创

时间:2026-11-10 07:17:50 348浏览 收藏

这份调查最值得注意的地方,不是“虚拟机重新战胜容器”,而是两类工作负载仍在生产环境里长期共存。CNCF 与 Broadcom 赞助、Linux Foundation Research 开展的研究收集了 492 位云原生基础设施从业者和负责人在 2026 年 9 月的回答:受访组织的生产应用平均有 53% 跑在虚拟机上,71% 的受访者预计未来 12 个月这个比例仍在相近范围内。

官方文章:https://www.cncf.io/blog/2026/11/09/new-research-virtual-machines-remain-central-to-cloud-native-infrastructure-as-ai-workloads-evolve/

官方研究页:https://www.cncf.io/reports/virtual-machines-agentic-ai-and-the-mix-of-workloads/

先记住三个判断
  • 调查描述的是共存格局,不是让所有团队从容器迁回虚拟机。
  • AI 和 Agentic workload 把隔离、资源利用与可控执行重新推到架构决策前面。
  • 调查里的“计划采用”是意向信号,落地前仍要按工作负载和运维能力做验证。

调查最重要的变化:虚拟机没有退出生产环境

在回答当前生产应用构成的组织中,平均 53% 的应用运行在 VM 上,51% 的组织表示至少一半生产应用采用 VM。大型组织的 VM 占比还更高:员工数达到 10,000 人以上的组织平均为 64%,少于 500 人的组织平均为 45%。这更像是存量业务、合规隔离、硬件利用和不同交付节奏共同留下的结果,而不是某一种平台的输赢。

运维组织也没有完全分裂。61% 的受访者认为 VM 团队与容器团队是协作或完全整合的,14% 仍然各自为政。调查同时记录了 KubeVirt 等 Kubernetes 上的 VM 管理方式,但使用比例不应被理解成“所有 VM 都已经由 Kubernetes 接管”。

CNCF 调查中生产应用、虚拟机、容器、团队协作、KubeVirt 与混合基础设施的关系说明图
图1:虚拟机与容器共存关系说明图,展示调查数字背后的部署与协作边界。

因此,平台团队要先问“这类负载需要什么边界”,再问“应该放进哪个编排入口”。遗留 VM、容器化服务和 Kubernetes 管理的 VM 可以同时存在,关键是把身份、网络、日志、补丁和故障责任说清楚。

AI 让隔离边界重新成为部署决策

调查里,正在扩大 VM 使用范围的组织中,53% 提到 VM 应用增长,48% 提到硬件资源利用率,47% 提到安全与隔离需求,34% 则把 AI 和 Agentic workload 作为推动因素。这里的含义不是“AI 必须运行在 VM 里”,而是模型生成代码、调用外部工具或接触数据时,平台需要更明确的执行边界。

受访者提供的隔离方式包括硬件级 VM 隔离、VM 内运行容器和 MicroVM 沙箱。有效回答中,62% 表示已经使用至少一种 VM 相关隔离方式。对未来一年的计划回答里,MicroVM 沙箱从当前 20% 上升到计划 30%,机密计算从 12% 上升到 26%,VM 内容器则从 40% 变为 41%。这些是受访者报告的当前使用和计划,不是 CNCF 对技术路线的推荐,也不是彼此排他的选项。

Agentic AI 与硬件级 VM 隔离、VM 内容器、MicroVM 沙箱、机密计算和 GPU 资源利用的关系说明图
图2:AI 工作负载隔离边界说明图,比较不同隔离机制与资源约束的关系。

对工程团队来说,真正新增的是隔离决策:哪些代码可以直接共享宿主资源,哪些任务需要更强的内核边界,哪些数据要配合机密计算,哪些 GPU 任务又会让隔离成本变得不可接受。这个问题要结合威胁模型、启动延迟、资源碎片和运维工具一起回答。

把调查数字翻译成架构选择

场景优先看什么不要直接假设
遗留 VM 与新服务并存网络、身份、补丁和故障责任是否统一容器化后所有依赖都会消失
Agent 执行不可信代码隔离强度、数据边界、审计与回收速度加一个容器就等于完成沙箱
GPU 或专用硬件任务拓扑、利用率、调度、启动与迁移成本更强隔离一定带来更高利用率
VM 与容器团队协作统一目录、值班、指标和升级路径引入 KubeVirt 就自动解决组织问题

调查还显示,运行 VM 的组织中,64% 使用本地 hypervisor,51% 使用公共云 IaaS,23% 同时使用两种环境;由于可多选,这些比例不能相加。平台选型应先按应用的状态、合规、硬件和网络约束分组,再决定哪些能力由现有 hypervisor、云平台、Kubernetes 或 MicroVM 运行时提供。

落地前先做一份最小核对

  1. 列出工作负载:区分遗留 VM、普通容器、需要 GPU 的任务和会执行生成代码的 Agent。
  2. 标注边界:为每类负载写清数据访问、网络出口、宿主共享和凭据生命周期。
  3. 选择隔离层:比较 VM、VM 内容器、MicroVM 或机密计算的启动、性能与运营成本。
  4. 补齐协作面:让 VM 和容器团队共用资产目录、日志字段、值班入口和回滚责任。
  5. 再做小范围验证:用启动延迟、资源利用率、隔离事件、故障恢复时间和审计完整性作为指标。

这份 CNCF 调查给出的结论更接近“平台需要同时理解多种工作负载”。对读者而言,最实用的动作不是追逐某个百分比,而是检查自己的架构是否能在 VM、容器和 AI 任务之间提供一致的身份、观测、隔离和运营接口。

常见问题

调查是不是说明容器化方向走错了?

不是。调查强调的是 VM 与容器并存,以及负责两类环境的团队正在协作或整合;它没有提出把已有容器应用整体迁回 VM。

为什么 AI 会提高 VM 或 MicroVM 的关注度?

Agent 可能生成代码、调用工具并接触数据,平台会更关注内核边界、数据隔离、审计和快速回收。VM、MicroVM 或机密计算只是可选的隔离层,仍要结合负载验证。

调查里的计划采用比例能直接当成采购依据吗?

不能。它是 492 位受访者的意向信号,且部分问题允许多选。采购前还要用自己的启动、性能、资源利用、合规和运营数据做小规模验证。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>