Webernetes: 使用 LLM 将 Kubernetes 移植到浏览器

Webernetes 为教育用途实现基于浏览器的 Kubernetes 集群

Webernetes 是 Kubernetes 到 TypeScript 的部分移植版本，允许用户完全在 Web 浏览器中运行 Kubernetes 集群。该项目历时两个月开发，包含分布在 629 个文件中的约 100,000 行 TypeScript 代码。它专门为创建交互式 Kubernetes 教育内容而设计，而非作为生产就绪的发行版。

架构实现与约束

Webernetes 并非原始 Go 代码库的 WebAssembly 编译版本。由于 Go-Wasm 二进制文件体积庞大，且缺乏 Kubernetes 所需的浏览器级系统 API，作者选择了通过手动（LLM 辅助）方式将其移植到 TypeScript。

已移植的核心组件

• Kubelet: 足以运行和探测 pod 的部分移植版本。
• Controllers: 实现 pod 调度器、namespace 控制器、kube-proxy 和 deployment 控制器。
• Networking: 一个基于浏览器的容器网络接口 (CNI)，用于模拟 pod 之间的通信网络。
• Runtime: 一个基于浏览器的容器运行时，通过容器运行时接口 (CRI) 与 kubelet 通信。
• API: 用于应用 manifest 并监听资源的专用 API。

镜像处理

为了保持较小的占用空间（压缩后约 140KiB），Webernetes 不从 Docker Hub 等注册表拉取镜像。相反，它使用一个基于浏览器的注册表，其中镜像通过 TypeScript API 定义。例如，开发者可以扩展 w8s.BaseImage 并实现 exec 方法来定义容器的行为。

LLM 驱动开发与质量保证

Webernetes 的几乎所有代码都是由大语言模型 (LLM) 编写的。为了防止项目变成“slop”（低质量、未经验证的 AI 代码），作者实施了两个层级的验证过程。

手动代码审查

每一行 LLM 生成的代码都经过了审查。这是必要的，因为 LLM 经常犯移植错误，包括：

• 捷径: 用简单的 JavaScript Map 对象替换复杂的 Kubernetes 缓存实现（LRU、FIFO 等），导致行为不正确。
• 过度热心: 虚构了原始 Go 代码中不存在的辅助函数，这使得并排审查变得复杂。
• 遗漏: 在移植过程中随意跳过 Go 表格测试 (table tests) 的部分章节。

基于 k3s 的集成测试

为了确保 TypeScript 移植版本与原始 Go 实现之间的行为一致性，作者编写了 204 个集成测试。这些测试使用官方的 kubernetes-client/javascript 库，在 Webernetes（在无头浏览器中）和真实的 k3s 集群（在 Node.js 中）上运行相同的代码。这确保了基于浏览器的运行时和网络行为与真实的 Kubernetes 集群完全一致。

项目指标与 Token 消耗

项目的增长通过 Git 指标以及 Codex 和 Claude 会话中的 LLM Token 使用情况进行追踪。

代码库增长

在 2026 年 4 月 20 日至 6 月 n 日之间，代码库从 0 增长到总计约 126,642 行（包括注释和演示应用），其中最显著的增长发生在 6 月。

Token 与成本分析

LLM 的使用特点是极高的缓存输入 Token 消耗。在开发的最后一周，作者利用了一组代理 (agents) 和子代理 (sub-agents) 来移植支持 Deployment 的复杂依赖项，导致仅那一周的 API 等效成本就飙升至 $1,811.64。

当前局限性与路线图

Webernetes 目前缺乏对若干生产级 Kubernetes 特性的支持，包括：

• ConfigMaps
• Secrets
• Pod 资源
• 持久化卷 (Persistent volumes)

未来的扩展将由创建特定教育内容的需求驱动，作者也邀请社区贡献者参与实现缺失的功能。