GitOps Vocabulary: ArgoCD, Flux, and Declarative Deployment Terms
GitOps principles, ArgoCD, Flux, declarative infrastructure, drift detection, and reconciliation vocabulary.
Modern Kubernetes teams have developed a rich set of terms around GitOps — a way of managing infrastructure and deployments where Git is the single source of truth. If you have joined a platform engineering team, started working with ArgoCD or Flux CD, or simply found yourself in a stand-up where people talk about reconciliation loops and drift detection, this guide is for you. Below you will find plain-English definitions of the most important GitOps terms, real conversation examples, and a quick-reference table to bookmark.
Core Terms
GitOps — a set of practices where the entire desired state of a system (applications, infrastructure, configuration) is stored in Git, and automated tooling continuously compares that state to what is actually running, correcting any differences.
“We moved to GitOps last quarter — every change goes through a pull request now, so we have a full audit trail.”
“GitOps makes rollbacks trivial. You just revert the commit and the cluster catches up.”
Declarative configuration — describing what you want the system to look like, rather than how to get there. You write YAML or JSON files that say “I want three replicas of this service” and the tooling figures out the steps.
“Stop writing imperative scripts. Let’s move everything to declarative config and let ArgoCD handle the rest.”
“The beauty of declarative configuration is that it is idempotent — you can apply it a hundred times and the result is the same.”
Desired state vs actual state — desired state is what your Git repository says should be running; actual state is what is currently deployed in the cluster. GitOps tools exist to close the gap between the two.
“The desired state in Git shows two replicas, but the actual state in the cluster is three. Something scaled it manually.”
“Whenever desired state and actual state diverge, our tooling will flag it and reconcile automatically.”
Drift Detection and Reconciliation
Drift detection — the process of continuously monitoring whether the actual state of a cluster has moved away (drifted) from the desired state defined in Git. Drift can happen when someone makes a manual change directly in the cluster using kubectl.
“Drift detection caught that someone had patched the config map directly on the node. That is exactly the kind of thing GitOps is meant to prevent.”
“We get a Slack alert the moment drift is detected. It keeps the team honest — no more cowboy deploys.”
Reconciliation loop — the continuous cycle in which a GitOps operator (ArgoCD or Flux) reads the desired state from Git, compares it to the actual state in the cluster, and applies any necessary changes to bring the two into alignment. This loop runs on a configurable interval.
“The reconciliation loop runs every three minutes by default. If you need faster convergence, you can reduce the interval or trigger a manual sync.”
“We had a service outage because the reconciliation loop was paused for maintenance and someone forgot to re-enable it.”
Prune (orphaned resources) — the automatic deletion of Kubernetes resources that exist in the cluster but are no longer defined in Git. If you remove a Deployment from your repository, pruning ensures it is also removed from the cluster rather than left running as an orphan.
“Enable pruning carefully — if a resource is accidentally deleted from Git, it will be torn down in production too.”
“We turned on prune for non-critical namespaces first to build confidence before enabling it cluster-wide.”
ArgoCD Concepts
ArgoCD — a popular GitOps operator for Kubernetes that runs inside the cluster, watches one or more Git repositories, and continuously syncs Kubernetes resources to match the state described in those repositories.
“We chose ArgoCD over Flux because the web UI makes it much easier to show stakeholders what is deployed where.”
“ArgoCD has built-in RBAC, which made it straightforward to give developers read access without letting them trigger syncs.”
Argo Application — the core custom resource in ArgoCD that ties together a Git source (repository URL, path, revision) with a Kubernetes destination (cluster and namespace). Each Application object tells ArgoCD exactly what to deploy and where.
“Create an Argo Application pointing at the
prod/paymentsfolder in the config repo and target the payments namespace on the prod cluster.”
“The Application went OutOfSync after the last commit — looks like someone pushed directly to main without going through the PR process.”
App of apps pattern — an ArgoCD pattern where a single root Application manages a collection of child Application manifests stored in Git. This allows an entire cluster’s set of applications to be bootstrapped and managed through one entry point.
“We use the app of apps pattern for cluster bootstrapping — one root app, and everything else is derived from it.”
“If you want to onboard a new environment, just add an Application manifest to the root folder and ArgoCD picks it up automatically.”
Sync policy (auto/manual) — controls whether ArgoCD applies changes automatically when it detects drift (auto) or waits for a human to click Sync or run argocd app sync (manual). Manual sync is common in production for extra safety.
“We keep sync policy on manual for prod — auto-sync is fine for staging, but production changes need a second pair of eyes.”
“After the incident, we switched to manual sync policy across the board until we improve our test coverage.”
Health check — ArgoCD’s built-in (and customisable) assessment of whether a deployed resource is actually working. A Deployment can be Synced (matches Git) but Degraded (pods are crash-looping). Health checks surface this distinction.
“The sync is green but the health check is degraded — check the pod logs, something is failing at startup.”
“We wrote a custom health check for our CRD so ArgoCD can report on it properly in the dashboard.”
Flux CD and Tooling
Flux CD — a GitOps operator from the Cloud Native Computing Foundation (CNCF) that uses a pull-based model to keep clusters in sync with Git. Flux is API-driven and integrates tightly with Kustomize and Helm.
“Our platform team standardised on Flux because it fits naturally into our existing Kustomize workflow.”
“Flux notifies us via webhook when a reconciliation succeeds or fails — it plugs straight into our alerting pipeline.”
Pull-based deployment — a deployment model where the agent running inside the cluster pulls configuration from Git, rather than having an external CI pipeline push changes into the cluster. This is considered more secure because the cluster does not need to expose its API server externally.
“Pull-based deployment means our CI server never needs cluster credentials — the Flux agent handles everything from inside.”
“Security liked the pull-based model because it dramatically reduces the attack surface compared to push-based pipelines.”
Kustomize overlay — a Kustomize feature that lets you define a base set of Kubernetes manifests and then layer environment-specific patches (overlays) on top without duplicating the base files. Common pattern: one base, plus overlays for dev, staging, and prod.
“The prod overlay just changes the replica count and resource limits — everything else inherits from the base.”
“We had a bug in the Kustomize overlay that was adding the wrong environment variable to prod. The diff in the PR would have caught it.”
Helm release — in Flux (and ArgoCD), a HelmRelease is a custom resource that describes a Helm chart deployment — which chart, which version, and what values to pass. The GitOps operator manages the full lifecycle of the Helm release declaratively.
“Bump the chart version in the HelmRelease manifest and open a PR — Flux will handle the upgrade once it merges.”
“We pin chart versions in the HelmRelease so a new upstream release never lands in production without review.”
How to Use These in Conversation
Scenario 1 — stand-up update
“The payments service HelmRelease is showing as degraded in ArgoCD. Health check says the readiness probe is failing. I am investigating now — might be a config issue in the prod overlay.”
Scenario 2 — architecture discussion
“Should we use auto sync policy on prod? I would rather keep it manual and require an explicit sync after each PR merges. Accidental drift detection alerts are fine, but auto-remediation in production makes me nervous.”
Scenario 3 — incident retrospective
“Root cause was manual drift — someone patched the replica count directly via kubectl during the incident without updating Git. The reconciliation loop corrected it twenty minutes later, which caused a second unexpected restart. Going forward, we enable pruning and lock down direct cluster access.”
Scenario 4 — onboarding a new service
“Add a new Argo Application manifest under the
apps/folder in the config repo. Use the app of apps pattern — the root application will pick it up automatically. Point it at theservices/new-billingpath and set the sync policy to manual for now.”
Quick Reference
| Term | What it means |
|---|---|
| GitOps | Git as the single source of truth for cluster state |
| Declarative configuration | Describe what you want, not how to achieve it |
| Desired state | What Git says should be running |
| Actual state | What is currently running in the cluster |
| Drift detection | Spotting gaps between desired and actual state |
| Reconciliation loop | Automated cycle that closes the gap between states |
| ArgoCD | GitOps operator with a UI; syncs Git to cluster |
| Flux CD | CNCF GitOps operator; pull-based, Kustomize/Helm native |
| Sync policy | Auto or manual trigger for applying Git changes |
| Prune | Delete cluster resources removed from Git |