5 ms·

> Use Helm. Or some other tool for managing Kubernetes manifests, I’m not picky – the important thing is that you ~never directly use kubectl apply, edit, or de

> Use Helm. Or some other tool for managing Kubernetes manifests, I’m not picky – the important thing is that you ~never directly use kubectl apply, edit, or delete. The resource lifecycle needs to be findable in version control. I'd say `kubectl apply` fits better with a Git oriented flow than the imperative `helm install` flow. Nothing about helm guarantees or forces you to use version control. Actually the opposite. If `helm install` fails. You need to `helm delete` first. It has no way of declaratively managing updates at all. Have a CI job call `kubectl apply -k ./deploy --prune` on every commit is way nicer than helm in my opinion.

cassianoleal 4y ago
Helm also hides complexity in the templates. There's a lot of valid complaints floating around YAML but what's worse than dealing with YAML is dealing with templated YAML. kubectl brings everything to the surface. Helm is an unnecessary abstraction.
- tecleandor 4y ago
  I think Helm can be nice to template mildly complex stuff you cannot reach simply with Kustomize, but it's true there are lot of things you can't see until you apply them, even when `helm lint` doesn't fail. If you need this templating, a think you can do is use helm for that but not for install/deployment: render the charts with `helm template` and then apply them with `kubectl apply` and/or verify the changes with `kubectl diff`. IIRC Argo CD can show you the differences between the running helm chart and the new version you want to apply if you haven't enabled automated syncing, but I only use Argo CD with Kustomize, so I can't say for sure right now. edit: by reading the article again I think the spirit of that point is not 'use just helm' but 'don't apply stuff directly'. Long term, if there's more than one person working in Kubernetes, that's prone to failure and configuration drift. Doing the templating in whatever language or system that fills your needs and then using something like Argo CD or Octopus to apply them can remove most of those problems.
  - pickledish 4y ago
    > by reading the article again I think the spirit of that point is not 'use just helm' but 'don't apply stuff directly' Yep, this is what I meant! Just "if you're using some kind of manager for your resources, which you probably are, then ONLY use that manager, don't just `apply` stuff out of band" is the idea :) I might take a pass later at making that more clear
- nijave 4y ago
  Helm templates tend to be too complex, in my opinion. On the other hand, having 50 services, deployments, ingresses, etc which have names/labels copy/pasted in 3-5 different places is also extremely complex--especially when you want to make a change to update all of them. Kustomize seems too basic--maybe JSONNet or something fills this gap
  - cassianoleal 4y ago
    I think one of the strengths of Kustomize is precisely that it's basic - although it may not be as basic as you think if you haven't used it in anger. I don't want complexity in my manifests. I want them to be to the point. Renaming in multiple places is very easy with find-replace.
Defitio 4y ago
Helm makes sure your tags and other metadata are the same in a more complex setup. It also allows to calculate a checksum for a config map which then triggers a restart of a deployment. It allows to do a proper release do to working conventions. It also makes it easy to pull out configuration options. I think kubectl apply is the worst option.
- thunky 4y ago
  Sounds like they're both the worst option.
  - Defitio 4y ago
    Why?
    - thunky 4y ago
      Because we can't begin to agree on how to do this in a standard way. The whole idea of git oriented flows seems to be an afterthought rather than being considered an important part of a standard production k8s deployment from the start. Here are some competing options I see after a quick glance in this thread: - kubectl apply -k ./deploy --prune - heml install - helm template + kubectl apply + kubectl diff - Kustomize - Argo CD - Octopus - JSONNet - Cue - Pulumi And because this is an advanced topic (most of the above require a large investment reading docs and github issues), I'm guessing many/most people never get beyond ad-hoc kubectl commands and letting their cluster run wild.
      - 0x457 4y ago
        Funny that most of those things don't compete: helm template and helm install are two entirely different things. Argo CD is just a way to deliver manifests to your cluster - manifests could originate from helm template, kustomize, raw manifests or JSONNet. kubectl apply -k is...well...Kustomize... There is a big distinction between first party software and third-party software. Helm is fine for first party software because you control the chart, but awful for 3rd party software because charts often don't have level of customization you need. Reinstalling shit with kustomize that was installed with helm is like 1/4 of my time at work. Kustomize won't get you 100% though because something has to generate base files first.
nine_k 4y ago
If you don't like Helm, there is Kustomize.
- spoiler 4y ago
  I'd like to second Kustomize. It's not getting enough popularity, IMO. It's also great because it doesn't break tooling by mixing in a templating language on top of a configuration language. If people need more than Kustomize supports, there's always Cue or Pulumi; I'd never recommend Helm, personally.
- kliaa 4y ago
  And if you don't like Kustomize, try Jsonnet. I wish this was a more common setup. This works very well at my company.
