Webernetes: 使用 LLMs 將 Kubernetes 移植到瀏覽器

Webernetes: 使用 LLMs 將 Kubernetes 移植到瀏覽器

Webernetes 為教育用途提供基於瀏覽器的 Kubernetes 集群

Webernetes 是 Kubernetes 到 TypeScript 的部分移植版本,允許使用者完全在網頁瀏覽器中執行 Kubernetes 集群。該專案開發歷時兩個月,包含約 100,000 行 TypeScript 程式碼,分布於 629 個檔案中。它專門為建立互動式 Kubernetes 教育內容而設計,而非作為生產就緒的發行版本。

架構實作與限制

Webernetes 並非原始 Go 程式碼庫的 WebAssembly 編譯版本。由於 Go-Wasm 二進位檔的大小以及 Kubernetes 所需的瀏覽器層級系統 API 缺失,作者選擇進行手動(由 LLM 輔助)的 TypeScript 移植。

已移植的核心組件

  • Kubelet: 足以執行與探測 pods 的部分移植版本。
  • Controllers: 實作了 pod scheduler、namespace controller、kube-proxy 與 deployment controller。
  • Networking: 一個基於瀏覽器的 Container Network Interface (CNI),用於模擬 pod 之間的網路通訊。
  • Runtime: 一個基於瀏覽器的容器執行環境,透過 Container Runtime Interface (CRI) 與 kubelet 通訊。
  • API: 用於套用 manifests 並監控資源的專用 API。

映像檔處理

為了保持輕量化的佔用空間(約 140KiB gzipped),Webernetes 並不從 Docker Hub 等註冊表拉取映像檔。相反地,它使用一個基於瀏覽器的註冊表,其中映像檔是透過 TypeScript API 定義的。例如,開發者可以擴充 w8s.BaseImage 並實作 exec 方法來定義容器的行為。

LLM 驅動開發與品質保證

幾乎所有的 Webernetes 程式碼都是由大型語言模型 (LLMs) 編寫的。為了防止專案變成「slop」(低品質、未經驗證的 AI 程式碼),作者實施了兩層驗證流程。

手動程式碼審查

每一行 LLM 生成的程式碼都經過了審查。這是必要的,因為 LLMs 經常犯移植錯誤,包括:

  • 捷徑: 將複雜的 Kubernetes 快取實作(如 LRU、FIFO 等)替換為簡單的 JavaScript Map 物件,導致行為不正確。
  • 過度熱心: 虛構了原始 Go 程式碼中不存在的輔助函數,這增加了並列審查的難度。
  • 遺漏: 在移植過程中任意跳過 Go table tests 的部分章節。

對 k3s 的整合測試

為了確保 TypeScript 移植版本與原始 Go 實作之間的行為一致性,作者編寫了 204 個整合測試。這些測試使用官方的 kubernetes-client/javascript 函式庫,在 Webernetes(於 headless browser 中)與真實的 k3s 集群(於 Node.js 中)上執行相同的程式碼。這確保了基於瀏覽器的執行環境與網路行為與真實的 Kubernetes 集群完全相同。

專案指標與 Token 消耗量

專案的成長是透過 Git 指標與 Codex 及 Claude 會話中的 LLM token 使用量來追蹤的。

程式碼庫成長

在 2026 年 4 月 20 日至 6 月 15 日期間,程式碼庫從 0 成長到總計約 126,642 行(包含註解與 demo app),其中最顯著的成長發生在六月。

Token 與成本分析

LLM 的使用特徵是極高的快取輸入 token 消耗量。在開發的最後一週,作者利用了一組 agent 與 sub-agents 來移植支援 Deployment 的複雜依賴項,導致該週的 API 等效成本飆升至 $1,811.64。

目前的限制與路線圖

Webernetes 目前缺乏對多項生產級 Kubernetes 功能的支持,包括:

  • ConfigMaps
  • Secrets
  • Pod resources
  • Persistent volumes

未來的擴展將由建立特定教育內容的需求所驅動,作者也邀請社群貢獻以實作缺失的功能。

Sources