helm-template

Cool! I just don't use the package management stuff. My workflow also has local manifest template rendering, but I use helm-template[0]. My chart is just a local directory, not a package or anything. Then, to release: * Render the chart and run it through kube-cloud-build[1] to make sure my containers are all built before I deploy: `helm template /path/to/chart | kube-cloud-build -r repo` * Deploy with helm: `helm upgrade RELEASE_NAME /path/to/chart` Has been working really well for me. [0] https://github.com/technosophos/helm-template [1] https://github.com/dminkovsky/kube-cloud-build

Helm is a lot simpler than it looks, and it’s awesome. I also had this exact perspective, not wanting to introduce more complexity and therefore held off on Helm for a long time. But then I got comfortable enough with Kubertnes and also my project got complex enough that I needed templating and then Helm was great to pick up. I just use one chart that I wrote for my application and I don’t mess around with repositories. I render the chart locally with helm template[0] to build my containers on Google Cloud container builder[1]. Then I deploy with helm upgrade. It’s a great flow! [0]https://github.com/technosophos/helm-template [1]https://github.com/dminkovsky/kube-cloud-build

We went down a similar path and ended up using helm-template [0] to render our helm charts without tiller. We also use an internal tool that: - maps applications to namespaces within clusters for different environments (since we have 1 cluster per environment) - does some magic around secrets to make them easier to interface with [0] https://github.com/technosophos/helm-template

This is an interesting use-case, one way you might be able to achieve this is using technosophos' template plugin[1] which will allow you to skip the trip to the cluster and render templates client-side. [1] https://github.com/technosophos/helm-template