VMware Explore 技术资料：在 VCF 上选择 VM、Container 与 Kubernetes 部署路径

应用现代化很少从一张白纸开始。企业既有大量稳定运行的虚拟机，也在增加容器化应用，还需要为部分团队提供完整的 Kubernetes 平台。如果为每类工作负载分别建设一套基础设施、门户和治理体系，平台很快会形成新的烟囱。

VMware Cloud Foundation 9.1 以 vSphere Supervisor 为基础，在同一套平台上提供 KubeVM Service、Container Service 与 vSphere Kubernetes Service，简称 VKS。三种服务面向不同复杂度的应用，却共享命名空间、策略、计算、网络与存储能力。

本文依据 VMware Explore 技术演讲。

先看重点

·Supervisor 是统一基础。它把 Kubernetes 声明式 API 延伸到虚拟机、容器、VKS 集群及平台服务，同时保留 vSphere 的计算、网络、存储与高可用能力。

·KubeVM Service 适合仍需虚拟机运行时、但希望引入自助服务、GitOps 与期望状态管理的应用。现有虚拟机还可以通过无中断导入纳入统一管理。

·Container Service 适合单容器、少量容器、开发测试和边缘场景。它直接在 ESXi 上运行隔离容器，不要求团队先建设和维护 Kubernetes 集群。

·VKS 适合生产级容器化应用、微服务、平台工程与 AI 工作负载。它提供符合 CNCF 标准的 Kubernetes 运行时，并接入企业级网络、存储、安全和可观测能力。

·三种服务并非互相替代。真正的选型依据是应用需要的编排复杂度、团队能力、运行时依赖和治理要求。

·VCF 9.1 继续增强 Supervisor、VM Service、Container Service、VKS 与内容分发能力，使不同工作负载可以沿用统一的消费和运维方式。

01应用现代化不等于全部改成 Kubernetes

企业应用通常同时处在多个阶段。有些系统依赖完整操作系统和传统中间件，有些应用已经封装为单个容器，还有一些微服务需要弹性伸缩、服务发现、滚动升级与多集群治理。只提供一种运行方式，很难同时满足这些需求。

▌ VCF 把多种工作负载放在同一平台

VCF 以 Supervisor 为基础，统一承载虚拟机、容器、Kubernetes 与数据服务

从架构上看，底层仍由 vSphere 提供计算、存储和网络资源。Supervisor 在其上提供统一的 Kubernetes 控制面，向上连接 KubeVM、Container、VKS 集群、网络服务、存储服务、镜像仓库与数据服务。

这种方式保留了不同运行时的特点，同时统一资源隔离、权限和服务消费入口。应用团队不必为了使用自助服务而强行改变应用形态，平台团队也不必为每类工作负载维护完全独立的管理体系。

▌ VCF 9.1 的增强覆盖完整消费链路

VCF 9.1 对 VKS、VM Service、Container Service、内容分发与 Supervisor 持续增强

PPT 列出的 VCF 9.1 重点包括 VKS 3.7、Kubernetes 1.36、更快的集群部署与升级、可选择的 CNI、多网卡和自定义节点镜像；VM Service 增加快速部署、日常运维增强、网络可变更与无中断导入；Container Service 提供基于 vSphere Pods 的容器实例。

统一内容分发和 Supervisor 的规模、网络及多集群区域增强，则为这些服务提供共同基础。理解这一点很重要：VCF 9.1 的变化并非只服务 Kubernetes，而是在完善从制品分发到运行时交付的整体路径。

02Supervisor 是三条路径的共同控制面

Supervisor 的核心作用，是把基础设施资源转换为可通过声明式 API 消费的对象。使用者描述期望状态，平台控制器负责创建、持续检查并调和实际状态。

▌ 一个 API 面向多种应用资源

Supervisor 通过统一 API 交付虚拟机、Kubernetes 集群与平台服务

应用团队可以使用 kubectl、YAML、自动化流水线或 GitOps 工具提交资源需求。平台团队继续管理底层集群、配额、存储策略、网络与安全边界。两类团队使用不同抽象层，各自保留清晰职责。

▌ ESXi 集群直接成为 Supervisor 的工作基础

Supervisor 控制平面提供 API 入口，ESXi 主机通过 Spherelet 参与工作负载管理

Supervisor 由控制平面虚拟机提供 API 入口。ESXi 主机通过 Spherelet 接收和执行工作负载状态，Spherelet 可以理解为针对 ESXi 运行环境实现的 kubelet。这样既利用 Kubernetes 控制模式，也保留 vSphere 原生调度与运行能力。

▌ Namespace 同时承担隔离与治理

vSphere Namespace 将测试、预发布、生产及不同应用边界分开

vSphere Namespace 是资源、权限和策略的逻辑边界。测试、预发布和生产可以配置不同配额、存储策略、网络访问及操作权限。一个 Namespace 还可以同时包含 VKS 集群、KubeVM 与其他服务，让混合架构仍然遵循一致的治理规则。

03KubeVM Service 让虚拟机进入声明式管理

