Skip to main content
Once a cluster is running you still need to keep its agent current, connect its repository and data sources, decide who can reach it, and eventually stop, move or delete it. Cluster Settings is where you do that for one cluster. Open the cluster and choose Settings in the cluster sidebar. The sections below follow its tabs: General, GitOps, Kubernetes, Variables, Integrations, AI Context, Access and Audit. Node groups, control planes and the bastion are not in Settings: see Nodes.

​
General

​
Cluster Health

The Cluster Health card shows whether the agent is Online or Offline, when it was last seen, and its version. When a newer agent is available, Upgrade to <version> upgrades it now. Next to it, Kubernetes Watch shows whether Ankra’s copy of the cluster’s resources is Synced, Syncing, Stale or in Error; View Details opens the per-resource breakdown on the Kubernetes tab. For what the agent does, see Cluster Agent.

​
Agent Settings

Whether Ankra upgrades this cluster’s agent for you depends on two switches, and both must allow it:
  • Auto-upgrade Agents in Organisation Settings → General. It is on by default for organisations created since 7 September 2026; older organisations turn it on there. While it is off, no cluster in the organisation is upgraded automatically.
  • Disable Auto-upgrade on this card. Off by default; turn it on to keep this one cluster at its current agent version while the rest of the organisation upgrades.

​
Maintenance

  • Generate command creates a fresh agent installation command. Run it on the cluster to reinstall the agent, or to reconnect it when the agent is offline.
  • Sync All Resources triggers a full reconciliation: Ankra re-applies the cluster’s stacks, add-ons and manifests. Use it after a network outage or after changes made outside Ankra.

​
What this cluster is for

Sets how loudly the cluster reports. The scan finds the same issues either way; the level decides how large a problem must be before it opens a ticket and reaches Slack: The environment picker on the cluster overview sets the same value. When the organisation has proactive AI Insights on, an AI Insights card here turns them off or on for this cluster - see AI Insights.

​
Power schedules

Stops and starts the cluster on a timetable, on the providers that support stop and start. See Stop, Start and Power Schedules.

​
Kubernetes Version

Shown for clusters Ankra provisions and for managed Kubernetes. Pick a newer version and confirm. On a cluster Ankra provisioned, Ankra upgrades one node at a time, control plane first, draining each node while respecting PodDisruptionBudgets, and takes an etcd snapshot before the control plane moves; on managed Kubernetes the provider runs the rollout. Downgrades are not supported. Auto upgrade patch versions keeps the cluster on the newest patch release of its current minor version; minor versions are never upgraded automatically. Provider details are in each provider guide, for example Hetzner and managed Kubernetes.

​
Archive

Archive this cluster parks a cluster that is expected to be offline without disconnecting it: it sends no offline notifications, triggers no offline alerts, and is ignored by fleet health. Unarchive it to resume monitoring.

​
GitOps

Connect the cluster to a Git repository so its stacks are stored as code: choose a GitHub or Bitbucket Cloud credential, then a repository and branch, or create a new repository from the tab. The Webhook status shows whether pushes reach Ankra (Active, Pending, Failed or Not Configured), with Retry when it failed. See GitOps.

​
Kubernetes

A table of every Kubernetes resource type Ankra syncs from the cluster, with its status, count, last sync and errors, refreshed every 10 seconds. Search by resource type or status. Full Sync re-reads every resource from the cluster, which is what to run when the console shows something that no longer matches the cluster.

​
Variables

Values that every stack on this cluster can reference. See Variables.

​
Integrations

Connects the cluster’s data sources: Metrics (your own Prometheus, see Prometheus Integration), External Log Viewer, Cloud Cost, Trivy Operator, and Log Source (see Log Sources). Built-in metrics need none of them - see Cluster Metrics. SOPS encryption is configured for the whole organisation, not per cluster; see SOPS Encryption.

​
AI Context

Tag repositories that matter to this cluster, each with a short note on why, so Ankra’s AI reads them when it works on the cluster. The same tags feed AI code review.

