[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.