[et1337]

The saddest part about Kubernetes is… after you set it all up, you still need a hacky deploy.sh to sed in the image tag to deploy! And pretty soon you’re back to “my dear friend you have built a Helm”. And so the configuration clock continues ticking…

[throwaway041207]

Claude Code has essentially fixed this perpetual annoyance for me. Doesn't matter if it's a hacked up deploy.sh that mixes sed, envsubst and god knows what or a non-idiomatic Helm chart that was perpetually on my backlog to fix... today I just say "make this do this thing and also fix any bash bugs along the way" and it just does it. Its effectiveness for these thousand-little-cuts type DevOps tasks is underrated IMO.

Now the actual CI/CD/thing-doers tools that all suck... I'm still stuck with those.

[mettamage]

I agree, I'm not great at devops, but my setup.sh and deploy.py have been game changers. Just vibe coding those was good enough.

Same with build.sh and doing it in such a way that I can use all the build.sh in my ci.yml for Github Actions.

[cassianoleal]

I have been using Kubernetes for 7 or 8 years now, and have nearly 100% stayed away from Helm.

Some Kustomize, a little bit of envsubst and we're good to go thank you very much.

[a456463]

This is why we don't take advice from randos on internet.

I manage 100+ variations on a single helm chart and 50+ such helm charts at work daily for 7 years across 11 datacenters/kubernetes clusters. And I have team members who swear by kustomize. The number of kustomize typo errors and issues that I have deal with is unimaginable. Whereas if I test and deploy a helm chart, I know it will work everywhere in every variation.

Kustomize is just plain terrible and backwards as a solution. It doesn't scale, it is half assed. It tries to basically require you to build your own compiler and parser and transform. With kustomize + envsubst: dear friend, you have built helm.

[supriyo-biswas]

How do you handle cleanups and hooks? The best way to do helm, at least for me, seems to be about limiting its use to simple templating use cases; if you end up needing an if, you've probably done something terribly wrong.

[cassianoleal]

That's my main gripe with Helm.

For the simple use case you're describing, Helm is not required. Plenty of other solutions around.

For use cases where it starts getting useful, we both agree that something has gone terribly wrong.

I still don't know why Helm exists. It's a solution that created lots of problems that didn't exist.

[antonvs]

My personal theory is that Helm may be ok for distributing a pre-packaged solution to other people. Then people mistook it for a tool that should be used in-house to deploy a company’s own systems, where it makes much less sense.

[a456463]

It makes absolute sense. You can use no variables and still deploy helm chart. It is a directory of plain old yaml objects. And add customization when you need as you evolve. Good luck doing that with kustomize.

[antonvs]

> And add customization when you need as you evolve.

Using one of the most horrible templating languages since ASP. Helm is what happens when a devops team decides to yolo into software development.

What's the issue with kustomize? It works well for us.

[arkeros]

You can rely purely on kubectl with something like:

cat manifests.yaml | kubectl apply -f - --server-side --field-manager "$FIELD_MANAGER" --prune --applyset "$APPLYSET" --namespace "$NAMESPACE"

[srcreigh]

Seems to be a case of the XY problem. What do you need cleanups and hooks for?

[supriyo-biswas]

Cleanups: I want to do a `helm uninstall` and have all the manifests go away at once instead of looking around for N different resources.

