This doc provides an in depth description for the various settings assigned to applications in Koncrete.

Applications have a number of different settings that can adjust the way that syncs occur. The default options are shown picture below:

Detailed descriptions of each of these settings are provided below, organized by section.

Sync Policy

The Sync Policy determines how often the target cluster is synced to the Git repository.

  1. Automatic Sync

    An application with an Automatic Sync policy will periodically (or instantly upon a detected change) sync the target cluster to the Git repository. By default, every 3 minutes the status of the cluster is checked against the Git repository specified infrastructure.

    Automatic Sync can also be configured to sync the target cluster to the Git repository every time a change occurs in the repo. This yields the often desirable experience of "git push" immediately updating the cluster. To setup instant syncing, use the ADD REPO button - this process will setup a webhook that Koncrete can read to instantly catch Git updates.

    Additionally, there are several flags that can be selected for Automatic Syncing:

    1. Prune Resources

      By default, Automatic Sync will not delete resources when Argo CD detects that the resource is no longer defined in Git. Checking Prune Resources allows Argo CD to delete resources for this application if they are no longer defined in the Git repository.

    2. Self Heal

      By default, changes that are made to the live cluster will not trigger an automated sync. Checking Self Heal allows Argo CD to force the desired state (defined by Git) into the cluster whenever a deviation is detected within the cluster.

    3. Allow Empty By default, Automatic Sync with Prune Resources selected will prevent an application for having empty resources. This is a default safety mechanism within Argo CD. Checking Allow Empty allows an application to have empty resources without being pruned.

  2. Manual Sync There are some cases where automatically syncing the target cluster to the Git repository is not desired. Instead, syncs can be performed manually with the Manual Sync policy. Selecting this option allows the user to control syncs manually, which can be performed either through Koncrete or directly within Argo.

Sync Options

These options determine specific details of how the syncing process occurs. The following options are mutually inclusive.

  1. Skip Schema Validation Selecting Skip Schema Validation uses the --validate=false flag when running kubectl apply. This is often desired for certain object classes, such as ServiceCatalog.

  2. Auto-Create Namespace (default)

    Selecting Auto-Create Namespace ensures that namespace specified as the application destination exists in the destination cluster.

  3. Prune Last By default, Argo CD will prune resources during the syncing process while others are still deploying. Selecting Prune Last allows resource pruning to only happen as a final, implicit step in the sync process - after other resources are deployed, become healthy, and after all other waves have completed successfully.

  4. Apply Out of Sync Only By default, syncing in Argo CD applies every object in the application. For large applications (like those that contain thousands of objects), this process is quite slow and puts unneeded pressure on the api server. Selecting Apply Out of Sync Only will change the sync process such that Argo CD only syncs out-of-sync resources, while other resources determined in-sync remain unchanged.

  5. Replace By default, Argo CD uses kubectl apply to apply the configurations stored in the Git repository. Selecting Replace instead allows Argo to use the kubectl replace or kubectl create commands to apply changes. There are some cases where the kubectl apply command is insufficient. For example, if the resource spec is too big, it may not be able to fit into the annotation that is added by kubectl apply. The Replace option can be selected for these cases. Argo advises caution when using the Replace option, as the kubectl replace and kubectl create commands are potentially destructive actions.

Prune Propagation Policy

The Prune Propagation Policy determines how resources are deleted during the syncing process. In Kubernetes, this is determining how the Garbage Collector deletes dependents.

  1. Foreground (default) When a Foreground cascading deletion is initiated, the root object enters a "deletion in progress" state. Upon entering this state, the garbage collector begins to delete the object's dependents. During this state, the object is still visible via the REST API. Once all of the blocking dependents are deleted, it deleted the owner object. Only dependents with ownerReference.blockOwnerDeletion=true block the deletion of an owner object.
  2. Background When a Background cascading deletion is initiated, Kubernetes deletes the owner object first. The garbage collector then deletes its dependents in the background.
  3. Orphan When an Orphan deletion is initiated, objects are deleted without deleting their dependents automatically. As such, their dependents are said to be orphaned.