Kubernetes in den Browser portiert

• webernetes ist ein Projekt, das Teile von Kubernetes nach TypeScript übertragen hat, um einen Cluster im Browser auszuführen. Es entstand in 2 Monaten mit 552 Commits, 629 Dateien und fast 100.000 Zeilen Code.
• Es kompiliert Kubernetes nicht unverändert nach WebAssembly, sondern implementiert Teile des kubelet, mehrere Controller, ein browserbasiertes CNI und Container-Runtime sowie APIs zur Cluster-Steuerung neu.
• Statt Images aus echten Image-Registries zu beziehen, werden Images per TypeScript-API definiert. Ziel ist keine Produktions-Distribution, sondern die Erstellung interaktiver Kubernetes-Inhalte.
• Der größte Teil des Codes wurde von einem LLM geschrieben, aber jede Zeile wurde von Menschen reviewed und mit 204 Integrationstests, die dieselben Tests wie gegen k3s ausführen, sowie 1.855 aus der Kubernetes-Go-Codebasis portierten Unit-Tests validiert.
• Beim Portieren kürzte das LLM wiederholt Code ab, erzeugte willkürliche Helper und ließ Tests aus. Um von schneller Codegenerierung zu profitieren, müssen Review und Tests gemeinsam eingesetzt werden.

---

Was webernetes im Browser ausführt

• webernetes ist ein Projekt, das Kubernetes teilweise nach TypeScript portiert, damit ein Cluster im Browser laufen kann.
• Der Demo-Cluster läuft vollständig im Browser und erledigt einen großen Teil dessen, was ein echter Kubernetes-Cluster tut.

  • Pod-Lebenszyklus

    • Cluster-DNS und Networking
    • Container-Garbage-Collection
    • IP-Zuweisung
    • Nachverfolgung von Deployment und ReplicaSet
    • Die blauen Punkte in der Demo zeigen, wie Pods einander Requests senden.

Teilportierung statt WebAssembly-Kompilierung

• Kubernetes wurde nicht nach WebAssembly kompiliert.
• Selbst ein einfaches Go-Programm hello, world!, das nach WebAssembly kompiliert wird, ist gzip-komprimiert etwa 540 KiB groß; webernetes ist gzip-komprimiert etwa 140 KiB groß.
• Würde man ganz Kubernetes nach WebAssembly kompilieren, wären vermutlich mehrere Megabyte Übertragung nötig, und wegen systemnaher API-Aufrufe, die im Browser nicht verfügbar sind, käme es bereits zur Compile-Zeit zu Fehlern.
• webernetes besteht aus folgenden Komponenten:
  • einer Teilportierung des Kubernetes-kubelet-Binaries, soweit sie für Pod-Ausführung und Probes nötig ist
  • Portierungen mehrerer Kubernetes-Controller, darunter Pod-Scheduler, namespace controller, kube-proxy und deployment controller
  • einem browserbasierten Container Network Interface (CNI) für die Kommunikation zwischen Pods
  • einer browserbasierten Container-Runtime, mit der kubelet Container über das Container Runtime Interface (CRI) ausführt
  • einer webernetes-Cluster-API für Aufgaben wie das Anwenden von Manifests und das Watchen von Ressourcen

Image-Definitionen und API-Nutzung

• Um die Größe klein zu halten, lädt webernetes keine echten Images aus Registries wie Docker Hub.
• Stattdessen besitzt es eine browserbasierte Registry, und Images werden über eine TypeScript-API definiert.
• Das Beispiel-Image HelloWorld erbt von w8s.BaseImage und gibt in exec bei HTTP-Requests auf Port 8080 "Hello, world!" zurück.
• Der Ablauf zur Nutzung des Clusters sieht so aus:
  • Mit new w8s.Cluster() wird ein Cluster erstellt.
  • Mit cluster.registerImage(HelloWorld) wird das Image registriert.
  • Mit cluster.apply() wird ein apps/v1-Deployment-Manifest angewendet.
  • Mit cluster.api.corev1.listNamespacedPod() wird die Pod-Liste abgefragt.
  • Mit cluster.informer("pods", ...) werden Pod-Änderungen beobachtet.
  • Mit cluster.on("request") und cluster.on("response") werden Request- und Response-Events zwischen Pods beobachtet.
  • Mit cluster.fetch() lassen sich HTTP-Requests über das Cluster-Netzwerk an Pod-IPs senden.
