TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Show HN: Glasskube – Open Source Kubernetes Package Manager, alternative to Helm

266 点作者 pmig11 个月前
Hello HN, we&#x27;re Philip and Louis from Glasskube (<a href="https:&#x2F;&#x2F;github.com&#x2F;glasskube&#x2F;glasskube">https:&#x2F;&#x2F;github.com&#x2F;glasskube&#x2F;glasskube</a>). We&#x27;re working on an open-source package manager for Kubernetes. It&#x27;s an alternative to tools like Helm or Kustomize, primarily focused on making deploying, updating, and configuring Kubernetes packages simpler and a lot faster. Here is a demo video (<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=aIeTHGWsG2c#t=17s" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=aIeTHGWsG2c#t=17s</a>) with quick start instructions.<p>Most developers working with Kubernetes use Helm, an open-source tool created during a hackathon nine years ago. However, with the rapid growth of Kubernetes packages to over 800 packages on the CNCF landscape today, the prerequisites have changed, and we believe it’s time for a new package manager. Every engineer we talked to has a love-hate relationship with Helm, and we also found ourselves defaulting to Helm despite its shortcomings due to a lack of alternatives.<p>We have spent enough time trying to get Helm to do what we need. From looking for the correct chart, trying to learn how each value affects the components and hand-crafting a schemaless values.yaml file, to debugging the final release if it inevitably fails to install, the experience of using Helm is, for the most part, time consuming and cumbersome.<p>Charts often become more complex, requiring the use of sub-charts. These umbrella charts tend to be even harder to maintain and upgrade, because so many different components are bundled into a single release.<p>We talked to over 100 developers and found that everyone developed their own little workarounds, with some working better than others. We collected the feedback poured everything we learned from that into a new package manager. We want to build something that is as easy to use as Homebrew or npm and make package management on Kubernetes as easy as on every other platform.<p>Some of the features Glasskube already supports are<p>Typesafe package configuration via UI or interactive CLI to inject values from other packages, ConfigMaps, and Secrets.<p>Browse our central package repository so there is no need to look for a Helm repository to find a specific package.<p>All packages are dependency-aware so they can be used and referenced by multiple other packages even across namespaces. We validate the complete dependency tree - So packages get installed in the correct namespace.<p>Preview and perform pending updates to your desired version with a single click of a button. All updates have been tested in the Glasskube test suite before being available in the public repository.<p>Use multiple repositories and publish your own private packages (e.g., your company&#x27;s internal services packages, so all developers will have the up-to-date and easily configured internal services).<p>All features are available via UI or interactive CLI. You can also manage all packages via GitOps.<p>Currently, we are focused on enhancing the user experience, aiming to save engineers as much time as possible. We are still using Helm and Manifests under the hood. However, together with the community, we plan to develop an entirely new packaging and bundling format for all cloud-native packages. This will provide package developers with a straightforward way to define how to install and configure packages, offer simple upgrade paths, and enable us to provide feedback, crash reports, and analytics to every developer working on Kubernetes packages.<p>We also started working on a cloud version. You can pre-signup here in case you are interested: <a href="https:&#x2F;&#x2F;glasskube.cloud" rel="nofollow">https:&#x2F;&#x2F;glasskube.cloud</a><p>We&#x27;d greatly appreciate any feedback you have and hope you get the chance to try out Glasskube.

24 条评论

