Port Kubernetes sang trình duyệt

 (ngrok.com)
1 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • webernetes là một dự án chuyển một phần Kubernetes sang TypeScript để chạy một cụm ngay trong trình duyệt; được xây dựng trong 2 tháng với 552 commit, 629 tệp và gần 100.000 dòng mã
  • Không phải cách biên dịch nguyên Kubernetes sang WebAssembly; dự án triển khai mới một phần kubelet, nhiều controller, CNI và container runtime dựa trên trình duyệt, cùng API thao tác cụm
  • Không kéo image từ registry thật, mà định nghĩa image bằng TypeScript API; mục tiêu không phải bản phân phối production mà là tạo nội dung Kubernetes có tính tương tác
  • Phần lớn mã do LLM viết, nhưng con người đã review từng dòng; được kiểm chứng bằng 204 bài kiểm thử tích hợp chạy cùng các bài test như k3s và 1.855 bài kiểm thử đơn vị được port từ codebase Kubernetes Go
  • Trong quá trình port, LLM liên tục rút gọn, tự tạo helper tùy ý và bỏ sót test; để tận dụng lợi thế sinh mã nhanh, cần áp dụng đồng thời review và kiểm thử

webernetes chạy gì trong trình duyệt

  • webernetes là dự án port một phần Kubernetes sang TypeScript để có thể chạy cụm trong trình duyệt
  • Cụm demo hoạt động hoàn toàn bên trong trình duyệt và thực hiện khá nhiều tác vụ mà một cụm Kubernetes thật làm

    • Vòng đời Pod

      • DNS và networking của cụm
      • Garbage collection cho container
      • Cấp phát IP
      • Theo dõi Deployment và ReplicaSet
      • Các chấm xanh trong demo biểu thị các Pod đang gửi request cho nhau

Chọn port một phần thay vì biên dịch WebAssembly

  • Đây không phải là biên dịch Kubernetes sang WebAssembly
  • Ngay cả khi biên dịch một chương trình Go hello, world! đơn giản sang WebAssembly, kích thước theo gzip cũng khoảng 540KiB, trong khi webernetes khoảng 140KiB theo gzip
  • Nếu biên dịch toàn bộ Kubernetes sang WebAssembly, nhiều khả năng sẽ phải truyền tải ở mức megabyte, và cũng phát sinh lỗi lúc biên dịch do các lời gọi API cấp hệ thống không dùng được trong trình duyệt
  • webernetes gồm các thành phần sau
    • Port một phần binary kubelet của Kubernetes cần cho việc chạy Pod và probe
    • Port nhiều Kubernetes controller như Pod scheduler, namespace controller, kube-proxy, deployment controller
    • Container Network Interface (CNI) dựa trên trình duyệt để giao tiếp giữa các Pod
    • Container runtime dựa trên trình duyệt để kubelet chạy container thông qua Container Runtime Interface (CRI)
    • API cụm webernetes cho các tác vụ như áp dụng manifest và watch tài nguyên

Cách định nghĩa image và sử dụng API

  • Để giữ kích thước nhỏ, webernetes không kéo image thật từ các registry như Docker Hub
  • Thay vào đó, nó có registry dựa trên trình duyệt và image được định nghĩa bằng TypeScript API
  • Image ví dụ HelloWorld kế thừa w8s.BaseImage và trong exec trả về "Hello, world!" cho request HTTP tới cổng 8080
  • Luồng sử dụng cụm như sau
    • Tạo cụm bằng new w8s.Cluster()
    • Đăng ký image bằng cluster.registerImage(HelloWorld)
    • Áp dụng manifest Deployment apps/v1 bằng cluster.apply()
    • Truy vấn danh sách Pod bằng cluster.api.corev1.listNamespacedPod()
    • Theo dõi thay đổi Pod bằng cluster.informer("pods", ...)
    • Quan sát sự kiện request và response giữa các Pod bằng cluster.on("request"), cluster.on("response")
    • Có thể gửi request HTTP tới IP Pod qua mạng cụm bằng cluster.fetch()
  • Có thêm ví dụ trong webernetes repository examples

Công dụng và giới hạn hiện tại

  • Mục đích của webernetes là tạo nội dung Kubernetes có tính tương tác
  • Đây không phải bản phân phối Kubernetes sẵn sàng cho production, và cũng không cần chạy image thật
  • Chỉ cần người tạo nội dung có thể thiết lập workload cụ thể để minh họa khái niệm Kubernetes mà họ muốn giải thích
  • Các tính năng hiện chưa hỗ trợ gồm
    • ConfigMaps
    • Secrets
    • Pod resources
    • persistent volumes
    • nhiều tính năng Kubernetes khác chưa cần đến
  • Dự định sẽ triển khai thêm các tính năng Kubernetes cần thiết trong quá trình tạo nội dung sau này

