Show HN: Glasskube v0.0.1 Technical Preview for a New Kubernetes Package Manager

[pmig]

https://glasskube.dev/blog/technical-preview/

Hi folks,

We worked hard over the last couple of weeks to build a new package manager for Kubernetes that makes it super simple to install packages and solves some of the shortcomings of helm (dependency management, multi namespace installations, a GUI and CLI as first class interfaces).

We just released our source code on GitHub: https://github.com/glasskube/glasskube/ and looking for feedback!

[gtirloni]

Skimming the readme, this seem focuses on reusing Helm charts but offering a supposedly more intuitive interface?

Does it change the way developers would work with YAML and Go templates or is it the same as in Helm?

[pmig → gtirloni]

We focus more on the installer experience, in the back we still use manifests and helm charts that will get deployed in the cluster, but the package operator will constantly sync them with central repository to make sure that the packages will stay up to date.

We didn't wanted to introduce a new standard in deployment method for our first preview to support as many packages as possible.

[nikau → pmig]

Another layer of abstraction will surely simplify things

[pmig → nikau]

Did you see our package manifest schema? We will add more information (dependencies, conflicts, etc.) into these package manifests, but keep the overhead low.

As a package manger also relies on the community and supported packages we don't want to introduce a new layer of abstraction that every package creator needs to implement.

[e12e → pmig]

But this doesn't do anything for packagers - making it easy to write new packages?

So far I think the best part of helm is installing/using packages - it's the terrible yaml-template soup that is the problem?

[pmig → e12e]

It helps packagers to distribute packages and package updates to the used. Think of it as the iOS app store for Kubernetes, we bridge the gap between publishing and installing a package, so we can help packagers get the latest version into the installers cluster and make sure the package is compatible with the installers cluster and - in a later version - support the packagers with crash logs and and bug reports.

[nikau → pmig]

maybe I'm misunderstanding the concept here - aren't all the dependencies and conflicts taken care at during the docker image creation phase?

Or are you talking about running dependent sidecars or something like that?

[pmig → nikau]

We are taking care of dependencies of other cloud native packages. For example the new Kubernetes dashboards has a dependency on cert-manager to generate certificates, or apps that have dependencies on databases or requirements for logging, monitoring or backups. All these dependencies point other cloud native packages that shouldn't / can't be installed in the same docker image.

[nikau → pmig]

right - in my experience that's probably the most insignificant thing to workout, but I guess if there's demand for it good luck.

[pmig → nikau]

Thanks!

[azaras]

Why do not use OLM infrastructure like catalogsources, subscriptions... but for apps?

[pmig → azaras]

That is good question, we looked into OLM and their infrastructure might be good fit for enterprises or huge clusters, but seemed to be an overkill for most (smaller) Kubernetes clusters. But we generally like the concept of operators, but don't want to solely be limited by only supporting operators.

Or do you mean the naming conventions?

[chologrande → pmig]

How is this any smaller than OLM or the Operator pattern? Having trouble seeing the differentiator other than "it's different"

[pmig → chologrande]

You can simply run "glasskube install cert-manager" or in the future "glasskube install [your package]" and glasskube makes sure all the dependencies get transitively installed.

In addition our GUI is served locally from the client and just creates package Cars, which then will be picked up by the package operator.

[chologrande → pmig]

I can simply run `helm install cert-manager` or `kubectl operator install cert-manager -n cert-manager --channel stable --approval Automatic --create-operator-group ` - both have dependency resolution.

Not trying to be negative here, trying to understand if there is value or functionality missing from established solutions, because it's not obvious to me.

[pmig → chologrande]

Your feedback is definitely reasonable, I don't perceive it as negativity.

Let me elaborate on both examples:

1. Helm dependencies

As cert-manager doesn't have any dependencies this will work fine, but we saw in many other helm charts often a "bitnami postgres" or the kube-prometheus-stack included. These dependencies will be installed in the same namespace as the original chart gets installed. Which is not very transparent for the user. A classic example is the Bitnami Wordpress chart where the MariaDB chart is included. The MariaDB chart received a major update through a Wordpress chart update which resulted in a lot of broken Wordpress installations.

With Glasskube we try to separate these dependencies into separate packages, so we can update the MariaDB (Operator) independently from the Wordpress installation. So a Glasskube package will be able to request a database (CR) and if the CRD is not yet present in the cluster we will install the CRD provider (mariadb-operator).

2. OLM cli

If you only want to manage operators and are very skilled you can use OLM which will have a similar effect, but as I tried to explain with the Wordpress example, most packages will not purely be an operator but have some namespaces components (like deployments) and will require custom resources from operators.

We have not yet introduced this distinction, but will maybe add the two categories ClusterPackages (Operators) and Packages (Apps) which play together nicely.

Our aim is to not recreate the wheel, but give cloud native developers the possibilities to make sure operator dependencies are met and Kubernetes users a simple CLI und GUI tool to get started without the need of copy pasting some helm commands that somebody else will update with different values or who does not read the changelog of a helm chart to fully understand the consequences.

Happy to get more of your knowledge to make Glasskube a better product, as we are still in the technical preview phase.

[e12e]

> We are always adding new supported packages & apps

How do I make a package and host/submit it?

[pmig → e12e]

We created a discussion thread in our GitHub repository explaining the necessary steps:

https://github.com/glasskube/glasskube/discussions/90

tldr: a pull request into our package repository