Mem-port Kubernetes ke Browser

• webernetes adalah proyek yang memindahkan sebagian Kubernetes ke TypeScript agar cluster bisa dijalankan di dalam browser. Proyek ini dibuat selama 2 bulan dengan 552 commit, 629 file, dan hampir 100 ribu baris kode
• Ini bukan pendekatan mengompilasi Kubernetes apa adanya ke WebAssembly, melainkan mengimplementasikan ulang sebagian kubelet, berbagai controller, CNI dan container runtime berbasis browser, serta API untuk mengoperasikan cluster
• Alih-alih mengambil image dari registry image sungguhan, image didefinisikan lewat API TypeScript; tujuannya bukan distribusi production, melainkan pembuatan konten Kubernetes interaktif
• Sebagian besar kode ditulis oleh LLM, tetapi setiap baris direview manusia, dan divalidasi dengan 204 integration test yang menjalankan pengujian yang sama seperti k3s serta 1.855 unit test yang di-port dari codebase Kubernetes Go
• Selama proses porting, LLM berulang kali melakukan peringkasan, membuat helper arbitrer, dan melewatkan test; untuk memperoleh manfaat dari generasi kode yang cepat, review dan testing harus diterapkan bersama

---

Apa yang dijalankan webernetes di browser

• webernetes adalah proyek yang mem-port sebagian Kubernetes ke TypeScript agar cluster bisa dijalankan di browser
• Cluster demo seluruhnya berjalan di dalam browser, dan melakukan cukup banyak pekerjaan yang dilakukan cluster Kubernetes sungguhan

  • Siklus hidup Pod

    • DNS dan networking cluster
    • Garbage collection container
    • Alokasi IP
    • Pelacakan Deployment dan ReplicaSet
    • Titik biru pada demo menunjukkan Pod yang saling mengirim request

Porting parsial sebagai ganti kompilasi WebAssembly

• Ini bukan mengompilasi Kubernetes ke WebAssembly
• Bahkan program Go hello, world! sederhana yang dikompilasi ke WebAssembly berukuran sekitar 540KiB dalam gzip, sedangkan webernetes sekitar 140KiB dalam gzip
• Jika seluruh Kubernetes dikompilasi ke WebAssembly, kemungkinan diperlukan transfer dalam ukuran megabyte, dan panggilan API tingkat sistem yang tidak tersedia di browser juga akan menimbulkan error saat kompilasi
• webernetes terdiri dari elemen-elemen berikut
  • Porting parsial binary Kubernetes kubelet yang diperlukan untuk menjalankan Pod dan probe
  • Porting beberapa controller Kubernetes seperti Pod scheduler, namespace controller, kube-proxy, dan deployment controller
  • Container Network Interface (CNI) berbasis browser untuk komunikasi antar-Pod
  • Container runtime berbasis browser yang memungkinkan kubelet menjalankan container melalui Container Runtime Interface (CRI)
  • API cluster webernetes untuk operasi seperti menerapkan manifest dan watch resource

Definisi image dan cara memakai API

• Untuk menjaga ukuran tetap kecil, webernetes tidak mengambil image sungguhan dari registry seperti Docker Hub
• Sebagai gantinya, ia memiliki registry berbasis browser, dan image didefinisikan dengan API TypeScript
• Contoh image HelloWorld mewarisi w8s.BaseImage, dan di dalam exec mengembalikan "Hello, world!" untuk request HTTP ke port 8080
• Alur penggunaan cluster adalah sebagai berikut
  • Membuat cluster dengan new w8s.Cluster()
  • Mendaftarkan image dengan cluster.registerImage(HelloWorld)
  • Menerapkan manifest Deployment apps/v1 dengan cluster.apply()
  • Melihat daftar Pod dengan cluster.api.corev1.listNamespacedPod()
  • Memantau perubahan Pod dengan cluster.informer("pods", ...)
  • Mengamati event request dan response antar-Pod dengan cluster.on("request"), cluster.on("response")
  • Mengirim request HTTP ke IP Pod melalui jaringan cluster dengan cluster.fetch()
• Contoh lebih banyak tersedia di webernetes repository examples

Kegunaan dan batasan saat ini

• Tujuan webernetes adalah membuat konten Kubernetes interaktif
• Ini bukan distribusi Kubernetes yang siap production, dan tidak perlu menjalankan image sungguhan
• Cukup jika pembuat konten dapat menyiapkan workload tertentu untuk menunjukkan konsep Kubernetes yang ingin dijelaskan
• Fitur yang saat ini belum didukung mencakup
  • ConfigMaps
  • Secrets
  • Pod resources
  • persistent volumes
  • berbagai fitur Kubernetes lain yang belum diperlukan
