GitOps pattern means you use source code and git repositories for both your applications, your infrastructure and environments too.
With kubernetes you can connect to a cluster and modify it via
kubectl apply or helm install`.
However with the
GitOps pattern developers don’t modify kubernetes directly; instead they propose changes to a git repository via a Pull Request which when it gets approved and merged causes the kubernetes cluster to be modified via some kind of operator such as the Jenkins X git operator
Benefits of GitOps
- all changes made to each environment are stored in git so it is easy to see who changed what, when and why.
- it is easy to revert changes if things go bad
- it helps share information between the team and to get feedback and reviews on changes to infrastructure
You could implement the GitOps pattern by just running
helm install mychart in some kind of script or operator.
We recommend checking in every kubernetes resource and custom resource definition to git - apart from kubernetes Secrets. For details why see the reasoning behind this decision.
Essentially having a canonical file in git for every non-Secret kubernetes and custom resource really helps when it comes to diagnosing issues with a cluster; since you don’t have to keep in your head what tools like helm, helmfile, kustomize, kpt, kubectl or jx do - you can just look at how the resource has changed in git to see why things are going wrong.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.