Tayang di HN: Glasskube – pengelola paket Kubernetes open source alternatif Helm

 (github.com/glasskube)
3 poin oleh GN⁺ 2024-06-27 | 1 komentar | Bagikan ke WhatsApp
  • Glasskube diperkenalkan sebagai pengelola paket open source untuk Kubernetes yang diklaim membuat deployment, update, dan konfigurasi 20 kali lebih cepat dibanding alat seperti Helm atau Kustomize
  • Pengguna dapat men-deploy paket melalui UI Glasskube, CLI, atau pendekatan GitOps, dengan inspirasi dari kesederhanaan Homebrew dan npm
  • Fitur utamanya mencakup instalasi paket dari UI tanpa mencari repositori Helm, input konfigurasi yang type-safe, injeksi nilai antar paket, instalasi yang sadar dependensi, serta update aman yang telah diuji sebelumnya
  • Semua paket Glasskube dikelola sebagai custom resource dan bisa ditangani dengan GitOps, serta mendukung banyak repositori dan deployment private package
  • Saat ini mendukung Kubernetes Dashboard, cert-manager, Ingress-NGINX Controller, Kube Prometheus Stack, Cloud Native PG, dan lainnya; versi beta dapat diinstal lewat Homebrew

Masalah manajemen paket Kubernetes yang ingin diselesaikan Glasskube

  • Glasskube adalah pengelola paket open source untuk Kubernetes
  • Glasskube diperkenalkan sebagai alat yang membuat proses deploy, update, dan konfigurasi paket di Kubernetes 20 kali lebih cepat dibanding alat seperti Helm atau Kustomize
  • Terinspirasi dari kesederhanaan Homebrew dan npm, pengguna dapat memilih salah satu cara berikut
    • UI Glasskube
    • CLI Glasskube
    • deployment paket langsung melalui GitOps
  • Latar belakang pengembangannya berasal dari pengalaman bekerja lebih dari 5 tahun di ekosistem Kubernetes sambil terus menghadapi kesulitan dalam manajemen paket, konfigurasi, dan deployment
  • Dalam pekerjaan sebelumnya, banyak waktu terpakai untuk membuat template dan menulis dokumentasi demi menjelaskan perintah serta konsep yang sulit dipahami
  • Alat seperti Homebrew, apt, dan dnf dijadikan pembanding karena lebih mudah digunakan dan lebih sedikit menimbulkan masalah, yang kemudian menjadi acuan dalam pengembangan Glasskube

Alur instalasi dan konfigurasi

  • Versi beta dapat diinstal melalui Homebrew
brew install glasskube/tap/glasskube
  • Opsi instalasi lainnya tersedia di installation guide
  • Setelah CLI terpasang, jalankan perintah berikut untuk memasang komponen yang dibutuhkan di cluster
glasskube bootstrap
  • Setelah bootstrap cluster selesai, UI package manager dapat dijalankan
glasskube serve
  • Perintah ini akan membuka http://localhost:8580 di browser default, dan pengguna bisa menelusuri serta memasang paket yang tersedia

Fitur UI, konfigurasi, dan manajemen dependensi

  • UI Glasskube menyatukan semua paket di satu tempat, sehingga pengguna dapat memasang paket ke cluster tanpa harus mencari repositori Helm secara terpisah
  • Konfigurasi paket dapat disusun melalui UI atau kuesioner CLI interaktif dengan nilai input yang type-safe
    • Nilai dapat dengan mudah diinjeksi dari paket lain, ConfigMap, atau Secret
    • Pendekatannya mengarah untuk tidak lagi memakai file values.yaml yang tidak bertipe dan tidak terdokumentasi
  • Manajemen dependensi memungkinkan paket Glasskube digunakan dan dirujuk oleh banyak paket lain
    • Paket dependensi dipasang di namespace yang benar
    • README menggambarkannya sebagai “cara umbrella chart seharusnya bekerja sejak awal”

