ハクソク

世界を動かす技術を、日本語で。

Kubernetesをブラウザに移植しました

2026年7月1日原文(ngrok.com)

概要

  • webernetes はKubernetesをTypeScriptで部分的に移植し、ブラウザでクラスタを実行可能にした新プロジェクト。
  • 約10万行のコードを2ヶ月で生成し、実際のKubernetesに近い動作をブラウザ上で実現。
  • LLM（大規模言語モデル）を活用しつつも、全コードのレビューと膨大なテストで品質を担保。
  • 本番運用目的ではなく、インタラクティブなKubernetes教材やデモ作成を主目的とする設計。
  • プロジェクトの成長過程・コスト・LLM活用の課題と工夫についても詳細に解説。

ブラウザで動くKubernetesクローン「webernetes」の開発記

  • webernetes はKubernetesのTypeScript移植プロジェクト
    • ブラウザ上でKubernetesクラスタをシミュレート
    • 約10万行、629ファイル、552コミット、2ヶ月で開発
  • 主な機能
    • Podライフサイクル管理
    • クラスタDNSとネットワーキング
    • コンテナガベージコレクション
    • IP割り当て、Deployment/ReplicaSetのトラッキングなど
  • デモ
    • ブラウザのみでクラスタが起動
    • 青い点がPod間通信を示すインタラクティブな可視化

WebAssemblyではなくTypeScript移植

  • KubernetesをWebAssemblyにコンパイルは困難
    • Go製KubernetesはシステムAPI依存が多く、ブラウザで動作不可
    • WebAssembly化するとサイズも巨大化（Hello Worldで540KiB、webernetesは140KiB）
  • webernetes は以下をTypeScriptで再実装
    • kubeletバイナリの一部（Pod実行・プローブ）
    • 複数のKubernetesコントローラー（スケジューラー、namespace controller、kube-proxy等）
    • ブラウザ用CNI（Container Network Interface）
    • ブラウザ用コンテナランタイム（CRI経由でkubeletと通信）
    • 独自APIでマニフェスト適用・リソース監視

イメージ管理とデプロイ例

  • Docker Hub等の実イメージ利用は非対応

    • 独自のブラウザレジストリとTypeScript APIでイメージを定義

  • イメージ例（TypeScriptクラスで定義）

    • HelloWorld クラスを継承し、HTTPリスナーを8080ポートで起動
    • ctx.waitUntilKilled()でPod終了まで待機

  • クラスタへのデプロイ手順

    • クラスタ生成
    • イメージ登録
    • Deploymentリソースをapply

APIインタラクション例

  • Pod一覧取得
  • Podの変更監視（Informer利用）
  • Pod間のリクエスト・レスポンスイベント監視
  • クラスタネットワーク経由でPodにリクエスト送信

webernetesの用途と今後

  • 主な用途
    • インタラクティブなKubernetes教材・デモ作成
    • 本番運用は非想定（ConfigMap、Secrets、永続ボリューム等は未実装）
  • 今後の拡張
    • 必要に応じて機能追加予定
    • コントリビューター募集（s.rose@ngrok.com）

LLM活用と品質担保

  • コードの大部分はLLMが生成
  • 品質担保のための工夫
    • 全コードを手動レビュー
    • Kubernetes実装と振る舞い一致を確認する数百のテスト作成
  • LLMによる移植の課題
    • ショートカット実装（Mapで全キャッシュを代用等）
    • 不要なヘルパー関数の自動生成
    • テストケースやコードの抜け落ち

テスト戦略

  • k3sとwebernetesで同一APIを用いた統合テストを実施
    • kubernetes-client/javascript APIを活用
    • Node環境とブラウザ環境で同一テストを実行
  • テスト例
    • Pod作成・削除の一連動作を検証
    • バグ発見時はまずk3sでパスするテストを追加し、webernetesで修正
  • テスト数
    • 統合テスト：204本
    • ユニットテスト：1,855本（多くはKubernetes Goコードの移植）