guhcampos11 个月前
I think this might be a step in the right direction, but my main problem with Kubernetes package management today might not be fixable by a package manager, sadly. The biggest issue I have in my daily life is handling the multiple levels of nested YAML and the unpredictability of the results.<p>Think of an ArgoCD ApplicationSet that generates a bunch of Applications. Those Applications render a bunch of Helm charts, and inside those charts there are CRDs used by some random operator like Strimzi, Grafana or Vector.<p>Given YAML&#x27;s lack of syntax and the absense of any sort of standard for rendering templates, it&#x27;s practically impossible to know what are the actual YAML being injected in the Kubernetes API when you make a top-level change. It&#x27;s trial and error, expensive blue-green deployments and hundreds of debugging minutes all the way, every month.
评论 #40794107 未加载
评论 #40794176 未加载
评论 #40793166 未加载
评论 #40794091 未加载
llama05211 个月前
This looks like an interesting take on package management. Would be cool for homebrew clusters and the like.<p>However things like helmfile with renovate paired with a pipeline is my personal preference even if just for ensuring things remain consistent in a repo.<p>The `update all` button for instance seems terrifying on a cluster that means anything at all. None the less it&#x27;s still cool for personal projects and the like!<p>The package controller reminds me a lot of Helm tiller with older versions of helm, and it became a big security issue for a lot of companies, so much so that helm3 removed it and did everything clientside via configmaps. Curious how this project plans on overcoming that.
评论 #40792265 未加载
0xbadcafebee11 个月前
Application packages are (traditionally) versioned immutable binaries that come with pre- and post-install steps. They are built with a specific platform in mind, with specific dependencies in mind, and with extremely limited configuration at install time. This is what makes packages work pretty well: they are designed for a very specific circumstance, and allow as little change as possible at install time.<p>Even with all that said, operating system packages require a vast amount of testing, development, and patching, constantly, even within those small parameters. Packages feel easy because potentially hundreds of hours of development and testing have gone into that package you&#x27;re installing now, on that platform you&#x27;re on now, with the components and versions you have now.<p>Kubernetes &quot;packages&quot; aren&#x27;t really packages. They are a set of instructions of components to install and configure, which often involves multiple distinct sets of applications. This is different in a couple ways: 1) K8s &quot;packages&quot; are often extremely &quot;loose&quot; in their definition, leading to a lot of variability, and 2) they are built by all kinds of people, in all kinds of ways, making all kinds of assumptions about the state of the system they&#x27;re being installed into.<p>There&#x27;s actually multiple layers of dependencies and configuration that have to come together correctly for a Kubernetes &quot;package&quot; to work. The K8s API version has to be right, the way the K8s components are installed and running have to be right, the ACLs have to be right, there has to be no other installed component which could conflict, the version of the components and containers being installed by the package need to be pinned (and compatible with everything else in the cluster), and the user has to configure everything properly. Upgrades are similarly chaotic, as there&#x27;s no sense of a stable release tree, or rolling releases. It&#x27;s like installing random .deb or .rpm or .dmg files into your OS and hoping for the best.<p>Nothing exists that does all of this today. To make Kubernetes packaging as seamless as binary platform-specific packaging, you need an entire community of maintainers, and either a rolling-release style (ala Homebrew) or stable versioned release branches. You basically need a project like ArtifactHub or Homebrew to manage all of the packages in one way. That&#x27;s a big undertaking, and in no way profitable.
评论 #40797136 未加载
verdverm11 个月前
I have a hard time seeing how a k8s package manager could ever be as simple as brew or apt. One reason that stands out is that I have different values depending on what environment I&#x27;m targeting, and almost every user has a snowflake, just the way it is. The idea of a repl like prompt or web UI for setting those values is not appealing to me.<p>The main pains remain unaddressed<p>- authoring helm charts sucks<p>- managing different values per environment<p>- connecting values across charts so I don&#x27;t have to
评论 #40792402 未加载
lars_francke11 个月前
We[1] build a lot of Kubernetes operators[2] and deal a lot with Helm and OLM issues. Good luck!<p>One immediate question: Your docs say &quot;Upgrading CRDs will be taken care of by Glasskube to ensure CRs and its operators don&#x27;t get out-of-sync.&quot; but searching for &quot;CRD&quot; in your docs doesn&#x27;t lead to any concrete results.<p>This is one of our biggest pain ponts with Helm right now. Can you share your plans?<p>[1] &lt;<a href="https:&#x2F;&#x2F;stackable.tech&#x2F;en&#x2F;" rel="nofollow">https:&#x2F;&#x2F;stackable.tech&#x2F;en&#x2F;</a>&gt;<p>[2] &lt;<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=Q8OSYOgBdCc" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=Q8OSYOgBdCc</a>&gt;
评论 #40793638 未加载
revel11 个月前
In my opinion kubernetes is fundamentally hamstrung by the overly simplistic operator model. I really like the general idea, but it&#x27;s not really possible to reduce the entire model down to &quot;current state, desired state, next action.&quot; It means that an entire workflow ends up in the next action logic, but with so many operators looking at the same system state it&#x27;s not really possible to know how the various components will interact. The problems with helm are a subcase of this larger issue.<p>By analogy, this is the same issue as frontend programming faces with the DOM. Introducing a VDOM &#x2F; reducer paradigm (like react) would go a long way towards solving these problems.
评论 #40795387 未加载
linuxdude31411 个月前
If you need something like this to use k8s you’re probably better off with a different solution.<p>Kubernetes is not intended to be something you use with no background. It’s hard, and without making a full blown PaaS there’s no getting away from that complexity.
k8sagic11 个月前
I think you are marketing this thing wrong.<p>This has very little to do with helm. For me helm is primarily not a package manager, its a templating language and a way of configuring and installing it to a k8s cluster happens through kubeapps, helm cli or argocd.<p>This approach also kills for me the really awesome IaC paradigma: I bootstrap ArgoCD and after that, reference only git repos.<p>Your demo doesn&#x27;t talk about HOW someone would use your templating features (like your &#x27;form&#x27; support) but shows everything besides that.<p>I honestly like this as i&#x27;m still having the feeling that something is wrong with helm, but the way you are approaching it, i think it will fail. It will not gain enough traktion as bigger companies do not need your tooling. Kubeapps works really well and helm too (you want to replace helm, you probably will keep the helm support in there for a long time).<p>The problems helm have is: its getting convoluted when helm charts become big. The templating folder is a shit place for basically having everything in there, yaml is not that good for templating and values.yamls become way to big.
评论 #40798750 未加载
评论 #40798685 未加载
tflinton11 个月前
The selling point of being faster than helm isn’t a very big draw to me.. I never felt the problem with helm was its speed.
slipheen11 个月前
This looks interesting, thanks for sharing it.<p>Feel free to disregard, but it would help me understand if you briefly explain how this fits in with &#x2F; compares to existing tools like argocd.<p>I watched your video and I saw that argo was one of the tools you were installing, so clearly this is occupying a different niche - But I&#x27;m not sure what that is yet :)
评论 #40792638 未加载
speedgoose11 个月前
Do you plan to eventually support alternatives to the mix of Golang templates in YAML? It’s my main issue regarding Helm charts and I dream about pkl helm charts.
评论 #40792130 未加载
评论 #40792076 未加载
评论 #40792089 未加载
woile11 个月前
Has anyone tried <a href="https:&#x2F;&#x2F;github.com&#x2F;stefanprodan&#x2F;timoni">https:&#x2F;&#x2F;github.com&#x2F;stefanprodan&#x2F;timoni</a> ? Seems like a good alternative to helm
评论 #40793260 未加载
评论 #40793091 未加载
fsniper11 个月前
When I check the packages repo, I see that they are yaml.files linking to helm packages. Is this only capable of deploying helm packages? Is there a packaging solution included too?
评论 #40792017 未加载
noisy_boy11 个月前
Google makes so many things - I wonder why they didn&#x27;t bother to build a simple programming language that is specifically suited for managing configs.
评论 #40799681 未加载
danmur11 个月前
&quot;Inspired by the simplicity of Homebrew and npm&quot; had me until here :P
impalallama11 个月前
Definitely looks like a solid improvement over Helm when it comes to just downloading and installing Kubernetes packages but it still to early for me to have a solid opinion since the aspect of actually building and distributing your own chart doesn&#x27;t seem have been tackled which is basically 90% of the use case for Helm despite calling itself a package-manager, ha.
necubi11 个月前
As someone with an opensource project that ships a helm package, I wish you the best of luck. Helm has many flaws, and we can definitely do better.<p>It sounds like your pitch is focused on users, but I think you might want to think about how to attract a package ecosystem. Some things that would make my life easier as a packager:<p>* Statically typed config language. It&#x27;s insane that we&#x27;re generating YAML files with Go templates. I&#x27;m a big fan of jsonnet, but whatever it is it should not be possible to have errors at runtime.<p>* A better way to document to users the various options and how they play together. For any moderately complex package it become very challenging to communicate how to configure the chart for your environment<p>* Better testing infrastructure; am I creating valid k8s resources given all of the possible configuration options?
cbanek11 个月前
I&#x27;ve had to use helm and argocd in anger at work, and I feel like the real problem is not helm, nor argocd. They are tricky to learn but in general pretty straightforward once you get it.<p>What was really annoying was the constant moving and changing the yaml that kubernetes wanted. After you update your cluster and things stop working, it&#x27;s really not about the layers on top, but it&#x27;s about kubernetes and having to keep up with the new beta versions and also sunsetting other things.
评论 #40796659 未加载
rad_gruchalski11 个月前
We started with some pretty cool Jsonnet-based build infrastructure and we&#x27;re pretty happy with it. Grafana Tanka is also okay, there&#x27;s tooling to generate Jsonnet libraries for anything that has a CRD. There&#x27;s jsonnet-bundler for package management.<p>One can throw Flux and Git* actions or what not in the mix. The outcome is a boring CI&#x2F;CD implementation. Boring is good. Boring and powerful because of how Jsonnet works.<p>It&#x27;s pretty neat in the right hands.
redbackthomson11 个月前
First off I just wanted to say I think it&#x27;s great that you&#x27;re attempting to tackle the problem that is Kubernetes package management. I work at a Kubernetes SaaS startup and spend many hours working with YAML and Helm charts every day, so I absolutely feel the pain that comes with it.<p>That being said, I&#x27;m confused as to where Glasskube is positioned in solving this problem. In the title of this post, you are claiming Glasskube is an &quot;alternative to Helm&quot;; although in your documentation you have a &quot;Glasskube vs Helm&quot; guide that explicitly states that &quot;Glasskube is not a full replacement of Helm&quot;. I&#x27;m trying to understand how these two statements can be true. To make things more confusing, under the hood Glasskube repositories appear to be a repackaging of a Helm repository, albiet with a nicer UI.<p>From what I&#x27;ve gathered after reading the docs, Glasskube is being positioned as an easier way to interact with Helm charts - offering some easy-to-use tooling for upgrades and dependency management. To me, that doesn&#x27;t exactly feel like it replaces Helm, but simply supplements my use of it, because it doesn&#x27;t actually combat the real problems of using Helm.<p>My biggest pain points, some of which I don&#x27;t think Glasskube is addressing, that I think are at the crux of switching off Helm:<p>- The arbitrary nature of how value files are laid out - every chart appears to have its own standards for which fields should be exposed and the nomenclature for exposing them<p>- Helm releases frequently get stuck when updating or rolling back, from which they can&#x27;t be fixed without needing to be uninstalled and reinstalled<p>- I need to reference the Helm chart values file to know what is exposed and what values and types are accepted (Glasskube schema&#x27;d values files does address this! Yay!)<p>Apart from the Helm chart values schema, I don&#x27;t think Glasskube solves these fundamental problems. So I&#x27;m not sure why I would spend the large amount of effort to migrate to this new paradigm if the same problems could still cause headaches.<p>Lastly, I would also concur with @llama052&#x27;s comment, that an &quot;update all&quot; button will always be forbidden in my, and probably most other, companies. Considering the serious lack of standardisation that comes with Helm chart versioning (whether the app version changes between charts, whether roles or role bindings need to be updated, whether values have been deprecated or their defaults have changed, etc.), it&#x27;s incredibly risky to update a Helm chart without understanding the implications that come with it. Typically our engineers have to review the release notes for the application between the two Helm chart versions, at least test in dev and staging for a few days, and only then can we feel comfortable releasing the changes - one chart at a time. Not to mention that if you are in charge of running a system with multiple applications, you probably want to use GitOps, and in that case a version upgrade would require a commit to the Git repository and not just a push of a button on the infra IDP.
leroman11 个月前
Somehow I am able to get bye with Kustimise. Cant stand the mess that is helm and its eco system.
评论 #40794119 未加载
评论 #40794504 未加载
评论 #40792859 未加载
epgui11 个月前
My immediate question is whether&#x2F;how this can be an improvement over using the terraform helm provider.<p>If I need a better GUI anywhere, it’s probably in EKS, or something that makes working with EKS a bit less painful.
评论 #40793129 未加载
hodgesrm11 个月前
I see that Glasskube is licensed under Apache 2.0. Do you plan to contribute it to the CNCF? Many of us are very skeptical of base infra that is not protected by a foundation.
评论 #40796610 未加载
评论 #40796640 未加载
curiousdeadcat11 个月前
Nickel feels like my end game for this kind of thing.