大量企业应用短期内仍会运行在虚拟机中。原因可能是操作系统依赖、商业软件认证、传统中间件、硬件驱动或改造成本。KubeVM Service 的价值，是在不改变虚拟机运行时的前提下，引入 Kubernetes 风格的自助服务和生命周期管理。

▌ 虚拟机也可以由 YAML 与 GitOps 驱动

KubeVM Service 在 Namespace 中以声明式方式定义和管理虚拟机

使用者通过声明式资源定义虚拟机规格、镜像、网络和存储。控制器持续维护期望状态，CI/CD 或 Argo CD 等工具可以把虚拟机部署纳入代码审查、版本控制和漂移检测。底层仍保留 DRS、HA、vMotion、隔离与快照等 vSphere 能力。

▌ 现有虚拟机可无中断纳入服务

现有 vSphere 虚拟机可迁入 Namespace，并无中断导入 KubeVM Service

VCF 9.1 的无中断导入能力降低了传统应用进入统一平台的门槛。平台可以先把虚拟机迁入 vSphere Namespace，再批量导入 KubeVM Service 管理范围。应用不需要停机，也不必立即更换现有网络。

导入并不等于应用容器化。它改变的是交付与治理方式，使既有虚拟机能够接入自助服务、策略和自动化体系。后续是否重构应用，可以根据业务价值和技术条件另行决定。

▌ VM Group 管理多虚拟机应用

VM Service Groups 支持批量电源操作与分波次启动顺序

很多传统系统由多台虚拟机组成，并且对启动顺序有明确要求。VM Service Groups 可以把虚拟机加入同一组，统一执行电源操作，并通过不同波次定义启动次序。数据库、应用服务和前端节点因此可以按照依赖关系恢复。

▌ KubeVM 最适合哪些场景

KubeVM Service 的能力、适用场景与主要价值

·应用必须保留完整操作系统，或者仍依赖传统软件认证与现有存储、网络生态。

·团队希望使用 Kubernetes 工具链和 GitOps 管理虚拟机，但不准备立即重构应用。

·组织需要把现有 vSphere 虚拟机逐步纳入 Namespace、配额、策略和统一自动化。

·多台虚拟机需要一致的生命周期操作或受控启动顺序。

04Container Service 提供轻量容器运行方式

并非每个容器都需要完整 Kubernetes 集群。单体 Web 服务、自动化工具、短期测试环境和边缘应用，可能只需要快速启动一个或少量隔离容器。如果为此维护控制平面、节点和集群插件，平台开销会超过应用本身。

▌ 容器直接运行在 vSphere Pods 中

Container Service 在 vSphere Namespace 中部署隔离的 vSphere Pods

Container Service 以 vSphere Pods 为基础，把容器实例直接运行在 ESXi 上。使用者可以通过界面完成部署与生命周期操作，也可以挂载持久卷创建 StatefulSet，并支持多容器组合。

▌ 降低 Kubernetes 管理门槛

Container Service 提供面向单容器的快速、简洁、界面化交付方式

团队不需要先掌握 Kubernetes 集群安装、节点维护和插件管理，就能获得镜像化交付、快速启动与隔离运行的优势。平台直接复用 ESXi 资源，省去独立 Kubernetes 管理层。

轻量并不代表没有治理。镜像来源、网络访问、持久化数据、资源配额、日志和漏洞扫描仍需纳入平台策略。Container Service 省去的是完整集群的管理负担，而不是安全与运维责任。

▌ Container Service 最适合哪些场景

Container Service 的能力、适用场景与主要价值

·开发或测试环境需要快速运行一个容器实例。

·边缘或轻量应用只包含少量容器，不需要复杂编排。

·团队希望使用容器，但暂时不具备 Kubernetes 运维能力。

·应用需要独立隔离环境，并希望减少集群控制面和节点管理开销。

05VKS 面向生产级 Kubernetes 应用

当应用由多个微服务组成，需要滚动升级、弹性伸缩、服务发现、策略控制和生态插件时，完整 Kubernetes 集群仍然是合适选择。VKS 在 VCF 内提供符合 CNCF 标准的 Kubernetes 运行时，并把基础设施服务接入集群生命周期。

▌ 完整 Kubernetes 能力与基础设施集成

VKS 在 VCF 上交付符合标准的 Kubernetes 集群，并集成硬件、存储、安全与多版本支持

VKS 支持生产级 Kubernetes 集群，并通过 vSphere Namespace 连接身份、网络、存储、安全、日志和监控。平台可以按需创建多个相互隔离的集群，同时继续利用 vSphere 的高可用与基础设施运维能力。

▌ 标准生态减少应用绑定

VKS 连接 Harbor、Argo CD、OpenBao、Helm、Prometheus 等标准生态组件

VKS 的重要特点是保持 Kubernetes 标准接口。应用可以使用 Helm、证书管理、可观测性、密钥管理、镜像仓库与 GitOps 工具。团队已经在其他标准 Kubernetes 环境中构建的应用，更容易迁移或复用。

