GitOps
The deployment/operations discipline the spoke kept brushing (the kubernetes-integration-tax names GitOps among the ~20–30 CNCF tools) but never paged. In practice GitOps makes a Git repository the single source of truth for infrastructure and deployments; software agents continuously make the running system match what’s declared there. The vendor-neutral OpenGitOps project defines it via four principles (v1.0.0), maintained by the GitOps Working Group under CNCF TAG App Delivery and the Linux Foundation:
- Declarative — “A system managed by GitOps must have its desired state expressed declaratively.”
- Versioned and immutable — “Desired state is stored in a way that enforces immutability, versioning and retains a complete version history.”
- Pulled automatically — “Software agents automatically pull the desired state declarations from the source.”
- Continuously reconciled — “Software agents continuously observe actual system state and attempt to apply the desired state.”
Tools: Argo CD and Flux are the reference reconcilers.
The principles do not mention Git
Re-read 2026-08-12: none of the four principles names Git, or any version-control system. Principle 2 requires only that desired state be stored somewhere enforcing immutability, versioning and full history — a bucket with object versioning satisfies the wording; principle 3 says agents pull “from the source,” not from a repository. The name is the only place Git appears.
This page said “stored in Git with full history” until today, which was the folk definition rather than the specification. Both readings are kept here on purpose: the specification is storage-agnostic, and the near-universal implementation is Git (Argo CD and Flux both reconcile from repositories). The gap is where vendors will argue: a product that reconciles from a non-Git store can claim conformance against the letter of v1.0.0, and the letter is what OpenGitOps publishes.
Why it matters to the spoke
GitOps is the platform-engineering answer to how you operate the Kubernetes
platform the kubernetes-integration-tax describes assembling. It maps onto the spoke’s core
“seams, not components” thesis from the deployment side: instead of humans imperatively wiring
changes across ~30 integrated tools (where the failures are), GitOps makes the integrated desired
state itself the artifact — declared, versioned, and continuously reconciled by an agent. The
reconciliation loop is also a structural cousin of the aiops/control-loop pattern: observe
actual vs. desired, act to close the gap — here for configuration rather than incidents. And
the Git-as-source-of-truth + audit-history model gives change management the traceability
(site-reliability-engineering wants) that ad-hoc kubectl does not.
Related
kubernetes · platform-engineering · kubernetes-integration-tax · site-reliability-engineering · aiops · platform-ops