11 ms·

Somehow I am able to get bye with Kustimise. Cant stand the mess that is helm and its eco system.

by leroman 2y ago

k8sToGo 2y ago
Do you rewrite all the apps that are out there as your own kustomize charts or what do you mean by "its eco system"
- leroman 2y ago
  Kustomize is basically a higher level file for K8s deployments, I have all the resources as declarative code that gets deployed when I apply the relevant directory. I have istio + ssl certs + services and any other resource, multiple projects with cross project communication and provisioning etc..
- leroman 2y ago
  By “eco system” I mean all the charts that get shared, when ever I try to look under the hood I instantly regret it..
  - lmm 2y ago
    So what do you do when you need to deploy something a bit fiddly with multiple components (e.g. Cassandra) that would just be importing a shared chart in Helm. Do you rewrite that yourself in kustomize?
    - leroman 2y ago
      Mostly look for an operator for that
joshuak 2y ago
Agreed. Adding black boxes on top of black boxes is not a good way to abstract complexity. Helm does nothing more than any template engine does, yet requires me to trust not only the competency of some random chart author but also that they will correctly account for how my k8s environment is configured. When I inevitably have to debug some deployment, now I'm digging through not only the raw k8s config, but also whatever complexity Helm has added on to obfuscate that k8s config complexity. Helm is an illusion. All it does is hide important details from you.
cortesoft 2y ago
I always see comments like this, and as someone who used Kustomize first and then moved to Helm, it really doesn't fit with my experience. I found Kustomize extremely annoying to work with. Changing simple configuration options required way too much work. Take a simple example - changing the URL value of an ingress. This is something every deploy is going to have to set, since it will be different for every cluster. In Kustomize, I first have to find the ingress resource, then recreate the nesting properly in my kustomize file, and then repeat that for every deployment. In Helm, I just change one entry in a values file, that is clearly named so I know what I am setting. In addition, it is REALLY hard to refactor resources once there are a lot of Kustomization files. If I want to redo how the deployment works, I have to change every Kustomize file that any other repo using my project uses. If I have a lot of other people who are pulling in my project and then using kustomize on top of it, we have to coordinate any changes, because changing the structure breaks all Kustomizations. With Helm, as long as I keep the same values file structure, I am free to move things around however I want. I can use values in completely new locations without having to change anything about the values files themselves. I just don't see how it is easier. I find it a lot easier to read a default values file and figure out what every setting does rather than read 20 k8s yaml files trying to figure out what does what. In some ways, I kind of feel like the Kustomize enthusiasts LIKE the things I find annoying about it; they think you SHOULD have to read every resource and fully understand it, and they don't want anyone to be able to change anything without every kustomizer also changing things. I get the theory that everyone should know the underlying resources, but in practicality I find Kustomize to be the wrong level of abstraction for what I want to do.

Somehow I am able to get bye with Kustimise. Cant stand the mess that is helm and its eco system.

k8sToGo 2y ago

Do you rewrite all the apps that are out there as your own kustomize charts or what do you mean by "its eco system"

leroman 2y ago
Kustomize is basically a higher level file for K8s deployments, I have all the resources as declarative code that gets deployed when I apply the relevant directory. I have istio + ssl certs + services and any other resource, multiple projects with cross project communication and provisioning etc..
leroman 2y ago
By “eco system” I mean all the charts that get shared, when ever I try to look under the hood I instantly regret it..
- lmm 2y ago
  So what do you do when you need to deploy something a bit fiddly with multiple components (e.g. Cassandra) that would just be importing a shared chart in Helm. Do you rewrite that yourself in kustomize?
  - leroman 2y ago
    Mostly look for an operator for that

joshuak 2y ago

Agreed. Adding black boxes on top of black boxes is not a good way to abstract complexity. Helm does nothing more than any template engine does, yet requires me to trust not only the competency of some random chart author but also that they will correctly account for how my k8s environment is configured. When I inevitably have to debug some deployment, now I'm digging through not only the raw k8s config, but also whatever complexity Helm has added on to obfuscate that k8s config complexity. Helm is an illusion. All it does is hide important details from you.

cortesoft 2y ago

I always see comments like this, and as someone who used Kustomize first and then moved to Helm, it really doesn't fit with my experience. I found Kustomize extremely annoying to work with. Changing simple configuration options required way too much work. Take a simple example - changing the URL value of an ingress. This is something every deploy is going to have to set, since it will be different for every cluster. In Kustomize, I first have to find the ingress resource, then recreate the nesting properly in my kustomize file, and then repeat that for every deployment. In Helm, I just change one entry in a values file, that is clearly named so I know what I am setting. In addition, it is REALLY hard to refactor resources once there are a lot of Kustomization files. If I want to redo how the deployment works, I have to change every Kustomize file that any other repo using my project uses. If I have a lot of other people who are pulling in my project and then using kustomize on top of it, we have to coordinate any changes, because changing the structure breaks all Kustomizations. With Helm, as long as I keep the same values file structure, I am free to move things around however I want. I can use values in completely new locations without having to change anything about the values files themselves. I just don't see how it is easier. I find it a lot easier to read a default values file and figure out what every setting does rather than read 20 k8s yaml files trying to figure out what does what. In some ways, I kind of feel like the Kustomize enthusiasts LIKE the things I find annoying about it; they think you SHOULD have to read every resource and fully understand it, and they don't want anyone to be able to change anything without every kustomizer also changing things. I get the theory that everyone should know the underlying resources, but in practicality I find Kustomize to be the wrong level of abstraction for what I want to do.