GitOps is a continuous delivery model where the desired state of a Kubernetes cluster is declared entirely in Git, and an automated operator continuously reconciles the cluster's actual state toward what Git says it should be. This model inverts the traditional push-based CI/CD pipeline — where a CI system runs `kubectl apply` directly against the cluster — replacing it with a pull-based model where the cluster's operator (Argo CD, Flux) watches a Git repository and applies changes when the repository diverges from the cluster state. The inversion produces three operationally important properties: the Git repository becomes the single authoritative source of truth for all cluster state, making every cluster change auditable as a Git commit with an author, a timestamp, and a reviewed diff; rollback becomes `git revert` rather than a cluster-specific command; and the cluster can self-heal by re-applying the Git state if manual `kubectl` edits create drift between what Git says and what the cluster contains.
25 minintermediate
GitOps with Argo CD — declarative continuous delivery and progressive delivery
Analogy🏏Cricket
🏏 Think of it like cricket: The Pod-ReplicaSet-Deployment hierarchy maps precisely onto the three levels of IPL franchise team management. A Pod is a single player on the field at a given moment — the smallest unit of participation, carrying its own identity and fulfilling a specific role in the current game. A ReplicaSet is the franchise's match-day playing XI contract — it specifies that exactly eleven players matching a specific profile must always be on the field; if one is injured and leaves, the team management immediately sends a substitute of the same profile to restore the count. A Deployment is the franchise's season-long team strategy — it manages how the playing XI evolves between matches: when a new batting approach is adopted, the Deployment replaces the old XI with the new one in a controlled rolling substitution rather than swapping all eleven players simultaneously and disrupting team cohesion. Just as the franchise director does not manage individual players directly — the playing XI contract (ReplicaSet) handles the count and the season strategy (Deployment) handles the transitions — you never manage Pods directly in production; the Deployment manages the transition and the ReplicaSet maintains the count. This reveals why the three-level hierarchy exists rather than one omnibus 'workload' object: each level solves one specific problem, and composing three focused abstractions produces better separation of concerns than one object that conflates scheduling, scaling, and update management.
Lesson 30 of 33
0% complete