Hooks: I want to apply my database migrations and populate the database with static datasets before I deploy my application, without having my CI connect to the database cluster (at places I've worked, the CI cluster and K8s cluster were completely separate).

[vbezhenar]

Regarding cleanups: I'm using flux CD with kustomize. It tracks resources that it created. If I delete manifest from my repository, flux will delete resources that were created from these manifests. For me that's pretty much the ideal workflow.

Regarding hooks: I don't know. All applications that I've used, implemented migrations internally (it's usually Java with Flyway), so I don't need to think about it. One possible approach could be to use flux CD with Job definition. I think that Flux will re-create Job when it changes. So if you change image tag, it'll re-create Job and it'll trigger Pod execution. But I didn't try this approach, so not sure if that would work for you.

[cassianoleal]

> Cleanups: I want to do a `helm uninstall` and have all the manifests go away at once instead of looking around for N different resources.

    kubectl delete -f <manifests.yaml>

    kubectl delete -k <kustomization_directory>

> I want to apply my database migrations and populate the database with static datasets before I deploy my application, without having my CI connect to the database cluster

A Job feels like a good fit for this. CI deployes the Job without connecting to DB, Job runs migrations using the same connectivity as the application.

[johntash]

> apply my database migrations and populate the database with static datasets before I deploy my application

You could a) have the app acquire a lock in the db and do its own migrations, or b) create a k8s job that runs the migration tool, but make sure the app waits for the schema to be updated or at least won't do anything bad.

[0xbadcafebee]

There are a multitude of cases of operations which need to be performed before and after specific actions in K8s. It depends on the resource, operator, operational changes, state, bugs, order of operations, and more.

[a456463]

This is a BS claim with no proof. This is the strength of helm.

[bavell]

Going on 10 years now for me, tried Helm a bit and yep - all I've really needed was a package.json deploy script with sed to bump the image version.

[jeffrallen]

Or if your colleagues are "smarter" than you they make it in Clojoure instead, with an EDN-but-with-subroutines config language, so that not only yaml-aware editors are useless, but EDN-aware editors cannot make heads or tails of the macros.

Fun times.

[vbezhenar]

I don't understand you.

For very simple deployments, you don't need anything at all. Just write manifests and use `kubectl apply`. You can write `deploy.sh` but it'll be trivial.

If you want templating, there are many options. You can use `sed` for the most simple templating needs. You can use `cpp`, `m4`, `helm` or `kustomize`. I, personally, like `kustomize`, but `helm` probably not the worst template engine out there.

Kustomize is even somewhat included into basic kubernetes tooling, so if you want something "opinionated", it is there for you. It works.

[wg0]

Anyone remembers the GitOps thingy called flux? Weave was the company name.

Git and Kubetnetes configuration cannot go hand in hand. You cannot go back in past indefinitely because cluster state might not be that reversible. If so, git is useless.

And no, doesn't apply for database migrations. You can mostly run migrations backwards if each migration was written carefully.

[LelouBil]

I'm starting to use it for my self hosted services.

I have a "simple" representation of services using CUE, that generates the yaml manifests and flux deploys them.

I hesitated a while before going the k8s route but before that I had a overly error-prone Ansible configuration and I got sick of manual templating (hence the move to CUE for type safety).

There's also the fact that I wanted my services to be as plug and play as possible, so for example automatically generated openid credentials and very easily configurable central SSO, along with the easily configurable reverse-proxy.

If anyone thinks that k8s is not the best tool for this, I'm always interested in advice.

(Also a lot of complexity in my setup is due to self hosting, I have Istio, MetalLB, proxmox CSI, and all other kind of stuff that your cloud provider would already have, and these are the things that take most of the configuration files in my repo)

[Zizizizz]

I've used it in the past and personally loved it. Just bumping a yaml file in a git repo to the image tag I wanted deploying was a godsend and nearly automated. I can't speak to your experience though which I am certain is valid and a real problem. We just never had those kind of issues so we could either revert to an earlier tag that worked or publish a new image with the required resolution steps.

[Zizizizz]

https://fluxcd.io/ + helm + with a CI pipeline that pushes the docker images to a registry means that after the setup, anytime you push a new image and tag, k8s can automatically update without needing to do anything manual.

[btown]

And if you want your Helm to run on certain deploys, and maintain a declarative set of the variables given to charts over time, thinking you can use Helmfile and some custom GitHub Actions… “my dear friend you have built a GitOps.”

(I tend to think this one is acceptable in the beginning, but certainly doesn’t scale.)

[esafak]

Use a CD solution like Spinnaker, BunnyShell, or Kargo.

[turtlebits]

skaffold. It'll also wait for rollout to stabilize.

[PunchyHamster]

If few lines of scripting is your problem you shouldn't be programming