<p>I’m currently using kubernetes and I came across of helm.
Let’s say I don’t like the idea of “infecting” my kubernetes cluster with a process that is not related to my applications but I would gladly accept it if it could be beneficial.</p>

<p>So I made some researches but I still can’t find anything I can’t easily do by using my yaml descriptor and kubectl so for now I can’t find an use except,maybe, for the environizing.</p>

<p>For example (taking it from guides I read:</p>

<ol>
<li>you can easily install application, eg. helm install nginx —> I add an nginx image to my deployment descriptor, done</li>
<li>repositories -> I have docker ones (where I pull my images from)</li>
<li>you can easily helm rollback in case of release failure-> I just change the image version to the previous one in my kubernetes  descriptor, easy</li>
</ol>

<p>What bothers me is that, at level of commands, I do pretty much the same effort (helm update->kubectl apply).
In exchange for that I have a lot of boilerplate because of keeping the directory structure helm wants and I feel like missing the control I have with plain deployment descriptors ...what am I missing?</p>

<p>It is totally understandable your question. For small and simple deploys the benefits is not actually that great. But when the deploy of something is very complex Helm helps a lot.</p>

<p>Think that you have a couple squads that develop microservice for some company. If you can make a Chart that works for most of them, the deploy of each microservices would differ only by the image and the resources required. This way you get an standardized deployment and easier to all developers.</p>

<p>Another use case is deploying applications which requires a lot of moving parts. For example, if you want to deploy a Grafana server on Kubernetes you're probably going to need at least a Deployment and a Configmap, then you would need a service that matches this deployment. And if you want to expose it to the internet you need an ingress too. </p>

<p>One relatively simple application, would require 4 different YAMLs that you would to manually configure and make sure everything is correct instead you could do a simple <code>helm install</code> and reuse the configuration that someone has already made, sometimes even the company who created the Application.</p>

<p>There are a lot of other use cases, but these two are the ones that I would say are the most common.</p>
