---
title: GitOps Research
---
# GitOps Research

#### What
GitOps brings a set of opinionated and prescriptive best practices about applying these ideas in the context of Kubernetes

1. git as source of truth for configuration
2. git as single location
3. audit trail
- All changes happen via git commits

- Kubernetes is the mechanism that converges the desired and observed states
- desired: what our config states
- observed: current state of the cluster
- Not just for kubernetes though..
- Terraform

#### Limitations
#### Other tools

---
Why?
- Deployment is fully automated
- can happen more frequently
- is less error prone
- Automatic "audit log"
- improves troubleshooting and retrospectives
-

What?
- Config in files
- Files in VCS
- "Agents" detect changes in VCS and apply immediately.

How?

Trade-offs?

Tools in the "GitOps" topic:

https://github.com/topics/gitops
- fluxcd/flux — "The GitOps Kubernetes operator"
- argoproj/argo-cd
- jenkins-x/jx

https://landscape.cncf.io/category=continuous-integration-delivery&format=card-mode&grouping=category&sort=stars

Questions:
1. What's the difference between GitOps and CI/CD?
2. What's the difference between "GitOps" tooling and "Developer Tooling" (e.g. Skaffold)?

Resources:
- https://github.com/StarpTech/k8s-gitops

## Outline for Community Meeting (What is gitops)

### Who is it for?
- dev + ops

###

### Problem statement (John)
- What came before gitops?
- first did it by hand
- wrote lots of scripts to do deployment
- pains
- Error prone when done manually
- Had to create your own audit trail
- Lots w

### Solution (Cari)
- Configuration as version managed code
- A git repo is the single source of truth for the desired state of the whole system
- Takes advantage of VCS features
- Automated tests and checks
- rollback
- Workflow for promoting the code to prod via branches and PR's
- declarative spec as system of record
- One for each environment
- all Git commits cause verifiable and idempotent updates in the cluster
- system of converance
- a convergence mechanism to bring the desired and observed states in sync both eventually, and autonomically. Within the cluster, this is Kubernetes.
- triggered immediately with a “change committed”
- Kubernetes API server continually tries to drive the cluster to the desired state
- Converges the cluster from desired state to coverged state where the two are equal
- .. glue that connects these steps...