I am at the point where I am probably going to avo...
# kubernetes
I am at the point where I am probably going to avoid helm as a whole from my pulumi stack If there is something I wish to install, I would rather grab it’s docker image and deploy it independently as a pulumi deployment, instead of with helm. Helm is finicky and non-deterministic, even as
. I know Pulumi tries to “translate” helm using the
object, but its never worked for me given that most helm packages use Helm hooks, and as such only work with
The latter is a black box to Pulumi that just causes all sorts of issues and problems. I like Pulumi and I’m sticking to it, but helm is just not a very good thing Unless the
way by Pulumi starts maybe interpreting helm hooks. Anyone else struggling with Helm and made the same resolution?
Absolutely understand where you're coming from, I feel the same. I've found
works fine most of the time for simpler charts, but they generally don't have hooks anyway. Using Release in those cases makes for a good cost-saving measure if you're using Pulumi Cloud. It's my experience with helm as a tool in general too, so I really don't blame pulumi for it. I actually had my CI do a retry when pulumi fails to work around the flakiness.
It's disappointing that the issue for hook support in Chart was closed with the
object: https://github.com/pulumi/pulumi-kubernetes/issues/555
same story here, we try not to use helm at all and that's even with helm 3+, previous versions were even worse
I am not and never have been a fan of Helm, and generally do my best to avoid it at all costs. (Speaking personally here, not on behalf of Pulumi.)
It's been a while since I looked into it, but it'd be technically possible to implement hooks + the lookup api into the Chart resource. Would provide a good balance of compatibility with Pulumi's superior support of... well, everything k8s 😆
I would be okay with this if I didn't need helm in the interim before jumping into kustomize and flux.