• Weitere Beispiele finden sich in den webernetes repository examples.

Zweck und aktuelle Einschränkungen

• Ziel von webernetes ist die Erstellung interaktiver Kubernetes-Inhalte.
• Es ist keine produktionsreife Kubernetes-Distribution und muss auch keine echten Images ausführen.
• Es reicht aus, wenn Content-Ersteller bestimmte Workloads konfigurieren können, um die Kubernetes-Konzepte zu zeigen, die sie erklären möchten.
• Derzeit nicht unterstützte Funktionen umfassen unter anderem:
  • ConfigMaps
  • Secrets
  • Pod resources
  • persistent volumes
  • verschiedene Kubernetes-Funktionen, die bisher noch nicht benötigt wurden
• Künftig sollen weitere Kubernetes-Funktionen implementiert werden, wenn sie bei der Content-Erstellung gebraucht werden.

Warum es zwar mit LLM gebaut wurde, aber nicht unbeaufsichtigt

• Fast der gesamte Code von webernetes wurde von einem LLM geschrieben.
• Für die Zuverlässigkeit des Projekts wurden zwei Dinge parallel gemacht:
  • Jede Codezeile wurde persönlich reviewed.
  • Es wurden Hunderte Tests erstellt, die prüfen, ob webernetes sich wie ein echter Cluster verhält.
• Durch manuelles Review entstand die Zuversicht, dass der größte Teil des Codes zeilenweise der Kubernetes-Go-Codebasis entspricht.
• Die Tests prüfen, ob diese lexikalische Ähnlichkeit tatsächlich zu gleichem Verhalten führt.
• Fehler, die nach dem Review verbleiben, liegen in der Verantwortung des Projekt Autors; wer ein Problem findet, wird gebeten, ein Issue zu öffnen.

Warum portierter Code Review brauchte

• Bei Fällen, in denen ein LLM einen C-Compiler schrieb oder Bun von Zig nach Rust portierte, gab es Möglichkeiten, die Korrektheit automatisch zu verifizieren.
  • Anthropic hatte bestehende C-Compiler zum Vergleichen.
  • Bun verfügte über eine große Testsuite, der man genug vertraute, um ohne manuelles Review mehr als eine Million Zeilen neuen Rust-Code zu mergen.
• webernetes hatte diese Grundlage nicht.
  • Wenn eine Testsuite nötig war, musste sie selbst geschrieben werden.
  • Um mit echtem Kubernetes zu vergleichen, musste auch die Vergleichsmethode selbst geschaffen werden.
• Der Großteil des webernetes-Codes wurde aus der Kubernetes-Go-Codebasis portiert, und das LLM wurde eingesetzt, weil es schneller schien als das Abtippen per Hand.
• Beim Portieren machte das LLM wiederholt Fehler:
  • Abkürzen: Es implementierte Kubernetes-Komponenten wie LRU cache, expiring cache, FIFO cache und transforming cache nicht korrekt, sondern ersetzte sie durch Map, was falsches Verhalten hätte erzeugen können.
  • Übermäßiges Aufräumen: Es erzeugte Helper-Funktionen, die es im ursprünglichen Go-Code nicht gab, was Reviews erschwerte oder subtile Unterschiede erzeugen konnte.
  • Auslassen: Beim Portieren von Go-Table-Tests ließ es häufig Testfälle eigenmächtig weg.
• Um den Ergebnissen einer LLM-Portierung zu vertrauen, muss man die Ausgabe reviewen; der Projekt Autor geht davon aus, dass er nicht weiß, welche Abkürzungen sich das Modell nimmt.

Tests im Vergleich mit einem echten Cluster