Vì sao dùng LLM tạo nhưng không giao phó hoàn toàn

  • Gần như toàn bộ mã của webernetes do LLM viết
  • Để đảm bảo độ tin cậy của dự án, tác giả làm song song hai việc
    • Tự review từng dòng mã
    • Tạo hàng trăm bài test để kiểm tra webernetes có hành xử giống cụm thật hay không
  • Việc review thủ công giúp có được sự tin tưởng rằng phần lớn mã giống codebase Kubernetes Go đến từng dòng
  • Test có vai trò kiểm tra liệu sự tương đồng về mặt từ vựng đó có dẫn tới hành vi giống nhau trong thực tế hay không
  • Những lỗi còn lại sau review là trách nhiệm của tác giả dự án; nếu phát hiện vấn đề, tác giả đề nghị mở issue

Vì sao mã port cần được review

  • Các trường hợp dùng LLM để viết compiler C hoặc port Bun từ Zig sang Rust có cách tự động kiểm chứng tính đúng đắn
    • Anthropic có các compiler C hiện có để so sánh
    • Bun có bộ test quy mô lớn đủ đáng tin cậy để merge hơn 1 triệu dòng mã Rust mới mà không cần review thủ công
  • webernetes không có nền tảng như vậy
    • Nếu cần test suite thì phải tự viết
    • Nếu muốn so sánh với Kubernetes thật thì cũng phải tự chuẩn bị cách so sánh
  • Phần lớn mã webernetes được port từ codebase Kubernetes Go, và tác giả dùng LLM vì cho rằng như vậy sẽ nhanh hơn gõ tay
  • Trong quá trình port, LLM lặp đi lặp lại nhiều lỗi
    • Rút gọn: Không triển khai đúng LRU cache, expiring cache, FIFO cache, transforming cache… của Kubernetes mà thay bằng Map, có thể tạo ra hành vi sai
    • Dọn dẹp quá mức: Tạo các hàm helper không có trong mã Go gốc, khiến review khó hơn hoặc có thể tạo ra khác biệt tinh vi
    • Bỏ sót: Khi port table test của Go, thường tự ý bỏ qua các test case
  • Để tin tưởng kết quả port của LLM, cần review đầu ra; tác giả dự án cho rằng mình không biết có lối tắt nào có thể dùng được

Kiểm thử so sánh với cụm thật

  • Dù mã trông giống bản gốc đặt cạnh nhau, runtime Go và JavaScript khác nhau nên hành vi có thể khác
  • webernetes cũng cần phiên bản JavaScript của channels, mutexes, câu lệnh select của Go và các hành vi kiểu Go khác
  • Chạy cùng một mã test trên cả webernetes và cụm k3s để so sánh hành vi
  • Đối tượng tương thích API được chọn là client Kubernetes JavaScript chính thức có kiểu TypeScript, kubernetes-client/javascript
  • Test harness thay đổi môi trường chạy thông qua kubernetes.describe(..)
    • pnpm test:node test trong môi trường Node với đích là k3s
    • pnpm test:browser test trong headless browser với đích là webernetes
  • Kiểm thử tích hợp không chỉ kiểm tra mã đã port mà còn xác nhận container runtime và cluster network tùy chỉnh dựa trên trình duyệt có hoạt động khớp với cụm thật hay không
  • Khi phát hiện bug, trước tiên tạo test pass trên k3s nhưng fail trên webernetes, rồi dùng vòng phản hồi đó để nhờ LLM hỗ trợ hiểu nguyên nhân và sửa lỗi
  • Tại thời điểm viết, webernetes có 204 bài kiểm thử tích hợp và 1.855 bài kiểm thử đơn vị

Vì sao phải dùng cả review lẫn test

  • Mã do LLM tạo cũng cần test tốt và mã tốt giống như PR do con người viết
  • Khác biệt của năm 2026 là với đồng nghiệp con người, ta từng kỳ vọng họ làm việc tốt ở một mức nào đó, còn với LLM thì giả định rằng nó sẽ không làm việc tốt sẽ an toàn hơn
  • Nếu ngay cả mã test cũng không được review, sẽ khó biết LLM đang làm việc theo tiêu chí thành công nào
  • Dù review toàn bộ mã, nếu không có test thì khó tin rằng con người đã suy luận được mọi khả năng
  • LLM không mệt và gõ rất nhanh, nên cách hữu ích là để nó đề xuất các edge case mà con người không nghĩ tới, rồi nếu hợp lý thì cho nó viết test
  • Tác giả cho rằng cách kết hợp gu và sự hiểu biết của con người với năng lực viết nhanh của LLM là thay đổi lớn nhất kể từ khi bắt đầu sự nghiệp năm 2012

