CGOA key terms

The complete, declarative description of how a system and its resources should look, stored as versioned configuration rather than produced by imperative commands. Reconciliation tools compare it against observed reality and act on any difference.

The actual condition of the running system as reported by the environment itself, such as live cluster objects or cloud resource attributes. It is read continuously and compared with the desired state to detect drift.

The continuous control loop that compares desired state with observed state and issues changes so the two converge. It runs without human triggering, which is what makes GitOps self-healing rather than a one-time deployment script.

Any divergence between the declared desired state and what actually runs, caused by manual edits, out-of-band changes, or failed automation. Detecting and correcting drift is a core promise of GitOps operating models.

A description of the end result you want, expressed as data such as YAML manifests, rather than a sequence of steps to execute. Declarative form is what allows a machine to compare and converge states repeatedly.

Instructions that specify the exact commands or steps to perform, such as a deployment script. It records process rather than outcome, so it cannot be diffed against live state or safely re-run to converge.

The practice of treating a Git repository as the single authoritative record of desired system state. Everything deployed must be traceable to a commit, and nothing outside the repository is allowed to define production.

A GitOps principle requiring desired state to be stored so that every past version is retained and identifiable, enabling rollback, audit, and reproduction. Git commits, tags, and signed history provide this property.

A GitOps principle stating that software agents in the target environment fetch the desired state themselves, rather than an external system pushing changes in. Pull reduces credential exposure and enables continuous convergence.

A GitOps principle requiring software agents to keep observing the environment and correcting divergence from desired state without manual intervention, so the system converges even after failures or unauthorized changes.

One canonical location that all parties and automation treat as authoritative for a given piece of information. In GitOps it is usually a Git repository, avoiding conflicting definitions spread across wikis, tickets, and consoles.

The behavior where an automated agent restores the declared state after deletion, manual modification, or partial failure, without a human re-running a pipeline. It follows directly from continuous reconciliation of desired state.

A controller running inside the target environment that pulls manifests from Git, applies them, and reports status. Examples include Argo CD application controllers and Flux controllers such as kustomize-controller and helm-controller.

A long-running process that watches resources and drives actual state toward desired state in a loop. In GitOps tooling, controllers watch both Git-derived configuration and cluster objects to perform reconciliation.

A controller that packages operational knowledge for a specific application, encoding tasks like backup, upgrade, or failover as reconciled custom resources. Operators extend the same control-loop pattern to stateful workloads.

A file, usually YAML or JSON, that declares one or more Kubernetes resources. Manifests are the unit of desired state stored in Git and rendered by tools before an agent applies them.

A template-free configuration customization tool built into kubectl that overlays patches and common settings onto base YAML. It is widely used to produce per-environment manifests for a GitOps repository layout.

A packaged collection of Kubernetes templates plus default values that render into manifests. GitOps agents can install charts directly or render them, and chart versions must be pinned for reproducible desired state.

A layer of configuration applied on top of a shared base to produce the manifests for one environment, such as staging or production. Overlays keep differences explicit and small while sharing common definitions.

The controlled movement of a validated change from one environment or stage to the next, typically by merging or copying configuration into the next environment's path or branch. It should be repeatable and auditable.

A repository pattern where each environment lives in its own directory within one branch, sharing a common base. It simplifies promotion via pull requests but gives weaker isolation than separate repositories or branches.

A repository pattern that gives each environment its own repository or long-lived branch, providing stronger access control and blast-radius isolation at the cost of more merge and synchronization effort.

A layout where each environment tracks its own branch, and promotion means merging between branches. It is easy to start with but risks divergence and painful cherry-picks when branches drift apart.

An Argo CD pattern in which one parent Application points at a directory of child Application manifests, letting a single root object bootstrap and manage many applications declaratively from Git.

An Argo CD resource that generates multiple Applications from a template plus a generator, such as a Git directory generator or cluster list. It scales multi-cluster and multi-tenant deployments without hand-writing each Application.

The Argo CD custom resource that binds a Git source path and revision to a destination cluster and namespace, defining one reconciliation target. Its sync status and health summarize convergence for that unit.

A Flux custom resource that specifies which Git or OCI source to fetch, which path to build with Kustomize, and how often to reconcile it. It is the primary workload definition in Flux v2.

A Flux source resource that defines a Git URL, branch or tag, interval, and optional credentials. Other Flux resources reference it to obtain artifacts, separating source fetching from applying configuration.

A reported condition describing whether the live environment matches the desired manifests, usually Synced or OutOfSync. It answers whether the declared state has been applied, not whether the workload is healthy.

A reported condition describing whether a deployed workload is functioning, such as Progressing, Healthy, or Degraded. It is distinct from sync status, which only measures agreement with declared configuration.

Restoring a previously known-good desired state, in GitOps usually by reverting a commit or pointing to an earlier revision so the agent reconciles back. The repository history makes the target unambiguous.

A chronological, attributable record of every change to desired state and every reconciliation action. Commit metadata, pull request reviews, and agent events together provide evidence for compliance and incident review.

The review process where changes to desired state are proposed as pull requests, reviewed, validated by automated checks, and merged. It provides peer review and approval evidence before anything reaches an environment.

Automation that builds and tests code on every change, producing verified artifacts. In GitOps it runs before configuration changes merge, so only tested images and manifests reach the desired-state repository.

The practice of keeping software always in a releasable state with automated promotion steps. GitOps supplies the deployment and reconciliation half, while delivery pipelines typically handle build, test, and artifact publication.

A stronger form of continuous delivery where every change passing automated gates is released without manual approval. Combined with GitOps, merging to the desired-state repository becomes the release action.

A model where an external pipeline or operator sends changes into the environment using stored credentials. It contrasts with GitOps pull, since the environment does not fetch its own desired state.

A component or pipeline step that writes new container image tags into the desired-state repository when a build publishes. It keeps configuration changes in Git rather than mutating the cluster directly.

Handling sensitive values so they never appear in plaintext in Git, using sealed or encrypted manifests, external secret stores, or references resolved at runtime. It is a common gap when teams first adopt GitOps.

An encrypted manifest that can be committed safely and is decrypted only by a controller in the target cluster holding the private key. It keeps secret material versioned alongside other configuration.

A controller that reads secret values from an external provider such as a cloud vault and materializes them as Kubernetes Secrets. Git stores only references, so credentials never enter the repository.

Releasing a change to a subset of traffic or users and expanding gradually based on measured health, using techniques like canaries and blue-green. It complements GitOps by gating how fast reconciled state spreads.

A progressive delivery technique that routes a small share of traffic to a new version and increases it only if metrics stay acceptable. Automated analysis can roll back by reverting the desired-state change.

Managing desired state for many clusters from shared repositories, with per-cluster overlays or generators selecting what each cluster receives. It raises questions of tenancy, credential scoping, and blast radius.

A packaged, versioned object stored in an OCI-compliant registry, which can hold rendered manifests or Helm charts instead of container images. Flux and Argo CD can reconcile desired state from such artifacts.

A cluster extension that registers a new resource kind, letting tools like Argo CD and Flux express their configuration as Kubernetes objects. Controllers then reconcile those objects like any built-in resource.

A YAML file supplying parameters to a Helm chart at render time. In GitOps it lives in the repository and must be versioned and reviewed, since it directly shapes the desired state produced.