• Ke depannya, fitur Kubernetes yang diperlukan dalam proses pembuatan konten akan diimplementasikan lebih lanjut

Dibuat dengan LLM, tetapi tidak diserahkan begitu saja

• Hampir seluruh kode webernetes ditulis oleh LLM
• Untuk keandalan proyek, dua hal dilakukan secara bersamaan
  • Mereview setiap baris kode secara langsung
  • Membuat ratusan test untuk memastikan webernetes berperilaku sama seperti cluster sungguhan
• Melalui review manual, penulis mendapatkan keyakinan bahwa sebagian besar kode identik baris demi baris dengan codebase Kubernetes Go
• Test berperan untuk memastikan apakah kemiripan leksikal seperti ini benar-benar menghasilkan perilaku yang sama
• Kesalahan yang tersisa setelah review adalah tanggung jawab penulis proyek, dan jika menemukan masalah, ia meminta agar issue dibuka

Mengapa kode hasil porting perlu direview

• Dalam kasus penulisan compiler C dengan LLM atau porting Bun dari Zig ke Rust, ada cara untuk memverifikasi kebenaran secara otomatis
  • Anthropic memiliki compiler C yang sudah ada untuk dibandingkan
  • Bun memiliki test suite besar yang cukup dipercaya untuk menggabungkan lebih dari 1 juta baris kode Rust baru tanpa review manual
• webernetes tidak memiliki dasar seperti itu
  • Jika butuh test suite, itu harus ditulis sendiri
  • Jika ingin membandingkan dengan Kubernetes sungguhan, cara perbandingannya juga harus disiapkan sendiri
• Sebagian besar kode webernetes di-port dari codebase Kubernetes Go, dan LLM digunakan karena diperkirakan lebih cepat daripada mengetiknya dengan tangan
• Dalam proses porting, LLM berulang kali membuat kesalahan
  • Peringkasan: LLM dapat mengganti LRU cache, expiring cache, FIFO cache, transforming cache, dan lainnya di Kubernetes dengan Map tanpa mengimplementasikannya dengan benar, sehingga menghasilkan perilaku yang salah
  • Pembersihan berlebihan: LLM dapat membuat fungsi helper yang tidak ada di kode Go asli, sehingga review menjadi sulit atau muncul perbedaan halus
  • Kelalaian: Saat mem-port table test Go, LLM sering kali secara arbitrer melewatkan kasus test
• Untuk mempercayai hasil porting LLM, output-nya harus direview, dan penulis proyek menganggap dirinya tidak tahu jalan pintas apa yang bisa ia ambil

Test yang dibandingkan dengan cluster sungguhan

• Walaupun kode tampak mirip berdampingan dengan aslinya, runtime Go dan JavaScript berbeda, sehingga perilakunya bisa berbeda
• webernetes juga membutuhkan versi JavaScript dari channels, mutexes, statement select milik Go, dan perilaku bergaya Go lainnya
• Kode test yang sama dijalankan pada webernetes dan cluster k3s untuk membandingkan perilaku
• Untuk target kompatibilitas API, dipilih klien Kubernetes JavaScript resmi dengan tipe TypeScript, kubernetes-client/javascript
• Test harness mengganti environment eksekusi melalui kubernetes.describe(..)
  • pnpm test:node menjalankan test di environment Node terhadap k3s
  • pnpm test:browser menjalankan test di headless browser terhadap webernetes
• Integration test memastikan bukan hanya kode yang di-port, tetapi juga container runtime berbasis browser kustom dan cluster network berperilaku sesuai dengan cluster sungguhan
• Jika menemukan bug, pertama dibuat test yang lulus di k3s tetapi gagal di webernetes, lalu loop umpan balik itu digunakan dengan bantuan LLM untuk memahami dan memperbaiki penyebabnya
• Pada saat penulisan, webernetes memiliki 204 integration test dan 1.855 unit test

Mengapa review dan test harus dipakai bersama

• Kode yang dibuat LLM tetap membutuhkan test yang baik dan kode yang baik, sama seperti PR yang ditulis manusia
• Perbedaan pada 2026 adalah: untuk rekan manusia, kita sampai batas tertentu mengharapkan pekerjaan yang baik, tetapi untuk LLM, lebih aman mengasumsikan bahwa ia tidak akan melakukan pekerjaan yang baik
• Jika bahkan kode test tidak direview, sulit mengetahui kriteria keberhasilan apa yang sedang dikerjakan LLM
• Walaupun semua kode direview, tanpa test sulit percaya bahwa manusia dapat menalar semua kemungkinan
• Karena LLM tidak lelah dan mengetik dengan cepat, pendekatan yang berguna adalah membuatnya mengusulkan edge case yang tidak terpikirkan manusia, lalu jika valid, memintanya menulis test
• Menggabungkan selera dan pemahaman manusia dengan kemampuan menulis cepat LLM terasa sebagai perubahan terbesar sejak penulis memulai kariernya pada 2012