• Selbst wenn der Code nebeneinander sehr ähnlich zum Original aussieht, können sich Go- und JavaScript-Runtime unterschiedlich verhalten.
• webernetes brauchte außerdem JavaScript-Versionen von channels, mutexes, Gos select-Anweisung und weiteren Go-typischen Verhaltensweisen.
• Derselbe Testcode wird sowohl gegen webernetes als auch gegen einen k3s-Cluster ausgeführt, um das Verhalten zu vergleichen.
• Als Ziel für API-Kompatibilität wurde der offizielle JavaScript-Kubernetes-Client kubernetes-client/javascript gewählt, der TypeScript-Typen hat.
• Das Test-Harness wechselt die Ausführungsumgebung über kubernetes.describe(..).
  • pnpm test:node testet in einer Node-Umgebung gegen k3s.
  • pnpm test:browser testet in einem headless browser gegen webernetes.
• Die Integrationstests prüfen nicht nur den portierten Code, sondern auch, ob die custom browserbasierte container runtime und das cluster network sich passend zu einem echten Cluster verhalten.
• Wenn ein Bug gefunden wird, wird zuerst ein Test erstellt, der in k3s besteht und in webernetes fehlschlägt; über diese Feedback-Schleife wird dann mit Hilfe des LLM die Ursache verstanden und behoben.
• Zum Zeitpunkt der Erstellung hat webernetes 204 Integrationstests und 1.855 Unit-Tests.

Warum Review und Tests zusammen eingesetzt werden müssen

• Auch von einem LLM erstellter Code braucht, genau wie ein menschlicher PR, gute Tests und guten Code.
• Der Unterschied im Jahr 2026 besteht darin, dass man von menschlichen Kollegen bis zu einem gewissen Grad gute Arbeit erwartet, während es bei einem LLM sicherer ist, anzunehmen, dass es keine gute Arbeit leisten wird.
• Wenn man nicht einmal den Testcode reviewed, ist schwer zu wissen, gegen welches Erfolgskriterium das LLM eigentlich arbeitet.
• Selbst wenn man allen Code reviewed, ist es ohne Tests schwer zu glauben, dass Menschen alle Möglichkeiten durchdenken können.
• LLMs werden nicht müde und tippen schnell; nützlich ist daher, sie Edge Cases vorschlagen zu lassen, an die Menschen nicht gedacht haben, und sie bei Plausibilität Tests dafür schreiben zu lassen.
• Die Kombination aus menschlichem Geschmack und Verständnis mit der schnellen Schreibfähigkeit von LLMs fühlt sich für den Autor wie die größte Veränderung seit seinem Karrierestart 2012 an.

Projektumfang und Token-Nutzung

• Der erste Commit landete am 21. April im heutigen webernetes repository.
• Ein Teil der frühen Arbeit fand in einem Branch des Repositorys hinter dieser Blog-Seite statt, daher bildet die Grafik nicht die gesamte Realität vollständig ab.
• Die Codezeilen-Grafik zeigt für die Woche vom 15. Juni 126.642 Zeilen.
• Die eingangs erwähnten rund 100.000 Zeilen schließen Nicht-TypeScript-Code, Kommentare und die demo app aus.
• Die wöchentliche Gesamtzahl der Zeilen stieg wie folgt:
  • Woche vom 20. April: 11.640 Zeilen
  • Woche vom 27. April: 20.660 Zeilen
  • Woche vom 4. Mai: 25.048 Zeilen
  • Woche vom 11. Mai: 30.417 Zeilen
  • Woche vom 18. Mai: 42.301 Zeilen
  • Woche vom 25. Mai: 54.155 Zeilen
  • Woche vom 1. Juni: 79.704 Zeilen
  • Woche vom 8. Juni: 98.532 Zeilen
  • Woche vom 15. Juni: 126.642 Zeilen
• Bei der Token-Nutzung der Codex- und Claude-Sessions waren cached input tokens deutlich größer als andere Token-Kategorien, besonders ausgeprägt, je häufiger lange Kontextfenster gefüllt wurden.
• In der Woche vom 15. Juni wurden 104.155.857 uncached input tokens, 2.196.467.968 cached input tokens und 6.420.826 output tokens genutzt.

