HN’de Tanıtıldı: Glasskube – Helm’e Alternatif Açık Kaynak Kubernetes Paket Yöneticisi

 (github.com/glasskube)
3 puan yazan GN⁺ 2024-06-27 | 1 yorum | WhatsApp'ta paylaş
  • Glasskube, Kubernetes için açık kaynaklı bir paket yöneticisi olarak tanıtılıyor; paketleri dağıtmayı, güncellemeyi ve yapılandırmayı Helm veya Kustomize gibi araçlara göre 20 kat daha hızlı hale getirdiği belirtiliyor
  • Kullanıcılar paketleri Glasskube UI, CLI veya GitOps yöntemiyle dağıtabiliyor; Homebrew ve npm’in sadeliğinden ilham almış
  • Başlıca özellikleri arasında Helm deposu aramadan UI üzerinden paket kurulumu, tip güvenli yapılandırma girdileri, paketler arası değer enjeksiyonu, bağımlılık farkındalığıyla kurulum ve önceden test edilmiş güvenli güncellemeler yer alıyor
  • Tüm Glasskube paketleri özel kaynaklar olarak yönetiliyor ve GitOps ile ele alınabiliyor; birden fazla depo ve private package dağıtımı da destekleniyor
  • Şu anda Kubernetes Dashboard, cert-manager, Ingress-NGINX Controller, Kube Prometheus Stack, Cloud Native PG gibi paketleri destekliyor; beta sürüm Homebrew ile kurulabiliyor

Glasskube’un çözmeyi hedeflediği Kubernetes paket yönetimi sorunu

  • Glasskube, Kubernetes için açık kaynaklı bir paket yöneticisidir
  • Kubernetes’te paket dağıtma, güncelleme ve yapılandırma işlerini Helm veya Kustomize gibi araçlara göre 20 kat daha hızlı hale getirdiği belirtiliyor
  • Homebrew ve npm’in sadeliğinden ilham almış; kullanıcılar aşağıdaki yöntemlerden birini seçebiliyor
    • Glasskube UI
    • Glasskube CLI
    • GitOps üzerinden doğrudan paket dağıtımı
  • Geliştirilme arka planında, Kubernetes ekosisteminde 5 yılı aşkın süre çalışırken paket yönetimi, yapılandırma ve dağıtım konularında sürekli zorluklar yaşanması var
  • Önceki iş akışlarında, anlaşılması zor komutlar ve kavramlar için şablon oluşturmak ve dokümantasyon yazmak çok zaman alıyordu
  • Homebrew, apt, dnf gibi araçların kullanımının kolay ve daha az sorunlu olması, Glasskube geliştirilirken karşılaştırma noktası oldu

Kurulum ve yapılandırma akışı

  • Beta sürüm Homebrew ile kurulabiliyor
brew install glasskube/tap/glasskube
  • Diğer kurulum seçenekleri installation guide içinde yer alıyor
  • CLI kurulduktan sonra, cluster için gerekli bileşenleri kurmak üzere aşağıdaki komut çalıştırılıyor
glasskube bootstrap
  • Cluster bootstrap işlemi tamamlandıktan sonra paket yöneticisi UI’ı başlatılabiliyor
glasskube serve
  • Bu komut varsayılan tarayıcıda http://localhost:8580 adresini açıyor; kullanıcılar mevcut paketleri keşfedip kurabiliyor

UI, yapılandırma ve bağımlılık yönetimi özellikleri

  • Glasskube UI, tüm paketleri tek bir yerde sunarak kullanıcıların Helm depolarını ayrıca aramadan cluster’a paket kurabilmesini sağlıyor
  • Paket yapılandırması, UI veya etkileşimli CLI soru formu üzerinden tip güvenli girdilerle oluşturulabiliyor
    • Diğer paketlerden, ConfigMap’lerden ve Secret’lardan kolayca değer enjekte edilebiliyor
    • Tip bilgisi olmayan ve dokümante edilmemiş values.yaml dosyalarını kullanmayan bir yaklaşım öneriliyor
  • Bağımlılık yönetimi, Glasskube paketlerinin birçok farklı paket tarafından kullanılabilmesini ve referans alınabilmesini sağlayacak şekilde işliyor
    • Bağımlı paketler doğru namespace’e kuruluyor
    • README bunu “umbrella chart en başından beri böyle çalışmalıydı” şeklinde ifade ediyor

