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

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.

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.

Given YAML's lack of syntax and the absense of any sort of standard for rendering templates, it's practically impossible to know what are the actual YAML being injected in the Kubernetes API when you make a top-level change. It's trial and error, expensive blue-green deployments and hundreds of debugging minutes all the way, every month.

This looks like an interesting take on package management. Would be cool for homebrew clusters and the like.

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.

The `update all` button for instance seems terrifying on a cluster that means anything at all. None the less it's still cool for personal projects and the like!

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.

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.

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're installing now, on that platform you're on now, with the components and versions you have now.

Kubernetes "packages" aren'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 "packages" are often extremely "loose" 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're being installed into.

There's actually multiple layers of dependencies and configuration that have to come together correctly for a Kubernetes "package" 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's no sense of a stable release tree, or rolling releases. It's like installing random .deb or .rpm or .dmg files into your OS and hoping for the best.

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's a big undertaking, and in no way profitable.

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'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.

The main pains remain unaddressed

- authoring helm charts sucks

- managing different values per environment

- connecting values across charts so I don't have to

We[1] build a lot of Kubernetes operators[2] and deal a lot with Helm and OLM issues. Good luck!

One immediate question: Your docs say "Upgrading CRDs will be taken care of by Glasskube to ensure CRs and its operators don't get out-of-sync." but searching for "CRD" in your docs doesn't lead to any concrete results.

This is one of our biggest pain ponts with Helm right now. Can you share your plans?

[1] <https://stackable.tech/en/>

[2] <https://www.youtube.com/watch?v=Q8OSYOgBdCc>

In my opinion kubernetes is fundamentally hamstrung by the overly simplistic operator model. I really like the general idea, but it's not really possible to reduce the entire model down to "current state, desired state, next action." 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's not really possible to know how the various components will interact. The problems with helm are a subcase of this larger issue.

By analogy, this is the same issue as frontend programming faces with the DOM. Introducing a VDOM / reducer paradigm (like react) would go a long way towards solving these problems.

If you need something like this to use k8s you’re probably better off with a different solution.

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.

I think you are marketing this thing wrong.

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.

This approach also kills for me the really awesome IaC paradigma: I bootstrap ArgoCD and after that, reference only git repos.

Your demo doesn't talk about HOW someone would use your templating features (like your 'form' support) but shows everything besides that.

I honestly like this as i'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).

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.

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.

This looks interesting, thanks for sharing it.

Feel free to disregard, but it would help me understand if you briefly explain how this fits in with / compares to existing tools like argocd.

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'm not sure what that is yet :)

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.

Has anyone tried https://github.com/stefanprodan/timoni ? Seems like a good alternative to helm

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?

Google makes so many things - I wonder why they didn't bother to build a simple programming language that is specifically suited for managing configs.

"Inspired by the simplicity of Homebrew and npm" had me until here :P

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't seem have been tackled which is basically 90% of the use case for Helm despite calling itself a package-manager, ha.

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.

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:

* Statically typed config language. It's insane that we're generating YAML files with Go templates. I'm a big fan of jsonnet, but whatever it is it should not be possible to have errors at runtime.

* 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

* Better testing infrastructure; am I creating valid k8s resources given all of the possible configuration options?

I'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.

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's really not about the layers on top, but it's about kubernetes and having to keep up with the new beta versions and also sunsetting other things.

We started with some pretty cool Jsonnet-based build infrastructure and we're pretty happy with it. Grafana Tanka is also okay, there's tooling to generate Jsonnet libraries for anything that has a CRD. There's jsonnet-bundler for package management.

One can throw Flux and Git* actions or what not in the mix. The outcome is a boring CI/CD implementation. Boring is good. Boring and powerful because of how Jsonnet works.

It's pretty neat in the right hands.

First off I just wanted to say I think it's great that you'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.

That being said, I'm confused as to where Glasskube is positioned in solving this problem. In the title of this post, you are claiming Glasskube is an "alternative to Helm"; although in your documentation you have a "Glasskube vs Helm" guide that explicitly states that "Glasskube is not a full replacement of Helm". I'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.

From what I'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't exactly feel like it replaces Helm, but simply supplements my use of it, because it doesn't actually combat the real problems of using Helm.

My biggest pain points, some of which I don't think Glasskube is addressing, that I think are at the crux of switching off Helm:

- 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

- Helm releases frequently get stuck when updating or rolling back, from which they can't be fixed without needing to be uninstalled and reinstalled

- I need to reference the Helm chart values file to know what is exposed and what values and types are accepted (Glasskube schema'd values files does address this! Yay!)

Apart from the Helm chart values schema, I don't think Glasskube solves these fundamental problems. So I'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.

Lastly, I would also concur with @llama052's comment, that an "update all" 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'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.

Somehow I am able to get bye with Kustimise. Cant stand the mess that is helm and its eco system.

My immediate question is whether/how this can be an improvement over using the terraform helm provider.

If I need a better GUI anywhere, it’s probably in EKS, or something that makes working with EKS a bit less painful.

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.

Nickel feels like my end game for this kind of thing.