We are using kustomize to create the yaml and argocd for deployment. All via ci and git-ops. works really well
Also using Kustomiza and Argo. It's really good imo.
Getting tired of Helm – any better way to handle deployments in Kubernetes?
11–20 of 24 posts
Re: Getting tired of Helm – any better way to handle deployments in Kubernetes?
#12Kustomize is easier to manage at scale, but some upfront effort is required. Many charts are distributed as Helm packages, so you’ll often need to export them as raw YAML manifests. In an ideal setup, ArgoCD combined with Kustomize should cover most deployment needs. However, depending on your workflow, you may eventually need a way to dynamically replace variables. If the built-in tools in recent Kustomize versions aren’t sufficient, consider using envsubst as a fallback.
Re: Getting tired of Helm – any better way to handle deployments in Kubernetes?
#13if 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.
Re: Getting tired of Helm – any better way to handle deployments in Kubernetes?
#14Kustomize is easier to manage at scale, but some upfront effort is required. Many charts are distributed as Helm packages, so you’ll often need to export them as raw YAML manifests. In an ideal setup, ArgoCD combined with Kustomize should cover most deployment needs. However, depending on your workflow, you may eventually need a way to dynamically replace variables. If the built-in tools in recent Kustomize versions…
I handle deploy time dynamic variables with `sed`. You shouldn't need more complexity than that.
(Not that I haven't had the need, I've use jsonnet with libk8s at scale. But if you're asking the question this simply, you probably don't need it)
Re: Getting tired of Helm – any better way to handle deployments in Kubernetes?
#15+1 for Kustomize
Re: Getting tired of Helm – any better way to handle deployments in Kubernetes?
#16I use Pulumi native package for Kubernetes, no more YAML, only instances of Typescript classes.
Re: Getting tired of Helm – any better way to handle deployments in Kubernetes?
#17I built my own tooling around templated manifest files (jinja2) and management via ansible playbooks (templated).
Re: Getting tired of Helm – any better way to handle deployments in Kubernetes?
#18What exactly are you doing with Helm that's making it so painful to use, and what does your development workflow look like? I've certainly had my fair share of issues with Helm, especially when trying to get a bit too fancy with creating Helm libraries, and standardised charts. I've also found that trying to aggregate multiple charts into a single chart for deploying an environment can also become a nightmare to manage.
I'm currently looking at Helmfile so that I don't need to aggregate charts into a 'parent chart', and i'd also like to move towards a single standardised chart that all microservices can use, rather than spin up a new chart for each service.
Re: Getting tired of Helm – any better way to handle deployments in Kubernetes?
#19Holos.run for my homelab cluster. Cuelang has a learning curve but works well with argo unlike Timoni and let's you import existing charts, bare manifests, and use kustomize. Let's me abstract config with custom types and unification/(inheritance if that is easier to think about but a bit wrong)
Re: Getting tired of Helm – any better way to handle deployments in Kubernetes?
#20Kustomize is easier to manage at scale, but some upfront effort is required. Many charts are distributed as Helm packages, so you’ll often need to export them as raw YAML manifests. In an ideal setup, ArgoCD combined with Kustomize should cover most deployment needs. However, depending on your workflow, you may eventually need a way to dynamically replace variables. If the built-in tools in recent Kustomize versions…
I handle deploy time dynamic variables with `sed`. You shouldn't need more complexity than that. (Not that I haven't had the need, I've use jsonnet with libk8s at scale. But if you're asking the question this simply, you probably don't need it)
> I handle deploy time dynamic variables with `sed`
I brought up envsubst because it’s a simpler, cleaner, and often overlooked option for variable substitution.
> Not that I haven't had the need, I've use jsonnet with libk8s at scale. But if you're asking the question this simply, you probably don't need it
In my view, Jsonnet isn’t an improvement - it’s complicated to learn, cumbersome to use, and prone to mistakes.
That said, if an organization decides to adopt any specific tool, I believe consistency in tooling, design, and practices is more important than the tool itself.