Kubernetes’i tarayıcıya port etti

 (ngrok.com)
1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • webernetes, Kubernetes’in bir bölümünü TypeScript’e taşıyıp tarayıcı içinde bir küme çalıştıran bir proje; 2 ayda 552 commit, 629 dosya ve neredeyse 100 bin satırlık ölçekte oluşturuldu
  • WebAssembly ile Kubernetes’i olduğu gibi derlemek yerine, kubelet’in bir kısmı, çeşitli controller’lar, tarayıcı tabanlı CNI ve container runtime ile kümeyi yönetmek için bir API yeniden uygulandı
  • Gerçek image registry’lerinden image çekmek yerine image’lar TypeScript API ile tanımlanıyor; hedef prodüksiyon dağıtımı değil, etkileşimli Kubernetes içeriği üretmek
  • Kodun büyük kısmı LLM tarafından yazıldı ancak her satır insan tarafından incelendi; doğrulama için k3s ile aynı testleri çalıştıran 204 entegrasyon testi ve Kubernetes Go kod tabanından taşınan 1.855 birim testi kullanıldı
  • LLM, port etme sırasında kısaltma, keyfi helper üretme ve test atlama hatalarını tekrar tekrar yaptı; hızlı kod üretiminin avantajını elde etmek için inceleme ve testin birlikte uygulanması gerekiyor

webernetes’in tarayıcıda çalıştırdığı şey

  • webernetes, Kubernetes’i kısmen TypeScript’e port ederek tarayıcıda bir küme çalıştırmayı mümkün kılan bir proje
  • Demo kümesi tamamen tarayıcı içinde çalışıyor ve gerçek bir Kubernetes kümesinin yaptığı işlerin önemli bir kısmını yerine getiriyor

    • Pod yaşam döngüsü

      • Küme DNS’i ve ağ iletişimi
      • Container garbage collection
      • IP ataması
      • Deployment ve ReplicaSet takibi
      • Demodaki mavi noktalar, Pod’ların birbirine istek gönderdiğini gösteriyor

WebAssembly derlemesi yerine seçilen kısmi port yaklaşımı

  • Bu, Kubernetes’in WebAssembly’ye derlenmiş hali değil
  • Basit bir Go hello, world! programı bile WebAssembly’ye derlendiğinde gzip ile yaklaşık 540KiB oluyor; webernetes ise gzip ile yaklaşık 140KiB
  • Kubernetes’in tamamı WebAssembly’ye derlense megabaytlarca veri aktarımı gerekebilir ve tarayıcıda kullanılamayan sistem düzeyi API çağrıları nedeniyle derleme zamanında hatalar da oluşabilir
  • webernetes şu bileşenlerden oluşuyor
    • Pod çalıştırma ve probe’lar için gerekli Kubernetes kubelet ikilisinin kısmi portu
    • Pod scheduler, namespace controller, kube-proxy, deployment controller gibi çeşitli Kubernetes controller’larının portları
    • Pod’lar arası iletişim için tarayıcı tabanlı container network interface (CNI)
    • kubelet’in container runtime interface (CRI) üzerinden container çalıştırmasını sağlayan tarayıcı tabanlı bir container runtime
    • manifest uygulama ve kaynak watch etme gibi işler için webernetes cluster API’si

Image tanımları ve API kullanım biçimi

  • webernetes, küçük kalmak için Docker Hub gibi registry’lerden gerçek image’lar çekmiyor
  • Bunun yerine tarayıcı tabanlı bir registry’ye sahip ve image’lar TypeScript API ile tanımlanıyor
  • Örnek image HelloWorld, w8s.BaseImage sınıfından türetiliyor ve exec içinde 8080 portuna gelen HTTP isteklerine "Hello, world!" döndürüyor
  • Kümeyi kullanma akışı şöyle
    • new w8s.Cluster() ile küme oluşturulur
    • cluster.registerImage(HelloWorld) ile image kaydedilir
    • cluster.apply() ile apps/v1 Deployment manifest’i uygulanır
    • cluster.api.corev1.listNamespacedPod() ile Pod listesi alınır
    • cluster.informer("pods", ...) ile Pod değişiklikleri izlenir
    • cluster.on("request"), cluster.on("response") ile Pod’lar arası istek ve yanıt olayları gözlemlenir
    • cluster.fetch() ile küme ağı üzerinden Pod IP’sine HTTP isteği gönderilebilir
  • Daha fazla örnek webernetes repository examples içinde bulunuyor

