Skip to main content
In this lesson we perform a manual reconciliation of an Argo CD application to illustrate why making ad-hoc changes directly in the Kubernetes cluster results in an OutOfSync state. You will:
  • Confirm cluster namespaces.
  • Synchronize an Argo CD application from Git.
  • Inspect the resulting live resources.
  • Make an intentional manual change in-cluster to cause drift.
  • Observe Argo CD detecting the OutOfSync state and restore the desired state by synchronizing from Git.

1. Confirm existing namespaces

First, verify which namespaces are present in the cluster:

2. Synchronize the Argo CD application

In the Argo CD web UI, click “Synchronize” for the application. Choose to auto-create the namespace if prompted and synchronize both the Deployment and Service manifests. Argo CD will apply those manifests and report the created ReplicaSet and Service details (such as the NodePort).
The image shows an interface for ArgoCD, displaying the status and details of an application called "highway-animation," which is healthy and synced to the latest commit. A visual workflow represents the deployment process from service to pod.
You can inspect logs, events, and a summary of the applied YAML from the Argo CD UI.

3. Inspect the created Pod manifest (live cluster)

Here is the Pod manifest that was created by the Deployment in the cluster:

4. Confirm the new namespace and resources

After synchronization, the highway-animation namespace should exist:
List all resources in the highway-animation namespace:
The app is reachable via the NodePort (e.g., http://localhost:32000) and will render the highway animation. With the Deployment set to 1 replica, you will see one vehicle.

5. Create drift: manually scale the Deployment in-cluster

In a non-GitOps workflow, an operator might directly edit the Deployment in the cluster to increase replicas:
Make these edits in the live Deployment manifest:
  • Change replicas: 1 to replicas: 5
  • Update the container environment variable POD_COUNT value from '1' to '5'
After saving, Kubernetes will create 4 additional pods and the app will show five vehicles. Important: This manual change modifies the live cluster state but does not update the Git repository. That causes the live state to diverge from the desired state declared in Git.

6. Example: live (cluster) Deployment after manual edit

Live (cluster) Deployment snippet showing the manual change:

7. Desired (Git) Deployment in the repository

The desired manifest stored in Git still declares 1 replica:
Because the live cluster has 5 replicas while Git declares 1, Argo CD will detect a difference and mark the application OutOfSync. In the Argo CD UI you can click “Diff” to view the highlighted mismatches between the live and desired manifests.

8. Reconcile back to Git (manual sync)

To restore the cluster to the Git-declared desired state, click “Synchronize” in Argo CD. Argo CD will reconcile the resources and update the live cluster to match the manifests in the repository. In this scenario it will update the Deployment (not the Service) to revert the replica count back to 1.
The image shows an Argo CD dashboard displaying the status and configuration of a Kubernetes application named "highway-animation," indicating a healthy sync status with a visual representation of its components and pods.
After synchronization, Argo CD will revert the cluster to the Git desired state and the application will again show a single pod/vehicle.

Quick reference: kubectl & Argo CD actions

Best practice

Never make long-lived configuration changes directly in the cluster. Always update the Git repository with the desired state and let your GitOps operator (Argo CD) reconcile the cluster. This ensures a single source of truth, prevents configuration drift, and makes rollbacks and audits straightforward.

Watch Video