GitOps
The deployment/operations discipline the spoke kept brushing (the kubernetes-integration-tax names GitOps among the ~20–30 CNCF tools) but never paged. 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 in Git. The vendor-neutral OpenGitOps project (CNCF) defines it via four principles (v1.0.0):
- Declarative — the desired state is expressed declaratively (not imperative scripts).
- Versioned & immutable — that state is stored in Git with full history and enforced immutability.
- Pulled automatically — agents pull the declarations from the source (not pushed by CI).
- Continuously reconciled — agents constantly observe actual state and converge it to the declared state, auto-correcting drift.
Tools: Argo CD and Flux are the reference reconcilers.
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