Skip to main content
In this lesson we’ll clarify what GitOps means and outline the common deployment models you’ll encounter when adopting Git as the single source of truth for infrastructure and applications. GitOps is a paradigm that treats a Git repository as the authoritative, versioned record of the desired state for infrastructure and apps. Changes are made declaratively in Git (via commits and pull requests), and a GitOps operator continuously reconciles the live environment to match that repository. Extending this pattern to package management lets you manage packages the same way you manage application and cluster configuration—declaratively and audibly.
The image features a "GitOps" logo with two buttons below labeled "What is Gitops?" and "What are the different deployment models?" with a copyright notice from KodeKloud.
How a GitOps workflow typically works:
  • You author declarative manifests, Helm charts, or package definitions in a Git repository.
  • A GitOps operator (for example Argo CD) watches the repository for commits and PR merges.
  • The operator reconciles the target environment (for example a Kubernetes cluster) to match the Git state, applying changes automatically.
  • All changes are auditable (logged in Git), and configuration drift is detected and corrected by the operator.
This approach replaces manual kubectl/app deployments with a reproducible, auditable pipeline.
The image features the text "gitops" with an associated logo and includes labeled buttons for "Package Management," "Code Commits," and "Gitops Operator."
In this lesson we use Argo CD as the GitOps operator. Argo CD runs in-cluster and continuously compares the live state against the Git repository, then applies any necessary changes to reconcile differences. Using Argo CD (or a similar operator) improves consistency, reduces manual interventions, and makes deployments repeatable and auditable.
The image is a diagram of Argo CD, a GitOps operator, highlighting issues like "Manual Deployment" and "Configuration drift" in red, and benefits like "Consistency" in green.
Two common deployment models:
  • Push model: An external system (CI/CD pipeline) detects commits and pushes changes to the target environment. Simpler to bootstrap, but it relies on external triggers and may make auditing and drift detection harder.
  • Pull model: A GitOps operator running inside the target environment continuously monitors Git and pulls/apply changes when new commits arrive. This model provides a declarative reconciliation loop, stronger control, and better observability.
The image illustrates a "Pull Model" in a code deployment process, showing a user pushing code to a Git repository and an event-watching component pulling updates from the repository.
Comparison: Push vs Pull
For Kubernetes-focused deployments, the pull model (with a GitOps operator like Argo CD) is generally recommended because it provides continuous reconciliation, better audit trails, and reduced operational complexity.
Key takeaways
  • Use Git as the central source of truth and protect repository integrity (branch protections, signed commits, PR reviews).
  • GitOps enables declarative management of infrastructure, applications, and package definitions.
  • The pull model is preferred for Kubernetes environments because it enforces a continuous reconciliation loop and improves reliability.
  • Choose the model that matches your operational constraints—simplicity vs. control—and ensure proper RBAC and observability for any operator you run.
References and further reading

Watch Video