HN पर लॉन्च: Glasskube – Helm का एक ओपन सोर्स Kubernetes पैकेज मैनेजर विकल्प

 (github.com/glasskube)
3 पॉइंट द्वारा GN⁺ 2024-06-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Glasskube, Kubernetes के लिए एक ओपन सोर्स पैकेज मैनेजर है, जिसे Helm या Kustomize जैसे टूल्स की तुलना में deployment, update और configuration को 20 गुना तेज़ बनाने वाला बताया गया है
  • उपयोगकर्ता Glasskube UI, CLI, या GitOps तरीके से पैकेज deploy कर सकते हैं, और यह Homebrew तथा npm की सरलता से प्रेरित है
  • मुख्य फीचर्स में Helm repository खोजे बिना UI से पैकेज install करना, type-safe configuration input, पैकेजों के बीच values injection, dependency-aware install, और पहले से tested safe updates शामिल हैं
  • सभी Glasskube पैकेज custom resources के रूप में मैनेज किए जाते हैं और GitOps के साथ हैंडल किए जा सकते हैं, साथ ही कई repositories और private package deployment का भी समर्थन है
  • यह फिलहाल Kubernetes Dashboard, cert-manager, Ingress-NGINX Controller, Kube Prometheus Stack, Cloud Native PG आदि को सपोर्ट करता है, और beta version को Homebrew से install किया जा सकता है

Glasskube Kubernetes पैकेज मैनेजमेंट की किस समस्या को हल करना चाहता है

  • Glasskube, Kubernetes के लिए एक ओपन सोर्स पैकेज मैनेजर है
  • इसे Kubernetes में पैकेज deploy, update और configure करने की प्रक्रिया को Helm या Kustomize जैसे टूल्स की तुलना में 20 गुना तेज़ बनाने वाला बताया गया है
  • यह Homebrew और npm की सरलता से प्रेरित है, और उपयोगकर्ता इनमें से किसी एक तरीके को चुन सकते हैं
    • Glasskube UI
    • Glasskube CLI
    • GitOps के माध्यम से सीधे पैकेज deploy करना
  • इसका विकास Kubernetes ecosystem में 5 साल से अधिक काम करते हुए पैकेज मैनेजमेंट, configuration और deployment में लगातार आई कठिनाइयों के अनुभव से हुआ
  • मौजूदा workflows में समझने में कठिन commands और concepts के लिए templates बनाना और documentation लिखना बहुत समय लेने वाला काम था
  • Homebrew, apt, dnf जैसे टूल्स का उपयोग आसान था और उनमें कम समस्याएँ थीं; यही तुलना Glasskube के विकास की प्रेरणा बनी

इंस्टॉलेशन और configuration flow

  • beta version को Homebrew से install किया जा सकता है
brew install glasskube/tap/glasskube
  • अन्य installation options installation guide में उपलब्ध हैं
  • CLI install करने के बाद, cluster में आवश्यक components install करने के लिए यह command चलाएँ
glasskube bootstrap
  • cluster bootstrap पूरा होने के बाद, पैकेज मैनेजर UI शुरू किया जा सकता है
glasskube serve
  • यह command default browser में http://localhost:8580 खोलती है, जहाँ उपयोगकर्ता उपलब्ध पैकेज browse और install कर सकते हैं

UI, configuration और dependency management फीचर्स

  • Glasskube UI सभी पैकेजों को एक ही जगह उपलब्ध कराता है, जिससे उपयोगकर्ता अलग से Helm repository खोजे बिना cluster में पैकेज install कर सकते हैं
  • पैकेज configuration को UI या interactive CLI questionnaire के जरिए type-safe input values के साथ सेट किया जा सकता है
    • दूसरे पैकेजों, ConfigMap और Secret से values आसानी से inject की जा सकती हैं
    • यह बिना type और बिना documentation वाली values.yaml files के उपयोग से आगे बढ़ने का तरीका सुझाता है
  • dependency management यह सुनिश्चित करता है कि Glasskube पैकेज कई अन्य पैकेजों द्वारा उपयोग और refer किए जा सकें
    • dependent packages सही namespace में install किए जाते हैं
    • README इसे इस तरह बताता है कि “umbrella chart को शुरू से ही ऐसे काम करना चाहिए था”

