KubeEdge et OpenYurt : Kubernetes jusqu'aux sites distants

La demande revient de plus en plus souvent : une PME industrielle a douze sites de production, chacun avec un petit serveur qui fait tourner de la supervision d'automates, un peu de traitement d'image et un cache local. Un réseau de magasins veut la même chose sur quarante points de vente. Une entreprise du BTP a des bases de chantier reliées par 4G. Dans les trois cas, la question posée est identique : est-ce qu'on peut piloter tout ça depuis un seul Kubernetes, au lieu d'administrer quarante clusters à la main ?

La réponse marketing est oui. La réponse opérationnelle est plus nuancée, et elle dépend d'un détail que la plupart des architectures ignorent jusqu'au premier incident : ce que fait Kubernetes quand le lien vers un site tombe.

Kubernetes part d'une hypothèse forte : le kubelet parle à l'API server en permanence, sur un réseau fiable et à faible latence. Toute la mécanique de réconciliation repose là-dessus.

Le node lifecycle controller vérifie l'état des nœuds toutes les 5 secondes. Au bout de 40 secondes sans nouvelle d'un nœud (node-monitor-grace-period), il le marque NotReady et lui applique le taint node.kubernetes.io/unreachable:NoExecute. Les pods qui n'ont pas de tolérance explicite sont alors évincés au bout de 300 secondes, valeur injectée par défaut par l'admission controller DefaultTolerationSeconds. En clair : cinq minutes de coupure WAN, et le control plane décide que vos pods doivent mourir.

Sur un site distant, ça donne une situation absurde. Le serveur du magasin tourne parfaitement, les conteneurs répondent, mais le control plane à Toulouse considère le nœud comme perdu et tente de replanifier les workloads ailleurs. Ailleurs, c'est nulle part : les autres nœuds sont dans d'autres magasins, avec d'autres capteurs et d'autres réseaux locaux. Résultat, des pods Pending en pagaille, et quand le lien revient, un kubelet qui redémarre et cherche à récupérer sa configuration auprès d'un API server qu'il vient de retrouver, dans un ordre qui n'a rien de déterministe.

Le piège classique, c'est de croire que ça se règle en poussant les tolérances à 3600 secondes. Ça masque le symptôme, ça ne traite pas la cause. Un kubelet coupé du cloud pendant une heure n'a plus aucune source de vérité locale : au moindre redémarrage du nœud, il ne sait pas quels pods relancer, parce que son état vit dans etcd, à 600 km de là. La sensibilité d'etcd à la latence, déjà critique en exploitation d'un control plane classique, devient franchement disqualifiante dès qu'on parle de liens 4G ou de fibres opérateur avec des micro-coupures.

C'est exactement le problème que KubeEdge et OpenYurt attaquent, par deux chemins différents.

KubeEdge, sorti des labos Huawei Cloud en 2018, est devenu en octobre 2024 le premier projet d'edge computing à atteindre le statut de projet gradué à la CNCF. Ce n'est pas un détail de gouvernance : ça signifie un niveau de maturité, de sécurité et de diversité de contributeurs audité par la fondation.

L'architecture repose sur deux blocs. Côté cloud, CloudCore se greffe sur un API server Kubernetes standard : CloudHub tient les connexions WebSocket ou QUIC avec les sites, EdgeController traduit les objets Kubernetes vers les nœuds distants, DeviceController gère les équipements physiques.

Côté site, EdgeCore remplace le kubelet par edged, un équivalent qui parle directement au runtime de conteneurs. La pièce maîtresse est le MetaManager : il persiste dans une base SQLite locale l'état désiré du nœud, les pods, les ConfigMaps, les secrets. Quand le lien tombe, edged ne va plus chercher quoi que ce soit dans le cloud, il lit sa base locale. Le nœud redémarre, relit son SQLite, relance ses pods. Aucune éviction, aucune replanification, parce que le control plane n'a plus autorité immédiate sur ce qui tourne là-bas.

L'autre singularité de KubeEdge, c'est qu'il ne se limite pas aux conteneurs. Le modèle Device Twin permet de représenter un automate, un capteur Modbus ou une passerelle MQTT comme une ressource Kubernetes, avec un état désiré et un état rapporté. Sur un site industriel, ça change la nature du projet : on ne déploie plus des pods, on pilote un parc d'équipements avec les mêmes outils.

