Kubernetes को ब्राउज़र में पोर्ट किया गया

 (ngrok.com)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • webernetes एक प्रोजेक्ट है जिसमें Kubernetes के कुछ हिस्सों को TypeScript में पोर्ट करके ब्राउज़र के अंदर क्लस्टर चलाने योग्य बनाया गया है; इसे 2 महीनों में 552 commits, 629 files और लगभग 100,000 lines के पैमाने पर बनाया गया
  • यह Kubernetes को वैसे-का-वैसा WebAssembly में compile करने का तरीका नहीं है; इसमें kubelet के कुछ हिस्से, कई controllers, browser-based CNI और container runtime, और cluster manipulation API नए सिरे से implement किए गए हैं
  • यह वास्तविक image registry से images नहीं लाता, बल्कि TypeScript API से images define करता है; लक्ष्य production distribution नहीं, बल्कि interactive Kubernetes content बनाना है
  • ज़्यादातर code LLM ने लिखा, लेकिन हर line को इंसान ने review किया, और k3s जैसे ही tests चलाने वाले 204 integration tests तथा Kubernetes Go codebase से port किए गए 1,855 unit tests से validate किया गया
  • Porting के दौरान LLM ने बार-बार simplification, arbitrary helpers बनाना और tests छोड़ना जैसी गलतियां कीं; तेज़ code generation का लाभ लेने के लिए review और tests को साथ में लागू करना ज़रूरी है

webernetes ब्राउज़र में क्या चलाता है

  • webernetes एक प्रोजेक्ट है जो Kubernetes को TypeScript में आंशिक रूप से port करके ब्राउज़र में cluster चलाने योग्य बनाता है
  • Demo cluster पूरी तरह ब्राउज़र के अंदर चलता है और वास्तविक Kubernetes cluster के कई काम करता है

    • Pod lifecycle

      • Cluster DNS और networking
      • Container garbage collection
      • IP allocation
      • Deployment और ReplicaSet tracking
      • Demo में नीले dots दिखाते हैं कि Pods एक-दूसरे को requests भेज रहे हैं

WebAssembly compilation के बजाय चुना गया partial porting

  • Kubernetes को WebAssembly में compile नहीं किया गया है
  • एक साधारण Go hello, world! program को WebAssembly में compile करने पर भी gzip के हिसाब से लगभग 540KiB बनता है, जबकि webernetes gzip के हिसाब से लगभग 140KiB है
  • पूरे Kubernetes को WebAssembly में compile करने पर संभवतः megabytes में transfer चाहिए होगा, और browser में उपलब्ध न होने वाली system-level API calls के कारण compile-time errors भी आएंगे
  • webernetes इन components से बना है
    • Pod execution और probes के लिए ज़रूरी Kubernetes kubelet binary का partial port
    • Pod scheduler, namespace controller, kube-proxy, deployment controller जैसे कई Kubernetes controllers का port
    • Pods के बीच communication के लिए browser-based Container Network Interface (CNI)
    • kubelet को Container Runtime Interface (CRI) के जरिए containers चलाने देने वाला browser-based container runtime
    • manifest apply करने और resource watch जैसे कामों के लिए webernetes cluster API

Image definition और API usage का तरीका

  • Size छोटी रखने के लिए webernetes Docker Hub जैसी registries से वास्तविक images fetch नहीं करता
  • इसके बजाय इसमें browser-based registry है, और images TypeScript API से define की जाती हैं
  • उदाहरण image HelloWorld, w8s.BaseImage को extend करती है और exec के अंदर 8080 port HTTP request पर "Hello, world!" लौटाती है
  • Cluster usage flow इस प्रकार है
    • new w8s.Cluster() से cluster बनाया जाता है
    • cluster.registerImage(HelloWorld) से image register की जाती है
    • cluster.apply() से apps/v1 Deployment manifest apply किया जाता है
    • cluster.api.corev1.listNamespacedPod() से Pod list query की जाती है
    • cluster.informer("pods", ...) से Pod changes watch किए जाते हैं
    • cluster.on("request"), cluster.on("response") से Pods के बीच request और response events observe किए जाते हैं
    • cluster.fetch() से cluster network के जरिए Pod IP पर HTTP request भेजी जा सकती है
  • और उदाहरण webernetes repository examples में हैं