​
Access

  • Access grants give organisation members access to this cluster, cluster-wide or to one namespace, enforced by Kubernetes RBAC within about a minute. See Cluster Access.
  • Generate kubeconfig gives you a kubeconfig that reaches the cluster through the Ankra gateway. See Kubeconfig.
  • SSH Access manages the SSH keys installed on the nodes of clusters Ankra provisions, and shows the commands to reach them through the jump host.

​
Audit

The Audit tab lists every manual action performed on this cluster: lifecycle (create, import, start, stop, upgrade, terminate), scaling and node group changes, node restarts, stack changes, and Helm upgrades and rollbacks. Each entry shows who did it, what it touched, when, and the structured details; when an edit produced a commit in the cluster’s GitOps repository, the entry links to it. View in organisation audit log opens the organisation Audit Log filtered to this cluster. Export CSV and Export JSON download this cluster’s entries, honouring the search on screen. The tab needs the audit read permission, held by owners and admins by default and grantable to custom roles. Entries cannot be edited or deleted.

​
Danger Zone

The Danger Zone card at the bottom of General holds the actions that cannot be undone. Which ones appear depends on the kind of cluster.

​
Move to another organisation

Imported clusters only. Move cluster moves the cluster into another organisation; you must be an admin of both. It keeps its agent, executions, stacks, resources, findings, DNS records and variables. Access grants, role assignments, kube tokens, notification routes, group memberships, links to this organisation’s registries and credentials, AI context repositories and the GitOps connection are detached; recreate them in the destination. Billing, the audit trail and support tickets stay with the old organisation. The move is refused while operations are running, while the cluster is in a cluster mesh or has DNS zones bound to the organisation, and when the destination already has a cluster with that name. The dialog gives the reason. The CLI equivalent is ankra cluster move <cluster> --organisation <id|slug|name>.

​
Stop cluster

Stop cluster and Start cluster release and restore the compute of a cluster Ankra provisioned. What a stop keeps depends on the provider; see Stop and start a cluster. The CLI commands for each provider are in Operate an Ankra Managed Cluster.

​
Switch the deployment engine

On a cluster still deploying with ArgoCD, Switch default deployment engine and Decommission ArgoCD move it to the native engine. See Decommissioning ArgoCD.

​
Disconnect Cluster

Imported clusters only. Disconnect removes the cluster from Ankra; running workloads and installed components stay, GitOps sync stops, and the agent is not removed from the cluster, so uninstall it yourself. To bring the cluster back, import it again. A managed Kubernetes cluster offers Disconnect from Ankra, which leaves the provider cluster running, and a separate action that deletes it at the provider - see Managed Kubernetes.

​
Terminate cluster

For clusters Ankra provisioned, Terminate destroys the cloud infrastructure and removes the cluster from Ankra. It cannot be undone. First clean up provider resources that Ankra does not track. For a cluster already terminated whose record remains, Delete Cluster removes the record.

​
Persistent volumes

On Hetzner, OVHcloud, UpCloud, DigitalOcean, Scaleway and AWS EC2, terminating a cluster also deletes the cloud volumes its CSI driver created for PersistentVolumeClaims, and the data on them. Ankra does this only once you accept it:
  • Dashboard. The Terminate and Delete cluster dialogs list the volumes by claim and size, and the delete button stays disabled until you tick I understand that these volumes and their data are deleted.
  • CLI. ankra cluster deprovision names the volumes and asks. In a script, pass --accept-volume-data-loss; --yes never stands in for it, and without it the command stops with exit code 2.
  • API. The delete needs ?accept_volume_data_loss=true and answers 409 naming the volumes without it.
  • Ankra’s AI. The delete_cluster tool names the volumes and asks you first.
--force tolerates unreachable infrastructure but never replaces the acknowledgement. When Ankra cannot list a cluster’s volumes it asks anyway. A cluster whose retention_policy is retain (the default on AWS EC2 and Scaleway) keeps its volumes, which keep billing in your cloud account until you delete them.

​
Next steps