4 ms·
Interesting that they avoid helm. It is the "plug and play" solution for Kubernetes. However, that is only in theory. My experience with most operators out ther
by k8sToGo 3y ago
Interesting that they avoid helm. It is the "plug and play" solution for Kubernetes. However, that is only in theory. My experience with most operators out there was clunky, buggy, or very limited and did not expose everything needed. But I still end up using helm itself with the combination of ArgoCD.
- habitue 3y agoHelm is just a mess. If you're going to deploy something from helm, you're better off taking it apart and reconstructing it yourself, rather than depending on it to work like a package manager
- hobofan 3y agoIn my experience, if you use first-party charts (= published by the same people that publish the packaged software) that are likely also provided to enterprise customers you'll have a good time (or at least a good starting point). For third-party charts, especially for more niche software I'd also rather avoid them.
- szszrk 3y agoI think the important detail here is that he mentions he doesn't use it because of operators. That may mean they tried it in previous major version which used teller. That was quite a long time ago. That being said, helm templates are disgusting and I absolutely hate how easily developers complicate their charts. Even the default empty chart has helpers. Why, on Earth, why? I almost fully relate to OPs aproach to k8s but I think with their simplified approach helm (the current one) could work quite well.
- stackskipton 3y agoWe avoided Helm as well. We found that Kustomize provides enough templating to cover almost all the common use cases and it's very easy for anyone to check their work, kubectl kustomize > compiled.yaml. FluxCD handles postbuild find and replace. At most places, your cluster configuration is probably pretty set in stone and doesn't vary a ton.