cue-by-example

if you only work with your own stuff, helm is easily (and best) avoided. i like generating k8s yaml with cue, example: https://github.com/cue-labs/cue-by-example/tree/main/003_kub... there's also https://timoni.sh/ if you want a helm-like experience, but with cue instead of templating. If you're working with upstream projects, unfortunately many of them will only provide helm charts, so you got to decide between rewriting them to suit your env/tool, or just live with the crappiness of helm.

If you have 200 YAML files for a single service and 46 clusters I think you're using k8s wrong. And 5 + 3 different monitoring and logging tools could be a symptom of chaos in the organization. k8s, and the go runtime and network stack have been heavily optimized by armies of engineers at Google and big tech, so I am very suspicious of these claims without evidence. Show me the resource usage from k8s component overhead, and the 15 minute to 3 minute deploys and then I'll believe you. And the 200 file YAML or Helm charts so I can understand why in gods name you're doing it that way. This post just needs a lot more details. What are the typical services/workloads running on k8s? What's the end user application? I taught myself k8s in the first month of my first job, and it felt like having super powers. The core concepts are very beautiful