\n\n本文分析了 VM 迁移至 K8s 时网络配置导致项目停滞的原因。强调了 IP 变更引发的“网络税”风险，建议根据需求选择 L3 现代化或 L2 平移模式，以确保迁移顺利完成。
译自：VM Migration to Kubernetes: What Breaks and How to Prevent It | Tigera – Creator of Calico
作者：Dillon Barry
关于将 VM（虚拟机）迁移到 Kubernetes 的业务案例，每一个参与其中的人预先都不会告诉你：计算部分其实是最简单的。
将工作负载从 vSphere 迁移到 Kubernetes 在概念上非常直接。工具已经成熟，架构也经过验证。计算资源移动，存储重新映射，平台团队也有一套计划。
而网络，才是项目悄然停滞的地方。
这并非因为技术不可行，而是因为在项目启动前，没有人对网络进行合理的评估。一场平台迁移演变成了多团队的协调练习。防火墙团队需要变更窗口，安全团队需要审查本不该改变的网络位置，应用团队发现了没人记录的硬编码 IP。
六个月后，一半的 VM 仍留在 vSphere 上，而项目在技术上处于“进行中”状态。
这并不是技能差距，它发生在拥有精干团队的最成熟组织中。这是一个评估问题，并且有一个特定的原因：VM 网络工作方式与 Kubernetes 网络工作方式之间的差距，比迁移计划上看起来的要大得多。
这篇文章是写给那些批准这些项目的人的。以下是实际会出故障的地方，以及在出故障前需要做出的决策。
为什么 VM 迁移到 Kubernetes 会在网络上停滞
在传统的虚拟化环境中，VM 的 IP 地址就是它的身份。不仅是在技术层面作为路由目标，在运维层面也是如此。它在 DNS 中注册，在防火墙规则中被引用，被监控代理监视，被对等应用连接。在受监管的环境中，它甚至可能出现在合规文档中。
Kubernetes 构建在不同的假设之上。工作负载是临时性的。地址来自集群管理的范围，在集群之外没有任何意义。身份基于标签（Label），而非地址。
当 VM 使用默认网络模型迁移到 Kubernetes 时，它会获得一个新的 IP。这个新 IP 会波及到所有引用旧 IP 的地方：防火墙规则、DNS、安全审查、监控、对等应用。这些在技术上都不难，问题在于平台团队并不拥有这些系统，也无法控制这些时间表。一项本以为属于单一团队的迁移任务，变成了四个团队之间的协调练习。
这就是“网络税”：一种不考虑 VM 原有连接关系的底层网络模型所带来的隐藏成本。你的平台团队在支付这笔税，你的项目进度表在吸收它。
这并非个案。根据 Portworx 2024 年 Kubernetes 专家之声报告，58% 的组织计划使用 KubeVirt 等技术将部分 VM 迁移到 Kubernetes。在这些组织中，65% 计划在未来两年内实施。
迁移正在发生，而评估决策现在就要做出。
想象一个运行了数年的单一 VM。它的 IP 地址存在于两条防火墙规则、一个监控仪表板、一个负载均衡器后端，以及一份最后审计于 2021 年的合规文档中。应用团队将其硬编码在一个三年来没人打开过的配置文件里。这个 VM 并不罕见，它具有代表性。现在，请将其乘以 200 倍。
VM 迁移至 Kubernetes 在实践中的两种失败模式
在 VM 到 Kubernetes 的迁移中，有两种失败模式反复出现。一旦你知道要去寻找它们，它们就不再令人意外。
安全瓶颈
企业环境中的 VLAN 不仅仅是路由工具，它们还是合规性构建块。组织花费多年时间进行网络分段，以满足 PCI-DSS、SOC 2 或内部安全策略。这些网段由安全团队拥有并记录。对它们的任何更改都需要签字批准。
当 VM 的网络位置在迁移过程中发生变化时，即使 VM 本身未变，安全团队也有正当理由对其进行审查。审查需要多长时间就得等多久，平台团队无法加速这一过程。
平台碎片化
范围扩大和安全瓶颈的共同结果是“部分迁移”。依赖较少的 VM 完成了迁移，而那些嵌入在防火墙规则或经过安全审查的 VLAN 网段中的静态 IP VM 则留在了 vSphere 上。
组织最终并行运行两个平台，且没有达成一致的整合路径。支撑迁移合理性的成本降低和运维简化被推迟。项目在技术上没有被取消，只是永久性地无法完成。
对于许多组织来说，这不仅仅是一次规划练习。活跃的许可证重新谈判和长期虚拟化路线图的不确定性，已将这些讨论从待办事项移到了董事会会议室。迁移正在进行中，下个季度做出的评估决策将决定它们能否成功。
每个 VM 迁移至 Kubernetes 都需要回答的一个问题
在对任何 VM 迁移项目进行评估或预算规划之前，有一个问题值得明确回答：这次迁移是否也是一次现代化改造？
如果是，那么网络重新设计就是预期内的工作。额外的团队协调也是范围的一部分。据此规划预算和时间表，并计划让安全和网络团队从一开始就参与进来。
如果不是，那么为迁移选择的网络模型将决定“平移（lift-and-shift）”是切实可行的，还是仅仅是空谈。
这听起来像是一个技术问题，其实不然。这是一个恰好有技术答案的项目评估问题。
默认的 Kubernetes 网络模型是为云原生工作负载设计的。这些容器拥有临时地址且没有上游依赖。它并非为那些绑定了十年防火墙规则、DNS 条目和合规文档（且使用固定 IP）的 VM 设计的。
使用为前者设计的模型来迁移后者，正是项目陷入困境的根源。你不是在为 Kubernetes 集群选择网络模型。你是在选择你的迁移是否也是一次现代化改造，以及你的预算是否考虑到了这一点。
在某些组织中，关于 VM 迁移使用哪种网络模型的决定权根本不在平台团队手中。在 VLAN 作为合规构建块而非仅仅是路由工具的地方，安全团队拥有决定权。这并不罕见，这也是为什么要在选择架构之前，而不是之后，邀请他们参与评估讨论的原因。
两种网络模型，两种不同的项目
在 Kubernetes 中运行 VM 有两种网络模型，选择哪一种取决于迁移的实际目的。
现代化模型
在三层（L3）模型中，VM 从集群的地址范围中获取一个新的 IP 地址。流量在集群和网络其余部分之间路由。一旦 VM 进入集群网络，它的操作方式就与容器相同。Kubernetes 原生工具无需修改即可应用。长期的运维模型非常整洁。
权衡之处在于：所有引用旧地址的地方都需要更新。防火墙、DNS、监控、对等应用。这就是工作量所在。当以现代化为目标时，这是预期内且有预算支持的；对于运行少量 VM 或上游依赖较少的 VM 的组织，这通常是正确的选择。问题不在于 L3 路由本身，而是在从未评估过现代化需求的 VM 资产上使用 L3 路由。
平移模型
在二层（L2）模型中，现有的网络段直接延伸到 Kubernetes 集群中。利用 KubeVirt 将 VM 作为原生 Kubernetes 工作负载与容器并排运行，VM 保留其原始 IP 地址。它原先所在的 VLAN 在集群内部得以保留。从上游网络的角度看，工作负载并没有移动。防火墙规则依然适用，DNS 依然解析。安全团队不需要被拉入一场他们未曾计划的审查中。
Calico L2 桥接网络（L2 Bridge Networks）提供了这种能力。上游网络继续看到与以往相同的工作负载。没有变更申请，没有重新配置，也没有其他团队介入。
实际结果是：平台团队端到端地拥有迁移。没有排队等待的防火墙变更申请，没有对未改变的工作负载进行安全审查，没有应用团队的依赖。项目按照原定范围和原定时间表交付。这才是“平移”应有的含义。
你可以将 VM 从 VMware 迁移到 Kubernetes，它保留原始 IP，留在原始 VLAN。一切都不需要改变。而现在，它可以受到 Calico 网络策略的保护，并通过 Calico 流量日志进行可观测性分析。
对于迁移具有多年积累的网络依赖关系的 VM 团队来说，这种连续性决定了迁移是能够完成，还是会被取消。
关于 L2 桥接模式的技术分解，请参阅我们的博客文章：使用 Calico L2 桥接网络将 VM 平移至 Kubernetes，文中详细介绍了网络连续性的实际工作原理，并包含网络研讨会录像。
迁移至 Kubernetes 后，你的 VM 资产能获得什么
为迁移选择 L2 模型并不意味着你的 VM 资产将永远停留在传统模式。迁移只是开始，“第二天（Day 2）”网络才是接下来的重点。
一旦 VM 在 Kubernetes 中运行，平台团队就能获得旧虚拟化环境无法提供的运维能力。流量可见性（包括迁移后的 VM 与其他工作负载之间的东西向流量）无需额外工具即可实现。安全策略可以使用团队用于容器的相同构建块直接应用于 VM 接口，并根据安全团队设定的任何时间表逐步替换传统的防火墙规则。这就是实践中的深度防御（Security in Depth）：一层层应用到每个工作负载的控制，而不是一次性替换单一的边界防护。
VM 还可以在集群节点之间移动，而无需重新配置网络。相同的 IP，相同的 VLAN，上游网络无需更改。通过 KubeVirt 在节点间进行热迁移，无需额外的网络协调步骤。
这就是“策略优先”迁移所能实现的：在工作负载移动之前，网络和安全层已经统一，因此“第二天”的操作不需要进行第二次迁移。迁移和现代化保持在独立的时间表上，拥有独立的预算，由独立的团队管理。互不阻塞。
上个季度迁移到 Kubernetes 的 VM，今天就可以应用由安全团队使用现有审查流程编写的新安全策略。迁移并没有强迫他们在时机或工具上做出妥协。安全团队获得了一个版本化且可审计的策略模型，而平台团队则按时完成了迁移。这两个结果并不冲突。
批准 VM 迁移至 Kubernetes 前要问的四个问题
在批准任何 VM 迁移项目之前，有四个问题值得明确回答：
- 这次迁移也是一次现代化改造吗？ 如果是，请为多团队协调预留预算。如果不是，请确认网络模型支持真正的平移。
- 哪些 VM 的静态 IP 嵌入在防火墙规则或合规文档中？ 这些是最容易导致停滞的工作负载。在工作开始前识别它们，而不是在进行中。
- 迁移后的 VM 目前所在的 VLAN 段由谁拥有？ 如果是安全团队，他们应该出现在评估环节，而不是执行阶段。
- 对于无法现代化的工作负载，计划是什么？ 如果没有答案，请做好两个平台无限期并行运行的准备。
在项目启动前，对单个 VM 进行“爆炸半径”分析。挑选一个，映射连接到其 IP 的每个服务、引用它的每条防火墙规则、每个 DNS 条目，以及每个条目的所有者。这一项练习比任何架构图都能更真实地告诉你迁移的真实范围。如果答案填满了一个表格，那么你的迁移就不是一个周末就能完成的项目；如果答案只有三行，那就从那里开始。
这些不是技术问题，而是评估问题。答案决定了迁移是实现了其业务价值，还是悄然变成了一个没人批准的烂尾工程。
想了解更多关于 VM 迁移的信息？咨询专家，了解如何迁移你的 VM 资产。
常见问题
-
为什么 VM 迁移到 Kubernetes 会停滞？ 大多数停滞在网络层面，而非计算层面。默认的 Kubernetes 网络模型会为迁移的工作负载分配新 IP 地址，这会破坏引用原始地址的防火墙规则、DNS 条目和合规文档。原本看似平台团队的项目变成了跨网络、安全和应用团队的协调练习。
-
VM 迁移中二层（L2）和三层（L3）网络有什么区别？ 三层（L3）模型从集群地址范围为 VM 分配新 IP——这对现代化项目很整洁，但需要更新所有引用旧地址的系统。二层（L2）模型将现有网段延伸到集群中，使 VM 保持原始 IP 和 VLAN。L3 是现代化模型；L2 是平移模型。
-
VM 迁移到 Kubernetes 时能保留其 IP 地址吗？ 可以——但必须使用将现有网段延伸到 Kubernetes 集群的二层（L2）网络模型。通过 L2 网络，VM 保留其原始 IP 和 VLAN；防火墙规则、DNS 条目和对等应用无需重新配置即可继续工作。
-
KubeVirt 支持平移（lift-and-shift）迁移吗？ KubeVirt 将 VM 作为原生 Kubernetes 工作负载运行，但网络模型决定了迁移是真正的平移，还是变相的现代化改造。将 KubeVirt 与二层网络模型结合可以保留 VM 的原始 IP 和 VLAN——这才是实践中平移的真正含义。
-
VM 到 Kubernetes 迁移中的“网络税”是什么？ “网络税”是指选择一种未考虑 VM 现有连接关系（防火墙规则、DNS、监控、对等应用、合规文档）的网络模型所带来的隐藏成本。修复这些问题在技术上都不难，但平台团队不拥有这些系统，也无法控制其时间表。这笔税体现为项目延迟和部分迁移。全
- 工智能