updates, GitOps और repository support

  • पैकेज updates में इच्छित version के लिए pending update को पहले से preview किया जा सकता है, और फिर एक click या CLI command से उसे लागू किया जा सकता है
  • सभी updates को Glasskube test suite के साथ पहले से test किया जाता है
  • पैकेजों पर प्रतिक्रिया और comments GitHub discussions या Glasskube UI के भीतर छोड़े जा सकते हैं
  • GitOps integration इस तरीके पर आधारित है कि सभी Glasskube पैकेज custom resources के रूप में मैनेज किए जाते हैं
  • Renovate integration पर भी काम चल रहा है, और संबंधित issue renovatebot/renovate#29322 में है
  • कई repositories और private package का उपयोग किया जा सकता है
    • इसका उपयोग कंपनी के internal service packages deploy करने के लिए किया जा सकता है
    • इसमें ऐसा परिदृश्य बताया गया है जहाँ developers आसानी से up-to-date internal services सेट कर सकें

पैकेज installation architecture

  • glasskube install [package] flow में UI या CLI, Client के माध्यम से package repository और Kubernetes API दोनों का उपयोग करते हैं
  • UI, local server http://localhost:8580 के माध्यम से Client से जुड़ता है
  • CLI, cobra CLI के माध्यम से Client से जुड़ता है
  • Client पहले package validation के लिए Package Repo की जाँच करता है
  • validation के बाद Kubernetes API में Package custom resource बनाया जाता है
  • cluster के भीतर PackageController और PackageInfoController reconcile करते हैं
    • PackageController, Package को reconcile करता है और आवश्यकता होने पर PackageInfo बनाता है
    • PackageInfoController, package repository से package manifest को update करता है
    • updated manifest, PackageInfo में reflect होता है
    • इसके बाद PackageController पैकेज को Kubernetes में deploy करता है
  • Kubernetes पैकेज की स्थिति Client को वापस भेजता है

समर्थित पैकेज और प्रोजेक्ट जानकारी

  • Glasskube पहले से कई पैकेजों को सपोर्ट करता है
  • समर्थित और आने वाले पैकेजों की पूरी सूची glasskube.dev/packages पर देखी जा सकती है
  • संबंधित प्रोजेक्ट के रूप में Glasskube Apps Operator glasskube/operator भी है
  • समस्याएँ, bugs और feature requests Discord या GitHub issues के माध्यम से भेजे जा सकते हैं
  • Glasskube को Apache 2.0 license के तहत वितरित किया जाता है

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

