I vividly remember the early days of my DevOps journey—things felt straightforward until Docker came along. Then, Kubernetes entered the scene and I initially felt overwhelmed. However, as I delved deeper into it, my discomfort eased. I also began discovering numerous tools that made working with Kubernetes more efficient and seamless. In this blog post, I will discuss one of those tools: Helm.

What is Helm?

Helm is a package manager for Kubernetes that simplifies the deployment and management of applications. Users can define, install, and upgrade complex Kubernetes applications using pre-configured packages called charts.

Challenges with Helm

• Package Management: Helm facilitates the deployment of Kubernetes applications through pre-configured packages known as charts.

• Template Engine: Deploying multiple microservices in Kubernetes involves repetitive configuration tasks. Helm's templating engine addresses this by enabling the creation of a common blueprint for all microservices. Using placeholders in a template file, dynamic values are sourced from an external configuration file, reducing redundancy and enabling easy customization.

• Cross-Cluster Deployment: Helm simplifies the deployment of the same application across various Kubernetes clusters by creating an application chart. This bundles all required YAML files into a single chart, streamlining the deployment process and enabling easy redeployment across different environments with just one command.

• Rollback and Upgrades: Helm facilitates smooth updates and rollbacks of applications by managing release versions and configurations.

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

Shortcomings

• No Automatic Upgrades for CRDs: Helm does not automatically upgrade Custom Resource Definitions (CRDs) when an application is installed. Typically, the user or developer must manually manage CRD changes, which can be error-prone.

• 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 multiple releases of different charts have the same dependencies, there is no method to share these dependencies between them. Each release installs its own copy of the dependency, potentially leading to duplication of resources and inefficiencies.

• Chart Creation: Helm generates numerous files across various subdirectories, which can make it challenging to distinguish between example codes and essential files for a chart.

• Maintenance: Helm does not manage the maintenance of an application once its release is installed.

Meet Glasskube

Glasskube is an open-source Kubernetes package manager that simplifies package management for Kubernetes. It features high dependency awareness, reduced complexities, and increased transparency. Check out their GitHub repository.

Features

• Streamlined UI and CLI: Glasskube offers a powerful UI and CLI without complexities.

• Package Updates: Packages installed using Glasskube are always installed in the latest version and provide automatic updates. A specific version can also be installed.

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

• Custom Resource Definitions (CRD): 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: Glasskube installs packages in the latest version and provides automatic updates. Users can explore new versions using the outdated command and upgrade them with the upgrade command.

• Dependency Management: Dependency management is a vital feature provided by Glasskube, accommodating the installation of specific packages required by multiple packages.

• Custom Resource Definition (CRD) Changes: Glasskube facilitates the upgrading of CRDs, ensuring synchronization between CRs and their operators.

• 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 ensures smooth upgrades across multiple Kubernetes versions by automatically testing all packages.

Conclusion

The Kubernetes landscape is replete with numerous tools, each having certain limitations and complexities. Adopting another tool may be necessary to overcome some limitations. While this might seem daunting, it's all about finding the right balance between functionality, ease of use, and compatibility with your specific infrastructure and requirements. The flexibility and vast ecosystem of tools and resources available make Kubernetes versatile and powerful.

Shoutout to Glasskube for collaborating with me on this blog.