5 ms·

> How else are you going to deploy pieces of k8s infra into k8s if not with Helm and Helm Charts? kubectl apply -f $MANIFESTS > you're still going to be using

by Bayart 4y ago

> How else are you going to deploy pieces of k8s infra into k8s if not with Helm and Helm Charts? kubectl apply -f $MANIFESTS > you're still going to be using Helm (if not indirectly via Argo) and you will inevitably need to template things that need to be dynamically configured at render-time. Use Kustomize for dynamic vars and keep it at a minimum. Templating is the root of all evil. Helm mostly adds unnecessary complexity and obscurity. Sure it's faster to deploy supporting services with it, but how often do you actually need to do that anyway ? The time you're initially gaining by using Helm might generate an order of magnitude more time in maintenance later on because you've created a situation where the underlying mechanics are both hidden and unknown from you.

vbezhenar 4y ago
> kubectl apply -f $MANIFESTS How do you configure it? Like you're installing new version, do you go over manifests and edit those by hand over and over every update? Do you maintain some sed scripts? helm is awesome because it separates configuration.
- Bayart 4y ago
  I actually used to sed configurations, now I use yq[0] whenever I need to programatically edit YAML/JSON. It has much less side effects. But for Kubernetes manifests specifically, the right tool for the job is Kustomize[1] (which in that case does what Helm does for you, keeping dynamic variables separate). It ships with kubectl and I'm a big believer in using default tools when possible. > Like you're installing new version, do you go over manifests and edit those by hand over and over every update? I check the patch notes, diff the configuration files to see if anything new popped up, do the required changes if necessary, jump the version number and deploy. It sounds laborious but it's really not that much work most of the time, and more importantly it forces you to have a good sense for what and how everything works. Plus it allows you to have a completely transparent, readable environment. Both are important for keeping things running in a production environment. Otherwise you might find yourself debugging incomprehensible systems you've never paid attention to in the middle of the night with 2 hours left before traffic starts coming in. [0]: https://github.com/mikefarah/yq https://github.com/mikefarah/yq [1]: https://kustomize.io https://kustomize.io
  - vbezhenar 4y ago
    Well, that makes sense but sounds like I would spend much more time than necessary for many packages. If that would be my full-time job, I guess it would work, but I just need to install something and move on to other things. Some packages install thousands of lines of yaml. I guess I would need more than one day to grok it. Installing it with helm is easy and it usually works. Something simple like GitLab probably would be impossible to understand for a simple person.
    - Bayart 4y ago
      Yeah, I might be thinking of it as simpler than it really is just out of habit. Though it has to be said than most Kubernetes resources are pretty pedestrian, with habit you know where to look for the meaningful bits (much like any other form of source code).

by Bayart 4y ago

vbezhenar 4y ago

> kubectl apply -f $MANIFESTS How do you configure it? Like you're installing new version, do you go over manifests and edit those by hand over and over every update? Do you maintain some sed scripts? helm is awesome because it separates configuration.

Bayart 4y ago
I actually used to sed configurations, now I use yq[0] whenever I need to programatically edit YAML/JSON. It has much less side effects. But for Kubernetes manifests specifically, the right tool for the job is Kustomize[1] (which in that case does what Helm does for you, keeping dynamic variables separate). It ships with kubectl and I'm a big believer in using default tools when possible. > Like you're installing new version, do you go over manifests and edit those by hand over and over every update? I check the patch notes, diff the configuration files to see if anything new popped up, do the required changes if necessary, jump the version number and deploy. It sounds laborious but it's really not that much work most of the time, and more importantly it forces you to have a good sense for what and how everything works. Plus it allows you to have a completely transparent, readable environment. Both are important for keeping things running in a production environment. Otherwise you might find yourself debugging incomprehensible systems you've never paid attention to in the middle of the night with 2 hours left before traffic starts coming in. [0]: https://github.com/mikefarah/yq https://github.com/mikefarah/yq [1]: https://kustomize.io https://kustomize.io
- vbezhenar 4y ago
  Well, that makes sense but sounds like I would spend much more time than necessary for many packages. If that would be my full-time job, I guess it would work, but I just need to install something and move on to other things. Some packages install thousands of lines of yaml. I guess I would need more than one day to grok it. Installing it with helm is easy and it usually works. Something simple like GitLab probably would be impossible to understand for a simple person.
  - Bayart 4y ago
    Yeah, I might be thinking of it as simpler than it really is just out of habit. Though it has to be said than most Kubernetes resources are pretty pedestrian, with habit you know where to look for the meaningful bits (much like any other form of source code).