Skala proyek dan penggunaan token

• Commit pertama masuk ke webernetes repository saat ini pada 21 April
• Sebagian pekerjaan awal dilakukan di branch repository di balik situs blog ini, sehingga grafik tidak sepenuhnya mencerminkan keseluruhan realitas
• Grafik baris kode menunjukkan 126.642 baris pada pekan 15 Juni
• Angka sekitar 100 ribu baris yang disebut di awal adalah jumlah yang mengecualikan kode non-TypeScript, komentar, dan demo app
• Total baris per minggu bertambah sebagai berikut
  • Pekan 20 April: 11.640 baris
  • Pekan 27 April: 20.660 baris
  • Pekan 4 Mei: 25.048 baris
  • Pekan 11 Mei: 30.417 baris
  • Pekan 18 Mei: 42.301 baris
  • Pekan 25 Mei: 54.155 baris
  • Pekan 1 Juni: 79.704 baris
  • Pekan 8 Juni: 98.532 baris
  • Pekan 15 Juni: 126.642 baris
• Dalam penggunaan token sesi Codex dan Claude, cached input token jauh lebih besar daripada token lain, terutama ketika jendela konteks panjang sering diisi
• Pada pekan 15 Juni, digunakan 104.155.857 uncached input token, 2.196.467.968 cached input token, dan 6.420.826 output token

Lonjakan pada minggu terakhir dan biaya

• Pada minggu terakhir, upaya menambahkan dukungan Deployments ke demo app ternyata menjadi pekerjaan yang lebih besar dari perkiraan
• Upaya porting pertama oleh LLM melewatkan banyak fungsi dari komponen yang diperlukan
• Setelah itu, beberapa agent dikerahkan untuk mengidentifikasi rantai dependensi, setiap komponen di-port oleh lebih banyak sub-agent, dan review dilakukan oleh sub-agent lainnya
• Cara ini menyelesaikan pekerjaan lebih cepat daripada kerja manual, tetapi efisiensi tokennya sangat buruk, dan pada akhirnya tetap membutuhkan review manual
• Biaya token LLM jika dikonversi ke API meningkat per minggu, dan pada pekan 15 Juni mencapai $1,811.64
• Sepanjang proyek, waktu penulis tetap menjadi item paling mahal sampai akhir

Materi penutup dan cara berpartisipasi

• Ada juga seri video yang merekam proses pembuatannya
  • Part 1
  • Part 2
  • Part 3 akan segera dirilis
• Dalam video, Anda juga bisa melihat optimisme awal yang keliru, serta cara bekerja sebagian besar hands-free dengan kontrol suara dan pelacakan mata
• Penulis meminta orang untuk mencoba proyek ini dan membuka issues, atau menghubungi [e-mail] jika membuat sesuatu atau mengalami kebuntuan

[GN⁺]

Pendapat di Hacker News

• Dari sudut pandang orang yang suka mengajar dan membuat sesuatu, hal seperti ini bisa cukup berguna
  Misalnya, saya membuat ini https://kubernetes-made-simple.vercel.app/ dan sekarang sepertinya bisa saya tambahkan ke sana
  • Kalau mengubah jumlah Pod yang diharapkan di iPhone, simulator reconciliation jadi aneh dan meledak tak terkendali
    Tapi situsnya tetap keren
  • Saya sudah membaca semuanya, dan isinya bagus
    Akan lebih baik kalau Gateway diperluas lagi, dan jika memungkinkan CRD juga disebutkan
  • Situs yang keren
    Kalau harus memilih satu hal yang paling sering disalahpahami orang tentang k8s sehingga membuat proses belajarnya jadi tidak perlu sulit, apa itu?
