从 VMware 迁移
到 Kubernetes

为什么从 VMware 迁移到 Kubernetes 正在加速

过去，VMware 迁移往往很容易被推迟。很多组织愿意忍受许可证复杂性、硬件耦合和存储开销，因为原有运维模式足够熟悉，而变化的代价看起来太高。

如今情况已经改变。基础设施负责人必须回答三个关键问题：

1. 未来长期承载虚拟机和 stateful application 的平台是什么？
2. 如何避免把 VMware 时代的存储假设带到下一代环境里？
3. 如何在不制造运维混乱的情况下分阶段迁移？

对越来越多的团队来说，答案不再是“换一个新的独立 hypervisor 平台”，而是把 Kubernetes 作为现代基础设施的运维模型，并根据团队需求选择 OpenShift、Rancher、Talos 或原生 Kubernetes，在需要保留虚拟机时再借助 KubeVirt。

这并不意味着所有工作负载会在一夜之间全部容器化，而是意味着目标平台可以同时承载 VM 和容器，让团队按自己的节奏推进现代化。

一个现实可行的 VMware 到 Kubernetes 目标架构

一个现实的目标架构通常由四层组成：

• Kubernetes：负责编排、策略、自动化和生命周期管理的控制面。
• OpenShift、Rancher、Talos 或原生 Kubernetes：团队标准化的运维环境。
• KubeVirt：当 VM 仍然在范围内时，在 Kubernetes 内承载虚拟机的虚拟化层。
• Simplyblock：支撑 VM 磁盘、快照、克隆以及 stateful 数据的持久块存储平台。

关键在于，VMware 迁移项目往往不是败在理念上，而是败在存储和运维层面。让 VM 跑在 Kubernetes 上并不难，难的是让它们以正确的性能特征、数据服务能力和 day-2 运维方式稳定运行。

Simplyblock 在这里提供了面向现代环境的 NVMe-first 存储层。团队可以从 Kubernetes-native storage 起步，把平台对齐到 OpenShift、Rancher by SUSE 或 Talos，并在需要承载虚拟机场景时加入 KubeVirt storage。

哪种目标平台更适合

并不是所有 VMware 迁移都会落在同一个 Kubernetes 发行版或同一种运维模式上。更重要的问题是，哪种控制面和运维模式最适合你的团队、合规要求和生命周期管理方式。

OpenShift 适合企业级标准化

如果团队已经高度围绕 Red Hat 构建平台，OpenShift 往往是更自然的迁移目标，因为它更容易维持跨集群的一致安全、策略和运维模型。Simplyblock for OpenShift 是对应的参考路径。

Rancher 适合多集群编队管理

对于需要跨业务单元、地区或客户管理多个 Kubernetes 环境的组织，Rancher 往往更适合作为运维层。Simplyblock for Rancher by SUSE 和 Simplyblock + Rancher Virtualization Bundle 在这类场景中很有参考价值。

Talos 适合极简、API 驱动的基础设施

有些团队不仅想离开 VMware，还想避免通用 Linux 节点带来的配置漂移。Simplyblock for Talos 和 Simplyblock + Talos Virtualization Bundle 更适合这种更声明式、更极简的 Kubernetes 运维模式。

如果仍需保留 VM，就选择 KubeVirt

如果虚拟机仍是目标环境的一部分，KubeVirt 就是连接旧环境与新平台模型的桥梁。KubeVirt storage 展示了 simplyblock 如何支持 VM 磁盘、快照、克隆以及对性能敏感的虚拟化工作负载。

应该先迁移哪些工作负载

从 VMware 迁移并不一定要从最关键的 VM 群开始。实践中，第一波迁移更适合那些既能帮助验证目标架构，又不会带来过高风险的工作负载。

比较适合作为起点的包括：

• 开发和测试 VM
• 对性能要求适中的内部业务服务
• 平台管理的共享服务
• 已经和 Kubernetes 环境相邻的 VM 型应用
• 原本会默认落在 VMware 上的新工作负载

这些迁移能帮助团队验证运维模型、观察存储行为，并在更大规模迁移前打磨平台。

通常需要更多前期设计的工作负载包括：

• 对延迟高度敏感的数据库
• 高合规要求的系统
• 假设环境非常固定的 legacy appliance
• 带有复杂网络和备份依赖的大规模 VM 资产

这些工作负载也可以迁移，但应在目标平台完成验证和标准化之后再进行。

不能忽视的存储要求

如果 VMware 到 Kubernetes 的迁移是认真的，存储绝不能被当成附属问题。

1. VM 性能需求不会消失

把虚拟机移到 KubeVirt 并不会让它们自动适应噪声存储。很多 VM 依然需要可预测延迟、稳定吞吐和持续一致的 IOPS，尤其是数据库、中间件和内部平台。

2. 快照、克隆和恢复是运维刚需

迁移项目往往过度关注 compute 位置，而忽略了存储工作流。实际上，虚拟磁盘和 stateful 数据同样需要快照、克隆、备份集成和恢复流程。

3. 多租户和 QoS 会变得更重要