コードレビューとテストの意義

  • LLM生成コードにも人間と同等以上のレビュー・テストが必要
  • テストとコードレビューの両方が不可欠
  • LLMは疲れず高速にコードを生成できるため、人間の弱点を補完
  • LLMからエッジケース提案を受けてテストを拡充する活用法も有効

開発の進捗とコスト

  • 週ごとのコード行数・トークン消費・APIコストをグラフで可視化
    • 開発後期には大量のトークンを消費（例：1週間で$1,800超）
  • 大規模な依存関係や機能追加時はLLMエージェントを多用
    • トークン効率は悪化するが、開発速度は向上

まとめ・今後

  • 開発過程やLLM活用、音声・視線入力によるハンズフリー開発も紹介

  • webernetesは教材・デモ用途に最適

  • 利用・コントリビュート歓迎（GitHubリポジトリ・デモサイトあり）

    • https://github.com/ngrok/webernetes
    • https://webernetes-demo.ngrok.app/
    • 問い合わせ先：s.rose@ngrok.com

Hackerたちの意見

これ、バズる前に早めに投資しとくべきだね。インスタントクラシック！

└

100%！

└

ウェブスケールテクノロジー™

kubeの複雑さに関するジョークが多く出るのを予想して、kubeのようなものが達成すべきタスクに必要な複雑さのレベルだっていう面白い議論ができると思うんだ。フレッド・ブルックスの本質的複雑さと偶発的複雑さのルールみたいにね。もちろん、もっとシンプルにできることにkubeを使うと、急に偶発的な複雑さになっちゃうけど。

まず最初に、これは本当にクールだね。LLM支援のエンジニアリングをこうやって捉えるのが正しい気がする。AIは驚くほどの量のコードを生成できるけど、実際の価値はレビューの仕組みやその周りのテストにあると思う。ブラウザでのKubernetesのアプローチもいいけど、もっと興味深いのはワークフローで、特に「見た目が正しい」と信じるだけじゃなくて、k8sに対してテストする行動だね。AIが書いたコードに対して、どれだけのチームがすでにこのレベルの検証をやってるのか気になるな。これから数年でみんながこの方向に進むかもしれないね。

└

これは、文字通りコードに対して仕様がある特定のケースだよね。残念ながら、すべてのコーディングの試みにはそんな機会があるわけじゃないけど。

これ、いいね。過去にKubernetesの教育コンテンツを作成してた者として、こういうものを作る魅力はよくわかるよ。確か、最初はKatacodaを使って、その後別の似たようなプラットフォームを使ったけど、特定のセットアップで各ユーザーに新しいインスタンスをその場で立ち上げてくれるからすごく便利だった。今は、概念的・アーキテクチャ的な教育に向いてるみたいだけど、本当に楽しいのはkubectlをマスターし始めるときだね。

└

そうそう、過去の役割では、制御プレーンがどう機能するかを説明するための図を作るのにこれがすごく役立っただろうな。劣化や故障モードを示したり、異なるアーキテクチャやk8sへのデプロイ方法を比較したりするのにね。

└

残念ながらKatacodaが有料化しちゃったね（理由はわかるけど、こういうのにはコストがかかるから）。他の似たようなプラットフォームも、資金を提供してくれる人がいなくなって消えちゃったみたい。もったいないな。これが代替案になればいいけど、現実とズレるリスクもあるよね。でも、少なくともその場合でも、コアは常に関連性があるはず。

これ、めっちゃいいね！最初にこのアイデアを思いついてたらよかったなぁ。これは楽しい学びと実験のツールになると思う。ずっとサービスの負荷分散やキューイングのシミュレーションができるウェブページを作りたいと思ってたから、これがその基盤になりそう。

└

悪いニュースかもしれないけど、これ見てみて: https://samwho.dev/load-balancing https://encore.dev/blog/queueing

ちなみに、数日前にこれを遊びで作ったよ：https://imjasonh.github.io/kubescheduler-the-game/ 楽しかった！

Hacker Newsで議論の続きを見る