GitOps Principles

The Four Principles

OpenGitOps distills GitOps into four statements:

1. Declarative — desired system state is described as data, not imperative commands
2. Versioned and immutable — that description lives in Git: every change is a commit with an author, review, and history
3. Automated delivery — agents apply changes automatically; divergence is detected and corrected
4. Continuously reconciled — the agent reports and drives the actual state toward the declared state

Practical consequences: git revert is your rollback, PR review is your change advisory board, and cluster state becomes reconstructible from the repository plus an image registry.

Push vs Pull Delivery

Push: CI pipelines run kubectl apply or helm upgrade with cluster credentials. Simple to start — but nothing corrects manual changes afterward, credentials fan out to every pipeline, and history splits across Git and cluster events.

Pull: a controller inside the cluster watches the repository, renders manifests, diffs them against live state, and applies differences — then keeps doing it. A human edit to a Deployment gets reverted (or alerted on) within minutes.

Prerequisites for either style: everything expressively declarative (Helm values, Kustomize overlays), a plan for secrets (SOPS, external secret stores), and no kubectl edit in normal operations — hand edits are exactly the drift the system exists to remove.

Pitfalls and Interview Angles

Git-as-backup only. Storing manifests in Git without an applying agent is just versioning — no automation, no reconciliation, no GitOps.

Secrets in plaintext. Git becomes the single most attractive target; encrypt (SOPS) or reference external stores, and protect branches with signed commits.

Double-writers. If pipelines AND a reconciler both apply changes, they fight: pipeline applies v2, reconciler reverts to Git's v1. Pick one writer per cluster — usually the reconciler.

Repo layout mismatches. Overlapping paths between two controllers cause resources to be adopted and pruned by different owners; give each application/env a disjoint path.

Interview angle: define drift concretely (live state ≠ Git state), explain how the pull agent resolves it, and contrast it with what push CI would leave behind after a manual edit.