उपयोग और मौजूदा सीमाएं

  • webernetes का उद्देश्य interactive Kubernetes content बनाना है
  • यह production-ready Kubernetes distribution नहीं है, और इसे वास्तविक images चलाने की ज़रूरत भी नहीं है
  • Content creators जिन Kubernetes concepts को समझाना चाहते हैं, उन्हें दिखाने के लिए specific workloads set कर सकें, इतना पर्याप्त है
  • फिलहाल unsupported features में ये शामिल हैं
    • ConfigMaps
    • Secrets
    • Pod resources
    • persistent volumes
    • कई Kubernetes features जिनकी अभी ज़रूरत नहीं पड़ी
  • आगे content creation के दौरान जिन Kubernetes features की ज़रूरत होगी, उन्हें और implement करने की योजना है

LLM से बनाया, लेकिन सब कुछ उसी पर क्यों नहीं छोड़ा

  • webernetes का लगभग पूरा code LLM ने लिखा है
  • Project reliability के लिए दो चीज़ें साथ-साथ की गईं
    • Code की हर line खुद review की गई
    • यह verify करने के लिए सैकड़ों tests बनाए गए कि webernetes वास्तविक cluster जैसा behave करता है या नहीं
  • Manual review से यह भरोसा मिला कि code का बड़ा हिस्सा Kubernetes Go codebase से line-by-line समान है
  • Tests की भूमिका यह जांचना है कि यह lexical similarity वास्तव में behavior की equivalence में बदलती है या नहीं
  • Review के बाद बची गलतियां project author की ज़िम्मेदारी हैं, और समस्या मिलने पर issue खोलने का अनुरोध किया गया है

Ported code में review क्यों ज़रूरी था

  • LLM से C compiler लिखने या Bun को Zig से Rust में port करने के मामलों में correctness को automatically verify करने का तरीका मौजूद था
    • Anthropic के पास तुलना करने के लिए existing C compilers थे
    • Bun के पास इतना भरोसेमंद बड़ा test suite था कि manual review के बिना 1 million lines से ज्यादा नया Rust code merge किया जा सके
  • webernetes के पास ऐसी नींव नहीं थी
    • Test suite चाहिए था तो उसे खुद लिखना पड़ा
    • वास्तविक Kubernetes से तुलना करनी थी तो comparison method भी खुद बनाना पड़ा
  • webernetes का अधिकतर code Kubernetes Go codebase से port किया गया, और हाथ से type करने की तुलना में तेज़ होगा यह मानकर LLM का इस्तेमाल किया गया
  • Porting के दौरान LLM ने बार-बार गलतियां कीं
    • Simplification: Kubernetes के LRU cache, expiring cache, FIFO cache, transforming cache आदि को ठीक से implement न करके Map से replace कर सकता था, जिससे गलत behavior बन सकता था
    • Over-cleanup: Original Go code में न होने वाले helper functions बनाकर review कठिन कर सकता था या subtle differences ला सकता था
    • Omission: Go के table tests port करते समय test cases को मनमाने ढंग से छोड़ देने की घटनाएं अक्सर हुईं
  • LLM porting results पर भरोसा करने के लिए output review करना ज़रूरी है, और project author का मानना है कि वे खुद यह नहीं जानते कि कौन-से shortcuts सुरक्षित हैं

