Add-on Settings

​

Overview

Every add-on deployed through Ankra is backed by an ArgoCD Application. The settings page lets you fine-tune how ArgoCD synchronizes, monitors, and recovers your add-on. You can configure these settings from:

• Stack Builder — click any add-on and open the Settings tab
• Standalone Add-ons — open the add-on and click Settings

Changes made in the Stack Builder are applied when you save the stack. Changes to standalone add-ons are applied to ArgoCD immediately.

---

​

Settings Profiles

Profiles are pre-configured bundles of settings optimized for common scenarios. Select a profile to quickly apply recommended values, or choose Custom to configure each setting individually. Changing any individual setting automatically switches the profile to Custom.

---

​

Sync Policy

The sync policy determines how ArgoCD responds to changes in your Git repository and drift in your cluster.

​

Automated Sync

When enabled, ArgoCD automatically syncs your add-on whenever changes are detected in Git. When disabled, you must trigger syncs manually.

​

Auto Prune

When enabled alongside Automated Sync, ArgoCD automatically deletes Kubernetes resources that are no longer defined in Git. This keeps your cluster clean but means removing a resource from your stack will delete it from the cluster.

​

Self Heal

When enabled alongside Automated Sync, ArgoCD automatically reverts any manual changes made directly to the cluster. If someone modifies a resource with kubectl, ArgoCD will detect the drift and restore the resource to match Git.

---

​

Sync Options

Sync options are flags that control specific ArgoCD behaviors during synchronization. You can select multiple options.

---

​

Health & Revisions

​

Strict Health Check

When enabled, ArgoCD requires all resources created by the add-on to report a healthy status before considering the deployment successful. This is useful for production-critical add-ons where partial deployments are unacceptable. When disabled (default), ArgoCD considers the sync successful as soon as resources are applied, regardless of their health status.

​

Revision History Limit

Controls how many previous application revisions ArgoCD retains (1—100). Higher values consume more storage but make it easier to audit changes and understand deployment history. The default is 10.

---

​

Retry Policy

The retry policy controls automatic retry behavior when a sync operation fails. Retries use exponential backoff: each retry waits longer than the previous one, up to the max delay. For example, with the defaults, retries happen at approximately 5s, 10s, 20s, 40s, and 80s (capped at 3m).

---

​

Sync Window

Sync windows restrict when ArgoCD is allowed to synchronize your add-on. This is useful for enforcing change-management policies, such as only allowing deployments during business hours or maintenance windows. When a sync window is active, ArgoCD will only sync during the defined window. Outside the window, changes accumulate in Git and are applied when the next window opens.

---

​

Ignore Differences

Ignore Differences lets you tell ArgoCD to skip specific fields when comparing the desired state (Git) with the live state (cluster). This prevents false “OutOfSync” reports caused by fields that are mutated at runtime by Kubernetes controllers, webhooks, or operators.

​

Why Ignore Differences?

ArgoCD continuously compares your Git repository with the live cluster state. When they differ, ArgoCD reports the resource as OutOfSync. However, some fields are legitimately modified after deployment:

• Webhook controllers inject caBundle values into webhook configurations
• Kubernetes assigns clusterIP to Services automatically
• Operators update status fields and annotations on custom resources
• Controllers like kube-controller-manager set default values on resources

Without ignore rules, these runtime mutations cause constant OutOfSync status, triggering unnecessary syncs (with auto-sync) or masking real configuration drift.

​

Resource Selectors

Each ignore rule can be scoped to specific resources using optional selectors: All selectors are optional. Omitting a selector means the rule matches all values for that field. For example, a rule with only Kind: Service and no name or namespace applies to every Service in the add-on.

​

Matching Methods

Each rule must include at least one of the following methods to specify which fields to ignore.

​

JSON Pointers

JSON Pointers (RFC 6901) are path-based references into a JSON document. They use / as a separator and numeric indices for arrays. Syntax: /path/to/field or /path/0/arrayElement Examples:

​

JQ Path Expressions

JQ path expressions use the jq query language syntax to target fields. They are more powerful than JSON Pointers and support wildcards and array iteration. Syntax: .path.to.field or .path[0].arrayElement Examples:

​

Managed Fields Managers

Instead of targeting specific fields, you can ignore all fields managed by a particular controller or process. Kubernetes tracks which controller “owns” each field through its Server-Side Apply mechanism. Examples:

​

Common Examples

​

Important Behaviors

---

​

Related