Le protocole cloud-edge n'est pas le protocole Kubernetes standard. C'est un canal de messages compressé, conçu pour des liens médiocres. C'est ce qui explique les chiffres de passage à l'échelle du projet.

Kubernetes en configuration standard tient officiellement jusqu'à 5 000 nœuds et 150 000 pods, avec 110 pods par nœud, selon les recommandations de la fondation pour les grands clusters. Au-delà, ce n'est plus supporté.

Le rapport de test de passage à l'échelle de KubeEdge annonce 100 000 nœuds edge et plus d'un million de pods sur un seul cluster, avec des latences conformes aux SLI/SLO définis par la communauté Kubernetes : démarrage de pod en 4 087 ms au 99e percentile pour un seuil communautaire à 5 000 ms, 1 688 ms à la médiane. Le test a été mené sur KubeEdge v1.11.0-alpha.0 avec Kubernetes v1.23.4.

Ce chiffre demande d'être lu correctement. Il a coûté un master à 128 CPU et 256 Go de RAM, cinq instances CloudCore à 12 CPU et 48 Go chacune, et 300 Go de SSD SAS pour etcd. Personne, en France, sur un parc de PME, n'a besoin de ça. Ce que le test démontre, c'est autre chose : l'architecture de KubeEdge lève le plafond structurel d'un Kubernetes classique. Pour quarante magasins, la question n'est plus de savoir si ça tient, elle est de savoir si la complexité ajoutée se justifie.

OpenYurt, issu d'Alibaba Cloud, est passé projet en incubation à la CNCF en juillet 2025. Son parti pris est plus conservateur, et c'est précisément ce qui le rend intéressant en exploitation : il ne remplace pas le kubelet.

À la place, il installe YurtHub, un démon systemd sur chaque nœud edge qui s'intercale comme proxy entre le kubelet, les pods et l'API server. En fonctionnement normal, il relaie. En cas de coupure, il bascule sur son cache local, stocké dans /etc/kubernetes/cache/, et sert les requêtes Get, List et Watch depuis ce cache. Les requêtes Create, Update et Delete retournent une erreur, ce qui est le comportement correct : on ne fait pas semblant d'accepter une écriture qu'on ne peut pas répliquer.

Conséquence directe : un nœud qui redémarre hors ligne retrouve, via YurtHub, exactement les ressources dont le kubelet a besoin pour relancer ses pods. Le kubelet ne sait même pas qu'il est coupé du monde.

Les valeurs par défaut à connaître : 250 requêtes en vol maximum, un ramasse-miettes du cache toutes les 120 minutes, un timeout de heartbeat à 2 secondes et une tolérance de 40 secondes sur la santé du kubelet. OpenYurt ajoute par-dessus la notion de NodePool, qui regroupe les nœuds d'un même site et confine le trafic de service à l'intérieur du pool. C'est cette brique qui évite qu'un service du magasin de Bordeaux se fasse router vers un pod du magasin de Lille.

L'avantage opérationnel d'OpenYurt est net : moins de code exotique sur les nœuds, un kubelet standard, une conversion possible d'un cluster existant. Le prix à payer, c'est qu'il ne gère pas les équipements industriels avec la profondeur du modèle Device Twin de KubeEdge.

La bande passante n'est pas le sujet, la stabilité l'est. Un lien 4G à 20 Mbps avec des micro-coupures toutes les dix minutes est pire pour un control plane distribué qu'un ADSL stable à 8 Mbps. Chaque reconnexion déclenche une resynchronisation. Un tunnel WireGuard bien réglé entre les sites et le cloud, avec un keepalive adapté, fait plus pour la stabilité que doubler le débit.

L'observabilité s'inverse. Sur un cluster classique, on scrute Prometheus depuis le cloud. Sur une architecture edge, un site déconnecté ne remonte plus rien, et l'absence de métrique devient elle-même le signal. Il faut instrumenter le canal cloud-edge en priorité, avant les applications, et accepter que l'historique métrique d'un site coupé comporte des trous.

La mise à jour est le vrai chantier. Pousser une nouvelle image sur quarante sites derrière des liens hétérogènes, sans registre local, c'est quarante téléchargements simultanés qui saturent les liens. Un registre miroir par site ou par région n'est pas une option, c'est un prérequis.