Kullanım amacı ve mevcut sınırlamalar

  • webernetes’in amacı etkileşimli Kubernetes içeriği üretmek
  • Prodüksiyona hazır bir Kubernetes dağıtımı değil ve gerçek image’ları çalıştırması da gerekmiyor
  • İçerik üreticisinin anlatmak istediği Kubernetes kavramını göstermek için belirli workload’ları kurabilmesi yeterli
  • Şu anda desteklenmeyen özellikler arasında şunlar var
    • ConfigMaps
    • Secrets
    • Pod resources
    • persistent volumes
    • Henüz ihtiyaç duyulmayan çeşitli Kubernetes özellikleri
  • Gelecekte içerik üretim sürecinde ihtiyaç oldukça daha fazla Kubernetes özelliği uygulanması planlanıyor

LLM ile yapıldı ama tamamen ona bırakılmadı

  • webernetes kodunun neredeyse tamamı LLM tarafından yazıldı
  • Projenin güvenilirliği için iki şey birlikte yapıldı
    • Tüm kod satırları tek tek incelendi
    • webernetes’in gerçek bir küme gibi davrandığını doğrulayan yüzlerce test yazıldı
  • Manuel inceleme sayesinde kodun büyük bölümünün Kubernetes Go kod tabanıyla satır satır aynı olduğuna dair güven oluştu
  • Testler ise bu sözcüksel benzerliğin gerçekten davranış eşdeğerliğine dönüştüğünü doğrulama görevini gördü
  • İnceleme sonrasında kalan hatalar proje yazarının sorumluluğunda; sorun bulanlardan issue açmaları isteniyor

Port edilen kodun neden incelemeye ihtiyaç duyduğu

  • LLM ile C derleyicisi yazma veya Bun’ı Zig’den Rust’a port etme örneklerinde doğruluğu otomatik doğrulamanın yolları vardı
    • Anthropic’in karşılaştırabileceği mevcut C derleyicileri vardı
    • Bun tarafında, manuel inceleme olmadan 1 milyondan fazla satırlık yeni Rust kodunu merge edecek kadar güvenilen büyük bir test paketi bulunuyordu
  • webernetes’te böyle bir temel yoktu
    • Test paketi gerekiyorsa onu da sıfırdan yazmak gerekiyordu
    • Gerçek Kubernetes ile kıyas yapmak için kıyaslama yöntemini de ayrıca kurmak gerekiyordu
  • webernetes kodunun büyük bölümü Kubernetes Go kod tabanından port edildi ve elde yazmaktan hızlı olacağı düşünüldüğü için LLM kullanıldı
  • Port etme sürecinde LLM tekrar tekrar hata yaptı
    • Kısaltma: Kubernetes’in LRU cache, expiring cache, FIFO cache, transforming cache gibi yapıları düzgün uygulanmak yerine Map ile değiştirilip yanlış davranış üretilebiliyordu
    • Aşırı düzenleme: Kaynak Go kodunda olmayan helper fonksiyonları üreterek incelemeyi zorlaştırabiliyor veya ince farklar yaratabiliyordu
    • Eksiltme: Go’daki table test’leri port ederken test case’leri keyfi biçimde atlaması sık görülen bir durumdu
  • LLM port çıktısına güvenmek için sonuçların incelenmesi gerekiyor; proje yazarı da modelin kendi kullanabileceği kestirmeleri bilmediğini düşünüyor

