K8s Anti-Design Pattern Series – The absence of Helm

Introduction:

For the time being, Helm is the only option for managing Kubernetes packages. Helm can be compared to the popular package management tools apt and rpm. The powers of Helm are often overstated, leading people to reject it in favour of a less effective “alternative.” If you’re looking for a package manager with templating skills, look no further than Helm. Comparing it to any of the existing templating options is a red herring. It’s a problem shared by all Kubernetes formatting solutions: inconsistent output. They can work their wonders during the deployment of an application, but once that process is complete, Kubernetes is left knowing nothing but a collection of manifests. The only way to bring back the lost “application” is to have access to the initial source files.

In contrast, Helm is aware of the entire application and keeps data relevant to that application in the cluster. After a programme has been deployed, Helm monitors the resources it uses. The distinction is marginal but meaningful.

In this example, we’ll assume you have kubectl access to a cluster with 4 applications, each of which is made up of numerous resources. One of these programmes needs to be removed, and that’s your job.A basic templating solution (like Kustomize) makes it difficult to deduce the architecture of an application by inspecting its currently active resources. You will need to manually inspect resources with kubectl and establish the correlations between the application components if you do not have the original templates (i.e. kustomizations and original patches).

Monitoring

Helm, on the other hand, monitors the applications within the network. In a nutshell, you can Say

helm ls (to look at the list of applications in the namespace)

helm uninstall my-release (to remove the application)

No access to the original templates is needed or to a CI pipeline.

Helm is much more than a templating solution, so comparing it to Kustomize/k8compt/kdeploy and similar utilities is misleading.

The ability to revert to a previous state is one of Helm’s most impressive characteristics. You get a page at 3 a.m. and need to execute the quickest possible rollback in a Kubernetes cluster you’ve never worked with before. There isn’t enough time to go through Git’s history of template revisions and figure out which one is the “prior” one.

A simple click of Helm’s button will accomplish this.

helm ls (to see releases)

helm history my-release (to see previous versions of deployments)

helm rollback my-release my-previous-version

Helm is able to do all of this without leaving the cluster because it understands what an application is, in contrast to templating systems that are idle once a deployment is complete. It’s also widely believed that modifying a chart necessitates duplicating the original chart and making local modifications there. It is recommended that Helm charts be maintained in dedicated Helm repositories. To distribute a Helm chart to a cluster, you should use the Helm repository, not the Git repo, though having a duplicate in Git is fine (as per the GitOps paradigm).

Helm-3

Also, since Helm 3, there is no longer a server-side component (the infamous Tiller), so if you were worried about the cluster’s security when you first assessed Helm, you should give it another try Helm is the equivalent of the package administration tools apt/rpm, and its absence would be unusual. It’s important to make an informed decision about whether or not to use Helm, rather than being misled into thinking that there’s “a better templating option than Helm.”