1 टिप्पणियां

 
GN⁺ 2024-06-27
Hacker News की राय

  • यह सही दिशा में एक कदम हो सकता है, लेकिन अभी Kubernetes package management में सबसे बड़ी समस्या package manager से हल करना मुश्किल लगती है
    रोज़मर्रा में सबसे मुश्किल बात यह है कि nested YAML कई लेयर्स में जमा होता जाता है और नतीजा predictable नहीं रहता
    उदाहरण के लिए, ArgoCD ApplicationSet कई Applications बनाता है, वे Applications Helm charts render करते हैं, और उन charts के अंदर Strimzi, Grafana, Vector जैसे arbitrary operators द्वारा इस्तेमाल किए जाने वाले CRD होते हैं
    YAML की syntax कमजोर है और template rendering का कोई standard भी नहीं है, इसलिए top-level change करने पर असल में Kubernetes API में inject होने वाला YAML क्या होगा, यह जानना लगभग असंभव है
    आखिर में यह हर महीने trial-and-error, महंगी blue-green deployment, और सैकड़ों मिनट की debugging में बदल जाता है

    • DevOps के आसपास के tools में YAML का व्यापक रूप से अपनाया जाना एक गलती थी
      मुझे लगता है कि सही दिशा proper programming language support है
      Ideally, static type system चाहिए जो Turing-complete न हो और termination guaranteed हो; typed Starlark जैसा कोई रूप ठीक लगता है
    • उत्सुकता है कि आपने rendered manifests pattern इस्तेमाल किया है या नहीं: https://akuity.io/blog/the-rendered-manifests-pattern/
    • यही वह समस्या है जिस पर Glasskube Cloud(https://glasskube.cloud/) फोकस करना चाहता है
      glasskube[bot] से GitOps pull requests पर जुड़े सभी clusters में वास्तव में बदलने वाले resources का exact diff comment करवाना चाहते हैं
      यह diff cluster के अंदर चलने वाला controller करता है
      इसे codecov analysis जैसा समझें, लेकिन resource changes के लिए dedicated
    • समाधान है Kubernetes का इस्तेमाल न करना

  • package management के लिए यह एक दिलचस्प approach लगती है, और Homebrew-style clusters जैसी जगहों के लिए ठीक लगती है
    फिर भी व्यक्तिगत रूप से, repository में consistency बनाए रखने के लिए मैं helmfile + Renovate + pipeline combo को पसंद करता हूँ
    उदाहरण के लिए update all button किसी meaningful cluster में काफ़ी डरावना लगता है
    personal projects जैसी जगहों पर यह अब भी शानदार tool है
    package controller पुराने Helm के Tiller से काफी मिलता-जुलता है, और वह कई कंपनियों में बड़ा security issue बना था, इसलिए Helm 3 में उसे हटाकर configmap-based client-side processing में बदल दिया गया; उत्सुकता है कि यह project उस समस्या से कैसे निपटेगा

    • Glasskube packages को GitOps repository में रखा जा सकता है क्योंकि सभी packages CR(custom resource) हैं
      CLI में --dry-run और --output yaml flags सेट करके फिर Git में डालना भी संभव है
      साथ ही Renovate के साथ package updates support करने वाले pull requests पर काम चल रहा है: https://github.com/renovatebot/renovate/issues/29322
      Helm 3 अब client-side tool है, इसलिए अपने-आप RBAC enforce नहीं कर सकता
      OLM ने operator-level permissions देने के लिए Operator Groups(https://olm.operatorframework.io/docs/advanced-tasks/operato...) introduce किए थे
      Glasskube packages में भी कुछ ऐसा ही introduce किया जा सकता है, और Glasskube को खुद अब भी काफी मजबूत permissions की जरूरत होगी, लेकिन package scope को limit किया जा सकता है और fine-grained permissions जोड़ी जा सकती हैं

  • पारंपरिक रूप से application packages version-pinned immutable binaries होते हैं, जिनमें install से पहले/बाद के steps शामिल होते हैं। इन्हें किसी खास platform और खास dependencies को ध्यान में रखकर build किया जाता है, और install के समय configuration बेहद सीमित होती है।
    packages इसलिए अच्छी तरह काम करते हैं क्योंकि उन्हें बहुत specific environment के लिए design किया जाता है, और install के समय बदली जा सकने वाली चीज़ों को न्यूनतम रखा जाता है।
    फिर भी operating system packages को उन संकरी शर्तों के भीतर भी लगातार भारी testing, development और patching की ज़रूरत पड़ती है।
    अभी जो package install करना आसान लगता है, वह इसलिए हो सकता है क्योंकि मौजूदा platform, मौजूदा components और versions के लिए उसमें सैकड़ों घंटे लगे हों।
    Kubernetes का “package” असल में package नहीं, बल्कि install और configure किए जाने वाले components के लिए निर्देशों के bundle जैसा होता है, और अक्सर इसमें कई अलग-अलग application bundles शामिल होते हैं।
    यह फर्क दो तरह से दिखता है: K8s “package” की परिभाषा बहुत ढीली होती है, इसलिए variability बहुत ज़्यादा होती है, और तरह-तरह के लोग तरह-तरह से इन्हें बनाते हैं, साथ ही target system state के बारे में तरह-तरह की assumptions रखते हैं।
    Kubernetes “package” के काम करने के लिए dependencies और configuration की कई layers का मेल खाना ज़रूरी है।
    K8s API version, K8s components कैसे install और run होते हैं, ACL, टकरा सकने वाले existing components का न होना, package द्वारा install किए जाने वाले components और container versions का pin होना और cluster में बाकी चीज़ों के साथ compatibility, user configuration—सब कुछ मेल खाना चाहिए।
    upgrade भी stable release tree या rolling release की अवधारणा न होने के कारण इसी तरह उलझे हुए हैं; यह operating system पर arbitrary .deb, .rpm, .dmg files install करके उम्मीद करने जैसा है कि सब ठीक चलेगा।
    आज ऐसा कुछ नहीं है जो यह सब कर दे।
    Kubernetes packaging को platform-specific binary packaging जितना smooth बनाने के लिए maintainers की पूरी community और Homebrew जैसी rolling release approach या stable version release branches की ज़रूरत होगी।
    अंततः ArtifactHub या Homebrew जैसे किसी project को सभी packages को एक ही तरीके से manage करना होगा, लेकिन यह बड़ा काम है और बिल्कुल भी profitable नहीं दिखता।

    • Glasskube ने भी Homebrew की तरह “core” Glasskube package repository (https://github.com/glasskube/packages) में packages रखने के तरीके से शुरुआत की थी।
      इसका structure ऐसा है कि सभी updates centrally store किए जाएँ और CI/CD workflow से test हों, ताकि users tested और smooth upgrades का लाभ ले सकें।
      users अपनी private repositories और packages भी host कर सकते हैं, लेकिन default रूप से हम खुद एक opinionated package set देना चाहते हैं।
      अलग-अलग Kubernetes versions या environments के हिसाब से build करने के बारे में भी हम पहले से सोच रहे हैं, और ज्यादा configuration को build stage में शामिल करने के लिए किसी दिन यह ज़रूरी होगा।

  • मुझे यकीन नहीं कि K8s package manager कभी brew या apt जितना simple हो पाएगा।
    खासकर इसलिए कि target environments के हिसाब से values अलग होती हैं, और लगभग हर user के पास अपना अलग “snowflake” environment होता है।
    ऐसी values configure करने के लिए REPL-style prompts या web UI का इस्तेमाल मुझे आकर्षक नहीं लगता।
    core pain अभी भी हल नहीं हुआ है: Helm chart लिखना तकलीफदेह है, environment-specific values manage करनी पड़ती हैं, और अच्छा होगा अगर charts के बीच values जोड़नी न पड़ें।

    • वास्तविक production में snowflake clusters बहुत ज़्यादा हैं, और हाल में attended cloud native conference में भी यह hot topic था।
      platform teams teams और clusters में Kubernetes configuration को और standardized बनाने के लिए internal developer platforms बना रही हैं, ताकि developers सिर्फ छोटे modifications कर सकें।
      experience के हिसाब से ऐसी अलग-अलग configurations कम की जानी चाहिए, और यही Glasskube बनाने की वजहों में से एक थी।
      Helm chart लिखना तकलीफदेह है, इससे 100% सहमत हूँ, और आगे हम इसे बदलना चाहते हैं।
      Glasskube packages अभी भी configurable हैं, लेकिन meaningful defaults देते हैं।
      Glasskube में दूसरे packages की configuration values को आसानी से reference किया जा सकता है, इसलिए वही values बार-बार देने की ज़रूरत नहीं होती।

  • मैं Kubernetes operators काफी बनाता हूँ और Helm और OLM की समस्याओं से अक्सर निपटता हूँ।
    docs में लिखा है कि “CRD upgrades Glasskube handle करता है ताकि CR और operator एक-दूसरे से mismatch न हों,” लेकिन docs में “CRD” search करने पर कोई ठोस result नहीं मिलता।
    यह अभी Helm में मेरे सबसे बड़े pains में से एक है, इसलिए जानना चाहूँगा कि क्या आप plan share कर सकते हैं।
    [1] <https://stackable.tech/en/>
    [2] <https://www.youtube.com/watch?v=Q8OSYOgBdCc>

    • public Glasskube repository के packages CRD changes apply करने के लिए configured हैं।
      इन्हें Manifest या helm-controller के ज़रिए handle किया जाता है।
      docs update किए जाएँगे।

  • मुझे लगता है कि Kubernetes अपनी बहुत ज्यादा simple operator model की वजह से fundamentally constrained है।
    overall idea मुझे पसंद है, लेकिन पूरे model को “current state, desired state, next action” तक घटा देना वास्तव में असंभव है।
    आखिरकार पूरा workflow next action logic के अंदर चला जाता है, और एक ही system state को देखने वाले operators इतने ज्यादा होते हैं कि यह समझना मुश्किल हो जाता है कि अलग-अलग components कैसे interact करेंगे।
    Helm की समस्या इसी बड़े problem का subcase है।
    analogy दें तो यह वैसा ही है जैसा frontend programming में DOM के साथ problem होती है।
    React जैसे virtual DOM/reducer paradigm को लाने से ऐसी समस्याओं को हल करने में काफी मदद मिलेगी।

    • “current state, desired state, next action” मूल रूप से सामान्य control theory के काम करने का तरीका है।
      state, goal, goal की ओर disturbances होते हैं, और अगर आप powerful और flexible tool चाहते हैं तो मुझे लगता है abstraction का यह level सही है।
      समस्या यह है कि machine की physical characteristics और deployment में इतना बड़ा फर्क होता है कि उन्हें meaningful तरीके से virtualize या simulate करने की cost बहुत ज्यादा है।
      इसलिए इसके बजाय physical structure के subset पर validate किया जाता है कि configuration state काम करती है या नहीं।
      यानी dev, staging, prod environments रखना, color deployments, canary analysis, partial rollouts आदि इस्तेमाल करना।

  • अगर K8s इस्तेमाल करने के लिए ऐसे tool की ज़रूरत है, तो शायद कोई दूसरा solution इस्तेमाल करना बेहतर है।
    Kubernetes background knowledge के बिना इस्तेमाल करने के लिए नहीं बना है, और यह मुश्किल है।
    जब तक आप पूरा PaaS नहीं बनाते, उस complexity से बचना मुश्किल है।

  • मुझे लगता है इस tool की marketing दिशा गलत है
    इसका Helm से बहुत ज़्यादा संबंध नहीं है
    मेरे लिए Helm मुख्य रूप से package manager नहीं, बल्कि template language है, और kubeapps, Helm CLI, ArgoCD के ज़रिए K8s cluster में configure और install करने का तरीका है
    यह approach एक बेहतरीन IaC paradigm को भी तोड़ देता है
    क्योंकि ArgoCD को bootstrap करने के बाद सिर्फ़ Git repository को reference करने वाला structure बेहतर होता है
    demo यह नहीं दिखाता कि form support जैसी template capabilities को कैसे इस्तेमाल किया जाए, बल्कि बाकी चीज़ें ही दिखाता है
    Helm में कुछ समस्या है, ऐसा एहसास अब भी है, इसलिए सच कहूँ तो यह tool खुद मुझे पसंद है, लेकिन मौजूदा approach के साथ यह fail होगा लगता है
    बड़ी companies को इस tool की ज़रूरत नहीं होगी, इसलिए पर्याप्त adoption पाना मुश्किल होगा
    Kubeapps और Helm दोनों ठीक से काम करते हैं, और Helm को replace करने की बात हो तब भी शायद Helm support लंबे समय तक बनाए रखी जाएगी
    Helm की समस्या यह है कि chart बड़े होते जाते हैं तो वे complex हो जाते हैं
    एक templates folder में practically सब कुछ रखने वाला structure messy है, YAML templates के लिए suitable नहीं है, और values.yaml बहुत ज़्यादा बड़ा हो जाता है

    • demo end users पर ज़्यादा focus किया गया है
      configuration options की details package configuration docs में देखी जा सकती हैं: https://glasskube.dev/docs/design/package-config/
    • मैं arrogant या dismissive सुनाई नहीं देना चाहता, लेकिन अगर आपको लगता है कि Helm मुख्य रूप से package manager नहीं है, तो आपने K8s पर deployed infrastructure के साथ बहुत ज़्यादा काम नहीं किया है

  • Helm से तेज़ होने वाला selling point मुझे बहुत attract नहीं करता
    मुझे कभी नहीं लगा कि Helm की समस्या speed है

  • दिलचस्प लग रहा है
    मौजूदा tool ArgoCD के साथ यह कैसे fit होता है या compare होता है, इसका छोटा-सा explanation मिल जाए तो समझने में मदद मिलेगी
    मैंने video देखा, और install किए जाने वाले tools में से एक Argo था, इसलिए यह ज़रूर किसी अलग niche में आता होगा, लेकिन अभी तक मुझे साफ़ नहीं है कि वह क्या है

    • ArgoCD GitOps repository की state को cluster में sync करने, installed resources को visualize करने और potential errors दिखाने के लिए एक शानदार tool है
      इसका अक्सर इस्तेमाल developers द्वारा cluster access के बिना company की core applications की state देखने के लिए किया जाता है
      Glasskube उन packages पर focus करता है जिन पर core applications depend करती हैं
      यह infrastructure components का lifecycle manage करता है, updates test करता है, और upgrade paths provide करता है
      आप Glasskube package को GitOps repository में डालकर ArgoCD से cluster में sync भी कर सकते हैं, और बाकी काम PackageController संभालता है