Gerçek kümeyle karşılaştırmalı testler

  • Kod, kaynakla yan yana benzer görünse de Go ve JavaScript runtime’ları farklı olduğu için davranış da farklı olabilir
  • webernetes içinde JavaScript sürümü channels, mutexes, Go’nun select ifadesi ve diğer Go tarzı davranışlara da ihtiyaç vardı
  • Aynı test kodu hem webernetes hem de k3s kümesi üzerinde çalıştırılarak davranışlar karşılaştırıldı
  • API uyumluluğu hedefi olarak TypeScript tiplerine sahip resmi JavaScript Kubernetes istemcisi kubernetes-client/javascript seçildi
  • Test harness’i, kubernetes.describe(..) üzerinden çalışma ortamını değiştiriyor
    • pnpm test:node, Node ortamında k3s hedeflenerek test çalıştırıyor
    • pnpm test:browser, headless browser içinde webernetes hedeflenerek test çalıştırıyor
  • Entegrasyon testleri yalnızca port edilmiş kodu değil, özel tarayıcı tabanlı container runtime ve cluster network bileşenlerinin de gerçek kümeyle uyumlu çalışıp çalışmadığını doğruluyor
  • Bir hata bulunduğunda önce k3s’te geçen ama webernetes’te başarısız olan bir test yazılıyor, ardından bu geri bildirim döngüsüyle LLM yardımı kullanılarak neden anlaşılıyor ve düzeltiliyor
  • Yazının yazıldığı sırada webernetes içinde 204 entegrasyon testi ve 1.855 birim testi bulunuyor

İnceleme ve testin birlikte kullanılmasının nedeni

  • LLM tarafından üretilen kod da, insanın yazdığı bir PR gibi, iyi testlere ve iyi koda ihtiyaç duyuyor
  • 2026’daki fark şu: insan bir ekip arkadaşından bir ölçüde iyi iş beklenebilirken, LLM’den iyi iş çıkmayacağını varsaymak daha güvenli
  • Test kodu bile incelenmezse LLM’in hangi başarı ölçütüne göre çalıştığını bilmek zorlaşıyor
  • Tüm kod incelense bile test yoksa, insanın bütün olasılıkları zihninde çıkarım yapabileceğine güvenmek zor
  • LLM yorulmadan ve hızlı yazdığı için, insanın aklına gelmeyen edge case’leri önermesini sağlamak ve mantıklıysa bunlar için test yazdırmak faydalı
  • İnsan zevki ve anlayışı ile LLM’in hızlı yazma becerisini birleştiren bu yaklaşımın, yazarın 2012’de başlayan kariyerinden beri gördüğü en büyük değişim olduğu düşünülüyor

Proje ölçeği ve token kullanımı

  • İlk commit, 21 Nisan’da mevcut webernetes repository içine girdi
  • İlk çalışmaların bir kısmı bu blog sitesinin arkasındaki depo dalında yapıldığı için grafikler tüm gerçeği birebir yansıtmıyor
  • Kod satırı grafiği, 15 Haziran haftası itibarıyla 126.642 satır gösteriyor
  • Başta sözü edilen yaklaşık 100 bin satır, TypeScript dışı kodlar, yorumlar ve demo app hariç tutularak hesaplandı
  • Haftalık toplam satır sayısı şöyle arttı
    • 20 Nisan haftası: 11.640 satır
    • 27 Nisan haftası: 20.660 satır
    • 4 Mayıs haftası: 25.048 satır
    • 11 Mayıs haftası: 30.417 satır
    • 18 Mayıs haftası: 42.301 satır
    • 25 Mayıs haftası: 54.155 satır
    • 1 Haziran haftası: 79.704 satır
    • 8 Haziran haftası: 98.532 satır
    • 15 Haziran haftası: 126.642 satır
  • Codex ve Claude oturumlarında token kullanımı içinde cached input token miktarı, diğer token türlerinden çok daha büyüktü; özellikle uzun context window sık sık dolduruldukça bu daha da belirgin hale geldi
  • 15 Haziran haftasında 104.155.857 uncached input token, 2.196.467.968 cached input token ve 6.420.826 output token kullanıldı

