The fundamental difference between a traditional CI/CD model and a GitOps model lies in how changes are applied to the Kubernetes cluster—whether they are "pushed" to the cluster by an external system or "pulled" by an agent running inside the cluster.
CI/CD (Push Model)In a typical CI/CD pipeline for Kubernetes, the CI/CD server (like Jenkins, GitLab CI, or GitHub Actions) is granted credentials to access the cluster. When a pipeline runs, it executes commands like kubectl apply or helm upgrade to push the new application configuration and image versions directly to the Kubernetes API server.
Actor: The CI/CD pipeline is the active agent initiating the change.
Direction: Changes flow from the CI/CD system to the cluster.
Security: Requires giving cluster credentials to an external system.
In a GitOps model, a Git repository is the single source of truth for the desired state of the application. An agent or controller (like Argo CD or Flux) runs inside the Kubernetes cluster. This controller continuously monitors the Git repository.
When it detects a difference between the desired state defined in Git and the actual state of the cluster, it pulls the changes from the repository and applies them to the cluster to bring it into the desired state. This process is called reconciliation.
Actor: The in-cluster controller is the active agent initiating the change.
Direction: The cluster pulls its desired state from the Git repository.
Security: The cluster's credentials never leave its boundary. The controller only needs read-access to the Git repository.
