GitOps has become a buzzword in the Kubernetes ecosystem. Vendors slap the label on anything that reads from a Git repository. But at its core, GitOps is a specific operational model with specific tradeoffs. Understanding what you’re actually getting—and what you’re giving up—matters before you commit to the approach.
What GitOps Actually Means
GitOps, as originally defined by Weaveworks, has four principles:
- Declarative: The entire desired state of the system is expressed declaratively
- Versioned and immutable: The desired state is stored in a way that enforces immutability and versioning (a Git repository)
- Pulled automatically: Software agents automatically pull the desired state from the source
- Continuously reconciled: Software agents continuously observe actual system state and attempt to apply the desired state
The pull-based reconciliation is the key differentiator from push-based CI/CD. In a push model, your pipeline runs and pushes changes to the cluster. In GitOps, a controller in the cluster continuously pulls from Git and applies changes.
Traditional Operations: What It Looked Like
“Traditional operations” covers a lot of territory, but the common thread is imperative, push-based, often manual change management:
- SSH to a server and make a change
- Run a script that provisions infrastructure
- Trigger a Jenkins pipeline that SSHes into servers and deploys
- Use Ansible to push configuration to hosts
- Run
kubectl applyfrom a developer’s laptop or CI server
The shared characteristic: a human or script with elevated access pushes changes to infrastructure. The infrastructure doesn’t pull; it receives.
What GitOps Gains You
Audit Trail That Actually Works
In traditional operations, the audit trail is whatever you remember to document and whatever your logging captures. “Who changed the replica count to 1 on Friday night?” might be answered by log analysis if you have the right logs, or might be answered by “we’re not sure.”
In GitOps, the answer is in the git log. Every change to cluster state went through a commit. Who made it, when, why (the commit message), and what it changed are all there, forever.
git log --oneline --follow clusters/production/my-app/helmrelease.yaml
This isn’t just convenient—it’s often a compliance requirement. SOC2, PCI-DSS, and FedRAMP auditors ask who made changes to production. “It’s in the git log” is a complete and auditable answer.
Rollback That Actually Works
“Rollback” in traditional operations often means:
- Re-running the old version of a deployment script
- Finding the old Helm values file you hopefully saved somewhere
- Re-applying the old manifest you’re not sure you have
- Manually reversing the changes you made
In GitOps:
git revert HEAD
git push
The GitOps controller sees the new commit, computes the diff from desired state to current state, and applies it. Rollback is deterministic because the previous state is always available in Git history.
Drift Detection and Auto-Remediation
In traditional operations, configuration drift is silent. Someone makes a change directly to the cluster, and your Git repo (if you have one) no longer matches reality. You discover this when something breaks.
In GitOps, the controller continuously compares desired state (Git) to actual state (cluster). Drift is detected immediately and, in many configurations, automatically remediated. The cluster is always converging toward what’s in Git.
This is powerful for compliance scenarios: “We guarantee our production cluster configuration matches our reviewed and approved configuration in Git.” That’s a strong statement with GitOps. It’s hard to make without it.
Self-Service and Pull Request Workflows
Cluster changes that previously required elevated access to production can become pull requests reviewed and merged by anyone with repo access. A developer who needs their service’s resource limits increased can open a PR, get it reviewed by the platform team, and have it applied automatically when merged.
This democratizes cluster management while maintaining oversight through code review—a better model than “only ops can touch production.”
What GitOps Costs You
The Mental Model Shift
Traditional ops is imperative: you tell the cluster what to do. GitOps is declarative: you tell Git what you want. The controller figures out what to do.
This shift takes time. The first few times you need to make a change “right now” and the instinct is to kubectl apply but you know you should update Git first, it feels slow. The instinct to directly edit cluster resources never fully goes away. You have to build the discipline.
Emergency Response Friction
When production is on fire, GitOps adds a step: update Git, push, wait for reconciliation. In traditional ops, you kubectl edit or kubectl scale and the change is immediate.
GitOps practitioners handle this with “break glass” procedures: emergency changes are made directly to the cluster (bypassing GitOps) and then reconciled into Git after the incident. This works but requires discipline to actually update Git afterward.
Some teams disable auto-remediation during incidents specifically to allow direct cluster manipulation. The reconciliation is then re-enabled once the incident is resolved and Git is updated to match what was done.
Repository Management Overhead
GitOps requires a well-organized repository. Multiple environments, multiple clusters, namespace structure, dependency management—all of this lives in Git. A poorly organized GitOps repo is harder to work with than a well-organized one, and it takes time to get right.
Initial Complexity
Setting up Flux or Argo CD is not complex, but the concepts—HelmRepositories, HelmReleases, Kustomizations, reconciliation intervals, dependency ordering—have a learning curve. Teams that weren’t already Kubernetes-native often find the initial setup daunting.
When Traditional Approaches Still Win
GitOps is not the right answer for everything:
Small teams with simple infrastructure: If you have three services deployed by one person, GitOps is overhead without proportional benefit.
Environments that change frequently and manually: Some environments are genuinely experimental—developers spinning up ad-hoc test environments. Forcing every change through Git is friction that slows experimentation.
Non-Kubernetes infrastructure: GitOps as described is a Kubernetes pattern. For traditional VMs, bare-metal servers, and non-K8s infrastructure, Ansible, Puppet, Chef, and Terraform are better fits (though Terraform’s GitOps-like state management shares many principles).
Tight feedback loops: When iterating rapidly in development, the Git commit → push → reconcile loop adds friction compared to direct kubectl.
The Hybrid Reality
Most mature teams end up with a hybrid:
- Production and staging: Full GitOps with auto-reconciliation
- Development environments: Direct kubectl or Helm CLI for rapid iteration
- Infrastructure provisioning: Terraform/Pulumi for cloud resources (GitOps-adjacent with PR-based workflows)
- Break-glass procedures: Direct cluster access for incidents, with post-incident Git reconciliation
This isn’t a failure to commit to GitOps—it’s pragmatic recognition that different contexts have different requirements.
The Verdict
GitOps is the right model for managing production Kubernetes clusters. The audit trail, rollback, and drift detection capabilities are genuinely valuable, not just theoretically appealing. The cost is real but manageable.
Traditional push-based operations made sense for the infrastructure models that preceded Kubernetes. GitOps is designed for the Kubernetes model: declarative, reconciliation-based, immutable infrastructure.
Don’t adopt GitOps because it’s fashionable. Adopt it because the specific problems it solves—audit trail, rollback, drift—are problems you have or will have.