वास्तविक cluster से तुलना वाले tests

  • Code original के साथ-साथ समान दिखे, तब भी Go और JavaScript runtimes अलग हैं, इसलिए behavior अलग हो सकता है
  • webernetes में JavaScript version के channels, mutexes, Go के select statement और अन्य Go-style behavior की भी ज़रूरत थी
  • समान test code को webernetes और k3s cluster दोनों पर चलाकर behavior compare किया गया
  • API compatibility target के रूप में TypeScript types वाले official JavaScript Kubernetes client kubernetes-client/javascript को चुना गया
  • Test harness kubernetes.describe(..) के जरिए execution environment बदलता है
    • pnpm test:node Node environment में k3s के against tests चलाता है
    • pnpm test:browser headless browser में webernetes के against tests चलाता है
  • Integration tests केवल ported code ही नहीं, बल्कि custom browser-based container runtime और cluster network के वास्तविक cluster के अनुरूप behavior को भी verify करते हैं
  • Bug मिलने पर पहले ऐसा test बनाया जाता है जो k3s में pass हो और webernetes में fail, फिर उस feedback loop में LLM की मदद से cause समझकर fix किया जाता है
  • लिखे जाने के समय webernetes में 204 integration tests और 1,855 unit tests हैं

Review और tests साथ में क्यों इस्तेमाल करने चाहिए

  • LLM-generated code में भी, इंसान द्वारा लिखे PR की तरह, अच्छे tests और अच्छा code चाहिए
  • 2026 में फर्क यह है कि human colleague से कुछ हद तक अच्छा काम अपेक्षित था, लेकिन LLM के बारे में यह मानना सुरक्षित है कि वह अच्छा काम नहीं करेगा
  • Test code तक review न किया जाए तो यह जानना मुश्किल है कि LLM किस success criterion के लिए काम कर रहा है
  • सारा code review करने पर भी tests न हों तो यह मानना कठिन है कि इंसान हर संभावना reason कर सकता है
  • LLM थकता नहीं और तेज़ी से type करता है, इसलिए उससे ऐसे edge cases सुझवाना जिनके बारे में इंसान ने नहीं सोचा, और valid होने पर tests लिखवाना उपयोगी है
  • इंसानी taste और understanding को LLM की तेज़ writing ability के साथ जोड़ने का तरीका 2012 में career शुरू होने के बाद सबसे बड़ा बदलाव लगा

Project scale और token usage

  • पहला commit 21 अप्रैल को मौजूदा webernetes repository में गया
  • शुरुआती काम का कुछ हिस्सा इस blog site के पीछे वाले repository branch में हुआ था, इसलिए graph पूरी वास्तविकता को पूरी तरह capture नहीं करता
  • Code lines graph 15 जून वाले सप्ताह के लिए 126,642 lines दिखाता है
  • शुरुआत में बताए गए लगभग 100,000 lines का आंकड़ा TypeScript नहीं होने वाले code, comments और demo app को छोड़कर है
  • Weekly total lines इस तरह बढ़ीं
    • 20 अप्रैल वाला सप्ताह: 11,640 lines
    • 27 अप्रैल वाला सप्ताह: 20,660 lines
    • 4 मई वाला सप्ताह: 25,048 lines
    • 11 मई वाला सप्ताह: 30,417 lines
    • 18 मई वाला सप्ताह: 42,301 lines
    • 25 मई वाला सप्ताह: 54,155 lines
    • 1 जून वाला सप्ताह: 79,704 lines
    • 8 जून वाला सप्ताह: 98,532 lines
    • 15 जून वाला सप्ताह: 126,642 lines
  • Codex और Claude sessions में token usage में cached input tokens बाकी tokens से कहीं ज्यादा थे, और लंबे context windows को बार-बार भरने पर यह खास तौर पर स्पष्ट हुआ
  • 15 जून वाले सप्ताह में uncached input token 104,155,857, cached input token 2,196,467,968, output token 6,420,826 इस्तेमाल हुए

अंतिम सप्ताह की तेज़ बढ़ोतरी और लागत

  • अंतिम सप्ताह में demo app में Deployments support जोड़ने की कोशिश अपेक्षा से ज्यादा बड़ी हो गई
  • LLM की पहली porting attempt ने ज़रूरी components की कई functionalities छोड़ दीं
  • इसके बाद कई agents का इस्तेमाल करके dependency chain identify की गई, हर component को और अधिक sub-agents से port कराया गया, और अन्य sub-agents से review कराया गया
  • इस तरीके से manual work की तुलना में काम तेज़ी से पूरा हुआ, लेकिन token efficiency बहुत खराब थी, और अंत में फिर भी manual review ज़रूरी था
  • API-converted LLM token cost हर सप्ताह बढ़ी, और 15 जून वाले सप्ताह में $1,811.64 थी
  • पूरे project में author का समय आखिर तक सबसे महंगा item रहा