Quy mô dự án và lượng token sử dụng

  • Commit đầu tiên được đưa vào webernetes repository hiện tại vào ngày 21 tháng 4
  • Một phần công việc ban đầu diễn ra trên một nhánh repository phía sau blog site này, nên biểu đồ không phản ánh hoàn toàn thực tế
  • Biểu đồ số dòng mã hiển thị 126.642 dòng vào tuần ngày 15 tháng 6
  • Con số khoảng 100.000 dòng nói ở đầu là số đã loại trừ mã không phải TypeScript, chú thích và demo app
  • Tổng số dòng theo tuần tăng như sau
    • Tuần ngày 20 tháng 4: 11.640 dòng
    • Tuần ngày 27 tháng 4: 20.660 dòng
    • Tuần ngày 4 tháng 5: 25.048 dòng
    • Tuần ngày 11 tháng 5: 30.417 dòng
    • Tuần ngày 18 tháng 5: 42.301 dòng
    • Tuần ngày 25 tháng 5: 54.155 dòng
    • Tuần ngày 1 tháng 6: 79.704 dòng
    • Tuần ngày 8 tháng 6: 98.532 dòng
    • Tuần ngày 15 tháng 6: 126.642 dòng
  • Lượng token sử dụng trong các phiên Codex và Claude có cached input token lớn hơn nhiều so với các loại token khác, đặc biệt nổi bật khi thường xuyên lấp đầy cửa sổ context dài
  • Trong tuần ngày 15 tháng 6, đã dùng 104.155.857 uncached input token, 2.196.467.968 cached input token và 6.420.826 output token

Đợt tăng vọt và chi phí tuần cuối

  • Trong tuần cuối, việc thêm hỗ trợ Deployments vào demo app trở nên lớn hơn dự kiến
  • Lần port đầu tiên của LLM bỏ sót nhiều chức năng của các thành phần cần thiết
  • Sau đó, tác giả huy động nhiều agent để xác định chuỗi phụ thuộc, port từng thành phần bằng thêm nhiều sub-agent, rồi review bằng các sub-agent khác
  • Cách này hoàn thành công việc nhanh hơn làm thủ công, nhưng hiệu quả token rất kém và cuối cùng vẫn cần review thủ công
  • Chi phí token LLM quy đổi theo API tăng theo từng tuần; trong tuần ngày 15 tháng 6 là $1.811,64
  • Trong toàn bộ dự án, thời gian của tác giả vẫn là khoản tốn kém nhất cho đến cuối

Tài liệu kết thúc và cách tham gia

  • Cũng có loạt video ghi lại quá trình xây dựng
  • Trong video có thể thấy sự lạc quan sai lầm ban đầu, cũng như cách làm việc gần như hands-free bằng điều khiển giọng nói và theo dõi mắt
  • Tác giả đề nghị dùng thử dự án và mở issues, hoặc liên hệ s.rose@ngrok.com khi bạn đã tạo được thứ gì đó hoặc gặp vướng mắc

Bài viết liên quan

