When it comes to handling complex infrastructures, Kubernetes is the first solution that comes to mind. Within our Kubernetes cluster, deployed applications consist of multiple interconnected objects, making the application complex. Each object typically has its own YAML file, and for our application to function properly, each file must be run using the kubectl apply command separately.

This is not ideal if we download these YAML files from the internet and want to change some default configurations. Making numerous changes means going through each file one by one, which is time-consuming. Additionally, when we want to uninstall the app later, we have to remember all the objects that belong to the app and delete them individually.

Solution: Helm?

Helm is a package manager for Kubernetes. Instead of dealing with individual application objects separately, Helm treats them as one large package. When a user needs to perform an action, they simply specify the package they want to work with, rather than listing all the specific objects. By recognizing the package name, Helm automatically identifies which objects need modification and handles the process accordingly.

With Helm, installing an entire application, even if it consists of multiple objects, is as simple as running a single command. Helm takes care of adding all the necessary objects to Kubernetes automatically. We can customize the settings for our app or package by specifying desired values at the time of installation, rather than editing multiple values in multiple YAML files.

Although Helm is an effective and widely adopted tool in the Kubernetes ecosystem, it has some limitations.

Shortcomings of Helm

Inconvenient Chart Creation: From my first experience with Helm, I remember creating a new chart and feeling completely overwhelmed. Many files were generated, making it incredibly difficult to navigate through all of them.

When I researched online to understand the contents of these files, I found a quote that stuck with me: “The first step in creating a chart is running helm create. The second is deleting 90% of the results.”

The directory looked something like this:

my-chart/
├── Chart.yaml
├── charts/
├── templates/
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   ├── hpa.yaml
│   ├── ingress.yaml
│   ├── service.yaml
│   ├── serviceaccount.yaml
│   └── tests/
│       └── test-connection.yaml
└── values.yaml

Complex serviceaccount.yaml file: Another confusing aspect was viewing the templates/serviceaccount.yaml file, which had the following content:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: {{ include "{{ .Chart.Name }}.fullname" . }}
  labels:
    {{- include "{{ .Chart.Name }}.labels" . | nindent 4 }}

At first glance, the file looks very different from standard YAML files. What do include, nindent, and all those symbols even mean?

After spending quite some time researching, I discovered that although Helm template files use the YAML file extension, they are Go templates.

No Automatic Upgrades for CRDs: In Helm, packaging Custom Resource Definitions (CRDs) is done by placing them in a dedicated crds directory. While upgrading charts, the upgrade of CRDs is intentionally ignored to prevent accidental data loss. However, this can lead to error-prone manual updates by engineers.

Helm Dependencies: In a Helm chart, dependencies are included as sub-charts. This creates an issue because sub-charts are installed in the same namespace as the primary release. If two releases share the same dependencies, there is no method to share dependencies between them.

Inconsistent values.yaml file pattern: Creating a values.yaml file for a chart release is different because there is no general schema for it. The only way to verify if your values.yaml file is valid is to run it through Helm. Using helm template allows you to render templates and detect possible errors in the configuration file.

Static Deployment: Once a Helm release is successfully installed, Helm doesn't help you maintain and keep the installation running. Additionally, it cannot perform any additional changes. This inability to interact with the release during its lifecycle means that Helm as a deployment method is inherently static.

While Helm may seem complex to some, its simple design made it the go-to tool for Kubernetes deployment methods. Just because something is widely adopted doesn't mean we shouldn't challenge its design and point out shortcomings.

Enter Glasskube

Glasskube is an open-source Kubernetes package manager that simplifies package management and empowers users to effortlessly install, upgrade, configure, and manage Kubernetes cluster packages. It streamlines repetitive and cumbersome maintenance tasks.

Why Glasskube?

Glasskube offers a package management solution with a user-friendly UI, reducing complexity and enhancing transparency. This can be a great alternative to traditional package managers that are quite complex and cumbersome to use. Additionally, for experienced developers, a brew-inspired CLI is also available.

Glasskube: Features

Streamlined UI and CLI: Glasskube does not contain unnecessary complexities and offers a powerful UI and CLI.

Automatic Updates: Minimal manual effort is required to update your application as Glasskube always installs the latest version and provides automatic updates.

Dependency Management: Dependency management is a crucial feature of Glasskube, as multiple packages may require specific packages to be installed.

Custom Resource Definitions (CRDs): Glasskube facilitates the upgrading of Custom Resource Definitions (CRDs), ensuring that CRs and their operators remain synchronized.

GitOps Ready with ArgoCD or Flux: Glasskube can be integrated into GitOps workflows, supporting popular tools like ArgoCD or Flux.

Glasskube vs. Helm

Package updates: One of the most helpful features of Glasskube is its ability to keep packages up to date by installing the latest versions and providing automatic updates. The outdated and upgrade commands make exploring new versions and applying updates seamless and efficient.

Dependency management: Glasskube allows the installation of specific packages required by multiple applications, which is incredibly useful. It significantly reduces conflicts and ensures the system remains stable and reliable.

Custom Resources Definition (CRD) changes: Using Glasskube to upgrade CRDs keeps CRs and their operators in sync.

Cloud-Native Architecture: Helm operates with a client-side architecture, processing and applying templates using the Kubernetes API. As Helm lacks a first-party server-side component, it is challenging to deploy packages using a GitOps approach, even though the releases are stored in Kubernetes Secrets.

Kubernetes version upgrade compatibility: Glasskube emphasizes simplicity and efficiency for users handling multiple packages across Kubernetes version upgrades.

To clarify, "Glasskube is no replacement for Helm." Helm provides developers with strengths in configuring releases. On the other hand, Glasskube mainly focuses on the administrative side, needing to install and customize a single application and ensuring multiple packages are kept up-to-date.

How to Get Started with Glasskube

Getting started with Glasskube is easy; all you need is a Kubernetes cluster and Glasskube.

Resources that might be helpful:

• Glasskube Docs

• Glasskube Installation Guide

• GitHub

How to Contribute to Glasskube

Glasskube is an open-source project that accepts code contributions and documentation changes on GitHub.

Everyone who wants to contribute is welcome – whether it's giving feedback, sharing insights, or contributing to documentation and code. Every contribution, no matter how small, is valued and greatly appreciated.

If you find Glasskube helpful and interesting, please give it a star on GitHub to show your support.

Conclusion

In conclusion, as we seek easier ways to manage Kubernetes packages, the importance of user-friendly tools and streamlined processes becomes clear. Simplifying interfaces, automating updates, and ensuring reliability are key goals as we evolve in managing applications on Kubernetes.

Shoutout to Glasskube for collaborating with me on this blog.