A GitOps continuous delivery tool for Kubernetes

Nothing but the Truth

Sync Policies

Automated sync policy allows Argo CD to apply changes from the Git repository automatically to the cluster. It can be configured in two modes: Auto-sync, wherein Argo CD automatically applies any changes as soon as they are detected in the Git repository, and Prune, wherein Argo CD automatically deletes resources that are not present in the Git repository but exist in the cluster.

Argo CD provides a variety of sync options to customize the synchronization process. For instance, setting Prune=false prevents an object from being pruned, ensuring it remains in the cluster even if it's not in the Git repository. On the other hand, Validate=false applies objects with the --validate=false flag, which can be useful for certain classes of objects that don't require validation.

Other options handle missing resources and resource deletion. The


option skips the dry run for missing resource types, and Delete=false retains certain resources even after your application is deleted.

Argo CD also offers options to control the timing and method of resource application. The PruneLast=true option allows resource pruning to happen as a final, implicit wave of a sync operation – after the other resources have been deployed and become healthy. If a resource spec is too big for kubectl apply, the Replace=true option uses the kubectl replace or kubectl create command to apply changes.

Finally, Argo CD also provides options to manage out-of-sync resources and resource propagation. With the


option, Argo CD syncs only out-of-sync resources, reducing pressure on the API server for applications with many objects. The PrunePropagationPolicy option controls the propagation policy for extraneous resources, with supported policies, including background, foreground, and orphan.

How do they work? When PrunePropagationPolicy is set to background, the Kubernetes garbage collector deletes the owner objects immediately, and the ownership-controlled objects are deleted in the background. For example, if you have a deployment that creates pods, and you delete the deployment with a background propagation policy, the deployment will be deleted immediately and the pods will be deleted in the background. You can set it as follows:

    argocd.argoproj.io/sync-options: PrunePropagationPolicy=background

However, when PrunePropagationPolicy is set to foreground, the ownership-controlled objects are deleted first, and the owner object is deleted once all dependent objects are deleted. Therefore, if you have a deployment that creates pods and you delete the deployment with a foreground propagation policy, the pods will be deleted first and the deployment will be deleted once all pods are deleted.

With the third setting, orphan, the owner object is deleted but the ownership-controlled objects are left as is. In this example, then, the deployment is deleted but the pods are left running. As you can see, users have extensive flexibility in managing the deletion of resources during pruning in Argo CD.

Sync Waves

At this point you might wonder how the synchronization process happens. Argo CD uses a mechanism known as "sync waves" that allow you to ensure certain resources are healthy before subsequent resources are synced. By default, all resources are assigned to wave 0. However, you can assign a resource to a specific wave by adding an annotation to the resource in the Git repository. The wave can be any integer, positive or negative. Resources with lower wave numbers are synced before resources with higher wave numbers. Resources with the same wave number are synced in parallel.

To assign a resource to a specific wave, use

apiVersion: v1
kind: ConfigMap
  name: my-configmap
    argocd.argoproj.io/sync-wave: "10"

When Argo CD starts a sync, it orders the resources by phase, wave, kind, and name. It applies resources in each wave and repeats this process until all phases and waves are in sync and healthy. The ConfigMap my-configmap is assigned to wave 10, which means it will be synced after resources in waves assigned values less than 10 are synced and become healthy. Also worth noting is the delay between each sync wave to give other controllers a chance to react to the spec change. The delay can be configured with the ARGOCD_SYNC_WAVE_DELAY environment variable.

Sync Phases

A sync operation is executed in a number of steps or phases. These phases allow you to control the order of operations and perform specific tasks at different stages of the sync process. At a high level are three phases: The first, PreSync, occurs before the main synchronization of resources. It's typically used to perform setup tasks that need to happen before the main sync, such as creating necessary namespaces or setting up permissions. Only hooks can be used in this phase.

The second phase, Sync, is the main phase of the sync operation, at which time Argo CD applies the desired state from the Git repository to the Kubernetes cluster. This phase includes creating, updating, or deleting resources as necessary to match the desired state.

The third stage, PostSync, occurs after the main synchronization of resources. It's typically used to perform cleanup or validation tasks that need to happen after the main sync, such as running tests or sending notifications. Like the PreSync phase, only hooks can be used.

You can define hooks for the PreSync and PostSync phases by adding annotations to the resources in your Git repository. To define a PreSync hook, use

apiVersion: batch/v1
kind: Job
  name: pre-sync-job
    argocd.argoproj.io/hook: PreSync

The Job pre-sync-job will be run during the PreSync phase of the sync operation. Similarly, you can define a PostSync hook with the

argocd.argoproj.io/hook: PostSync

annotation. As you can see, sync phases provide a powerful way to manage the lifecycle of a sync operation in Argo CD, allowing you to perform specific tasks at different stages of the process.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Native serverless computing in Kubernetes
    Knative transfers serverless workloads to Kubernetes and provides all the container components you need to build serverless applications and PaaS and FaaS services.
  • Secure and seamless server access
    The powerful Cloudflare Tunnel provides secure and seamless access to servers and applications, making it a convenient alternative to VPN for any modern IT infrastructure.
  • Users speak on Kubernetes in business practice
    Users in corporate and government agencies that have successfully switched to Kubernetes share their positive experiences and the stumbling blocks to be avoided.
  • Secure Kubernetes with Kubescape
    Kubescape checks Kubernetes container setups for security and compliance issues, making life easier for administrators.
  • Nested Kubernetes with Loft
    Kubernetes has limited support for multitenancy, so many admins prefer to build multiple standalone Kubernetes clusters that eat up resources and complicate management. As a solution, Loft launches any number of clusters within the same control plane.
comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>


		<div class=