Update, GitOps, dan dukungan repositori

  • Update paket memungkinkan preview pending update ke versi yang diinginkan, lalu dijalankan dengan satu klik atau perintah CLI
  • Semua update telah diuji lebih dulu dengan test suite Glasskube
  • Reaksi dan komentar terhadap paket dapat ditinggalkan melalui GitHub discussions atau di dalam UI Glasskube
  • Integrasi GitOps didasarkan pada cara semua paket Glasskube dikelola sebagai custom resource
  • Integrasi Renovate juga sedang dikerjakan, dengan isu terkait di renovatebot/renovate#29322
  • Banyak repositori dan private package dapat digunakan
    • Bisa dipakai untuk men-deploy paket layanan internal perusahaan
    • Diberikan skenario agar developer dapat lebih mudah menyiapkan layanan internal yang selalu mutakhir

Arsitektur instalasi paket

  • Alur glasskube install [package] memiliki struktur di mana UI atau CLI menggunakan Client untuk mengakses repositori paket dan Kubernetes API secara bersamaan
  • UI terhubung ke Client melalui server lokal http://localhost:8580
  • CLI terhubung ke Client melalui cobra CLI
  • Client terlebih dahulu memeriksa Package Repo untuk validasi paket
  • Setelah validasi, dibuat custom resource Package di Kubernetes API
  • Di dalam cluster, PackageController dan PackageInfoController melakukan reconcile
    • PackageController me-reconcile Package dan, bila perlu, membuat PackageInfo
    • PackageInfoController memperbarui manifest paket dari repositori paket
    • Manifest yang telah diperbarui kemudian tercermin di PackageInfo
    • Setelah itu PackageController men-deploy paket ke Kubernetes
  • Kubernetes mengembalikan status paket ke Client

Paket yang didukung dan informasi proyek

Bacaan terkait

