4 ms·
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
by eddyfromtheblok 3y ago
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 3y agoI 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
- glitchcrab 3y agoReally? 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 3y agoWe use helm which gives all of the version control we’ve ever needed
- glitchcrab 3y agoSo how do you manage the versions of helm charts you have installed? Or are you manually running helm install from a local machine?
- jonfw 3y agoWe 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
- jonasdegendt 3y agoHow 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.