Deployment Engines

The deployment engine is the part of Ankra that turns a Stack’s add-ons into Helm releases on your cluster and keeps them there. You rarely choose one: new clusters use the native engine, and clusters created before it keep ArgoCD until you migrate them. This page explains what each engine does, how an update is applied, and how to move a cluster from ArgoCD to native. How Ankra Works shows where the engine sits in the overall model.

​

Overview

Ankra supports two deployment engines for add-ons:

• Native (ankra_native): The Ankra agent uses the Helm CLI directly to install, upgrade, and reconcile chart-based add-ons. Releases are written to standard Helm storage (helm.sh/release.v1 Secrets).
• ArgoCD (argo_cd): The Ankra agent talks to an ArgoCD installation in the cluster, which renders the chart and applies it via server-side apply.

The engine is set per add-on, with a cluster-level default. New clusters use the native engine. Clusters created before it keep ArgoCD until you migrate.

​

Why migrate?

The native engine reduces the dependency surface on your cluster:

• No argocd-server, argocd-application-controller, argocd-repo-server, argocd-redis, argocd-applicationset-controller, argocd-notifications-controller, or argocd-dex-server to run on the cluster.
• No JWT lifecycle. The agent’s existing ServiceAccount is the only auth.
• Add-on status comes from the agent directly, not from ArgoCD.

On the native engine every add-on is a normal Helm release, so helm list, helm history, helm rollback and helm get manifest work directly against your cluster.

​

Feature parity

A cluster’s GitOps repository can be on GitHub or Bitbucket Cloud. Bitbucket Data Center is not supported as a GitOps source under either engine.

​

Applying an update

Installing or updating an add-on on the native engine runs helm upgrade --install, and the step does not succeed until the release is healthy. Two waits sit behind that, and both matter when an update cannot converge on its own. Helm waits first. The agent passes --rollback-on-failure --cleanup-on-fail, which makes Helm wait for the release’s resources to become ready and roll the release back if they do not, whether or not --wait is passed. The budget is the add-on’s helm_wait_timeout_seconds setting, 600 seconds by default. The automatic rollback then starts a fresh wait with the same budget, so a failing update can occupy twice the configured timeout before the step reports. The agent waits second, watching the rendered resources after Helm returns. If that wait expires, the agent rolls the release back to its previous revision - or uninstalls it, when the update was the add-on’s first install. Two add-on settings switch both behaviours off: rollback_on_failure: false and keep_failed_resources_for_debug: true. With either set, Helm applies the release and returns without waiting and nothing is rolled back. The agent still watches the rollout and still reports a timeout if the resources never become healthy, but the release keeps the new revision. If the agent stops while a rollback is running, the release can be left in pending-rollback, which blocks every later Helm operation on it. Clearing that by hand is not necessary: the next update of the add-on recovers the release before retrying, and so does the reconcile sweep below.

​

Reconcile loop

The native engine reconciles each add-on on its own schedule. Ankra asks the agent to reconcile an add-on whenever it is due. An add-on that just changed or failed is checked again within a minute or two; one that keeps coming back unchanged backs off in steps (5, 10, 20 minutes) to a check every 30 minutes, and a repeatedly failing one backs off to once an hour. Any change you make to the add-on makes it due immediately. The schedule lives in the platform, not in the agent. While a cluster cannot reach Ankra its workloads keep running untouched, but nothing is reconciled, deployed or self-healed until the connection returns; the agent reconnects on its own and the next due reconcile picks up where things stand. If the same drift reappears on three consecutive reconciles, self-heal for that add-on is paused for six hours rather than fighting whatever keeps changing the resource. Each sweep:

1. Recovers any release stuck in pending-* for more than 10 minutes: first attempts a fresh helm upgrade --install --atomic; if that fails, rolls back to the last deployed revision.
2. Detects drift against helm get manifest (live resources fetched in parallel; Helm-injected metadata stripped from both sides before diff).
3. If drift is detected and sync_policy.self_heal=true, marks the addon for update so the existing reconciler re-runs helm upgrade --install.
4. If sync_policy.auto_prune=true, deletes orphaned resources whose UID is no longer in the rendered manifest.

​

Sync windows

Set settings.sync_window.enabled=true on the addon and provide a 5-field cron expression and duration. The agent will only run create/update/self-heal operations inside the configured window. Outside the window, jobs return immediately as cancelled with an “outside_sync_window” task message.

​

Moving an add-on between namespaces

The native engine supports relocating an add-on to a different namespace. When you change an add-on’s target namespace, the agent installs the release into the new namespace and cleans up the resources left behind in the old one, so you don’t end up with orphaned objects. As with any namespaced move, persistent data tied to the old namespace (for example, PersistentVolumeClaims) is not automatically carried over - plan for data migration where relevant.

​

Migrating a cluster to the native engine

Moving a cluster from ArgoCD to the native engine is one flow in the portal:

1. Open the cluster’s Settings → General and scroll to the Danger Zone.
2. Click Decommission ArgoCD. Ankra first runs a preflight check and shows the add-ons that will migrate, anything that blocks the migration (resolve those add-on issues first), and warnings you have to acknowledge.
3. Confirm with Permanently decommission ArgoCD. Ankra migrates every ArgoCD-managed add-on to the native engine, then removes the Ankra-managed ArgoCD user. Workloads keep running during the migration, and re-running a failed migration is safe.

Each add-on is adopted with helm upgrade --install --take-ownership, so its live resources move into Helm storage without being recreated: resource UIDs do not change and no Pod restarts. The only change on the cluster is Helm’s app.kubernetes.io/managed-by=Helm label and the meta.helm.sh/release-name / meta.helm.sh/release-namespace annotations. The decommission leaves the ArgoCD installation itself and any ArgoCD Application CRs Ankra does not manage in place. Many teams keep using ArgoCD outside Ankra. If you no longer need it, uninstall it yourself with the tooling you installed it with (helm uninstall argocd, kubectl delete -f install.yaml, or argocd uninstall), and remove the leftover accounts.ankra and policy.csv entries from the argocd-cm and argocd-rbac-cm ConfigMaps if you keep ArgoCD running. The migration of addons is one-way: changing the cluster default deployment engine back to ArgoCD after decommission is not supported.