pmig

We are absolutely seeing a lot of snowflake clusters in the wild. This is also a hot topic on all cloud native conferences I attended lately.

Platform teams try to create internal developer platforms to further standardize Kubernetes configurations across teams and clusters, where developers can only do minor modifications. From my experience we want to reduce snow flake configurations. This is also a reason why we created Glasskube in the first place.

> - authoring helm charts sucks

Yes, 100% and we are on a mission to change this in future.

> - managing different values per environment

Glasskube packages are still configurable, but come with meaningful default values.

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

This is already possible, you can reference package configuration values from other packages easily via Glasskube, not needing to provide the same values multiple times.

Thanks for your input, let me comment on your points one by one.

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

Glasskube packages can also be put inside a GitOps repository as every package is a CR (custom resource). (They can even be configured via the CLI using the `--dry-run` and `--output yaml` flags and than put into git. In addition we are working on pull request to support package updates via Renovate: https://github.com/renovatebot/renovate/issues/29322

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

As helm3 is now a client side tool only, that means that it can't enforce any RBAC by itself. OLM introduced Operator Groups (https://olm.operatorframework.io/docs/advanced-tasks/operato...) which introduces a permissions on an operator level. We might introduce something similar for Glasskube packages. Glasskube itself will still require be quite powerful, but we can than scope packages and introduce granular permissions.

Yes, but no concrete plans.

We already looked into pkl, but this would require every package author to either have Java (and pkl) running on their system or we would need to package the jre (and pkl) in order to make it work probably. But Kubernetes examples are already out there (https://github.com/apple/pkl-k8s-examples) and we are keeping an eye on it.

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

Yes at the moment Glasskube packages wrap around Helm charts and manifests. We don't have a dedicated packaging format as of now.

We are actively looking into OCI images and other possibilities to bundle Kubernetes packages, but focus on features like multi namespace dependencies and simplicity at the moment.

How would you like to package Kubernetes packages or what should be avoided from your perspective?

What about `kubectl rollout restart deployment your-deployment` ?

Hi Justin

We have a comparison page with OLM here: https://glasskube.dev/docs/comparisons/olm/

Compared to Helm v2 the client doesn't talk to the controller (server) component directly, we only interact via the Kubernetes API and everything is stored in CRs.

A complete architecture Diagram can be found in our docs: https://glasskube.dev/docs/

Do you have any specifc questions or concerns? Are you facing any challenges in working with packages in Kubernetes? Also happy to jump on quick call. Feel free to contact me via LinkedIn: https://www.linkedin.com/in/pmigat/

Hi,

I'm Philip the second Co-Founder of Glasskube and happy to answer all technical questions and comments about Glasskube and Kubernetes. :-)

It's important to remember that if you perform signed commits you need to upload the public key to either your VCS :-).

Philip here, one of the maintainers behind Glasskube - the authors of the blog post. We currently working on a package manager for K8s and would love to perform user interviews with helm users and non-users.

If would could help we would love to talk to you!

Nice, sadly this is not available for Linux

I have been looking for a simple way to search and copy emojis for a long time and recently stumbled upon emojidb.org.

Makes sense! I like the approach.

Nice project, I really like the idea. Is it possible to create multiple log streams at once?

> That’s not something I’m able to do yet.

I'm not able to perform that prompt any tricks needed?

The website definitely looks nice. How does it compare to Strapi or Gatsby?

We recently chose cobra[1] to create a cli application. It comes with so many best practices already packaged like autocompletions, help texts etc. etc.

[1]: https://github.com/spf13/cobra

Yes, but only because I wonder if its just me or other people super skeptical about this account..

We are actually considering it internally as it solves our problem in combination with go templates and server side rendering.

I would either go with a pwa approach and your favorite front-end technology like Angular, Vue or React or just go native with Kotlin. Everything else will always be a trade-off like Flutter, ReactNative etc...)

Zwift must have a lot of seasonal variances for their revenue. I don't no anyone who is using swift during summer times. It's probably hard to build a recurring revenue business around it, because you have to fight for the users every season again against (cheaper) compatitors.

The first time I saw their X account I wasn't sure if it was serious project or not. Is this a valid marking strategy?

One if the decision points for us using Flux was the the helm controller. ArgoCD will just render the helm chart and apply the manifests. If you already habe an Helm Release in your cluster the migration path was easier with flux.

Flux for me was always superior to ArgoCD from a technical point of view, but they over the years ArgoCD became the more popular tool. I wonder if it was marketing, the missing UI or something else?

But super sad to see weaveworks shutting down I hope that the open source projects will continue to evolve.

Thanks!

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.

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.

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

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.

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.

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.