Güncellemeler, GitOps ve depo desteği

  • Paket güncellemeleri için istenen sürüme yönelik pending update önceden görülebiliyor ve tek tıklamayla ya da CLI komutuyla uygulanabiliyor
  • Tüm güncellemeler Glasskube test paketiyle önceden test ediliyor
  • Paketlere yönelik geri bildirim ve yorumlar GitHub discussions üzerinden veya Glasskube UI içinde bırakılabiliyor
  • GitOps entegrasyonu, tüm Glasskube paketlerinin özel kaynaklar olarak yönetilmesi yaklaşımına dayanıyor
  • Renovate entegrasyonu da devam ediyor; ilgili issue renovatebot/renovate#29322 adresinde yer alıyor
  • Birden fazla depo ve private package kullanılabiliyor
    • Şirket içi servis paketlerini dağıtmak için kullanılabiliyor
    • Geliştiricilerin güncel durumdaki şirket içi servisleri kolayca yapılandırmasını sağlayan bir senaryo sunuyor

Paket kurulum mimarisi

  • glasskube install [package] akışında UI veya CLI, Client aracılığıyla paket deposunu ve Kubernetes API’yi birlikte kullanan bir yapı izliyor
  • UI, yerel sunucu http://localhost:8580 üzerinden Client’a bağlanıyor
  • CLI, cobra CLI üzerinden Client’a bağlanıyor
  • Client önce paket doğrulaması için Package Repo’yu kontrol ediyor
  • Doğrulamadan sonra Kubernetes API’de Package özel kaynağı oluşturuyor
  • Cluster içinde PackageController ve PackageInfoController reconcile işlemini gerçekleştiriyor
    • PackageController, Package kaynağını reconcile ediyor ve gerekirse PackageInfo oluşturuyor
    • PackageInfoController, paket deposundaki paket manifest’ini güncelliyor
    • Güncellenen manifest PackageInfo içine yansıtılıyor
    • Ardından PackageController paketi Kubernetes’e dağıtıyor
  • Kubernetes paket durumunu Client’a geri döndürüyor

Desteklenen paketler ve proje bilgileri

İlgili okumalar

