Lesson 01 of 7 · Modules
GitOps principles & Argo CD architecture
What GitOps really means (the four OpenGitOps principles), why pull-based delivery beats pushing from CI for clusters, and how Argo CD's components work together to keep a cluster matching Git.
From "kubectl apply" to GitOps
Most teams start with someone running kubectl apply from a laptop, then move it into a CI pipeline. Both are push: something outside the cluster pushes changes in, and nobody notices if the cluster drifts afterwards.
GitOps flips it. The OpenGitOps principles:
- Declarative: the whole desired state is described (YAML, Helm, Kustomize).
- Versioned and immutable: it lives in Git, so every change is reviewed, recorded and revertible.
- Pulled automatically: an agent in the cluster fetches the desired state.
- Continuously reconciled: the agent compares desired vs live all the time and corrects differences.
Think of a LEGO model with instructions. The instructions (Git) show exactly how the model should look. A robot (Argo CD) sits next to the model and checks it every few minutes. If a brick is moved, the robot notices and puts it back. To change the model, you don't touch the bricks; you change the instructions, and the robot builds the new version.
Push vs pull
| Push (CI runs kubectl/helm) | Pull (GitOps agent) | |
|---|---|---|
| Cluster credentials | Stored in CI | Stay inside the cluster |
| Drift detection | Only when the pipeline runs | Continuous |
| Rollback | Re-run an old pipeline | git revert |
| Audit trail | CI logs | Git history (plus agent events) |
| Many clusters | CI needs access to each | Each cluster (or one Argo CD) pulls |
CI still matters: it tests and builds images and then updates Git (a new image tag). GitOps takes over from there.
Argo CD's architecture
- An Application (a custom resource) says: this path in this repo at this revision → this cluster and namespace.
- The controller shows two statuses: sync (does live match Git?
Synced/OutOfSync) and health (is it working?Healthy,Progressing,Degraded,Missing,Suspended). - By default, Argo CD polls repos every few minutes; webhooks from your Git server make it react immediately.
Flux is the other major CNCF GitOps tool (a set of controllers without a built-in UI). The principles in this track apply to both; the examples use Argo CD.
Try it: feel the difference
- In a kind cluster (see Kubernetes Administration, lesson 01), deploy nginx with
kubectl apply, then scale it by hand. Nothing records or reverts the change: that's push without GitOps. - Write down where your team's cluster credentials live today and who can change production without a review.
- Sketch your current delivery flow and mark which parts would move to "CI updates Git, the cluster pulls".
- (Lesson 02 installs Argo CD and repeats step 1 under GitOps.)
Going deeper: what GitOps doesn't solve
- Secrets can't go into Git in plain text; use Sealed Secrets, SOPS or External Secrets (see Kubernetes Security & Hardening, lesson 11).
- Data (databases, volumes) isn't in Git; GitOps restores the configuration, backups restore the data.
- Ordering and imperative steps (migrations) need hooks and waves (lesson 06).
- A bad commit reaches every cluster quickly. Structure repos and rollouts to limit blast radius (lessons 05 and 07).
Recap
- GitOps = declarative, versioned in Git, pulled by an in-cluster agent, continuously reconciled.
- Pull keeps credentials in the cluster and fixes drift; CI builds and updates Git.
- Argo CD: repo-server renders, application-controller compares and syncs, server serves UI/API/SSO.
- Two statuses per app: sync (matches Git?) and health (working?).
This site is a public version of my personal engineering knowledge hub. It intentionally excludes confidential company information and internal operational details.