The GitOps Paradox: Why Your Devs Need an API You Don't Want To Build

Sched Link Code Website/Homepage

Baseline

  • We all like files, humans like them, they are easy to use and AI can use them
  • Git is a good version manager
  • GitOps is cool and we want to keep it
  • Problem: I want to do something and now i need to create a yaml file and open a pr -> High toil
  • Question: Should git always be the primary entry path for changes
  • Idea: Use kubernetes api as our api server, have an operator that handels creation of manifests in git + promotions and so on and the changes to the “real” clusters are always made via gitopös

The paradox

  • We shield people from the kubernetes api and force them to use git
  • We build our own custom apis on top of the kubeapi anyways
  • Solution: Why not go back to using the Kubernetes API (humans and robots can use it)

Principles of the reverse gitops manifest

  1. API first (via Kubeapi) to reuse auth, crds, status, controllers and more
  2. Capture intent not implementation -> Not api-only (if you can do it bi-directional) with reversible&declarative resources
  3. GitOps applies -> Changes are always piped through gitops for reviews, history, rollback, promotions, …

Implemantations examples