Preuve Multi-Cloud

Un cluster Kubernetes a un plan de contrôle. Le nôtre pilote des nœuds locataires sur plus d'un cloud public depuis un seul plan de contrôle — et nous pouvons vous montrer les nœuds en direct, pas un diagramme de ce que l'architecture permettrait.

Ce qui est réellement exécuté aujourd'hui

En lisant directement le registre de services du plan de contrôle lui-même le 21 août 2026, la flotte de nœuds d'un locataire contient deux nœuds encore inscrits et dont le battement de cœur est reçu dans la minute, et un troisième qui a été retiré après le test décrit ci-dessous :

Nœud	Nuage	État	Agent
alicloud-node-1	Alibaba Cloud	prêt	0.7.9, specVersion 4
gcp-node-1	Google Cloud	prêt	0.7.9, specVersion 4
aws-node-1	Amazon Web Services	mis hors service après le test de réplication de juin 2026	0.3.51 au moment du test

L'endpoint WireGuard enregistré de alicloud-node-1 est une IP publique dans la plage d'adresses propre d'Alibaba Cloud, que nous confirmons indépendamment plutôt que de la prendre de l'étiquette auto-rapportée du nœud. Les deux nœuds sont joints au plan de contrôle via un maillage WireGuard, pas un VPC cloud partagé &mdash ; c'est le maillage qui permet à un plan de contrôle de traiter les réseaux de deux clouds différents comme une flotte adressable unique.

Placement multi-cloud, prouvé en direct — pas seulement conçu

Inscrire des nœuds sur deux clouds est une chose. Déplacer une charge de travail en cours d'exécution entre eux sans interruption où aucune des deux copies n'est saine en est une autre. Nous avons construit une porte de validation live obligatoire pour exactement ce cas (en interne « LG6 ») : créer un déploiement épinglé à alicloud-node-1, le laisser devenir sain, puis le replacer sur gcp-node-1. L'assertion qui compte est la troisième des sept : le conteneur alicloud-node-1 est toujours présent au moment où le conteneur gcp-node-1 est créé &mdash ; et n'est supprimé qu'une fois que le nouveau est confirmé sain. C'est la différence entre une migration protégée et une fenêtre où un déplacement inter-cloud supprime entièrement la charge de travail. La porte est documentée comme obligatoire spécifiquement parce que toutes les autres portes de validation live de l'époque fonctionnaient sur des placements mono-nœud et n'auraient pas pu détecter une régression ici.

Trois clouds, trois continents : comment le test de réplication a été exécuté

Le 14 juin 2026, un seul plan de contrôle a piloté un locataire à trois nœuds à travers Amazon Web Services, Google Cloud et Alibaba Cloud, et a répliqué des données de volume live entre eux. C'est ainsi que cela a été construit et ce qui a été mesuré.

Le maillage est venu en premier. Les trois nœuds ont été joints dans un maillage WireGuard complet &mdash ; six configurations de pair, chaque paire rapportant connected avec des handshakes live, chacun portant un vrai endpoint public plutôt qu'une supposition de NAT. Les agents qui ont appliqué ces pairs fonctionnent sans privilège : chacun génère un conteneur helper privilégié de courte durée pour écrire les routes de pair /32 et se termine. Pas de cap_add sur l'agent, pas de changement de compose, pas d'opérateur touchant l'une des trois machines.

Ensuite un volume distribué répliqué. Primaire sur le nœud AWS, réplique sur le nœud Google Cloud, synchronisé par un démon rsync exécuté par l'agent depuis sa propre image &mdash ; car un nœud verrouillé peut atteindre le registre privé et rien d'autre.

La mesure. Un fichier marqueur écrit dans le volume primaire sur le nœud AWS est apparu dans la réplique Google Cloud en environ quarante secondes, nœud‑à‑nœud à travers le maillage. Le plan de contrôle n'était pas du tout dans le chemin des données &mdash ; il décidait du placement et ensuite s'effaçait. C'est la partie qu'aucune topologie Kubernetes ne reproduit : les clusters seraient séparés, et quelque chose au-dessus d'eux devrait négocier la copie.

Ce que cela a coûté — y compris le bug qui nous induisait en erreur

Quatre versions de l'agent se sont intercalées entre un maillage connecté et une réplique réelle, chacune étant un défaut spécifique trouvé par un diagnostic progressivement plus profond :

• 0.3.48 — exécuter le démon rsync depuis l'image propre de l'agent ; l'image publique n'a pas pu être tirée sur les nœuds qui n'atteignent que le registre privé.
• 0.3.49 — traduire les chemins de conteneur en chemins hôte, car le répertoire de données propre de l'agent est un volume nommé et sa vue de ce chemin n'est pas celle de l'hôte.
• 0.3.50 — placer le démon sur le réseau hôte ; le pont ne servait pas de manière fiable le trafic arrivant sur l'interface WireGuard.
• 0.3.51 — lier le port configuré. Sans une directive port explicite, le démon revenait à la valeur par défaut, et l'ancien mappage de port sur le pont le masquait.

La constatation la plus importante est celle que nous avons trouvée nous-mêmes. Avant 0.3.51, le volume rapportait InSync. Ce n'était pas le cas. Ce statut provenait du marqueur de matérialisation local propre au plugin de stockage, et non d'un transfert terminé — un feu vert qui signifiait "le volume existe ici", pas "les données ont traversé l'océan". La percée a été d'exécuter netstat à l'intérieur du démon via l'API exec de l'agent et de ne rien trouver à l'écoute là où nous nous attendions. Nous mesurons maintenant la réplication en déplaçant un fichier et en le cherchant de l'autre côté, car un champ de statut peut être honnête sur la mauvaise question.

Une condition de concurrence subsistait ensuite — des suppressions se chevauchant vers la même destination pouvaient faire échouer une synchronisation — corrigée dans 0.3.52 et confirmée sur dix exécutions consécutives. Le travail a été promu en production le lendemain, et les volumes de test ont été supprimés via le chemin de finalisation propre au contrôleur, vérifiés comme disparus sur les deux nœuds.

Le nœud AWS a été retiré une fois que le test avait rempli son objectif. Le maillage, la réplication et la mesure sont ce que le test a prouvé ; garder une instance payante en cours d'exécution ensuite n'aurait rien prouvé de plus.

Source : journal d'ingénierie interne 2026-06-15_dvm-materialization-mesh-replication.md, qui consigne la vérification du maillage, les quatre versions de l'agent, le transfert de quarante-deux secondes, la course à l'exit-23 et sa confirmation en dix exécutions, ainsi que la promotion en production.

Au-delà de ce locataire : les exécutions en production reposent sur une infrastructure que nous ne possédons pas

Indépendamment de la flotte d'essai à deux clouds ci-dessus, notre plan de contrôle de production gère aujourd'hui une flotte mixte : son propre nœud de plateforme, plus deux nœuds appartenant à des clients fonctionnant sur une infrastructure que ces clients contrôlent, pas nous. Les nœuds appartenant à des clients ne peuvent pas être mis à niveau à distance par nous du tout &mdash ; ils ne se mettent à niveau que via une approbation explicite dans le tableau de bord que le client gère lui-même. C'est une deuxième preuve indépendante de la même affirmation sous-jacente : un seul plan de contrôle, des infrastructures véritablement séparées, avec la frontière d'isolation appliquée par qui peut même atteindre le nœud, pas seulement par la politique réseau.

Pour le mécanisme d'isolation des locataires qui rend le partage d'un plan de contrôle sur des infrastructures séparées sûr, voir Compliance.