Getting tired of Helm – any better way to handle deployments in Kubernetes?

I’ve been deep in Helm templates lately and it’s starting to feel like YAML hell. It was fine when we had a few services, but now it’s just hard to manage. Anyone found a workflow that avoids Helm altogether? Or made Helm manageable at scale?

25 points | by DeborahEmeni_ 61 days ago

18 comments

  • atmosx 61 days ago
    Kustomize 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.
    • GauntletWizard 61 days ago
      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)

      • atmosx 59 days ago
        > 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.

  • haiku2077 61 days ago
    ArgoCD for relatively simple stuff.

    For complex stuff I write Python or Go programs to build manifests, then shell out to kubectl apply. An old example - deploying a multi-instance modded Arma 3 server on k3s: https://github.com/dharmab/homelab-k3s/tree/main/lab

    • a-saleh 55 days ago
      Why just simple?

      T.b.h. if I were to write a manifest generator, I would still probably commit the thing into a repo and let argo do the rest. Maybe even fiddled around to make the generator into a config-management-plugin ... but that feels like over-doing it.

  • b11484 61 days ago
    I've been working on improving a tool called kr8+, which uses jsonnet to combine cluster config and apply it to components: https://github.com/ice-bergtech/kr8
  • 1024kb 60 days ago
    What 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.

  • arccy 61 days ago
    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.

  • a-saleh 55 days ago
    Recently I have been writing more stings in jsonnet. If I were with more haskell-friendly team, might even try dhall. In general, I feel like writing the yaml in something else than yaml is the way to go, and as long as you get imports and way to do templating that is not just string interpolation, you are good.
  • natbennett 61 days ago
    I prefer ytt for templating and kapp for deployments.

    https://github.com/carvel-dev/carvel

  • uaas 57 days ago
    IMHO at scale (both in terms of complexity and org level) having something consistent helps more than trying to fight the de-facto standard. Since most upstream projects are mainly distributed as Helm charts, going with anything else will require more effort eventually.
  • Open-Sourcery 60 days ago
    Holos.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)
  • bithavoc 61 days ago
    I use Pulumi native package for Kubernetes, no more YAML, only instances of Typescript classes.
  • LarsLarson 61 days ago
    We are using kustomize to create the yaml and argocd for deployment. All via ci and git-ops.

    works really well

    • GauntletWizard 61 days ago
      I'm a huge fan of Kustomize. I'm ambivalent towards argocd, but Kustomize is as close to a DWIM tooling as it's possible to get for Kubernetes.
    • OhSoHumble 61 days ago
      Also using Kustomiza and Argo. It's really good imo.
  • dvektor 61 days ago
    Yeah the whole 'git repo = helm chart' just does not feel great at all. As we all know, the only thing worse is not using helm and having to deal with writing all those service, pv, pvc, ingress yaml files individually :)
  • gtirloni 59 days ago
  • Nerudite 61 days ago
  • Kerbonut 60 days ago
    I built my own tooling around templated manifest files (jinja2) and management via ansible playbooks (templated).
  • Vespasian 61 days ago
    My recommendation is fluxcd for a great gitops based workflow (incorporates soap for secrets)
  • delduca 61 days ago
    +1 for Kustomize
  • johnjungles 61 days ago
    ArgoCD