• Keren. Sebagai orang yang dulu pernah membuat konten pelatihan Kubernetes, saya jelas bisa melihat daya tarik untuk membuat hal seperti ini
  Seingat saya awalnya kami memakai Katacoda, lalu kemudian platform lain yang mirip; platform itu sangat berguna karena langsung menjalankan instance baru dengan konfigurasi tertentu untuk setiap pengguna
  Namun saat ini ini tampaknya lebih cocok untuk mengajarkan konsep atau arsitektur. Keseruan sebenarnya baru dimulai saat mulai mahir memakai kubectl
  • Kalau di tempat kerja lama saya, ini pasti sangat bagus untuk diagram yang menjelaskan cara kerja control plane, penurunan performa dan mode kegagalan, serta perbandingan berbagai arsitektur atau cara deployment ke k8s
  • Sayangnya Katacoda sekarang masuk ke balik paywall. Saya sepenuhnya paham kenapa mereka melakukannya. Hal-hal seperti ini memang butuh biaya
    Platform lain yang mirip juga tampaknya menghilang karena tidak ada lagi yang menanggung biayanya, dan itu disayangkan
    Semoga ini bisa menjadi alternatif. Ada risiko menjadi usang karena berbeda dari kenyataan, tetapi intinya hampir selalu akan tetap berlaku
• Pertama-tama, ini benar-benar keren
  Ini terasa seperti cara yang tepat untuk memandang rekayasa berbantuan LLM. AI bisa menghasilkan kode dalam jumlah yang mengejutkan, tetapi nilai sebenarnya ada pada disiplin review dan pengujian di sekelilingnya
  Sudut pandang menjalankan Kubernetes di browser juga keren, tetapi yang lebih menarik adalah workflow-nya, terutama bagian menguji perilaku terhadap k8s alih-alih percaya pada sesuatu yang “kelihatannya masuk akal”. Saya penasaran sudah berapa banyak tim yang melakukan validasi setingkat ini terhadap kode yang ditulis AI, dan mungkin inilah arah yang akan dituju semua orang dalam beberapa tahun ke depan
  • Ini secara harfiah adalah kasus khusus yang punya spesifikasi untuk diimplementasikan secara sesuai
    Sayangnya tidak semua pekerjaan coding punya peluang seperti itu
• Nate Abele membawakan presentasi tentang topik ini di Carolina Code Conference tahun lalu
  https://youtu.be/t7L2iROVaRg?is=xoV4aiCXcYMVvVDL
• Benar-benar cukup keren
  Kompleksitas tambahan atau penurunan performa memang perlu sedikit pembenaran, tetapi untuk beberapa use case tampaknya cukup layak terbayar
• Sebelum lelucon tentang kompleksitas kube bermunculan, sepertinya ada argumen menarik bahwa sesuatu seperti kube memiliki tingkat kompleksitas yang memang diperlukan untuk melakukan pekerjaan-pekerjaan yang dimaksudkan bagi kube
  Mirip dengan pembedaan Fred Brooks antara kompleksitas esensial dan kompleksitas aksidental
  Tentu saja, jika memakai kube untuk hal yang sebenarnya bisa dibuat lebih sederhana, kube dengan cepat menjadi kompleksitas aksidental
• 1. Sepertinya ini tidak benar-benar menjalankan container di browser. Tampaknya semua service memerlukan connector kustom, dan yang lebih penting…
  2. …bukankah juga perlu renderer? Kalau tidak, saya tidak paham apa maksudnya “di-porting ke browser”
     Sebagai analogi, kalau seseorang mem-porting DOOM ke browser, artinya sekarang kita bisa memainkannya di browser. Tapi database yang terlihat di tab itu sebenarnya tidak bisa dijalankan di browser, kan?
     Menjalankan ruby2d tidak berarti tiba-tiba ada dukungan Ruby sisi klien. Perlu segala macam pekerjaan kustom agar benar-benar berjalan di tab browser
     Sebaliknya, service container backend pada umumnya benar-benar bisa dipindah-pindahkan dan dijalankan di mana saja
     Jadi saya kurang menangkap poinnya, dan tolong koreksi kalau saya salah. Ini juga tampaknya tidak selaras dengan klaimnya sendiri
  • Poin-poin itu tidak ada di judul, tetapi dibahas di isi tulisan
    Ini tidak menjalankan container image sungguhan. Mungkin lebih tepat disebut “Kubernetes yang disimulasikan”
    Yang di-porting adalah control plane. Scheduler, kube-proxy, deployment controller, dan lainnya dipindahkan dari source Go asli, lalu diuji kesesuaian perilakunya dengan k3s menggunakan client API yang sama. “Rendering”-nya adalah aplikasi demo yang memvisualisasikan request antarpod sebagai titik-titik yang bergerak
  • “Webernetes ditujukan untuk membuat konten Kubernetes interaktif”
• Demonya keren. Ini bisa dipakai untuk apa?
• Terkait hal ini, beberapa hari lalu saya membuat ini dengan vibe coding sekadar untuk bersenang-senang: https://imjasonh.github.io/kubescheduler-the-game/
  Itu menyenangkan
  • Game ini benar-benar sesuai selera saya