Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I found it has strange defaults (all services publicly exposed) and quite unfriendly to automate. Ended up sticking with native deployments.


Yah so the few helm charts I have used, I had not seen a huge value. If I wanted to change something without a hook, I end up using my own dockerfile anyway.. so I guess it is helpful as just a reference on how to get a service to work, but not that useful for prod deploys.


We've standardized on helm for prod deploys. Perhaps it's not a huge value, but it is a convenient way to bundle together a set of configs, templatize them and manage them.


Seconded. We use Helm to deploy OpenStack (and various supporting services) on Kubernetes: https://github.com/sapcc/helm-charts and https://github.com/sapcc/openstack-helm


It can be very helpful for complex deployments.

For example, if you want to deploy a distributed TensorFlow training on kubernetes with multiple parameter servers and task servers, it is a nightmare to do just with kubernetes yaml templates. Helm and it's go templating makes it much much easier.


I don't think we could live without helm charts. There are so many moving parts, and developers, it really makes life far easier.


Of course I made this comment today, and have spent the last hour trying to fix an issue. Funny how life works like that :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: