Kubernetes dans le navigateur : webernetes, le portage TypeScript signé ngrok

Kubernetes dans le navigateur, c’est le genre de titre qui fait lever un sourcil. Et pourtant, c’est exactement ce que Sam Rose, ingénieur chez ngrok, a réalisé en deux mois avec un projet baptisé webernetes. Voici ce que ça implique concrètement, et pourquoi ça mérite qu’on s’y attarde.

Kubernetes dans le navigateur : de quoi parle-t-on vraiment ?

Webernetes n’est pas une simulation ni une maquette. C’est un portage partiel mais fonctionnel des composants clés de Kubernetes, réécrit en TypeScript pour tourner entièrement côté client.

Le résultat : un cluster complet qui s’exécute dans votre onglet. Les cycles de vie des pods, le DNS interne, l’allocation d’IP en CIDR, le garbage collection des conteneurs, le suivi des Deployments et des ReplicaSets. Tout ça, dans le navigateur, sans serveur distant.

Le projet représente près de 100 000 lignes de TypeScript (hors commentaires et application de démo), réparties sur 552 commits dans 629 fichiers.

Ce que webernetes porte, et ce qu’il ne porte pas

La première question que tout le monde pose : est-ce une compilation WebAssembly de Kubernetes ? La réponse est non, et l’argument est solide.

Un simple programme Go « hello world » compilé en WASM pèse environ 540 Ko compressé. Webernetes, lui, ne pèse que 140 Ko compressé. Compiler l’intégralité de Kubernetes en WASM aurait signifié transférer plusieurs mégaoctets, sans parler des appels système incompatibles avec l’environnement navigateur.

À la place, webernetes implémente :

Un portage partiel du binaire kubelet, suffisant pour exécuter et sonder des pods.
Plusieurs controllers Kubernetes : scheduler, namespace controller, kube-proxy, deployment controller.
Un container network interface (CNI) simulé pour la communication inter-pods.
Un container runtime basé navigateur, communiquant via l’interface CRI.
Une API compatible avec le client officiel kubernetes-client/javascript.

En revanche, webernetes ne supporte pas encore les ConfigMaps, les Secrets, les ressources de pods, les volumes persistants ni d’autres fonctionnalités avancées. L’auteur est clair là-dessus : ce sont des manques assumés, à combler au fil des besoins.

Le registre d’images : une contrainte maîtrisée

Webernetes ne tire pas d’images depuis Docker Hub ou un registre distant. À la place, il embarque son propre registre navigateur. Les images se définissent directement en TypeScript, en héritant d’une classe de base.

Cette approche est cohérente avec l’objectif déclaré : créer du contenu pédagogique interactif sur Kubernetes. Pas un remplacement de production, mais un outil pour illustrer des concepts à un public technique.

LLMs et revue de code : la méthode de travail

La quasi-totalité du code webernetes a été générée par des LLMs (Codex et Claude, selon les graphiques publiés). Sam Rose est transparent là-dessus, et il anticipe le scepticisme.

Sa réponse tient en deux pratiques :

Revue ligne à ligne de chaque fichier généré, en comparaison directe avec le code Go upstream de Kubernetes.
Suite de tests comportementaux : les mêmes tests tournent contre un vrai cluster k3s et contre webernetes, en permutant simplement l’environnement d’exécution.

Au moment de la publication, le projet comptait 204 tests d’intégration et 1 855 tests unitaires, dont la majorité sont des portages directs des tests Go de Kubernetes.

Les LLMs ont montré des faiblesses récurrentes : omission silencieuse de cas de test, remplacement de structures de cache spécialisées par de simples Map, création de fonctions utilitaires qui n’existaient pas dans l’original. La revue manuelle a été le filet de sécurité principal.

Le coût total en tokens LLM sur neuf semaines atteint des sommes significatives, culminant à plus de 1 800 dollars la dernière semaine seule, lors d’un sprint final pour implémenter le support des Deployments dans l’application de démo. Sam Rose note lui-même que l’efficacité token de cette dernière semaine était médiocre.

Cas d’usage : éducation et contenu interactif

L’objectif premier est explicitement pédagogique. Webernetes permet à des créateurs de contenu technique de construire des démos interactives de concepts Kubernetes directement dans une page web, sans imposer à l’utilisateur de monter un cluster.

C’est une niche claire, et elle est cohérente avec le positionnement de ngrok dans l’écosystème réseau et tunnel. Le projet est disponible en open source sur le dépôt GitHub ngrok/webernetes.

Ce qu’il faut retenir

Webernetes est un portage TypeScript partiel mais fonctionnel de Kubernetes, qui tourne entièrement dans le navigateur sans WebAssembly.
Il reproduit les primitives essentielles : pods, DNS cluster, réseau simulé, Deployments, ReplicaSets, garbage collection.
L’approche LLM avec revue manuelle et double suite de tests (k3s vs navigateur) est la garantie de qualité centrale du projet.
L’objectif déclaré est pédagogique : produire du contenu interactif sur Kubernetes, pas un substitut de production.
Le code source est disponible sur GitHub, et le mainteneur invite activement les contributions.

Si vous travaillez sur de la formation Kubernetes ou des démos cloud-native, webernetes mérite clairement un essai. Des questions sur l’intégration dans vos workflows DevOps ou sur les outils de formation ? Échangeons en commentaire ou suivez le blog pour les prochaines analyses.