基于 Kube-OVN 的多集群多 VPC 互联设计与实现
本文介绍我们在 Kube-OVN 上开展的一项多集群多 VPC 互联工作。相关研究成果发表于 WWW 2025（The ACM Web Conference，CCF-A），这篇文章则主要从系统实现的角度，对该原型的设计背景、核心机制以及工程实现过程做一个简要整理。
这项工作的重点并不在于重新构建一套完整的多集群网络系统，而是在现有 Kube-OVN 网络模型基础上，围绕跨集群场景补齐若干关键控制能力，包括 VPC DNS 转发维护、网关隧道管理以及集群与 broker 之间的信息同步。整体目标比较明确：在尽量复用已有网络抽象和控制面的前提下，降低多集群多 VPC 环境下的配置复杂度与维护成本。
1. 背景与问题
在单集群场景下，Kubernetes 与 Kube-OVN 已经能够提供比较完整的网络能力，包括 Pod 通信、Service 暴露、VPC 隔离、网关管理等。这些能力在单一集群范围内通常具有较好的封装性，系统边界也相对清晰。
但在多集群环境中，问题会明显复杂很多。原本在单集群内部自然成立的一些假设，到跨集群场景下往往不再成立。例如，业务访问路径不再局限于集群内部，名称解析与网络可达性之间的关系也会变得更加松散；与此同时，网关、隧道、外部地址以及跨集群控制信息之间开始出现新的耦合关系。
在具体实践中，比较核心的问题主要体现在以下几个方面。
第一，不同集群之间的互联关系需要持续维护。跨集群通信不是一次性打通即可，随着节点、地址、网关状态以及网络对象的变化，控制面需要具备持续收敛能力，否则系统很容易退化为依赖人工维护的静态配置集合。
第二，多 VPC 环境下的服务发现和访问路径需要保持一致。对于业务而言，最直接的问题往往不是底层链路如何建立，而是服务名称能否被正确解析、解析结果能否对应到正确的跨集群访问路径。
第三，集群与 broker 之间的状态同步需要保持稳定。跨集群环境中，外部可达地址、网关状态以及集群侧视图如果不能及时传播，后续的自动化逻辑就很难建立在稳定的状态基础之上。
因此，从系统视角来看，这项工作的核心并不是单纯增加若干网络功能，而是围绕多集群多 VPC 场景中最关键的一组控制问题，构建一套能够持续维护和自动收敛的实现机制。
2. 设计考虑
这项工作的一个基本出发点，是尽量沿用 Kube-OVN 已有的网络模型，而不是在其之外再构造一套完全独立的体系。原因比较直接：Kube-OVN 已经提供了较成熟的 VPC、子网、网关等抽象，如果多集群能力完全另起一套实现，最终很容易出现模型不一致、控制逻辑重叠以及后续维护困难等问题。
因此，在整体设计上，我们更倾向于采用一种增量式的方式：在不打破现有网络模型的前提下，为多集群场景补齐必要的控制逻辑，使跨集群能力能够自然嵌入到已有系统中。
基于这一思路，设计上主要关注以下几点。
其一，尽量复用现有 Kube-OVN 的网络抽象，使新引入的控制逻辑能够与原有 VPC 和网关体系保持一致。
其二，尽量减少额外的系统复杂度。多集群网络本身已经具有较高复杂性，如果在控制面之外再叠加过多旁路机制，系统边界会迅速变得模糊。
其三，将容易漂移的配置收敛到控制器中统一维护。相比于依赖文档、脚本或人工操作，控制器方式更适合处理跨集群环境下持续变化的状态。
其四，强调工程上的可维护性，而不是追求过于铺开的功能完备性。对于这类原型系统而言，能够围绕关键场景形成一个清晰、稳定的闭环，往往比单纯扩展功能范围更重要。
3. 系统实现概述
从代码和功能主线来看，这一原型主要围绕三类能力展开：VPC DNS 转发维护、VPC 网关上的跨集群隧道维护，以及集群与 broker 之间的关键信息同步。这三部分在实现层面上分别对应不同的控制职责，但从整体上看，它们共同服务于同一目标，即让多集群多 VPC 环境下的跨集群访问从依赖人工拼装的过程，转变为可被控制器持续维护的系统能力。
3.1 VPC DNS 转发的自动维护
在多集群多 VPC 环境中，服务访问的第一步往往并不是建立实际的数据转发路径，而是完成正确的名称解析。对于业务侧而言，一个最直观的问题就是：服务名称是否能够被解析到正确的目标，以及解析完成后是否能够沿着预期路径访问到对应服务。
因此，系统实现中的第一部分工作聚焦于 VPC DNS 转发关系的自动维护。这里的关键点不在于单条转发规则本身，而在于如何将原本容易散落在人工配置和临时运维操作中的逻辑，统一收敛到控制面中进行持续管理。
这一机制的实现带来了几个比较直接的收益。首先，配置入口更加统一，不同对象之间的依赖关系更容易在控制器层面梳理清楚。其次，当 VPC、服务或集群间关系发生变化时，控制器能够按照期望状态继续收敛，而不需要每次都依赖手工补配。最后，名称解析与访问路径之间的对应关系可以更自然地纳入多集群整体网络模型中，而不是作为额外的旁路逻辑存在。
从工程角度看，这部分实现虽然不是最容易在表面上展示性能收益的一部分，但它对于提升系统整体可用性和一致性非常关键。很多跨集群系统在早期原型阶段都能完成基本的连通性，但真正决定它能否长期稳定运行的，往往恰恰是这类看似细碎却高度关键的控制逻辑。
3.2 基于 VPC 网关的跨集群隧道维护
跨集群互联最终仍然需要落到实际的数据转发路径上，因此网关始终是系统中的关键位置。在这一原型中，跨集群隧道的维护主要依托 Kube-OVN 的 VPC 网关能力进行扩展，而不是在系统之外单独引入一套独立的数据面。
采用这种实现方式主要有两方面考虑。一方面，它能够较好地保持与现有网络模型的一致性，使隧道、路由、NAT 和网关职责之间的关系更加清晰。另一方面，很多已有能力可以在此基础上自然复用，从而减少系统层面的重复建设。
在具体实现中，我们更关注的并不是“隧道能否被建立”这一静态问题，而是“隧道关系能否随着环境变化被持续维护”这一动态问题。多集群环境中的地址、节点、网关关联以及路由关系都不是静止不变的，如果仅通过一次性配置完成隧道建立，那么系统在后续运行中很容易因为状态变更而出现不一致问题。
因此，在这一部分实现中，控制器承担的职责不仅是建立初始隧道关系，更重要的是在相关对象变化时继续维护这些关系，使系统始终尽量向目标状态收敛。这样做的意义在于，它将跨集群连通性从静态配置问题转变为了持续的状态管理问题，也更符合 Kubernetes 控制器体系的设计习惯。
3.3 集群与 broker 之间的状态同步
除了名称解析和跨集群转发路径之外，多集群系统中还有一类非常关键、但又容易被忽视的问题，即状态同步。尤其是在引入 broker 参与跨集群协同的情况下，集群侧视图、外部可达地址以及网关相关信息如果不能保持及时同步，那么后续所有建立在这些信息之上的自动化逻辑都会受到影响。
因此，系统实现中的第三部分工作聚焦于集群与 broker 之间关键信息的同步维护，例如 GatewayExIp 等状态信息。这部分逻辑从表面上看更偏向元数据管理，而不像隧道和转发那样直接体现为数据路径上的变化，但实际上它在整个系统中承担着基础支撑作用。
从实际经验来看，多集群系统中的许多问题最终并不一定来自复杂的数据面逻辑，而更常见于状态不同步、视图不一致或者控制器无法感知关键变更等问题。也正因如此，我们在实现中将这部分状态同步作为一个明确的控制职责加以维护，使 broker 与集群之间能够在关键状态上保持尽可能一致的视图。
从系统设计的角度看，这一部分实现体现了一个比较重要的考虑：在讨论更复杂的路由、调度或高性能优化之前，首先需要保证状态面和控制面本身是稳定的。否则，后续所有自动化能力都可能建立在不可靠的基础之上。
4. 实现方式与工程取向
从整体上看，这一原型的实现并不是以构建一个“大而全”的多集群网络平台为目标，而是围绕若干确定的问题，逐步补齐控制能力并形成可运行的系统闭环。这也使得它在工程取向上与很多以功能堆叠为主的原型有所不同。
首先，这一实现更强调与现有平台能力之间的衔接，而不是通过引入大量新概念来重新定义系统边界。无论是 VPC DNS 转发、网关隧道还是 broker 同步，本质上都在试图将新增能力纳入已有 Kube-OVN 网络体系中统一理解和维护。
其次，这一实现更关注持续维护能力，而不是一次性配置能力。对于多集群系统而言，初始连通通常不是最困难的部分，困难之处在于系统运行过程中状态持续变化，而控制面是否具备相应的感知和收敛能力。正因如此，controller/operator 层面的设计在整个系统中占据了较大比重。
最后，这一实现更强调边界控制。多集群网络可以进一步延展出非常多的问题，包括更复杂的调度、更激进的数据面优化、更大规模下的状态同步策略等。但在这一阶段，我们更希望先围绕关键场景建立起一个逻辑清晰、边界明确、实现可控的系统原型，而不是在初始阶段就过早铺开所有问题。
5. 相关工作与本文工作的关系
这项工作的相关研究成果后来整理并发表于 WWW 2025。从更完整的系统视角看，这项工作聚焦于多 Kubernetes 集群间的高效通信框架，包含 broker 层、worker 层以及跨集群通信机制等内容。
而从这篇文章的角度，我们更关注其中与代码原型直接相关、且在工程实现中真正承担控制职责的部分。换句话说，论文提供的是更完整的系统视角和问题抽象，而本文希望记录的，则是这套思路在 Kube-OVN 多集群多 VPC 原型中的具体落点。
因此，本文并不尝试对论文中的所有机制逐一展开，而是围绕实际代码主线，整理那些能够较直接反映系统实现思路的部分。这种写法也更接近真实工程中的工作方式：许多系统能力在论文中可以被抽象为统一框架，但在代码实现中，往往是通过若干控制器和具体对象之间的协同逐步落下来的。
6. 一些体会
从个人角度看，这项工作最有价值的地方，不仅在于它形成了一套可以运行的原型，更在于它把一些原本停留在抽象层面的系统问题，真正转化为了可以实现、可以维护、也可以继续演进的工程对象。
一方面，这一过程让我更加明确地意识到，多集群网络问题本质上并不是简单的“连通性问题”，而是一个涉及名称解析、控制状态、网关协同以及持续收敛机制的系统工程问题。很多时候，系统能否长期稳定运行，并不取决于某个局部机制是否足够复杂，而取决于整体控制逻辑是否清晰、状态是否一致以及实现边界是否合理。
另一方面，这项工作也使我对 Kubernetes 控制器模式在网络系统中的作用有了更直接的理解。对于多集群环境而言，控制器真正有价值的地方，不只是自动完成若干配置，而是在状态持续变化的前提下，将系统不断拉回到期望状态。对于这类问题，controller/operator 提供的不只是实现手段，更是一种比较自然的系统组织方式。
此外，这项工作也让我更加重视工程上的克制。多集群网络是一个可以不断扩展的问题空间，但在实际实现中，能够优先抓住最关键的控制点，并在现有平台基础上逐步做出增量改进，往往比从一开始就追求过度铺开的功能设计更现实，也更容易形成稳定结果。
7. 结语
本文对我们在 Kube-OVN 上开展的多集群多 VPC 互联工作做了一个简要整理。整体来看，这项工作的重点并不在于构造一套完全独立的新系统，而是在现有网络模型基础上，通过补充 VPC DNS 转发维护、网关隧道管理以及集群与 broker 状态同步等关键控制能力，使多集群场景下的跨集群访问能够以更自动化的方式完成。
相关研究成果发表于 WWW 2025（CCF-A），但对我而言，这项工作的价值不仅在于论文本身，更在于它对应了一段比较完整的系统实现经历：从问题抽象、机制设计到控制器落地，再到原型逐步形成闭环，这一过程让我对云原生网络、多集群系统以及控制面自动化有了更加具体的认识。
后续如果继续沿这一方向展开，仍然有很多值得进一步讨论的问题，例如更大规模下的状态同步、更复杂场景中的故障处理，以及更高性能的数据面支持等。不过就当前阶段而言，这一原型已经较清晰地呈现出一个基本思路：在复杂系统中，真正关键的往往不是额外增加多少功能，而是能否围绕核心问题建立起一套可维护、可收敛、可持续演进的实现机制。