समापन सामग्री और भाग लेने का तरीका

  • निर्माण प्रक्रिया record करने वाली video series भी है
    • Part 1
    • Part 2
    • Part 3 जल्द जारी होने वाला है
  • Videos में शुरुआती गलत optimism और voice control व eye tracking से ज्यादातर hands-free काम करने का तरीका भी देखा जा सकता है
  • Project आज़माकर issues खोलने, या कुछ बनाया हो या कहीं अटक गए हों तो s.rose@ngrok.com पर संपर्क करने का अनुरोध किया गया है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय
  • जिसे सिखाना और बनाना पसंद है, उसके नज़रिए से यह काफ़ी उपयोगी हो सकता है
    उदाहरण के लिए, मैंने यह बनाया था https://kubernetes-made-simple.vercel.app/ और अब इसमें इसे जोड़ सकता हूँ
    • iPhone पर अपेक्षित Pod count बदलने पर reconciliation simulator अजीब तरह से बेकाबू हो जाता है
      फिर भी साइट शानदार है
    • मैंने सब कुछ पढ़ लिया, और सामग्री अच्छी है
      अगर Gateway को और विस्तार से बताया जाए, और संभव हो तो CRD का भी ज़िक्र किया जाए, तो अच्छा होगा
    • शानदार साइट है
      अगर एक ऐसी चीज़ चुननी हो जिसे ज़्यादातर लोग k8s के बारे में ग़लत समझते हैं और जिसकी वजह से सीखना बेवजह मुश्किल हो जाता है, तो वह क्या होगी?
  • बढ़िया है। मैंने पहले Kubernetes training content बनाया है, इसलिए साफ़ दिखता है कि ऐसा कुछ बनाने का आकर्षण क्यों होगा
    जहाँ तक मुझे याद है, शुरू में हमने Katacoda इस्तेमाल किया था, फिर बाद में एक और मिलते-जुलते platform का इस्तेमाल किया, और यह बहुत उपयोगी था क्योंकि यह हर user के लिए खास configuration के साथ तुरंत एक नया instance खड़ा कर देता था
    लेकिन फिलहाल यह concepts या architecture सिखाने के लिए ज़्यादा उपयुक्त लगता है। असली मज़ा तो तब शुरू होता है जब आप kubectl को फ़ुर्ती से चलाना सीख जाते हैं
    • मेरी पिछली नौकरी में यह control plane कैसे काम करता है, इसे समझाने वाले diagram, performance degradation और failure modes, और k8s पर deploy करने की अलग-अलग architectures या approaches की तुलना के लिए यह बेहद काम का होता
    • अफ़सोस की बात है कि Katacoda अब paywall के पीछे चला गया है। क्यों गया, यह मैं पूरी तरह समझता हूँ। ऐसी चीज़ों में पैसा लगता है
      ऐसे ही दूसरे मिलते-जुलते platforms भी शायद इसलिए गायब हो गए क्योंकि उनके खर्च उठाने वाला कोई नहीं रहा, जो दुखद है
      उम्मीद है यह उसका विकल्प बनेगा। यह जोखिम तो है कि यह वास्तविकता से अलग होकर पुराना पड़ जाए, लेकिन फिर भी मूल बातें लगभग हमेशा प्रासंगिक रहेंगी
  • सबसे पहले, यह सच में बहुत शानदार है
    यह LLM-assisted engineering को देखने का सही तरीका लगता है। AI हैरान कर देने वाली मात्रा में code बना सकता है, लेकिन असली value review discipline और उसके आसपास होने वाली testing में है
    Kubernetes को browser में चलाने का angle भी अच्छा है, लेकिन इससे भी ज़्यादा दिलचस्प इसका workflow है, खासकर वह हिस्सा जहाँ k8s के बारे में सिर्फ़ “यह सही लग रहा है” मान लेने के बजाय उसके behavior को test किया जाता है। सोचता हूँ कि अभी कितनी teams AI द्वारा लिखे गए code पर इस स्तर की verification करती हैं, और हो सकता है अगले कुछ वर्षों में हम सब इसी दिशा में जाएँ
    • यह सचमुच एक विशेष मामला है जहाँ implement करने के लिए एक spec मौजूद है
      दुर्भाग्य से हर coding task को ऐसा मौका नहीं मिलता
  • Nate Abele ने पिछले साल Carolina Code Conference में इसी विषय पर talk दी थी
    https://youtu.be/t7L2iROVaRg?is=xoV4aiCXcYMVvVDL
  • यह वाकई काफ़ी शानदार है
    अतिरिक्त complexity या performance loss के लिए कुछ हद तक justification चाहिए होगा, लेकिन कुछ use cases में इसका फ़ायदा पूरी तरह उसकी भरपाई करता दिखता है
  • kube complexity पर चुटकुले शुरू होने से पहले, यह दिलचस्प तर्क दिया जा सकता है कि kube जैसी चीज़ उतनी ही complex है जितनी उन कामों को करने के लिए ज़रूरी है जिनके लिए kube बनाया गया है
    यह Fred Brooks की essential complexity और accidental complexity की distinction जैसा लगता है
    बेशक, अगर आप ऐसे कामों के लिए kube इस्तेमाल करते हैं जिन्हें और सरल तरीके से किया जा सकता है, तो kube जल्दी ही accidental complexity बन जाता है
    1. मुझे नहीं लगता कि यह सच में browser में containers चला रहा है। लगता है कि हर service के लिए custom connector चाहिए, और उससे भी ज़्यादा महत्वपूर्ण बात…
    2. …क्या renderer भी नहीं चाहिए? नहीं तो “browser में port किया गया” का मतलब क्या है, समझ नहीं आता
      तुलना के लिए, अगर कोई कहे कि उसने DOOM को browser में port किया है, तो उसका मतलब होगा कि अब आप उसे browser में खेल सकते हैं। लेकिन tab में दिख रहे databases को आप सच में browser के भीतर चला तो नहीं सकते, है ना?
      अगर आप ruby2d चला दें, तो यह नहीं कहा जा सकता कि अचानक client-side Ruby support मिल गया। उसे browser tab में सच में चलाने के लिए बहुत सारा custom काम करना पड़ता है
      दूसरी तरफ़, सामान्य backend container services को सच में इधर-उधर ले जाकर लगभग कहीं भी चलाया जा सकता है
      इसलिए मैं मुद्दा ठीक से समझ नहीं पा रहा, और अगर मैं ग़लत हूँ तो सुधार दें। यह खुद किए गए दावे से भी मेल नहीं खाता लगता
    • वे बातें title में नहीं, लेकिन article में covered हैं
      यह असली container images नहीं चला रहा। शायद इसे “simulated Kubernetes” कहना ज़्यादा सही होगा
      जो port किया गया है, वह control plane है। scheduler, kube-proxy, deployment controller वगैरह को असली Go source से लाया गया है, और वही client API इस्तेमाल करके k3s के साथ behavior parity test की जाती है। “Rendering” एक demo app है जो Pod के बीच requests को बिंदुओं की मूवमेंट के रूप में visualize करती है
    • “Webernetes का उद्देश्य interactive Kubernetes content बनाना है”
  • demo अच्छा है। इसका इस्तेमाल कहाँ किया जा सकता है?
  • इसी से जुड़ी बात, मैंने कुछ दिन पहले मज़े के लिए इसे vibe coding से बनाया था: https://imjasonh.github.io/kubescheduler-the-game/
    मज़ेदार था
    • यह game बिल्कुल मेरी पसंद का है