Another question - At what point should a team move from regular Kubernetes manifests to Helm? In our case we have relatively little custom development and are using off-the-shelf components. We've already chose to use Helm, but I'm wondering if there's a place where we should be stepping back to regular Kubernetes manifests.
I think usually the reason people start using Helm is they want to install something like Prometheus or cert-manager in their cluster, but don't want to write their own manifests for that. They just want the equivalent of apt/yum/brew/etc. for k8s so they install whatever supporting tooling they need from the public stable helm charts. And then they realize they may need some minor customization with their own application manifests, and helm can do that too so they start using it for their own apps also.
If you don't need to install any extra 3rd party tooling in your clusters, like an ingress controller, or prometheus, or a fluentd log collector, and all you need to do is some basic variable substitution in your manifests across environments then something like kustomize is probably a better fit. I've also seen folks only use helm by doing for the values substitution, but none of the rollbacks, hooks, or other helm features.
Further to what Justin says, I agree that Helm can seem like (and be) overkill if you just want to template some variables into your manifests. On the other hand, it does three cool things:
1. You can install third-party software using public charts
2. You can have people install your software by publishing a chart.
3. You can manage releases, see release history, roll back to a specific release, and trigger actions using Helm hooks.
So it's certainly worth trying out, and we give a complete introduction to Helm in the book and show you what a chart looks like and how it works, and how to write your own charts. But I don't think we'd say it's an absolute must-have.
posted 2 weeks ago
In my case we are using Prometheus and we also manage services that are published by 3rd party providers and these providers are promoting the use of Helm. I see the benefits in the release and rollback functionality, so for this reason alone we'll continue down this path.
I hadn't considered publishing our own charts, but I can see where this may be useful for my team. I'll have to check-out the section of your book on Helm.
posted 2 weeks ago
Helm definitely adds a bit of complexity to the stack and there are plenty of things about Helm where I sort of scratch my head and am like "Really...???"
I'm glad that they moved away from tiller in Helm 3 and I am impressed by the dedication of the Helm maintainers so I am confident that it will be around for awhile and continue to get better and better.
I could see helm and kustomize eventually turning into something like apt VS yum in the Debian/RedHat world. I occasionally stumble upon k8s projects that are already offering both a helm chart as well as kustomize configs for installing their service. That's a bummer for the devs who now have to support 2 "package formats" but that's an age-old problem in tech that likely won't go away anytime soon.
I think the big win is by making things standard, so if helm makes it easier for you to install something upstream like prometheus and that works for you, then you will likely also find it beneficial to use helm to install your own apps, mainly because it helps to make things consistent. When someone asks you "How do I install x into our cluster?", it's much easier when there is only 1 answer and 1 way to do it.
There are plenty of things I don't like about helm, but I could say the same thing about apt, yum, brew, npm, gems, pip, etc. Ultimately I just want a standard way to install things that I don't have to build/write/maintain myself that mostly everyone else in the community is also using. And helm, for now, is mostly that.
We're all out of roofs. But we still have tiny ads: