GitOps Fundamentals
GitOps uses a Git repository as the single source of truth for declarative infrastructure and application configuration. An automated agent continuously reconciles the live system with the desired state defined in version-controlled files, making every change auditable and reversible.
itDevOps and software delivery | OpenSkills.info
Intro
GitOps Fundamentals
GitOps is a way of operating infrastructure and applications where the entire desired state of a system is described declaratively, stored in version control, and kept in sync by software agents that continuously compare what's actually running against what Git says should be running. The name is a compression of the idea: Git becomes the single source of truth for "what should exist," and an automated process — not a person running commands by hand — makes reality match it.
The term and its formal definition come from the CNCF's OpenGitOps working group, which publishes four principles that something has to satisfy to be called GitOps: the desired state must be expressed declaratively; it must be stored in a way that enforces immutability, versioning, and a complete history; software agents must pull that desired state automatically from the source rather than having it pushed to them; and those agents must continuously reconcile — observe the actual state, compare it to the desired state, and act to correct any difference.
The mental model
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://opengitops.dev/
Supports
- GitOps defined as open-source standards, best practices, and community education for adopting a structured approach to GitOps
- The four canonical GitOps Principles (v1.0.0) - Declarative, Versioned and Immutable, Pulled Automatically, Continuously Reconciled
- Overseen by the CNCF GitOps Working Group
- https://argo-cd.readthedocs.io/en/stable/
Supports
- Argo CD defined as a declarative, GitOps continuous delivery tool for Kubernetes
- Argo CD implemented as a Kubernetes controller that continuously monitors applications and compares live state against target state in Git
- An application whose live state deviates from target state is considered OutOfSync
- Argo CD reports/visualizes differences and can automatically or manually sync live state back to desired state
- Supported manifest tools - Kustomize, Helm, Jsonnet, plain directory of YAML/JSON manifests, custom config management plugins
- Application deployments can track branches, tags, or be pinned to a specific Git commit (tracking strategies)
- Features list - automated deployment, multi-cluster management, SSO/RBAC, rollback to any Git-committed configuration, health status analysis, automated drift detection, PreSync/Sync/PostSync hooks for blue/green and canary rollouts
- https://argo-cd.readthedocs.io/en/stable/core_concepts/
Supports
- Application defined as a group of Kubernetes resources as defined by a manifest (a Custom Resource Definition)
- Target state - desired state of an application as represented by files in a Git repository
- Live state - the live/actual state of an application (deployed pods etc.)
- Sync status - whether live state matches target state
- Sync - the process of making an application move to its target state
- Refresh - comparing latest code in Git with live state to determine differences
- Health - whether an application is running correctly and can serve requests
- Tool/configuration management tool/plugin definitions (e.g. Kustomize)
- https://fluxcd.io/flux/concepts/
Supports
- GitOps defined as declaratively describing and version-controlling a whole system, with automated process ensuring deployed environment matches Git-declared state
- GitOps Toolkit (gotk) as the collection of Flux controllers, composable APIs, and reusable packages for building GitOps-based continuous delivery on Kubernetes
- Source defined as a resource defining the origin of a repository containing desired state and requirements to obtain it; examples GitRepository, OCIRepository, HelmRepository, Bucket
- Sources checked for changes on an interval, producing a new artifact when a newer matching version is available
- Reconciliation defined as ensuring a given state matches a desired state declared elsewhere; examples include OCIRepository, HelmRelease, and Kustomization reconciliation
- Kustomization custom resource reconciles a local set of Kubernetes resources on a default 5-minute interval; manual kubectl edit/patch/delete changes are reverted unless reconciliation is suspended or the change is pushed to Git
- Bootstrap defined as the GitOps-native process of installing Flux itself - manifests applied to the cluster, then pushed to a Git repository, with Flux able to manage itself
- Continuous Delivery defined as delivering software updates frequently and reliably
- Continuous Deployment defined as automatically deploying code changes to production after passing automated testing
- Progressive Delivery defined as building on Continuous Delivery via gradual rollout to a subset of users using canary releases, feature flags, A/B testing; Flagger as Flux's progressive delivery controller
- Gitless GitOps model where Flux controllers rely on OCI-compliant registries rather than a live Git server as the production source of truth
- https://fluxcd.io/flux/
Supports
- Flux described as an open and extensible continuous delivery solution for Kubernetes keeping clusters in sync with sources of configuration
- Flux's "designed with security in mind" table entry explicitly citing Pull vs. Push and least amount of privileges as a core design principle
- Flux works with existing tools - Git providers (GitHub, GitLab, Bitbucket), S3-compatible buckets, all major container registries, CI workflow providers
- Flux is a CNCF Graduated project
- Flux audiences - cluster operators, platform engineers, app developers