Der Sprung in der letzten Woche und die Kosten

• In der letzten Woche wurde versucht, Deployments-Support in die demo app einzubauen, was deutlich größer wurde als erwartet.
• Der erste Portierungsversuch des LLM ließ viele benötigte Funktionen der notwendigen Komponenten aus.
• Anschließend wurden mehrere Agents eingesetzt, um die Dependency Chain zu identifizieren; jede Komponente wurde von weiteren Sub-Agents portiert, und wiederum andere Sub-Agents übernahmen Reviews.
• Diese Vorgehensweise erledigte die Arbeit schneller als manuelle Arbeit, war aber bei den Tokens sehr ineffizient, und am Ende war weiterhin manuelles Review nötig.
• Die in API-Nutzung umgerechneten LLM-Token-Kosten stiegen wöchentlich; in der Woche vom 15. Juni lagen sie bei 1.811,64 $.
• Über das gesamte Projekt hinweg blieb die Zeit des Autors bis zuletzt der teuerste Posten.

Abschließende Materialien und Mitmachen

• Es gibt auch eine Videoserie, die den Entstehungsprozess dokumentiert:
  • Part 1
  • Part 2
  • Part 3 erscheint demnächst.
• In den Videos sieht man auch den anfänglichen falschen Optimismus und die Arbeitsweise, bei der per Sprachsteuerung und Eye-Tracking größtenteils hands-free gearbeitet wird.
• Es wird darum gebeten, das Projekt auszuprobieren und Issues zu öffnen oder sich unter [e-mail] zu melden, wenn man etwas gebaut hat oder feststeckt.

[GN⁺]

Meinungen auf Hacker News

• Aus der Perspektive von jemandem, der gern lehrt und baut, kann so etwas ziemlich nützlich sein
  Ich habe zum Beispiel das hier gebaut: https://kubernetes-made-simple.vercel.app/ – das könnte ich jetzt dort ergänzen
  • Wenn man auf dem iPhone die erwartete Pod-Anzahl ändert, dreht der Reconciliation-Simulator merkwürdig durch
    Trotzdem ist die Seite cool
  • Ich habe alles gelesen, und der Inhalt ist gut
    Es wäre schön, Gateway weiter auszubauen und, wenn möglich, auch CRD zu erwähnen
  • Coole Seite
    Wenn du eine Sache nennen müsstest, die die meisten Leute bei k8s falsch verstehen und die das Lernen unnötig schwer macht: Was wäre das?
• Cool. Aus meiner früheren Erfahrung mit der Erstellung von Kubernetes-Schulungsinhalten kann ich den Reiz, so etwas zu bauen, definitiv nachvollziehen
  Soweit ich mich erinnere, haben wir anfangs Katacoda genutzt und später eine ähnliche andere Plattform; sie war sehr nützlich, weil für jeden Nutzer spontan eine frisch konfigurierte Instanz hochgefahren wurde
  Im Moment wirkt es allerdings besser für das Vermitteln von Konzepten oder Architektur geeignet. Der eigentliche Spaß beginnt, wenn man anfängt, kubectl routiniert zu beherrschen
  • In meinem früheren Job wäre das wirklich gut gewesen für Diagramme, die erklären, wie die Control Plane funktioniert, für Performance-Einbrüche und Fehlermodi sowie für Vergleiche verschiedener Architekturen oder Ansätze beim Deployment auf k8s
  • Leider ist Katacoda hinter einer Paywall verschwunden. Ich verstehe völlig, warum sie das gemacht haben. Solche Dinge kosten Geld
    Ähnliche andere Plattformen scheinen ebenfalls verschwunden zu sein, weil niemand mehr die Kosten tragen wollte; schade
    Ich hoffe, dass das hier eine Alternative wird. Es besteht zwar das Risiko, dass es mit der Realität auseinanderläuft und veraltet, aber die Grundlagen dürften fast immer gültig bleiben