Son haftadaki sıçrama ve maliyet

  • Son haftada demo app içine Deployments desteği eklenmeye çalışılırken iş beklenenden daha büyük hale geldi
  • LLM’in ilk port denemesi, gerekli bileşenlerin birçok özelliğini eksik bıraktı
  • Sonrasında birden fazla ajan kullanılarak bağımlılık zinciri belirlendi, her bileşen daha fazla alt ajanla port edildi ve başka alt ajanlarca inceleme yapıldı
  • Bu yöntem, manuel çalışmadan daha hızlı sonuç verdi ama token verimliliği çok kötüydü ve sonunda yine manuel inceleme gerekti
  • API karşılığı LLM token maliyeti haftalara göre arttı ve 15 Haziran haftasında $1,811.64 seviyesine ulaştı
  • Tüm proje boyunca, yazarın zamanı son ana kadar en pahalı kalem olmaya devam etti

Kapanış kaynakları ve katılım çağrısı

  • Yapım sürecini kaydeden bir video serisi de var
  • Videolarda ilk dönemdeki yanlış iyimserlik ile sesli kontrol ve göz takibi sayesinde büyük ölçüde hands-free çalışma biçimi de görülebiliyor
  • Projeyi deneyip issues açmaları ya da bir şey yaptılarsa veya bir yerde takıldılarsa s.rose@ngrok.com adresine ulaşmaları isteniyor

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Hacker News yorumları
  • Öğretmeyi ve bir şeyler yapmayı seven biri olarak, bunun epey faydalı olabileceğini düşünüyorum
    Örneğin bunu yaptım: https://kubernetes-made-simple.vercel.app/ ve şimdi buna ekleyebilirim
    • iPhone'da beklenen Pod sayısını değiştirince reconciliation simülatörü garip şekilde kontrolden çıkıyor
      Yine de site harika
    • Hepsini okudum ve içerik güzeldi
      Gateway kısmını biraz daha genişletip mümkünse CRD'lerden de bahsetmek iyi olurdu
    • Harika bir site
      Çoğu insanın k8s hakkında yanlış anlayıp öğrenmeyi gereksiz yere zorlaştırmasına neden olan şeylerden birini seçecek olsan bu ne olurdu?
  • Harika. Geçmişte Kubernetes eğitim içeriği hazırlamış biri olarak, bunun gibi bir şey yapma cazibesini açıkça görebiliyorum
    Hatırladığım kadarıyla önce Katacoda kullanıyorduk, sonra benzer başka bir platforma geçtik; her kullanıcı için belirli şekilde yapılandırılmış yeni bir instance'ı anında ayağa kaldırdığı için çok faydalıydı
    Ama bu şu an daha çok kavram veya mimari eğitimi için uygun görünüyor. Asıl eğlence, kubectl kullanmakta ustalaşmaya başlayınca başlıyor
    • Eski işyerimde olsaydı, control plane'in nasıl çalıştığını anlatan diyagramlar, performans düşüşü ve arıza modları, ayrıca k8s'e dağıtım için farklı mimari ya da yöntemlerin karşılaştırılması konusunda gerçekten çok iyi olurdu
    • Ne yazık ki Katacoda artık ücret duvarının arkasında. Neden böyle yaptıklarını tamamen anlıyorum; bu tür şeylerin bir maliyeti var
      Benzer diğer platformlar da masrafı karşılayacak kimse kalmadığı için ortadan kaybolmuş gibi görünüyor, ki bu üzücü
      Umarım bu bir alternatif olur. Gerçek dünyadan sapıp zamanla eskime riski var, ama özünde anlattıkları neredeyse her zaman geçerliliğini korur
  • Öncelikle gerçekten harika
    Bu, LLM destekli mühendisliğe bakmanın doğru yolu gibi geliyor. AI şaşırtıcı miktarda kod üretebilir ama asıl değer, inceleme disiplini ve etrafındaki testlerde yatıyor
    Kubernetes'i tarayıcıda ele alma yaklaşımı da güzel, ama daha da ilginç olan şey iş akışı; özellikle de “makul görünüyor” diye güvenmek yerine k8s üzerinde davranışı test etme kısmı. Halihazırda kaç ekibin AI'nın yazdığı kod için bu seviyede doğrulama yaptığını merak ediyorum; önümüzdeki birkaç yılda herkesin gideceği yön bu olabilir
    • Bu, kelimenin tam anlamıyla uygulanacak bir spesifikasyonun olduğu özel bir durum
      Ne yazık ki her kodlama işi böyle bir fırsata sahip değil
  • Nate Abele geçen yıl Carolina Code Conference'ta bu konuda bir sunum yapmıştı
    https://youtu.be/t7L2iROVaRg?is=xoV4aiCXcYMVvVDL
  • Gerçekten epey harika
    Ek karmaşıklık veya performans kaybı belli ölçüde gerekçelendirilmek zorunda olsa da, bazı kullanım durumlarında bunu fazlasıyla telafi edebilir gibi görünüyor
  • kube karmaşıklığıyla ilgili şakalar gelmeden şunu söyleyeyim: kube gibi bir şeyin, hedeflediği işleri yapmak için gereken düzeyde karmaşıklığa sahip olduğu yönünde ilginç bir argüman kurulabilir
    Bu, Fred Brooks'un özsel karmaşıklık ile tesadüfi karmaşıklık ayrımına benziyor
    Elbette daha basit yapılabilecek bir iş için kube kullanırsanız, kube hızla tesadüfi karmaşıklığa dönüşür
    1. Görünüşe göre aslında tarayıcıda container çalıştırmıyorlar. Tüm servisler için özel connector'lar gerekiyor gibi duruyor ve daha önemlisi…
    2. …bir renderer da gerekmiyor mu? Yoksa “tarayıcıya port edildi” tam olarak ne anlama geliyor, anlamadım
      Benzetme yaparsak, biri DOOM'u tarayıcıya port ettiyse bu artık onu tarayıcıda oynayabileceğiniz anlamına gelir. Ama sekmede gördüğünüz veritabanlarını gerçekten tarayıcıda çalıştırabiliyor değilsiniz, değil mi?
      ruby2d'yi ayağa kaldırınca bir anda istemci tarafında Ruby desteği geldiğini söyleyemezsiniz. Onu gerçekten tarayıcı sekmesinde çalıştırmak için her türlü özel çalışma gerekir
      Öte yandan tipik backend container servisleri gerçekten oradan oraya taşınıp hemen her yerde çalıştırılabilir
      O yüzden meselenin ne olduğunu pek anlayamadım; eğer yanılıyorsam lütfen düzeltin. İddia edilen şeyin kendisiyle de tam örtüşmüyor gibi görünüyor
    • Bu noktalar başlıkta yok ama yazının içinde ele alınıyor
      Gerçek container image'ları çalıştırmıyorlar. Buna “simüle edilmiş Kubernetes” demek belki daha doğru olur
      Port edilen şey control plane. Scheduler, kube-proxy, deployment controller gibi parçalar gerçek Go kaynak kodundan taşınmış ve k3s ile davranış eşleşmesini test etmek için aynı istemci API'si kullanılıyor. “Rendering” ise Pod'lar arasındaki istekleri hareket eden noktalar olarak görselleştiren demo uygulaması
    • “Webernetes, etkileşimli Kubernetes içeriği oluşturmak için tasarlanmıştır”
  • Demo harika. Bunu nerede kullanırdınız?
  • Bununla ilgili olarak birkaç gün önce eğlencesine bunu vibe coding ile yaptım: https://imjasonh.github.io/kubescheduler-the-game/
    Eğlenceliydi
    • Bu oyun tam benlik