- What happens when an application is configured with manual sync mode.
- Creating cluster resources from Git via the Argo CD UI.
- How Argo CD detects drift when live resources are edited directly.
- Reconciling the application back to Git’s desired state.
Desired manifests discovered by Argo CD
Argo CD inspects the Git repo and shows the desired manifests. For example, the Service manifest discovered by Argo CD:
Verify resources with kubectl
Use kubectl to confirm the namespace and resources were created:blue, so the running app shows blue vehicles.
Deployment (desired state in Git)
Deployment manifest stored in Git (replicas: 1, POD_COUNT env = “1”):Manual change on the cluster (drift)
If a developer edits the live Deployment directly (for example usingkubectl edit) and increases replicas to 5 and updates POD_COUNT to “5”, the live cluster will diverge from Git:
Reconcile by syncing from Git
To restore the cluster to the Git-defined desired state, click Synchronize in the Argo CD UI. Argo CD will fetch manifests from Git and apply them to the cluster — scaling the Deployment back to 1 replica and updating POD_COUNT back to “1”. Extra pods created by the manual edit will be terminated. After a successful sync, the resource tree displays resources as Synced and Healthy:
Quick reference — kubectl commands used
Further reading
Argo CD treats Git as the source of truth. Manual edits to live cluster resources cause drift (OutOfSync). To make a permanent change, update the manifests in the Git repository and then let Argo CD apply those changes (or use Argo CD’s UI to sync Git into the cluster). Avoid modifying cluster-managed resources directly unless you intentionally want to bypass Git.