Question
What causes an Argo CD application to remain OutOfSync after a sync operation?
Ari Dey
0 reputation · 02 Dec 2020, 00:02 UTC
97.5K views1
Loading…
0 reputation · 02 Dec 2020, 00:02 UTC
An Argo CD application should transition to Synced after a successful sync, but it can stay OutOfSync when the manifest path or revision is incorrect, the destination cluster is unreachable, the argocd-manager service account lacks necessary RBAC permissions, or repository credentials are invalid. Diagnosing the issue requires inspecting sync logs and verifying each of these factors without altering the live configuration prematurely.
How can one verify that the destination server URL is reachable from the Argo CD instance? Which specific RBAC permissions are required for the argocd-manager service account to manage resources in the target namespace? What steps confirm that repository credentials or SSH keys are correctly configured and valid?
34775 reputation · 02 Dec 2020, 07:18 UTC
An Argo CD application remains OutOfSync after a successful sync operation when the Live State in the cluster differs from the Desired State defined in Git. Even if the sync process reports success, any immediate modification to the resource by an external actor triggers a new drift detection, reverting the status to OutOfSync.
While connectivity and RBAC issues typically cause a Sync Failed error, a successful sync that returns to OutOfSync is usually caused by Live State Drift. Common triggers include:
To resolve this, you must identify the specific field causing the drift rather than attempting to re-sync repeatedly.
argocd
kuberneteskubectl get mutatingwebhookconfigurationsignoreDifferences block to your Application manifest to tell Argo CD to overlook those specific fields.argocd-server or argocd-application-controller pod:
kubectl exec -it <argocd-pod-name> -n argocd -- curl -k https://<destination-server-url>To provide a more specific recommendation, please provide the diff output from the Argo CD UI showing which specific fields are marked as different.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 02 Dec 2020, 01:49 UTC
Beyond mutating webhooks, it is important to consider how the Kubernetes API server handles default values and field ordering. Even when a manifest is applied correctly, the API server may inject default values for fields not specified in Git, or rearrange the order of elements in a list.
In some versions of Argo CD, these non-functional differences can trigger an OutOfSync status. To verify if this is the cause, compare the live manifest using kubectl get -o yaml against the Git source. If the diff shows fields that are functionally identical but structurally different (such as default timeout values), you can resolve this by adding those specific paths to the ignoreDifferences section of the Application spec.
Verification Tip: Check if the drift persists after a manual kubectl apply of the same Git manifest; if the cluster immediately adds fields that Argo CD flags, you are likely dealing with API-level defaults rather than an external controller.