标准兼容不代表所有组件都会自动安装。平台仍要根据目标架构选择 CNI、入口控制器、证书、密钥、监控和备份方案，并维护清晰的版本兼容矩阵。

▌ VKS 最适合哪些场景

VKS 的能力、适用场景与主要价值

·生产级微服务需要部署、扩缩容、滚动升级、自愈和多副本调度。

·受监管业务需要独立集群、明确策略边界和可审计的运行环境。

·AI、数据处理或平台工程团队需要 Kubernetes 生态与标准 API。

·组织希望在本地、混合云和边缘保持一致的 Kubernetes 应用模型。

▌ VKS 的价值不仅是创建集群

VKS 连接自助服务、版本交付、声明式 API、云原生界面与高可用能力

生产平台需要持续交付 Kubernetes 版本、处理补丁和升级，并为使用者提供可重复的集群模板。VKS 把这些工作与 Supervisor 的声明式 API、自助服务和 VCF 基础设施结合起来，使集群成为可持续运营的平台服务。

06三种运行方式到底怎么选

选型不应从“哪种技术更新”出发，而应从应用真正需要的运行时和编排能力出发。下面的判断顺序可以快速缩小范围。

▌ 第一步 看应用是否需要完整操作系统

如果应用依赖特定操作系统、驱动、传统中间件或商业软件认证，优先选择 KubeVM Service。它能保留虚拟机边界，同时让交付进入 Namespace、API 与 GitOps 模式。

▌ 第二步 看容器是否需要集群级编排

如果应用已经容器化，但只需要运行单个或少量容器，也不依赖复杂的服务发现、弹性伸缩和生态插件，可以选择 Container Service。它缩短了从镜像到运行实例的路径。

▌ 第三步 看是否需要完整 Kubernetes 生态

如果应用需要多服务编排、滚动升级、自动扩缩、Operator、Service Mesh、GitOps、策略控制或多集群管理，应选择 VKS。此时 Kubernetes 本身就是应用运行模型的一部分。

▌ 同一应用可以混合使用三种服务

VCF 在统一控制平面和治理体系上承载 VKS、KubeVM 与 Container Service

真实业务很可能同时使用多种运行方式。例如数据库暂时保留在 KubeVM 中，核心微服务运行在 VKS，轻量辅助任务使用 Container Service。只要它们位于清晰的 Namespace 与网络边界内，就能共享 VCF 的基础设施治理与高可用能力。

07统一运维比统一运行时更重要

三种服务的共同价值，在于让虚拟机和容器逐步进入一致的交付与运维体系。企业不必要求所有应用使用同一种运行时，但可以要求它们遵循统一的身份、策略、制品和自动化规则。

▌ 生命周期与自动化工具可以复用

虚拟机与容器共享生命周期管理、配置管理、构建工具和 GitOps 流程

期望状态定义、部署、删除与配置管理可以通过同一类工具完成。Packer 等工具负责构建虚拟机镜像，容器工具链负责构建 OCI 镜像，GitLab、GitHub、Argo CD 等平台则面向目标环境执行自动化。

统一的重点不是强求所有制品格式相同，而是建立一致的审批、身份、版本、审计和回滚流程。虚拟机模板与容器镜像都应可追溯，生产变更都应来自受控仓库和自动化流程。

08落地前需要确认的八项准备

运行时选择只是第一步。生产落地还需要把组织职责、基础设施能力与应用要求逐项对齐。

▌ 平台实施检查清单

·应用画像：确认操作系统依赖、容器化程度、状态数据、扩缩容方式、可用性目标和升级模式。

·Namespace 设计：按环境、业务或租户划分边界，并定义配额、存储策略、网络访问和角色权限。

·镜像与制品：明确虚拟机镜像、容器镜像、软件包和 Kubernetes 清单的来源、签名、扫描与保留策略。

·网络：设计 KubeVM、容器、VKS 集群、负载均衡、外部系统和物理网络之间的连通关系。

·存储：区分临时数据与持久数据，确认快照、备份、恢复、拓扑与性能策略。

·身份与权限：分离平台管理员、Namespace 管理员、开发者、流水线和运行应用身份，落实最小权限。

·可观测性：统一收集虚拟机、容器、Kubernetes 与应用层指标、日志和告警，并明确故障归属。

·生命周期：规划 VCF、Supervisor、VKS、节点镜像、CNI、CSI 与外部插件的兼容关系和升级顺序。

结语

VCF 9.1 给出的答案，不是要求所有应用立即迁移到 Kubernetes，而是让应用根据自身条件选择合适的运行方式，并在同一套平台治理下逐步现代化。

KubeVM Service 连接既有虚拟机与声明式管理，Container Service 为轻量容器提供更短的运行路径，VKS 则承载需要完整 Kubernetes 能力的生产应用。三者共享 Supervisor、Namespace 与 VCF 基础设施，形成从传统应用到云原生应用的连续选择。

实践中可以先完成应用画像与 Namespace 设计，再选择一条低风险业务链路试点。只要平台把身份、网络、存储、制品和生命周期规则建立起来，应用团队就能在不增加新烟囱的前提下选择最适合自己的运行方式。