一旦 Kubernetes 成为共享平台，不同团队和不同工作负载就会竞争同一套基础设施。存储需要明确的性能控制和隔离能力，而不仅仅是原始容量。

4. 独立扩展 compute 和 storage 是重要的经济杠杆

Software-defined infrastructure 的核心优势之一，就是 compute 和 storage 不必总是同步扩展。这一点在替代 VMware 时尤其重要，因为传统虚拟化环境常常把低效的扩展模式隐藏在昂贵的捆绑方案里。

因此，Software-defined storage 和 NVMe-over-TCP storage 不只是技术选型，而是战略问题。

一个降低风险的分阶段迁移计划

多数团队应把 VMware 迁移视为一系列平台里程碑，而不是一次性 cutover。

阶段 1：评估现有环境

梳理当前 VMware 环境中的工作负载、存储模式、恢复要求和运维依赖，识别哪些工作负载适合优先迁移，哪些需要更多方案设计。

阶段 2：构建目标平台

搭建 Kubernetes，明确是否采用 OpenShift、Rancher、Talos 或原生 Kubernetes 作为运维模型；如果 VM 仍在范围内，则验证 KubeVirt，并把正确的存储层放在底部。这一阶段必须测试性能、快照、克隆和租户隔离，而不是想当然。

阶段 3：先迁移低风险工作负载

利用早期迁移验证以下事项：

• VM 生命周期工作流
• 存储性能表现
• 备份与恢复流程
• 运维职责划分
• 可观测性与支持 runbook

阶段 4：扩大 VM 与容器混合运维

当平台证明可行后，团队就能在同一个 Kubernetes 基础上同时支撑虚拟机和容器化工作负载。通常也是在这个阶段，新的运维和经济优势开始真正显现。

阶段 5：迁移关键的 stateful 工作负载

当平台足够稳定后，就可以更有把握地迁移更关键的 VM 和 stateful 服务，并对性能、扩展性和恢复能力有更强信心。

为什么 simplyblock 能帮助 VMware 迁移计划

Simplyblock 在 VMware 到 Kubernetes 的策略中非常关键，因为它解决了最难的一类现实问题：如何为虚拟机和 stateful 工作负载提供现代块存储，同时又不把传统存储架构的成本和复杂性一起继承下来。

对于迁移计划而言，这通常意味着：

• 在共享平台上支撑 VM 磁盘和持久数据
• 降低对硬件绑定存储栈的依赖
• 把快照和克隆变成平台级工作流
• 让长期成本更加可预测
• 给平台团队一层真正适配 Kubernetes 运维方式的存储基础

如果你的目标不仅是“离开 VMware”，而是“构建一个更适合虚拟化和 cloud-native 工作负载的长期平台”，那么 simplyblock 的价值就会更加明显。

相关页面：

• OpenShift storage
• Rancher by SUSE storage
• Talos storage
• Simplyblock + Rancher Virtualization Bundle
• Simplyblock + Talos Virtualization Bundle
• KubeVirt storage
• Kubernetes storage
• Persistent Storage for Kubernetes
• VMware vs Kubernetes
• KubeVirt vs VMware

VMware 到 Kubernetes 迁移 FAQ

Kubernetes 真的是 VMware 的替代品吗？

不能直接这样理解。Kubernetes 是编排平台，而 VMware 是虚拟化平台。更现实的模式是把 Kubernetes、适合团队的运维层（如 OpenShift、Rancher 或 Talos）、KubeVirt 以及能支撑 VM 和 stateful workload 的存储平台结合起来。这套组合如果设计合理，可以替代相当大一部分以 VMware 为中心的基础设施。

所有 VMware 工作负载都适合迁移到 Kubernetes 吗？

不是。某些工作负载更适合作为第一波迁移对象。目标不是“理念正确”，而是找到适合迁移的工作负载，建立更好的目标平台，并避免让未来十年继续被旧约束锁定。

为什么在 VMware 迁移中，存储这么关键？

因为成功不只取决于 compute。VM 磁盘、快照、恢复、可预测延迟以及工作负载隔离都依赖底层存储层。糟糕的存储设计足以毁掉原本很有希望的迁移计划。

团队是否必须在 OpenShift、Rancher、Talos 和 KubeVirt 之间二选一？

不需要。OpenShift、Rancher 和 Talos 描述的是 Kubernetes 周围的运维环境，KubeVirt 则是在该环境中运行 VM 的虚拟化层。它们解决的是目标架构中的不同问题，可以与同一套 simplyblock 存储层组合使用。

在 VMware 退出策略中，KubeVirt 扮演什么角色？

KubeVirt 允许在 Kubernetes 内运行虚拟机，让团队能够在统一 control plane 上标准化，同时继续支持基于 VM 的应用。对于希望现代化但又不想要求所有工作负载立即容器化的组织来说，这是一座非常务实的桥梁。

团队应该何时开始规划迁移？

通常比他们想象的更早。即使执行会按阶段推进，平台设计、工作负载评估和存储验证也都需要时间。越早开始，选择越多，也越能避免后期被动决策。