1 bình luận

 
GN⁺ 4 giờ trước
Các ý kiến trên Hacker News
  • Với tư cách là người thích dạy học và thích xây dựng, thứ như thế này có thể khá hữu ích
    Ví dụ, tôi đã làm cái này https://kubernetes-made-simple.vercel.app/ giờ có thể thêm nó vào đây được
    • Khi đổi số Pod mong muốn trên iPhone, trình mô phỏng reconciliation bị chạy loạn một cách kỳ lạ
      Dù vậy trang này vẫn rất hay
    • Tôi đã đọc hết toàn bộ và nội dung rất tốt
      Sẽ hay hơn nếu mở rộng thêm về Gateway, và nếu có thể thì nhắc cả CRD nữa
    • Trang rất tuyệt
      Nếu phải chọn một điều mà đa số mọi người hiểu sai về k8s, khiến việc học trở nên khó một cách không cần thiết, thì đó là gì?
  • Tuyệt. Từng làm nội dung đào tạo Kubernetes, tôi thấy rõ sức hấp dẫn của việc muốn tạo ra thứ như thế này
    Theo tôi nhớ thì ban đầu chúng tôi dùng Katacoda, rồi sau đó dùng một nền tảng tương tự khác; nó rất hữu ích vì có thể dựng ngay một instance mới với cấu hình cụ thể cho từng người dùng
    Tuy nhiên hiện tại thứ này có vẻ phù hợp hơn cho việc dạy khái niệm hoặc kiến trúc. Phần thật sự thú vị bắt đầu khi bạn dùng kubectl thành thạo
    • Nếu ở công ty cũ của tôi, nó hẳn sẽ rất tuyệt để có các sơ đồ giải thích control plane hoạt động thế nào, các tình huống suy giảm hiệu năng và chế độ lỗi, cũng như so sánh nhiều kiến trúc hoặc cách triển khai lên k8s
    • Đáng tiếc là Katacoda đã bị đưa vào sau tường phí. Tôi hoàn toàn hiểu vì sao họ làm vậy. Những thứ như thế này đều tốn chi phí
      Có vẻ các nền tảng tương tự khác cũng biến mất vì không còn ai trả tiền duy trì, thật đáng tiếc
      Hy vọng cái này sẽ là một lựa chọn thay thế. Dù có rủi ro trở nên lỗi thời khi lệch khỏi thực tế, phần cốt lõi gần như sẽ luôn còn giá trị
  • Trước hết, thật sự rất tuyệt
    Đây có vẻ là cách đúng để nhìn nhận kỹ thuật có LLM hỗ trợ. AI có thể tạo ra lượng code nhiều đến đáng kinh ngạc, nhưng giá trị thật nằm ở kỷ luật review và các bài test xung quanh nó
    Góc tiếp cận Kubernetes trong trình duyệt cũng rất hay, nhưng điều thú vị hơn là workflow, đặc biệt là phần kiểm thử hành vi với k8s thay vì tin vào cảm giác “trông có vẻ đúng”. Tôi tò mò hiện đã có bao nhiêu team xác minh code do AI viết ở mức này, và có thể đây là hướng mà mọi người sẽ đi trong vài năm tới
    • Đây là một trường hợp đặc biệt, nơi đúng nghĩa là có đặc tả để triển khai theo
      Đáng tiếc là không phải mọi công việc lập trình đều có cơ hội như vậy
  • Nate Abele đã thuyết trình về chủ đề này tại Carolina Code Conference năm ngoái
    https://youtu.be/t7L2iROVaRg?is=xoV4aiCXcYMVvVDL
  • Thật sự khá tuyệt
    Mức độ phức tạp thêm vào hoặc tổn thất hiệu năng sẽ cần được biện minh ở một mức nào đó, nhưng có vẻ với một số use case thì phần đánh đổi này hoàn toàn xứng đáng
  • Trước khi các câu đùa về độ phức tạp của kube xuất hiện, có thể lập luận khá thú vị rằng những thứ như kube có mức phức tạp cần thiết để thực hiện các công việc mà kube được thiết kế cho
    Điều này giống với phân biệt của Fred Brooks giữa độ phức tạp bản chất và độ phức tạp ngẫu nhiên
    Tất nhiên, nếu dùng kube cho những việc có thể làm đơn giản hơn, kube sẽ nhanh chóng trở thành độ phức tạp ngẫu nhiên
    1. Có vẻ thực ra nó không chạy container trong trình duyệt. Dường như mọi service đều cần connector tùy chỉnh, và quan trọng hơn là…
    2. …chẳng phải cũng cần renderer sao? Nếu không thì tôi không hiểu “được port sang trình duyệt” nghĩa là gì
      Ví dụ, nếu ai đó port DOOM sang trình duyệt, điều đó nghĩa là giờ ta có thể chơi nó trong trình duyệt. Nhưng những cơ sở dữ liệu hiện trong tab đâu thể thật sự chạy trong trình duyệt, đúng không?
      Không thể nói rằng chỉ cần bật ruby2d là đột nhiên có hỗ trợ Ruby phía client. Muốn nó thật sự chạy trong tab trình duyệt thì cần đủ loại công việc tùy chỉnh
      Ngược lại, một service container backend thông thường thì thật sự có thể được di chuyển đây đó và chạy ở bất cứ đâu
      Vì vậy tôi không hiểu rõ ý chính, và nếu tôi sai thì xin hãy sửa. Nó cũng có vẻ không khớp với chính tuyên bố được đưa ra
    • Các điểm đó không có trong tiêu đề, nhưng được đề cập trong bài
      Nó không chạy container image thật. Có lẽ gọi là “Kubernetes mô phỏng” thì hợp hơn
      Phần được port là control plane. Scheduler, kube-proxy, deployment controller, v.v. được chuyển từ mã nguồn Go thật, và dùng cùng client API để kiểm thử mức độ khớp hành vi với k3s. “Rendering” là ứng dụng demo trực quan hóa các request giữa các Pod dưới dạng các chấm di chuyển
    • “Webernetes được dùng để tạo nội dung Kubernetes tương tác”
  • Demo rất hay. Dùng cái này vào việc gì thì hợp?
  • Liên quan đến chuyện này, vài ngày trước tôi đã làm cái này bằng vibe coding cho vui: https://imjasonh.github.io/kubescheduler-the-game/
    Làm khá vui
    • Trò này đúng gu tôi