多云验证

Kubernetes 集群有一个控制平面。我们的系统从一个控制平面驱动多个公共云上的租户节点——并且我们可以向您展示实时节点，而非架构可能允许的图示。

当前实际运行情况

从控制平面自身的服务注册表中直接读取，截至 2026 年 8 月 21 日，一个租户的节点集群有两个节点仍在一分钟内注册并进行心跳，第三个节点在以下描述的测试后已退役：

节点	云	状态	代理程序
alicloud-node-1	Alibaba Cloud	就绪	0.7.9, specVersion 4
gcp-node-1	Google Cloud	就绪	0.7.9, specVersion 4
aws-node-1	Amazon Web Services	2026年6月复制测试后退役	测试时的0.3.51

alicloud-node-1注册的 WireGuard 端点是阿里云自身地址范围内的一个公共 IP，我们独立确认了这一点，而不是取自节点的自报告标签。两个节点通过 WireGuard 网格加入控制平面，而不是共享的云 VPC——正是网格使得一个控制平面能够将两个不同云的网络视为一个可寻址的集群。

跨云部署，已证明在实际生产环境中运行 — 不仅仅是设计

在两个云上注册节点是一回事。在它们之间移动运行的工作负载而不出现两个副本都不健康的间隙，则是另一回事。我们针对这种情况构建了一个强制性的实时门控（内部称 “LG6”）：创建一个固定到 alicloud-node-1 的部署，使其变得健康，然后重新将其放置到 gcp-node-1 上。重要的断言是七个中的第三个：在创建 gcp-node-1 容器的那一刻，alicloud-node-1 容器仍然存在——并且只有在新容器被确认健康后才移除。这就是受保护迁移与跨云移动导致工作负载完全丢失的间隙之间的区别。该门控被记录为强制性的，具体是因为当时所有其他实时门控都针对单节点放置运行，无法捕获此处的回归。

三个云，三个大洲：复制测试是如何运行的

在 2026 年 6 月 14 日，一个控制平面驱动了一个横跨 亚马逊云科技、谷歌云和阿里云 的三节点租户，并在它们之间复制了实时卷数据。这就是它的构建方式和测量内容。

网格先行。 三个节点被加入一个完整的 WireGuard 网格——六个对等配置，每对都报告 connected 并进行实时握手，每个都携带一个真实的公共端点，而不是 NAT 猜测。应用这些对等的代理程序运行在 非特权模式：每个都生成一个短命的特权辅助容器来写入 /32 对等路由然后退出。代理程序上没有 cap_add，没有 compose 变更，没有任何操作员接触这三台机器。

然后是一个复制的分布式卷。 主卷在 AWS 节点上，副本在谷歌云节点上，由代理程序从 其自身镜像 运行的 rsync 守护进程同步——因为受限制的节点只能访问私有注册表，不能访问其他任何地方。

测量。 写入 AWS 节点主卷的标记文件，大约在 四十秒后出现在谷歌云副本中，跨网格实现节点‑到节点‑的传输。控制平面根本不在数据路径中——它决定放置位置然后让开。这是任何 Kubernetes 拓扑都无法复现的部分：集群将是独立的，它们之上的某个东西将必须代理复制。

所需的工作 — 包括那个欺骗我们的错误

四次代理程序发布连接了网格与实际复制，每一次都是通过逐步深入诊断发现的特定故障：

• 0.3.48 — 从代理程序自身的镜像运行 rsync 守护进程；在只能访问私有注册表的节点上，无法拉取公共镜像。
• 0.3.49 — 将容器路径转换为主机路径，因为代理程序自身的数据目录是一个命名卷，它对该路径的视图与主机不同。
• 0.3.50 — 将守护进程置于主机网络上；桥接网络未能可靠地为到达 WireGuard 接口的流量提供服务。
• 0.3.51 — 绑定配置的端口。如果没有明确的 port 指令，守护进程会回退到默认端口，而旧的桥接端口映射一直掩盖了这个问题。

最重要的发现是我们自己发现的那个。 在 0.3.51 之前，卷报告了 InSync。事实并非如此。该状态来自存储插件自身的本地物化标记，而非来自一次已完成的传输——一个“绿灯”意味着“卷在此处存在”，而非“数据已跨越海洋”。突破点是通过代理程序的 exec API 在守护进程内运行 netstat，并发现预期监听的位置没有任何响应。我们现在通过移动文件并在另一侧查找来衡量复制状态，因为状态字段可能对错误的问题是诚实的。

之后仍然存在一个竞态条件——对同一目标的重叠删除可能导致同步失败——在 0.3.52 中已修复，并通过十次连续运行确认。这项工作在次日被推广到生产环境，测试卷通过控制器自身的 finalize 路径删除，并在两个节点上验证已消失。

AWS 节点在测试完成其使命后被退役。测试所证明的是网格、复制和测量；之后继续运行付费实例不会证明更多东西。

来源：内部工程日志 2026-06-15_dvm-materialization-mesh-replication.md，记录了网格验证、四次代理程序发布、四十秒传输、exit-23 竞态及其十次运行确认，以及生产环境晋升。

超越此租户：生产运行在我们不拥有的基础设施上

除了上述双云测试集群外，我们生产环境的控制平面今天管理着一个混合集群：其自身的平台节点，加上 两个客户自有节点，这些节点运行在客户控制的基础设施上，而非我们的。客户自有节点完全无法由我们远程升级——它们只能通过客户自己驱动的显式仪表板批准来升级。这是对同一根本主张的第二个独立证明：一个控制平面，真正独立的基础设施，隔离边界由谁能访问节点来强制执行，而不仅仅是网络策略。

有关使跨独立基础设施共享控制平面变得安全的租户隔离机制，请参见 合规性。