• Zunächst einmal: wirklich cool
  Das fühlt sich nach der richtigen Art an, auf LLM-gestütztes Engineering zu blicken. KI kann erstaunlich viel Code erzeugen, aber der eigentliche Wert liegt in Review-Disziplin und den Tests drumherum
  Der Ansatz, Kubernetes im Browser zu behandeln, ist ebenfalls cool, aber interessanter ist der Workflow – insbesondere der Teil, bei dem Verhalten gegenüber k8s getestet wird, statt sich darauf zu verlassen, dass etwas „plausibel aussieht“. Ich frage mich, wie viele Teams bereits ein solches Maß an Verifikation für von KI geschriebenen Code anwenden, und ob das vielleicht die Richtung ist, in die in den nächsten Jahren alle gehen werden
  • Das ist ein Sonderfall, in dem es buchstäblich eine Spezifikation gibt, gegen die man implementieren kann
    Leider bietet nicht jede Coding-Aufgabe eine solche Möglichkeit
• Nate Abele hat letztes Jahr auf der Carolina Code Conference zu diesem Thema gesprochen
  https://youtu.be/t7L2iROVaRg?is=xoV4aiCXcYMVvVDL
• Wirklich ziemlich cool
  Zusätzliche Komplexität oder Performance-Verluste bräuchten zwar eine gewisse Rechtfertigung, aber bei manchen Use Cases scheint sich das durchaus auszahlen zu können
• Bevor die Witze über die Komplexität von kube losgehen: Man könnte interessant argumentieren, dass etwas wie kube genau das Maß an Komplexität hat, das nötig ist, um die Aufgaben zu erfüllen, für die kube gedacht ist
  Ähnlich wie Fred Brooks’ Unterscheidung zwischen essenzieller Komplexität und akzidenteller Komplexität
  Wenn man kube allerdings für Dinge nutzt, die sich einfacher erledigen ließen, wird kube schnell zu akzidenteller Komplexität
• 1. Es sieht nicht so aus, als würden tatsächlich Container im Browser ausgeführt. Offenbar braucht jeder Service einen Custom Connector, und noch wichtiger …
  2. …braucht man nicht auch einen Renderer? Sonst weiß ich nicht, was „in den Browser portiert“ bedeuten soll
     Als Analogie: Wenn jemand DOOM in den Browser portiert hat, heißt das, dass man es nun im Browser spielen kann. Aber die Datenbanken, die man in einem Tab sieht, kann man doch nicht wirklich im Browser ausführen, oder?
     Wenn man ruby2d startet, kann man nicht plötzlich sagen, es gebe Client-seitige Ruby-Unterstützung. Damit es tatsächlich in einem Browser-Tab läuft, braucht man jede Menge Custom-Arbeit
     Dagegen lassen sich normale Backend-Container-Services wirklich hierhin und dorthin verschieben und überall ausführen
     Daher verstehe ich den Punkt nicht so recht; korrigiert mich, falls ich falschliege. Es scheint auch nicht zu der eigentlichen Behauptung zu passen
  • Diese Punkte stehen zwar nicht im Titel, werden aber im Text behandelt
    Es werden keine echten Container Images ausgeführt. „Simuliertes Kubernetes“ wäre vielleicht die bessere Bezeichnung
    Portiert wurde die Control Plane. Scheduler, kube-proxy, Deployment Controller usw. wurden aus dem echten Go-Quellcode übertragen, und mit derselben Client-API wird die Verhaltensübereinstimmung mit k3s getestet. Das „Rendering“ ist eine Demo-App, die Anfragen zwischen Pods als sich bewegende Punkte visualisiert
  • „Webernetes ist dazu gedacht, interaktive Kubernetes-Inhalte zu erstellen“
• Die Demo ist cool. Wofür würde man das verwenden?
• Dazu passend habe ich vor ein paar Tagen aus Spaß per Vibe Coding das hier gebaut: https://imjasonh.github.io/kubescheduler-the-game/
  Hat Spaß gemacht
  • Dieses Spiel ist genau mein Ding