This message was deleted.

There’s no need to port helm charts to pulumi code. There’s a pulumi subprovider in the kubernets provider. https://www.pulumi.com/blog/using-helm-and-pulumi-to-define-cloud-native-infrastructure-as-code/

i'd use the yaml.configfile over helm

Thank you very much for your replies, this helped me a lot. I was irritated by the note on github https://github.com/pulumi/pulumi-kubernetes#deploying-a-helm-chart, stating it would be primarly for experimentation and transitioning. I also found a sample meanwhile that shows how to retrieve properties from resources created with helm or yaml using getResourceProperty() function. Thanks again for your help!

Largely agree with @cool-egg-852—lots of customers do precisely this. I do think it depends somewhat on what you’re doing. A common pattern in the helm ecosystem is, when a chart (usually not one of the top 5) doesn’t do exactly what you need, you end up forking it. In those cases it may or may not make sense to do a transition.

Being able to use helm charts is an essential interop boundary

Thanks for further clarification. I will keep in mind to critically reflect on "just" using a helm chart depending on my requirements. For the ingress-controller and cert-manager I'm going to start with the helm charts right now.

i switched from helm to the manifest files for nginx ingress and cert-manager because i got a lot of issues with upgrades

Oops. Can you elaborate a little which issues you've seen and why that was better when using the manifest files?

i think the cert-manager guys have swapped from being helm-first to manifest-first in terms of their recommendations

ah, ok. I'll have a look into their docs again. I'll defineteyl try the manifest files after the helm deployment is running. Thanks for sharing your experience.

If you use helm with pulumi you should not install tiller. It won’t be used anyways.

Ok, I have the helm part already working. I'll nevertheless try it with manifest files as well, just to learn some more options I have with pulumi. There is still one thing I can't figure out from the docs and examples. If I e.g. deploy an ingress-nginx with helm, how would I retrieve the external ip of the load balancer so I can make it a Output in my pulumi stack?

That’s the tricky part unfortunately. However, we personally never rely upon IPs outside of the stack. We always use DNS entries. This makes it easier for us as applications don’t need to be updated if the IP changes.

As I read your words, I realize that this is exactly what I want to achieve, creating an A entry for this ip. I just wanted it to output (or maybe better log it) somehow. I found a code snippet that hopefully helps me getting the ip, since I will need it anyways - either for logging it or using it to create a DNS entry. Is there any documentation around on how to read such values from a yaml.ConfigFile or a helm.v2.Chart?

you can parse the Resource[] that it returns

It sounds like

getResourceProperty

may be what you’re asking about. See https://github.com/pulumi/examples/blob/master/kubernetes-ts-helm-wordpress/index.ts#L21 for an example

@better-rainbow-14549 Thanks for your thoughts on that. I'll remember this for the next Azure based project. This one is on digital ocean and they don't yet support assigning static ip to load balancer, so I have to go the other route.