Most teams start deploying to Kubernetes the same way: the CI system builds an image, then runs kubectl apply or helm upgrade against the cluster. It works, until the number of apps and clusters grows. This guide explains what changes when an agent inside the cluster, like Argo CD, pulls the desired state from Git instead, and what trade-offs come with that.

The push model and where it strains

In a push pipeline, the CI job is the only thing that touches the cluster:

1. A commit triggers tests and an image build.
2. The job updates a manifest with the new image tag.
3. The job runs kubectl apply (or helm upgrade) against the cluster.

Three problems show up as you scale:

• Credentials live outside the cluster. Every pipeline needs a kubeconfig or cloud credentials, and that multiplies with each application and each cluster.
• Tooling lives on the runner. kubectl, helm, and their versions have to be installed and kept in sync wherever deployments run.
• Feedback stops at “applied”. The job knows the API server accepted the manifest. It doesn’t know whether the Pods actually became healthy.

Flip the direction: pull

With a pull model, an agent runs inside the cluster, watches a Git repository, compares what’s declared there with what’s running, and applies the difference.

Developer ─▶ App repo ─▶ CI (test, build) ─▶ Image registry
                            │
                            └─ commits new image tag ─▶ Config repo
                                                            ▲
                                        Argo CD (in cluster) ┘ pulls, compares, applies
                                                │
                                                ▼
                                            Kubernetes

Cluster credentials never leave the cluster, because the only thing that applies changes is the agent running inside it. Engineers and CI systems only need write access to Git. Argo CD can read plain YAML, Helm charts, and Kustomize overlays, and renders them into Kubernetes manifests before applying.

Keep application code and configuration in separate repositories

The usual recommendation is two repositories: one for application source code, one for Kubernetes configuration (Deployments, Services, ConfigMaps, Ingresses, and so on).

The reason is that configuration changes on its own schedule. Editing a Service or a ConfigMap shouldn’t trigger a full build-and-test pipeline for code that didn’t change, and you don’t want pipeline logic that inspects a commit to decide what to skip. The CI pipeline’s last step becomes “commit the new image tag to the config repo”, and Argo CD takes it from there. It also splits ownership cleanly: developers own CI, platform or operations teams own delivery.

Make Git the only way in: drift detection and self-heal

Argo CD watches the live cluster as well as the repository. When the two disagree, the application is reported as OutOfSync. Depending on how you configure it, Argo CD then either just tells you or reverts the cluster to match Git (see the sync policy guide in this series).

This has practical consequences:

• Every change has a commit, an author, and usually a reviewed pull request, which gives you an audit trail.
• Permissions move to Git. Junior engineers can open pull requests; only a few people merge. You don’t need per-person cluster roles to get that.
• A quick manual kubectl edit in production stops being invisible.

Rollback and recovery become Git operations

Because desired state is versioned, going back to a known-good state is a git revert, and Argo CD converges the cluster to it. The same idea covers recovery. If a cluster is lost, you create a new one, install Argo CD, register the same repository, and the workloads are recreated from it. Anything that isn’t in Git, such as persistent data or secrets you manage elsewhere, still needs its own backup story.

One Argo CD instance can also manage many clusters, so a single repository can drive a fleet.

What Argo CD doesn’t replace

Argo CD is a delivery tool, not a build tool. You still need CI to test code, build images, and push them to a registry. It is also specific to Kubernetes, so other deployment targets need other tooling. And it isn’t the only GitOps controller: Flux implements the same principles with a different design. The rest of this series assumes Argo CD and starts with getting it installed. For the full reference, see the official Argo CD documentation.