First, there has been a lot of talk about how much work it is to onboard to Kubernetes. There have even been recent discussions in Kubernetes SIGs. In UX terms, Kubernetes has a high barrier to entry.
I realize that many people who use and know Kubernetes like it. We folks are a group that has gotten past the high barrier to entry. Most have not.
Second, Helm is a package manager. It's like apt, yum, homebrew, and others. It lets someone who knows how to run an application (ops business logic) on a platform (like debian or k8s) and package it up so someone else who doesn't know this can easily run an application. This is why so many use brew and apt to install something rather than install everything by hand.
Something like jsonnet doesn't solve for these situations.
I know some folks don't like text-templating. I'm not a big fan of go templating. But, templating is something that people are used to and generally comfortable with. This means it has a fairly low barrier to entry.
Notice, a lot of the reasons for why Helm does things is to reduce friction for a large audience. To reduce the barrier to entry.
Yeah, the core reason to use Helm is for the ecosystem. The value that comes from being able to quickly set up and compose packages on https://github.com/helm/charts/ is larger than the (very) annoying YAML templating and chart reliability issues.
Lots of Helm charts have bugs, but lots of PyPI/NPM/Maven packages have bugs as well.
Jsonnet, Cue, and operators are nice, but unless someone can create an ecosystem that is as valuable as the Helm ecosystem, I don't see Helm disappearing.
This resonated with my recent experience. I have been using Docker and docker-compose quite comfortably for a few years now. I thought it'd try and dip toes into Kubernetes to extend my containerization skill-set and learn something new.
I ended up shelving it until I have time to take a proper course and dedicate the time to it. Docker compose was very easy to learn for me, with a few easy early "wins" and reasonably comprehensive and helpful documentation when I wanted to expand into new areas. For some reason, I really struggled grokking how to structure a k8 chart. Maybe I'll try again after a good night's sleep.
Have you tried plain manifests? Unless you need to support a lot of permutations (because of many environments, or you're distributing it and need to support many deployment options), Charts are generally a suboptimal way to get things running in k8s.
The major "wins" for using charts are usually around being able to use the same set of manifests with different values interpolated in. Which in turn, is really only valuable if you're supporting a large number of permutations that need to be kept in sync.
Thanks very much for the suggestion! I really didn't know where to start and the first few sites seemed to dive right into charts but I'll check out manifests this time. Thanks again.
First, there has been a lot of talk about how much work it is to onboard to Kubernetes. There have even been recent discussions in Kubernetes SIGs. In UX terms, Kubernetes has a high barrier to entry.
I realize that many people who use and know Kubernetes like it. We folks are a group that has gotten past the high barrier to entry. Most have not.
Second, Helm is a package manager. It's like apt, yum, homebrew, and others. It lets someone who knows how to run an application (ops business logic) on a platform (like debian or k8s) and package it up so someone else who doesn't know this can easily run an application. This is why so many use brew and apt to install something rather than install everything by hand.
Something like jsonnet doesn't solve for these situations.
I know some folks don't like text-templating. I'm not a big fan of go templating. But, templating is something that people are used to and generally comfortable with. This means it has a fairly low barrier to entry.
Notice, a lot of the reasons for why Helm does things is to reduce friction for a large audience. To reduce the barrier to entry.