1 yorum

 
GN⁺ 2024-06-27
Hacker News yorumları

  • Doğru yönde atılmış bir adım olabilir, ancak şu anda Kubernetes paket yönetimindeki en büyük sorun paket yöneticisiyle çözülmesi zor görünüyor
    Günlük kullanımda en zorlayıcı şey, iç içe YAML katmanlarının üst üste binmesi ve sonucun öngörülemez olması
    Örneğin ArgoCD ApplicationSet birden çok Application oluşturuyor; bu Application’lar Helm chart’larını render ediyor ve bu chart’ların içinde Strimzi, Grafana, Vector gibi rastgele operatörlerin kullandığı CRD’ler yer alıyor
    YAML’ın sözdizimi zayıf ve template render etme için bir standart da yok; bu yüzden üst düzeyde bir değişiklik yaptığınızda Kubernetes API’ye gerçekte hangi YAML’ın enjekte edileceğini bilmek neredeyse imkânsız
    Sonuçta bu her ay deneme yanılmaya, pahalı blue-green dağıtımlara ve yüzlerce dakikalık hata ayıklamaya dönüşüyor

    • DevOps çevresindeki araçlarda YAML’ın yaygın biçimde benimsenmesi bir hataydı
      Doğru yönün düzgün bir programlama dili desteği olduğunu düşünüyorum
      İdeal olarak Turing-complete olmayan ve sonlanması garanti edilen statik tip sistemi gerekir; tipli Starlark benzeri bir biçim uygun görünüyor
    • Render edilmiş manifest pattern’ını denediniz mi merak ediyorum: https://akuity.io/blog/the-rendered-manifests-pattern/
    • Bu, Glasskube Cloud’un (https://glasskube.cloud/) odaklanmak istediği sorun
      glasskube[bot]’un GitOps pull request’lerine bağlı tüm cluster’larda gerçekten değişecek kaynakların tam diff’ini yorum olarak eklemesini hedefliyoruz
      Bu diff, cluster içinde çalışan controller tarafından oluşturuluyor
      codecov analizine benziyor, ama kaynak değişikliklerine özel diye düşünebilirsiniz
    • Çözüm Kubernetes kullanmamak

  • Paket yönetimine ilginç bir yaklaşım gibi görünüyor ve Homebrew tarzı cluster’lar için fena görünmüyor
    Yine de şahsen, depoda tutarlılığı korumak adına helmfile + Renovate + pipeline kombinasyonunu tercih ederim
    Örneğin update all düğmesi, anlamlı bir cluster’da oldukça ürkütücü hissettiriyor
    Kişisel projeler gibi yerlerde hâlâ harika bir araç
    Paket controller’ı eski Helm’deki Tiller’a çok benziyor; bu da birçok şirkette büyük bir güvenlik sorunu olmuş, Helm 3’te kaldırılıp configmap tabanlı istemci tarafı işlemeye geçilmişti. Bu projenin o sorunu nasıl aşacağını merak ediyorum

    • Glasskube paketleri, tüm paketler CR (custom resource) olduğu için GitOps deposuna konabilir
      CLI’da --dry-run ve --output yaml bayraklarıyla yapılandırıp Git’e koymak da mümkün
      Ayrıca Renovate ile paket güncellemelerini destekleyen pull request’ler üzerinde çalışıyoruz: https://github.com/renovatebot/renovate/issues/29322
      Helm 3 artık istemci taraflı bir araç olduğu için kendi başına RBAC’i zorunlu kılamıyor
      OLM, operatör düzeyinde yetkiler sağlamak için Operator Groups’u (https://olm.operatorframework.io/docs/advanced-tasks/operato...) devreye aldı
      Glasskube paketlerine de benzer bir şey getirilebilir; Glasskube’un kendisi hâlâ oldukça güçlü yetkilere ihtiyaç duyacak olsa da paket kapsamı sınırlandırılabilir ve ayrıntılı yetkiler eklenebilir

  • Geleneksel olarak uygulama paketleri, kurulum öncesi/sonrası adımları içeren sürümü sabitlenmiş değişmez ikililerdir; belirli bir platform ve belirli bağımlılıklar düşünülerek derlenir ve kurulum sırasında yapılandırma son derece sınırlıdır.
    Paketlerin iyi çalışmasının nedeni, çok belirli bir ortamı hedefleyecek şekilde tasarlanmaları ve kurulum sırasında değiştirilebilecek kısımların en aza indirilmesidir.
    Buna rağmen işletim sistemi paketleri, o dar koşullar içinde bile sürekli olarak muazzam test, geliştirme ve yama çalışması gerektirir.
    Şu anda kurduğunuz paketin kolay görünmesi, mevcut platform, mevcut bileşenler ve sürümler için yüzlerce saat harcanmış olabileceği içindir.
    Kubernetes’teki “paket” ise aslında bir paket değil; kurulacak ve yapılandırılacak bileşenlere ilişkin bir talimat demetine daha yakındır ve çoğu zaman birden fazla ayrı uygulama demetini içerir.
    Bu fark iki şekilde ortaya çıkar: K8s “paketi”nin tanımı çok gevşektir ve bu yüzden değişkenliği yüksektir; her türden insan tarafından her türden yöntemle oluşturulur ve kurulacağı sistemin durumu hakkında her türlü varsayımda bulunur.
    Bir Kubernetes “paketi”nin çalışması için birden fazla bağımlılık ve yapılandırma katmanının uyumlu olması gerekir.
    K8s API sürümü, K8s bileşenlerinin kurulma ve çalıştırılma biçimi, ACL’ler, çakışabilecek mevcut bileşenlerin olmaması, paketin kurduğu bileşenlerin ve container sürümlerinin sabitlenmesi ve küme içindeki diğer şeylerle uyumluluğu, kullanıcı yapılandırması; bunların hepsinin uyumlu olması gerekir.
    Yükseltmeler de kararlı sürüm ağacı ya da rolling release kavramı olmadığı için benzer şekilde karmaşıktır; işletim sistemine rastgele .deb, .rpm, .dmg dosyaları kurup iyi gitmesini ummaya benzer.
    Bugün tüm bunları yapan bir şey yok.
    Kubernetes paketlemeyi platforma özel ikili paketleme kadar sorunsuz hâle getirmek için bakımcı topluluğunun tamamı ve Homebrew benzeri bir rolling release yaklaşımı ya da kararlı sürüm release branch’leri gerekir.
    Sonuçta ArtifactHub veya Homebrew gibi bir projenin tüm paketleri tek bir yöntemle yönetmesi gerekir; bu büyük bir iş ve hiç kârlı görünmüyor.

    • Glasskube de Homebrew’e benzer şekilde, paketleri “core” Glasskube paket deposunun (https://github.com/glasskube/packages) içine koyarak başladı.
      Yapı, tüm güncellemeleri merkezî olarak depolayıp CI/CD workflow’larıyla test ederek kullanıcıların test edilmiş, sorunsuz yükseltmelerden yararlanmasını sağlamayı amaçlıyor.
      Kullanıcılar kendi özel depolarını ve paketlerini de barındırabilir, ancak varsayılan olarak görüş sahibi bir paket kümesini doğrudan sunmak istiyoruz.
      Farklı Kubernetes sürümlerine veya ortamlara göre derleme yapmayı da şimdiden düşünüyoruz; daha fazla yapılandırmayı build aşamasına katmak için bir gün buna ihtiyaç olacak.

  • K8s paket yöneticisinin brew veya apt kadar basitleşip basitleşemeyeceğinden pek emin değilim.
    Özellikle hedef ortamların her birinde değerlerin farklı olması ve neredeyse her kullanıcının kendine özgü bir “kar tanesi” ortamına sahip olması büyük etken.
    Bu değerleri ayarlamak için REPL tarzı prompt’lar veya web UI kullanmak bana cazip gelmiyor.
    Temel acı noktası hâlâ çözülmedi: Helm chart yazmak eziyetli, ortama özel değerleri yönetmek gerekiyor ve chart’lar arasında değerleri birbirine bağlamamayı sağlamasını isterdim.

    • Gerçek sahada kar tanesi kümeler çok fazla ve yakın zamanda katıldığım bulut yerel konferansta da sıcak bir konuydu.
      Platform ekipleri, ekipler ve kümeler genelinde Kubernetes yapılandırmalarını daha standart hâle getirmek için dahili geliştirici platformları kuruyor ve geliştiricilerin yalnızca küçük değişiklikler yapabilmesini sağlamaya çalışıyor.
      Deneyimlerime göre bu tür birbirinden farklı yapılandırmaların azaltılması gerekiyor; Glasskube’u en başta yapma nedenimiz de buydu.
      Helm chart yazmanın eziyetli olduğuna %100 katılıyorum ve ileride bunu değiştirmeye çalışacağız.
      Glasskube paketleri hâlâ yapılandırılabilir, ancak anlamlı varsayılanlar sunar.
      Diğer paketlerin yapılandırma değerlerine Glasskube içinden kolayca referans verilebilir; böylece aynı değerleri birden çok kez sağlamanız gerekmez.

  • Çok sayıda Kubernetes operatörü geliştiriyorum ve Helm ile OLM sorunlarıyla sık sık uğraşıyorum.
    Belgelerde “CRD yükseltmelerini Glasskube işler, böylece CR’ler ve operatörler birbirinden sapmaz” deniyor; ancak belgelerde “CRD” aratınca somut bir sonuç çıkmıyor.
    Bu, şu anda Helm’de yaşadığımız en büyük acı noktalarından biri; planı paylaşabilir misiniz merak ediyorum.
    [1] <https://stackable.tech/en/>
    [2] <https://www.youtube.com/watch?v=Q8OSYOgBdCc>

    • Herkese açık Glasskube deposundaki paketler, CRD değişiklikleri uygulanacak şekilde yapılandırılmıştır.
      Manifest veya helm-controller üzerinden işlenir.
      Belgeler güncellenecek.

  • Kubernetes’in aşırı basit operatör modeli nedeniyle temelden kısıtlandığını düşünüyorum.
    Genel fikir hoşuma gidiyor, ancak tüm modeli “mevcut durum, istenen durum, sonraki eylem”e indirgemek fiilen imkânsız.
    Sonunda tüm workflow sonraki eylem mantığının içine giriyor; aynı sistem durumuna bakan çok fazla operatör olduğu için birden fazla bileşenin nasıl etkileşeceğini bilmek zorlaşıyor.
    Helm’in sorunu, bu daha büyük sorunun bir alt örneği.
    Benzetme yapmak gerekirse, frontend programlamanın DOM’da yaşadığı sorunla aynı.
    React gibi bir sanal DOM/reducer paradigması getirmek bu tür sorunların çözümüne büyük ölçüde yardımcı olurdu.

    • “Mevcut durum, istenen durum, sonraki eylem” temelde genel kontrol teorisinin çalışma biçimidir.
      Durum, hedef ve hedefe doğru yaşanan sapmalar vardır; güçlü ve esnek bir araç istiyorsanız bu soyutlama seviyesinin doğru olduğunu düşünüyorum.
      Sorun, makinenin fiziksel özellikleri ve yerleşiminin çok büyük fark yaratması; bunları anlamlı biçimde sanallaştırmanın veya simüle etmenin maliyetinin aşırı yüksek olması.
      Bu yüzden bunun yerine yapılandırma durumunun fiziksel yapının bir alt kümesi üzerinde çalışıp çalışmadığını doğrularız.
      dev, staging, prod ortamları bulundurmak; renkli dağıtım, kanarya analizi, kısmi rollout vb. kullanmak bu yaklaşımdır.

  • K8s kullanmak için böyle bir araca ihtiyaç duyuyorsanız muhtemelen başka bir çözüm kullanmanız daha iyi olur.
    Kubernetes, arka plan bilgisi olmadan kullanılsın diye yapılmadı ve zordur.
    Tam kapsamlı bir PaaS oluşturmadığınız sürece bu karmaşıklıktan kaçmak zordur.

  • Bu aracın pazarlama yönünün yanlış olduğunu düşünüyorum
    Bunun Helm ile pek ilgisi yok
    Benim için Helm, çoğunlukla bir paket yöneticisi değil, şablon dili; K8s kümelerine kubeapps, Helm CLI ve ArgoCD üzerinden yapılandırıp kurma biçimi
    Bu yaklaşım iyi bir IaC paradigmasını da bozuyor
    Çünkü ArgoCD’yi bootstrap ettikten sonra yalnızca Git deposuna referans veren bir yapı daha iyi
    Demo, form desteği gibi şablon özelliklerinin nasıl kullanılacağını göstermiyor; onun dışındaki şeyleri gösteriyor
    Helm’de bir sorun olduğu hissi hâlâ var, bu yüzden açıkçası aracın kendisini beğeniyorum; ama mevcut yaklaşımla başarısız olacak gibi görünüyor
    Büyük şirketlerin bu araca ihtiyacı yok, bu yüzden yeterli benimsenme elde etmek zor olacak
    Kubeapps de Helm de iyi çalışıyor; Helm’in yerini alacağını söylese bile muhtemelen Helm desteğini uzun süre tutacaktır
    Helm’in sorunu, chart’lar büyüdükçe karmaşıklaşması
    Her şeyin fiilen tek bir templates klasörüne girdiği yapı dağınık, YAML şablonlar için uygun değil ve values.yaml aşırı büyüyor

    • Demo daha çok son kullanıcıya odaklanıyor
      Yapılandırma seçenekleriyle ilgili ayrıntıları paket yapılandırma belgelerinde görebilirsiniz: https://glasskube.dev/docs/design/package-config/
    • Kibirli ya da küçümseyici görünmek istemem ama Helm’in çoğunlukla bir paket yöneticisi olmadığını düşünüyorsanız, K8s’e dağıtılmış altyapıyla pek fazla uğraşmamışsınız demektir

  • Helm’den daha hızlı olması satış argümanı olarak pek çekici değil
    Helm’in sorununun hız olduğunu hiç hissetmedim

  • İlginç görünüyor
    Mevcut araç olan ArgoCD ile nasıl örtüştüğünü ya da nasıl karşılaştırıldığını kısaca açıklarsanız anlamama yardımcı olur
    Videoyu izledim ve kurduğu araçlardan biri Argo’ydu; yani belli ki farklı bir nişi dolduruyor, ama bunun ne olduğunu hâlâ tam bilmiyorum

    • ArgoCD, GitOps deposunun durumunu kümeyle senkronize eden, kurulu kaynakları görselleştiren ve olası hataları gösteren harika bir araç
      Geliştiricilerin kümeye erişmeden şirketin temel uygulamalarının durumuna bakması için sıkça kullanılır
      Glasskube, temel uygulamaların bağımlı olduğu paketlere odaklanır
      Altyapı bileşenlerinin yaşam döngüsünü yönetir, güncellemeleri test eder ve yükseltme yolları sunar
      Glasskube paketlerini GitOps deposuna koyup ArgoCD ile kümeye senkronize edebilirsiniz; geri kalanını PackageController halleder