[eddyfromtheblok]

adopt a gitops tool (argo or flux):

- create a dev cluster

- create a test cluster

- manage dev & test clusters with gitops tool

- copy payloads and objects from your prod cluster in the gitops tool

- compare test to prod. try new things out in dev. tear down dev cluster at will

- create a new prod cluster based off of test cluster

- migrate things over slowly

[jonfw]

I never understood gitops. You introduce a whole new class of problem- syncing desired state from one place to another

Kubernetes is a perfectly good place to keep your desired state. I think it would be in most people’s best interests to learn to maintain, failover, and recover Kubernetes clusters, so they can trust the API, rather than trying to use tools to orchestrate their orchestration

[jonasdegendt]

How do you deploy workloads to your clusters then? `kubectl apply -f`? Another form of CI/CD?

Assuming you have some sort of build pipeline that also pushes to your cluster, Flux does the same thing whilst ensuring whatever was pushed never diverges.

[glitchcrab]

Really? So how would you version control changes to anything?

> learn to maintain, failover, and recover Kubernetes clusters

Kubernetes administration is a completely different topic to gitops, the two compliment each other - they don't replace each other.

[jonfw]

We use helm which gives all of the version control we’ve ever needed

[glitchcrab]

So how do you manage the versions of helm charts you have installed? Or are you manually running helm install from a local machine?

[jonfw]

We either install a new version of a helm chart, or we roll back. we have rollback jobs to roll back, and our CI/CD pipelines or our maintenace jobs do the install of the new version, depending on whether it's our app or a dependency