La sécurité change de périmètre. Un serveur dans un local technique de magasin n'a pas le niveau de contrôle d'accès physique d'un site opéré comme le DC Fullsave de Toulouse ou le site TDF de Bordeaux. Chiffrement des disques, secrets à durée de vie courte, et surtout : un nœud edge compromis ne doit jamais pouvoir écrire dans le control plane. Le RBAC par NodePool n'est pas cosmétique.

Voilà la partie que les articles cloud-native évitent soigneusement.

Si vos sites distants sont autonomes fonctionnellement, c'est-à-dire que le magasin de Lille n'a jamais besoin de parler au magasin de Bordeaux, alors un K3s indépendant par site piloté par FluxCD depuis un dépôt Git central répond au besoin, avec une fraction de la complexité. Chaque site a son propre control plane, sa propre autonomie totale, et le Git central joue le rôle de source de vérité asynchrone. Un site coupé pendant trois jours rattrape son retard tout seul au retour du lien. C'est l'approche décrite dans notre guide de plateforme edge avec K3s, Ceph et GitOps, et pour la majorité des cas français, elle gagne.

KubeEdge ou OpenYurt deviennent pertinents à trois conditions précises :

• Le nombre de sites dépasse la capacité d'une équipe à gérer autant de clusters distincts. En pratique, le basculement se situe autour de trente à cinquante sites, et il dépend surtout de la maturité de l'outillage GitOps existant.
• Les nœuds edge sont trop petits pour héberger un control plane. Un boîtier industriel à 2 cœurs et 4 Go de RAM ne fait pas tourner un serveur K3s plus les workloads. Un EdgeCore ou un kubelet plus YurtHub, oui.
• Il faut une vue unique et temps réel de l'ensemble du parc. Un kubectl get pods --all-namespaces qui couvre les quarante sites d'un coup, c'est un argument d'exploitation réel, pas un caprice.

Si aucune des trois n'est vraie, la stack ajoutée est une dette technique gratuite. Un cluster K3s par site avec GitOps se débogue avec les compétences Kubernetes existantes. Un CloudCore qui perd la synchronisation avec trente EdgeCore, non.

Le critère de décision n'est pas le nombre de sites, c'est le couple autonomie fonctionnelle et taille du matériel edge. Sites indépendants et matériel correct : K3s plus GitOps, point final. Sites qui doivent être vus et pilotés comme un ensemble cohérent, ou matériel contraint : KubeEdge si le pilotage d'équipements industriels fait partie du besoin, OpenYurt si on veut du Kubernetes le plus standard possible avec juste l'autonomie hors ligne en plus.

Et dans tous les cas, avant d'écrire la moindre ligne de manifeste : coupez le lien d'un site pendant deux heures en préproduction, redémarrez le serveur pendant la coupure, et vérifiez ce qui remonte. Test grandeur nature, ou rien. Une architecture edge dont le scénario de déconnexion n'a jamais été joué n'est pas une architecture, c'est une hypothèse.

Piloter un parc distribué depuis un point central, ça marche quand le lien entre les sites et le control plane est traité comme un composant de production à part entière : transit, tunnels, supervision du canal, procédures de reprise après coupure. C'est le travail qu'on fait sur les infrastructures multi-sites qu'on opère, avec un backbone AS41652 et des points de présence qui raccourcissent le chemin réseau entre les sites clients et le control plane. Si vous hésitez entre un cluster central étendu et des clusters autonomes par site, on peut cadrer l'architecture et opérer l'ensemble plutôt que de vous laisser découvrir les pièges en production.

• Test Report on KubeEdge's Support for 100,000 Edge Nodes : rapport officiel du projet avec les chiffres de latence, la configuration du control plane et les versions testées.
• Cloud Native Computing Foundation Announces KubeEdge Graduation : annonce officielle CNCF du 15 octobre 2024, premier projet edge gradué.
• YurtHub, documentation OpenYurt : référence officielle sur le proxy local, le cache et les paramètres par défaut.
• OpenYurt Becomes a CNCF Incubating Project : passage en incubation en juillet 2025 et périmètre du projet.
• Considerations for large clusters, Kubernetes : limites officielles de 5 000 nœuds et 150 000 pods pour un cluster standard.
• Nodes, documentation Kubernetes : comportement du node lifecycle controller, période de grâce et taints appliquées à un nœud injoignable.