4 ms·
Very interesting. I've been reluctant to adopt Helm for Kubernetes resource management because of a gut feeling that it's a heavyweight solution for what seems
by jka 7y ago
Very interesting. I've been reluctant to adopt Helm for Kubernetes resource management because of a gut feeling that it's a heavyweight solution for what seems broadly like a templating problem.
With ksonnet having gone quiet[0] this looks like a promising initiative.
I'd imagine that it'll need something like a package manager (or at least a curated list of common packages) in order to gain good adoption.
[0] - https://blogs.vmware.com/cloudnative/2019/02/05/welcoming-heptio-open-source-projects-to-vmware/ https://blogs.vmware.com/cloudnative/2019/02/05/welcoming-he...
- nouney 7y agoTake a look into kustomize https://github.com/kubernetes-sigs/kustomize https://github.com/kubernetes-sigs/kustomize
- jka 7y agoThanks! I had briefly used kustomize in the past, and it looks really useful for creating alternative dev/staging/production environments from a common base. In the end I decided that I'd collapse all environments down to behave identically, which is simpler, but does add a few constraints for development in particular. Will take another browse through while considering options for upcoming infrastructure :)
- MetalMatze 7y agoThe problem for us monitoring / observability people with kustomize is its limitation to be purely templating for Kubernetes. However we also want to template a lot of things like for example Prometheus configuration. Jsonnet can bridge that gap between the two worlds and in the end generate a ConfigMap YAML file that includes another YAML file Prometheus, as an example.
- slig 7y agoI tried to use kustomize recently but could not figure out how to write Job/CronJob properly. I wanted to use the configGenerator/secretGenerator, with prod/stage/dev.
- rfratto 7y agoGrafana Labs employee here. We've been using jsonnet-bundler as a package manager on top of our Tanka configs. As for some common packages, we open source most of ours[1]. We also provide Tanka-compatible configs for Loki[2]. [1]: https://github.com/grafana/jsonnet-libs https://github.com/grafana/jsonnet-libs [2]: https://github.com/grafana/loki/tree/master/production/ksonnet https://github.com/grafana/loki/tree/master/production/ksonn...
- jka 7y agoThanks a lot! I'll give these a try soon and provide any feedback via github.
- nodesocket 7y agoI'd also recommended taking a look at using Terraform[1] to manage Kubernetes resources instead of yaml files and kubectl. [1] https://www.terraform.io/docs/providers/kubernetes/guides/getting-started.html https://www.terraform.io/docs/providers/kubernetes/guides/ge...
- deleted 7y ago[deleted]
- cbushko 7y agoI agree. Terraform and it's providers are unbelievably powerful for deployments. Being able to create any sort of resource and passing that information onto your kubernetes service to use is really great. An example would be creating a dynamically names S3 bucket and passing it onto your service to use/manage. The same goes with anything needing credentials. Very powerful.
- kaidon 7y agoI usually just deploy "GKE clusters, node pools, AWS route 53, S3 buckets, etc" in terraform. Then take the terraform output and convert it to command line options that I pass to helm when deploying a kubernetes cluster. I'd be very tempted to just use terraform. But helm, with our forked charts, extensive values.yaml files, etc. has permiated the deployment. So... rather than try to break up the helm beast; I leave it and keep the separation of concerns (infrastructure vs k8s) as described at the beginning. It works pretty well to be honest is rarely the source of problems.
- cbushko 7y agoSomething that really helped me convert our helm charts to terraform was this little tool that convert yaml to terraform HCL. I would just render out the helm template and convert it. Note: It uses the kubernetes terrform provider and only support those objects https://github.com/sl1pm4t/k2tf/ https://github.com/sl1pm4t/k2tf/