ElevenLathe 4y ago
FYI Argo is the evolution of this idea.
ciceryadam 4y ago
If install fails with helm, you can just rollback to previous release: helm rollback <RELEASE> [REVISION]
mikedelago 4y ago
I agree; helm is too declarative. Whenever I can, I use helmfile[0] for storing variables for helm since it does add a declarative layer on top of helm. 0 - https://github.com/roboll/helmfile https://github.com/roboll/helmfile
- allochthon 4y ago
  I tried helmfile, but helm state weirdness became enough of an issue that I investigated `kubectl apply -k` (which uses `kustomize`), and after I got it working it felt like a significant improvement over helm+helmfile. (But I still use `helm` to generate manifests.)

cassianoleal 4y ago

Helm also hides complexity in the templates. There's a lot of valid complaints floating around YAML but what's worse than dealing with YAML is dealing with templated YAML. kubectl brings everything to the surface. Helm is an unnecessary abstraction.

tecleandor 4y ago
I think Helm can be nice to template mildly complex stuff you cannot reach simply with Kustomize, but it's true there are lot of things you can't see until you apply them, even when `helm lint` doesn't fail. If you need this templating, a think you can do is use helm for that but not for install/deployment: render the charts with `helm template` and then apply them with `kubectl apply` and/or verify the changes with `kubectl diff`. IIRC Argo CD can show you the differences between the running helm chart and the new version you want to apply if you haven't enabled automated syncing, but I only use Argo CD with Kustomize, so I can't say for sure right now. edit: by reading the article again I think the spirit of that point is not 'use just helm' but 'don't apply stuff directly'. Long term, if there's more than one person working in Kubernetes, that's prone to failure and configuration drift. Doing the templating in whatever language or system that fills your needs and then using something like Argo CD or Octopus to apply them can remove most of those problems.
- pickledish 4y ago
  > by reading the article again I think the spirit of that point is not 'use just helm' but 'don't apply stuff directly' Yep, this is what I meant! Just "if you're using some kind of manager for your resources, which you probably are, then ONLY use that manager, don't just `apply` stuff out of band" is the idea :) I might take a pass later at making that more clear
nijave 4y ago
Helm templates tend to be too complex, in my opinion. On the other hand, having 50 services, deployments, ingresses, etc which have names/labels copy/pasted in 3-5 different places is also extremely complex--especially when you want to make a change to update all of them. Kustomize seems too basic--maybe JSONNet or something fills this gap
- cassianoleal 4y ago
  I think one of the strengths of Kustomize is precisely that it's basic - although it may not be as basic as you think if you haven't used it in anger. I don't want complexity in my manifests. I want them to be to the point. Renaming in multiple places is very easy with find-replace.

Defitio 4y ago

Helm makes sure your tags and other metadata are the same in a more complex setup. It also allows to calculate a checksum for a config map which then triggers a restart of a deployment. It allows to do a proper release do to working conventions. It also makes it easy to pull out configuration options. I think kubectl apply is the worst option.

thunky 4y ago
Sounds like they're both the worst option.
- Defitio 4y ago
  Why?
  - thunky 4y ago
    Because we can't begin to agree on how to do this in a standard way. The whole idea of git oriented flows seems to be an afterthought rather than being considered an important part of a standard production k8s deployment from the start. Here are some competing options I see after a quick glance in this thread: - kubectl apply -k ./deploy --prune - heml install - helm template + kubectl apply + kubectl diff - Kustomize - Argo CD - Octopus - JSONNet - Cue - Pulumi And because this is an advanced topic (most of the above require a large investment reading docs and github issues), I'm guessing many/most people never get beyond ad-hoc kubectl commands and letting their cluster run wild.
    - 0x457 4y ago
      Funny that most of those things don't compete: helm template and helm install are two entirely different things. Argo CD is just a way to deliver manifests to your cluster - manifests could originate from helm template, kustomize, raw manifests or JSONNet. kubectl apply -k is...well...Kustomize... There is a big distinction between first party software and third-party software. Helm is fine for first party software because you control the chart, but awful for 3rd party software because charts often don't have level of customization you need. Reinstalling shit with kustomize that was installed with helm is like 1/4 of my time at work. Kustomize won't get you 100% though because something has to generate base files first.

nine_k 4y ago

If you don't like Helm, there is Kustomize.

spoiler 4y ago
I'd like to second Kustomize. It's not getting enough popularity, IMO. It's also great because it doesn't break tooling by mixing in a templating language on top of a configuration language. If people need more than Kustomize supports, there's always Cue or Pulumi; I'd never recommend Helm, personally.
kliaa 4y ago
And if you don't like Kustomize, try Jsonnet. I wish this was a more common setup. This works very well at my company.

ElevenLathe 4y ago

FYI Argo is the evolution of this idea.

ciceryadam 4y ago

If install fails with helm, you can just rollback to previous release: helm rollback <RELEASE> [REVISION]

mikedelago 4y ago

I agree; helm is too declarative. Whenever I can, I use helmfile[0] for storing variables for helm since it does add a declarative layer on top of helm. 0 - https://github.com/roboll/helmfile https://github.com/roboll/helmfile

allochthon 4y ago
I tried helmfile, but helm state weirdness became enough of an issue that I investigated `kubectl apply -k` (which uses `kustomize`), and after I got it working it felt like a significant improvement over helm+helmfile. (But I still use `helm` to generate manifests.)