1 komentar

 
GN⁺ 2024-06-27
Pendapat di Hacker News

  • Ini mungkin satu langkah ke arah yang benar, tetapi masalah terbesar dalam manajemen paket Kubernetes saat ini tampaknya sulit diselesaikan dengan package manager
    Yang paling menyulitkan sehari-hari adalah YAML bertingkat menumpuk dalam beberapa lapisan dan hasilnya tidak bisa diprediksi
    Misalnya, ArgoCD ApplicationSet membuat beberapa Application, Application tersebut merender chart Helm, dan di dalam chart itu ada CRD yang digunakan operator arbitrer seperti Strimzi, Grafana, dan Vector
    YAML memiliki sintaks yang miskin dan tidak ada standar rendering template, sehingga hampir mustahil mengetahui YAML apa yang sebenarnya akan disuntikkan ke Kubernetes API ketika membuat perubahan di level teratas
    Pada akhirnya ini berujung pada trial-and-error setiap bulan, deployment blue-green yang mahal, dan debugging selama ratusan menit

    • Adopsi YAML yang luas di alat-alat sekitar DevOps adalah sebuah kesalahan
      Menurut saya dukungan bahasa pemrograman yang layak adalah arahnya
      Idealnya diperlukan sistem tipe statis yang tidak Turing-complete dan terjamin berhenti; bentuk seperti Starlark bertipe tampaknya cocok
    • Penasaran apakah sudah pernah mencoba pola rendered manifest: https://akuity.io/blog/the-rendered-manifests-pattern/
    • Ini adalah masalah yang ingin difokuskan Glasskube Cloud(https://glasskube.cloud/)
      Mereka ingin glasskube[bot] mengomentari diff yang akurat dari resource yang benar-benar akan berubah di semua cluster yang terhubung ke pull request GitOps
      Diff ini dilakukan oleh controller yang berjalan di dalam cluster
      Anggap saja mirip analisis codecov, tetapi khusus untuk perubahan resource
    • Solusinya adalah tidak menggunakan Kubernetes

  • Ini tampak seperti pendekatan menarik untuk manajemen paket, dan terlihat cukup cocok untuk semacam cluster bergaya Homebrew
    Namun secara pribadi saya tetap lebih memilih kombinasi helmfile + Renovate + pipeline, bahkan demi menjaga konsistensi di repository
    Misalnya tombol update all terasa cukup menakutkan untuk cluster yang bermakna
    Untuk proyek pribadi, ini tetap alat yang keren
    Package controller-nya sangat mirip dengan Tiller di Helm lama, yang menjadi masalah keamanan besar di banyak perusahaan sehingga dihapus di Helm 3 dan diganti dengan pemrosesan sisi klien berbasis configmap; saya penasaran bagaimana proyek ini akan melewati masalah tersebut

    • Paket Glasskube dapat dimasukkan ke repository GitOps karena semua paket adalah CR(custom resource)
      Bisa juga mengaturnya dari CLI dengan flag --dry-run dan --output yaml, lalu memasukkannya ke Git
      Selain itu, mereka sedang mengerjakan pull request yang mendukung pembaruan paket lewat Renovate: https://github.com/renovatebot/renovate/issues/29322
      Helm 3 sekarang adalah alat sisi klien sehingga tidak bisa menegakkan RBAC sendiri
      OLM memperkenalkan Operator Groups(https://olm.operatorframework.io/docs/advanced-tasks/operato...) untuk menyediakan izin di tingkat operator
      Hal serupa dapat diperkenalkan juga pada paket Glasskube, dan meskipun Glasskube sendiri tetap akan membutuhkan izin yang cukup kuat, cakupan paket dapat dibatasi dan izin yang lebih terperinci dapat ditambahkan

  • Secara tradisional, paket aplikasi adalah binary immutable dengan versi yang dipatok yang mencakup tahap sebelum dan sesudah instalasi; paket itu dibangun dengan platform tertentu dan dependensi tertentu dalam pikiran, dan konfigurasi saat instalasi sangat terbatas.
    Alasan paket dapat bekerja dengan baik adalah karena paket dirancang untuk lingkungan yang sangat spesifik, dan bagian yang bisa diubah saat instalasi dibuat seminimal mungkin.
    Meski begitu, paket sistem operasi tetap membutuhkan pengujian, pengembangan, dan patch dalam jumlah besar bahkan dalam kondisi yang sempit itu.
    Paket yang Anda instal sekarang terasa mudah karena mungkin sudah ada ratusan jam yang dicurahkan untuk platform saat ini, komponen saat ini, dan versinya.
    “Paket” Kubernetes sebenarnya bukan paket, melainkan lebih mirip kumpulan instruksi tentang komponen yang harus diinstal dan dikonfigurasi, dan sering kali mencakup kumpulan beberapa aplikasi yang terpisah.
    Perbedaan ini terlihat dalam dua hal: “paket” K8s memiliki definisi yang sangat longgar sehingga sangat berubah-ubah, dan dibuat oleh berbagai orang dengan berbagai cara sambil membuat berbagai asumsi tentang kondisi sistem target instalasi.
    Agar “paket” Kubernetes berfungsi, beberapa lapisan dependensi dan konfigurasi harus cocok.
    Versi API K8s, cara komponen K8s diinstal dan dijalankan, ACL, ketiadaan komponen yang sudah ada yang bisa berbenturan, pematokan versi komponen dan container yang diinstal paket serta kompatibilitasnya dengan hal lain di dalam cluster, hingga konfigurasi pengguna, semuanya harus cocok.
    Upgrade juga sama membingungkannya karena tidak ada konsep pohon rilis stabil atau rolling release, mirip seperti memasang berkas .deb, .rpm, atau .dmg arbitrer pada sistem operasi dan berharap semuanya berjalan baik.
    Saat ini tidak ada yang menangani semua ini.
    Untuk membuat packaging Kubernetes semulus packaging binary per platform, dibutuhkan seluruh komunitas maintainer serta pendekatan rolling release seperti Homebrew atau branch rilis versi yang stabil.
    Pada akhirnya, proyek seperti ArtifactHub atau Homebrew harus mengelola semua paket dengan satu cara, tetapi itu pekerjaan besar dan tampaknya sama sekali tidak menguntungkan.

    • Glasskube juga memulai dengan cara yang mirip Homebrew, yaitu menempatkan paket di dalam repositori paket Glasskube “core” (https://github.com/glasskube/packages).
      Strukturnya adalah menyimpan semua update secara terpusat dan mengujinya dengan workflow CI/CD agar pengguna dapat menikmati upgrade mulus yang sudah diuji.
      Pengguna juga dapat meng-host repositori dan paket pribadi, tetapi pada dasarnya mereka ingin menyediakan sendiri kumpulan paket yang opinionated.
      Mereka juga sudah memikirkan build untuk versi atau lingkungan Kubernetes yang berbeda, dan itu suatu saat akan diperlukan jika lebih banyak konfigurasi ingin dilebur ke tahap build.

  • Saya tidak yakin apakah package manager K8s bisa menjadi sesederhana brew atau apt.
    Terutama karena nilai berbeda-beda di setiap lingkungan target, dan hampir semua pengguna memiliki lingkungan “snowflake” masing-masing.
    Menggunakan prompt bergaya REPL atau UI web untuk mengatur nilai semacam itu tidak menarik bagi saya.
    Rasa sakit utamanya masih belum terselesaikan: menulis chart Helm itu menyiksa, nilai per lingkungan harus dikelola, dan saya berharap nilai antar-chart tidak perlu disambungkan.

    • Di lapangan, cluster snowflake memang sangat banyak, dan ini juga menjadi topik hangat di konferensi cloud native yang baru-baru ini dihadiri.
      Tim platform membuat platform developer internal untuk lebih menstandarkan konfigurasi Kubernetes di seluruh tim dan cluster, serta berusaha agar developer hanya bisa melakukan perubahan kecil.
      Berdasarkan pengalaman, konfigurasi yang berbeda-beda seperti ini harus dikurangi, dan itulah salah satu alasan Glasskube dibuat sejak awal.
      Mereka 100% setuju bahwa menulis chart Helm itu menyiksa, dan ingin mengubahnya ke depan.
      Paket Glasskube tetap dapat dikonfigurasi, tetapi menyediakan default yang masuk akal.
      Nilai konfigurasi dari paket lain dapat dengan mudah dirujuk di Glasskube, sehingga nilai yang sama tidak perlu diberikan berulang kali.

  • Saya banyak membuat operator Kubernetes dan sering berurusan dengan masalah Helm serta OLM.
    Dokumentasinya menyebutkan bahwa “upgrade CRD ditangani oleh Glasskube agar CR dan operator tidak saling tidak sinkron”, tetapi saat mencari “CRD” di dokumentasi, tidak ada hasil yang konkret.
    Ini salah satu rasa sakit terbesar yang saya alami dengan Helm saat ini, jadi saya penasaran apakah rencananya bisa dibagikan.
    [1] <https://stackable.tech/en/>
    [2] <https://www.youtube.com/watch?v=Q8OSYOgBdCc>

    • Paket di repositori publik Glasskube dikonfigurasi agar perubahan CRD diterapkan.
      Ini ditangani melalui Manifest atau helm-controller.
      Dokumentasinya akan diperbarui.

  • Saya melihat Kubernetes pada dasarnya dibatasi oleh model operator yang terlalu sederhana.
    Saya suka ide besarnya, tetapi mereduksi seluruh model menjadi “status saat ini, status yang diinginkan, tindakan berikutnya” pada praktiknya mustahil.
    Pada akhirnya seluruh workflow masuk ke dalam logika tindakan berikutnya, dan karena terlalu banyak operator yang melihat status sistem yang sama, sulit mengetahui bagaimana berbagai komponen akan saling berinteraksi.
    Masalah Helm adalah subkasus dari masalah yang lebih besar ini.
    Sebagai analogi, ini seperti masalah yang dihadapi pemrograman frontend pada DOM.
    Memperkenalkan paradigma virtual DOM/reducer seperti React akan sangat membantu menyelesaikan masalah semacam ini.

    • “Status saat ini, status yang diinginkan, tindakan berikutnya” pada dasarnya adalah cara kerja teori kontrol secara umum.
      Ada status, tujuan, dan gangguan menuju tujuan; jika menginginkan alat yang kuat dan fleksibel, menurut saya tingkat abstraksi ini tepat.
      Masalahnya adalah karakteristik fisik dan penempatan mesin membuat perbedaan yang sangat besar, sehingga biaya untuk memvirtualisasikan atau menyimulasikannya secara bermakna terlalu tinggi.
      Karena itu, sebagai gantinya kita memverifikasi apakah status konfigurasi bekerja pada subset dari struktur fisik.
      Caranya dengan memiliki lingkungan dev, staging, dan prod, serta menggunakan deployment warna, analisis canary, rollout parsial, dan sebagainya.

  • Jika untuk menggunakan K8s diperlukan alat seperti ini, mungkin lebih baik memakai solusi lain.
    Kubernetes tidak dibuat untuk digunakan tanpa pengetahuan latar belakang, dan memang sulit.
    Kecuali Anda membuat PaaS penuh, sulit untuk lepas dari kompleksitas itu.

  • Sepertinya arah pemasaran tool ini keliru
    Ini tidak terlalu berkaitan dengan Helm
    Bagi saya, Helm terutama bukan package manager, melainkan bahasa templating, serta cara untuk mengonfigurasi dan memasang ke klaster K8s melalui kubeapps, Helm CLI, dan ArgoCD
    Pendekatan ini juga merusak paradigma IaC yang bagus
    Karena setelah melakukan bootstrap ArgoCD, struktur yang bagus adalah hanya merujuk ke repositori Git
    Demo tidak menunjukkan cara memakai fitur templating seperti dukungan form, melainkan hanya menunjukkan hal-hal lainnya
    Saya tetap merasa ada sesuatu yang bermasalah dengan Helm, jadi jujur saya suka tool ini sendiri, tetapi dengan pendekatan saat ini sepertinya akan gagal
    Perusahaan besar tidak membutuhkan tool ini, jadi akan sulit mendapatkan adopsi yang cukup
    Kubeapps maupun Helm sudah berjalan dengan baik, dan meski mengklaim akan menggantikan Helm, kemungkinan besar dukungan Helm akan tetap dipertahankan cukup lama
    Masalah Helm adalah semakin besar chart, semakin kompleks pula jadinya
    Struktur yang pada dasarnya menaruh semuanya dalam satu folder templates itu berantakan, YAML tidak cocok untuk templating, dan values.yaml menjadi terlalu besar

    • Demo tersebut lebih berfokus pada pengguna akhir
      Detail lebih lanjut tentang opsi konfigurasi dapat dilihat di dokumentasi konfigurasi package: https://glasskube.dev/docs/design/package-config/
    • Saya tidak bermaksud terdengar arogan atau meremehkan, tetapi jika Anda berpikir Helm terutama bukan package manager, berarti Anda belum banyak menangani infrastruktur yang dideploy ke K8s

  • Nilai jual bahwa ini lebih cepat daripada Helm tidak terlalu menarik
    Saya tidak pernah merasa masalah Helm adalah kecepatan

  • Kelihatannya menarik
    Akan membantu jika ada penjelasan singkat tentang bagaimana ini terhubung dengan atau dibandingkan dengan tool yang sudah ada, ArgoCD
    Saya sudah menonton videonya, dan karena salah satu tool yang dipasang adalah Argo, jelas ini menempati niche yang berbeda, tetapi saya masih belum paham apa tepatnya

    • ArgoCD adalah tool yang sangat baik untuk menyinkronkan status repositori GitOps ke klaster, memvisualisasikan resource yang terpasang, dan menampilkan potensi error
      Ini sering dipakai agar developer dapat melihat status aplikasi inti perusahaan tanpa akses ke klaster
      Glasskube berfokus pada package yang menjadi dependensi aplikasi inti
      Ia mengelola siklus hidup komponen infrastruktur, menguji update, dan menyediakan jalur upgrade
      Anda juga bisa memasukkan package Glasskube ke repositori GitOps dan menyinkronkannya ke klaster dengan ArgoCD, lalu sisanya ditangani oleh PackageController