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.
The Sync Policy determines how often the target cluster is synced to the Git repository.
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:
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.
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.
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.
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.
These options determine specific details of how the syncing process occurs. The following options are mutually inclusive.
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.
Auto-Create Namespace (default)
Selecting Auto-Create Namespace ensures that namespace specified as the application destination exists in the destination cluster.
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.
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.
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
kubectl.kubernetes.io/last-applied-configuration 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.
The Prune Propagation Policy determines how resources are deleted during the syncing process. In Kubernetes, this is determining how the Garbage Collector deletes dependents.
ownerReference.blockOwnerDeletion=trueblock the deletion of an owner object.