ankra cluster
Commands for managing and operating on clusters. Flagsankra cluster access
List, grant, and revoke per-user access to a cluster’s Kubernetes API through the Ankra gateway (the access used by ‘ankra cluster kubeconfig’ and ‘ankra cluster kube-token’). Managing access requires organisation admin rights. Grants apply to one cluster and one organisation member, identified by email. Examples:ankra cluster access grant
Grant an organisation member access to a cluster’s Kubernetes API through the Ankra gateway. The grant is cluster-wide by default; pass--namespace to limit it to one
namespace. Roles map to the standard Kubernetes ClusterRoles: view, edit,
admin, cluster-admin.
ankra cluster access list
List access grants for a clusterankra cluster access revoke
Revoke gateway access from a cluster. Pass a grant ID (from ‘ankra cluster access list’) to revoke a single grant, or an email address to revoke every grant that member has on the cluster.ankra cluster addons
Commands to list, manage settings, and uninstall addons.ankra cluster addons available
List addons available for installationankra cluster addons list
List addons for the active cluster; or show details for a single addonankra cluster addons settings
Read and write an addon’s settingsankra cluster addons settings get
Get settings for an addonankra cluster addons settings set
Change one or more settings on an addon without resending the rest. Each flag is applied to the addon’s stored settings; anything you do not pass is left as it is. To replace the whole document instead, use ‘ankra cluster addons update <addon> -f settings.json’. Backup settings (closed beta) override the add-on’s stack backup policy for this add-on only - use them for the one add-on in a protected stack that should be captured differently:ankra cluster addons uninstall
Uninstall an addon from the clusterankra cluster addons update
Update addon settings by providing a JSON file that conforms to the settings schema. Example JSON file:ankra cluster addons upgrade
Upgrade an addon by patching just the fields you supply. At least one mutating flag is required. Examples:--set* and --values-from-file are mutually exclusive: --set* mutates the
existing values document while --values-from-file replaces it.
Changing --namespace is destructive (Helm reinstall in the new namespace,
leaves the old release orphaned). Use --yes to skip the confirmation prompt
or interactively confirm.
ankra cluster addons values
Print the current Helm values document for an addon. By default the decoded YAML is written to stdout, making it easy to pipe into a file or edit and re-apply with--values-from-file:
ankra cluster agent
Commands to view agent status, get tokens, and upgrade agents.ankra cluster agent auto-upgrade
The platform rolls new agent releases out to every online agent automatically, as soon as the cluster has no write execution running. Disabling that here fences this cluster’s agent off from the rollout - for a freeze window or a migration night - and enabling it puts the agent back in. Either way ‘ankra cluster agent upgrade’ still applies the latest release on demand, and ‘ankra cluster agent status’ shows the current setting. Examplesankra cluster agent auto-upgrade disable
Fence the cluster agent off from the automatic fleet rolloutankra cluster agent auto-upgrade enable
Put the cluster agent back into the automatic fleet rolloutankra cluster agent ci
The cluster agent runs Ankra Pipelines steps itself, and these settings size that: how many steps it runs at once, and the storage class its step workspaces are carved from. Both are stored on the platform, so every install or upgrade command Ankra generates for this cluster carries them - unlike a hand-run ‘helm upgrade--set ci_worker_count=…’, which the next agent upgrade
renders away again.
ankra cluster agent ci get
Show the stored worker count and storage class, the agent version that has to honour them, whether that agent currently advertises it can run pipeline steps, and how the last write was applied. An agent that has not yet re-rendered its release reports pipeline steps as not advertised even with a non-zero worker count stored: the capability is what the agent reported on its last check-in, not what the settings ask for.ankra cluster agent ci set
Store how many pipeline steps this cluster’s agent runs at once, and optionally the storage class its step workspaces are carved from.--workers 0 disables the agent’s pipeline-step scheduler; the cluster keeps
its agent and everything else it does. --storage-class is only sent when you
pass it, so setting the worker count alone keeps the storage class already
stored; pass an empty value to fall back to the cluster’s default class.
The write always stores the values. Whether they reach the agent now depends
on the agent: an online agent new enough to accept chart values re-renders
its release immediately, an older one picks them up at its next upgrade, and
an offline one when it reconnects. The command says which of the three
happened.
ankra cluster agent status
Get agent status for the selected clusterankra cluster agent token
Get or generate agent token for the selected clusterankra cluster agent upgrade
Upgrade the agent on the selected clusterankra cluster ankracloud
Manage kubeadm or k3s clusters Ankra builds on Ankra Cloud servers. For Ankra Cloud Kubernetes, where the Ankra team runs the control plane, use ‘ankra cluster managed …--provider ankracloud_k8s’ instead. Both take the
same Ankra Cloud credential (‘ankra credentials ankracloud create’).
ankra cluster ankracloud bastion
Inspect, diagnose, and resize the cluster’s single bastion/gateway node. Find its node ID with ‘nodes list’.ankra cluster ankracloud bastion diagnose
Dispatch the provider’s read-only bastion diagnose job and wait for its report: sshd configuration, failed-login volume, disk, failed units, journal errors, listening ports, and pending security updates. Nothing on the host is changed. The platform waits up to two minutes for the job; a slower run hands back the operation id to poll with ‘cluster operations list’.ankra cluster ankracloud bastion resize
Resize the bastion/gateway node. The provider’s bastion/gateway update job powers it off, resizes it, and powers it back on, causing brief SSH/NAT downtime for the cluster.--wait covers the platform write only; the cloud resize runs as the operation
reported on success. Follow it with ‘ankra cluster operations list <operation_id>’.
ankra cluster ankracloud bastion status
Report the verdict the platform’s bastion health loop last recorded for the cluster’s bastion/gateway: whether it is reachable, which hop a failed probe stopped at, and when it was last checked. Nothing is probed by this command, so it answers even while the bastion is unreachable - use ‘bastion diagnose’ to SSH in and collect a fresh report.ankra cluster ankracloud control-plane
Inspect and change the control plane configuration. Only 1 or 3 controllers are allowed (etcd needs an odd number of voting members for quorum). The controller count can only be changed while the cluster is stopped, and applies the next time the cluster is started. The instance type can also be changed on a running cluster that has three controllers: they are then resized one at a time, keeping the Kubernetes API up. With a single controller it still needs a stopped cluster, because resizing the only controller takes the API down while it reboots. Run “control-plane get” to see which of the two is available right now.ankra cluster ankracloud control-plane get
Show the current control plane configurationankra cluster ankracloud control-plane set-count
Change the controller count (1 or 3)ankra cluster ankracloud control-plane set-instance-type
Change the instance type of every controller in a Ankra Cloud cluster. The instance type is stored as given; it is not checked against Ankra Cloud’s catalog. A name that does not exist is rejected by Ankra Cloud itself, which on a stopped cluster is at the next start - after this command has already reported success. On a running cluster the rolling resize drains each controller before resizing it, honouring its pods’ PodDisruptionBudgets.--force-drain bypasses them for
that drain, so pods whose budget refuses eviction are evicted anyway. It
applies to this request only, and only a live rolling resize reads it: a
stopped cluster’s offline resize drains nothing and ignores it, and so does a
request the rolling resize refuses (fewer than three controllers) or has
nothing to do for (the controllers already run that type).
List the instance types that do exist with:
ankra cluster ankracloud create
Create an Ankra-managed kubeadm (default) or k3s cluster on Ankra Cloud servers. Ankra builds the private network (unless--private-network-id adopts
one), a NAT router for the nodes’ IPv4 egress, the per-server firewalls, a
bastion with a public IPv4 address, and the control plane and worker servers.
The kube-apiserver stays private and is reached through the bastion.
Servers are sized by plan: list them with ‘ankra cluster ankracloud plans’.
Run ‘preflight’ first to check the zone, plans and network.
Examples:
ankra cluster ankracloud deprovision
Permanently delete an Ankra Cloud cluster and the servers, network, router and firewall rules Ankra created for it. An adopted private network is left in place. Volumes follow the cluster’s retention_policy: ‘retain’ keeps them, ‘delete’ sweeps them. A ‘delete’ cluster’s persistent volumes are named first and deleted only when you accept that: answer the prompt on a terminal, or pass--accept-volume-data-loss (--yes does not imply it).
ankra cluster ankracloud k8s-version
Get current Kubernetes version for an Ankra Cloud clusterankra cluster ankracloud networks
List the Ankra Cloud private networks a cluster can adoptankra cluster ankracloud nodes
Inspect every server Ankra manages for the cluster (control plane, workers, and bastion or gateway). Soft-deleted entries from a stopped cluster are included so the saved topology is visible before re-provisioning.ankra cluster ankracloud nodes cloud-init-log
Fetch ‘cloud-init status--long’ and the tail of
/var/log/cloud-init-output.log from the node over the platform’s bastion SSH
lane, as a tracked read-only operation. This is the debug surface for
node-group user-data: it shows whether the first-boot document ran and what
it printed, without needing the cluster’s SSH key. Repeated calls attach to
an in-flight fetch instead of dispatching duplicates. Find node ids with
‘nodes list’.
ankra cluster ankracloud nodes get
Show full spec and metadata for a single nodeankra cluster ankracloud nodes list
List all nodes for the clusterankra cluster ankracloud nodes restart
Schedule a native reboot (falling back to a power cycle) of the node as a tracked operation. The node must be in the ‘up’ state and have no restart already in flight. Workloads on the node are briefly unavailable while it reboots. Works for any node returned by ‘nodes list’, including the bastion/gateway.ankra cluster ankracloud plans
List the server plans (sizes) the create and node-group flags take. Pass--credential-id to browse before creating a cluster, or --cluster to list
the plans under an existing cluster’s own credential (for node groups and
control-plane or bastion resizes).
ankra cluster ankracloud preflight
Run the Ankra Cloud create preflight: credential, zone, plan and template availability and the network, without building anything. Takes the same flags as ‘create’.ankra cluster ankracloud pricing
Show Ankra Cloud storage and public IPv4 pricesankra cluster ankracloud start
Start a stopped Ankra Cloud cluster. Use--scope control_plane to bring up only the control plane.
ankra cluster ankracloud stop
Stop an Ankra Cloud cluster. A plain stop powers the servers off and keeps them with their disks; only a forced stop or a deprovision deletes servers.ankra cluster ankracloud templates
List the operating-system templates Ankra Cloud servers bootankra cluster ankracloud workers
Get current worker count for an Ankra Cloud clusterankra cluster ankracloud zones
List the Ankra Cloud zones a credential can useankra cluster apply
Apply an ImportCluster YAML to the Ankra APIankra cluster aws
Manage the lifecycle of self-managed Kubernetes clusters Ankra builds on EC2. These are k3s (or kubeadm) clusters on plain EC2 instances, not EKS. By default Ankra creates the whole network for the cluster (VPC, subnets, internet gateway, route tables, NAT) and removes it with the cluster; pass--vpc-id to build inside a VPC you already own instead. For an EKS control
plane use ‘ankra cluster managed’.
ankra cluster aws access-info
Show the bastion and control plane IPs plus ready-to-use SSH jump and Kubernetes API port-forward commands.ankra cluster aws availability-zones
List the availability zones of a regionankra cluster aws bastion
Inspect and diagnose the cluster’s single bastion/gateway node. Find its node ID with ‘nodes list’.ankra cluster aws bastion diagnose
Dispatch the provider’s read-only bastion diagnose job and wait for its report: sshd configuration, failed-login volume, disk, failed units, journal errors, listening ports, and pending security updates. Nothing on the host is changed. The platform waits up to two minutes for the job; a slower run hands back the operation id to poll with ‘cluster operations list’.ankra cluster aws bastion status
Report the verdict the platform’s bastion health loop last recorded for the cluster’s bastion/gateway: whether it is reachable, which hop a failed probe stopped at, and when it was last checked. Nothing is probed by this command, so it answers even while the bastion is unreachable - use ‘bastion diagnose’ to SSH in and collect a fresh report.ankra cluster aws control-plane
Inspect and change the control plane configuration. Only 1 or 3 controllers are allowed (etcd needs an odd number of voting members for quorum). The controller count can only be changed while the cluster is stopped, and applies the next time the cluster is started. The instance type can also be changed on a running cluster that has three controllers: they are then resized one at a time, keeping the Kubernetes API up. With a single controller it still needs a stopped cluster, because resizing the only controller takes the API down while it reboots. Run “control-plane get” to see which of the two is available right now.ankra cluster aws control-plane get
Show the current control plane configurationankra cluster aws control-plane set-count
Change the controller count (1 or 3)ankra cluster aws control-plane set-instance-type
Change the instance type of every controller in a AWS cluster. The instance type is stored as given; it is not checked against AWS’s catalog. A name that does not exist is rejected by AWS itself, which on a stopped cluster is at the next start - after this command has already reported success. On a running cluster the rolling resize drains each controller before resizing it, honouring its pods’ PodDisruptionBudgets.--force-drain bypasses them for
that drain, so pods whose budget refuses eviction are evicted anyway. It
applies to this request only, and only a live rolling resize reads it: a
stopped cluster’s offline resize drains nothing and ignores it, and so does a
request the rolling resize refuses (fewer than three controllers) or has
nothing to do for (the controllers already run that type).
List the instance types that do exist with:
ankra cluster aws create
Create an Ankra-managed k3s or kubeadm cluster on EC2 instances. By default Ankra creates the whole network: a VPC from--network-ip-range
(default 10.0.0.0/16) with a public bastion subnet and private node subnets
in each of --availability-zones (default: one zone, or three when the
control plane has 3 or more nodes), an internet gateway, route tables and
the nodes’ egress - ‘nat_gateway’ (the default; one NAT gateway per zone, or
one in total with --nat-gateway-single-zone) or ‘bastion_nat’ (the bastion is
the nodes’ NAT, the cheapest option). The created network is Ankra’s and is
deleted with the cluster.
Pass --vpc-id to build inside a VPC you already own instead: Ankra adopts
the VPC, --node-subnet-ids and --bastion-subnet-id and never creates or
deletes networking there. Egress is then detected from the node subnets’
route tables unless --egress-mode pins it: ‘existing’ uses the NAT gateway
or internet gateway the subnets already route through, ‘bastion_nat’ makes
the bastion the NAT. --network-ip-range, --availability-zones and
--nat-gateway-single-zone do not apply to an adopted VPC.
In both modes Ankra owns the instances, security groups, the generated SSH
key and the bastion. Run ‘preflight’ first to check the region, the network
(ownership, zones, CIDR or the adopted subnets), instance-type availability
and the resolved egress mode.
Examples:
ankra cluster aws deprovision
Permanently delete an AWS cluster and the provider resources Ankra created for it: the instances, security groups, bastion and generated SSH key, and - when Ankra created the network - the VPC, subnets, internet gateway, NAT gateways, route tables and elastic IPs. An adopted VPC and its subnets are never touched. EBS volumes and load balancers follow the cluster’s retention_policy: ‘retain’ keeps them (forced or not, for the volumes), ‘delete’ sweeps them. A ‘delete’ cluster’s persistent volumes are named first and deleted only when you accept that: answer the prompt on a terminal, or pass--accept-volume-data-loss (--yes does not imply it).
ankra cluster aws images
List the Ubuntu series and CPU architectures a create may ask for with--ubuntu-series and --architecture. The platform resolves the actual AMI at
build time, so there is no AMI id to pick.
ankra cluster aws instance-types
List EC2 instance types available in a regionankra cluster aws k8s-version
Get current Kubernetes version for an AWS clusterankra cluster aws nodes
Inspect every server Ankra manages for the cluster (control plane, workers, and bastion or gateway). Soft-deleted entries from a stopped cluster are included so the saved topology is visible before re-provisioning.ankra cluster aws nodes cloud-init-log
Fetch ‘cloud-init status--long’ and the tail of
/var/log/cloud-init-output.log from the node over the platform’s bastion SSH
lane, as a tracked read-only operation. This is the debug surface for
node-group user-data: it shows whether the first-boot document ran and what
it printed, without needing the cluster’s SSH key. Repeated calls attach to
an in-flight fetch instead of dispatching duplicates. Find node ids with
‘nodes list’.
ankra cluster aws nodes get
Show full spec and metadata for a single nodeankra cluster aws nodes list
List all nodes for the clusterankra cluster aws nodes restart
Schedule a native reboot (falling back to a power cycle) of the node as a tracked operation. The node must be in the ‘up’ state and have no restart already in flight. Workloads on the node are briefly unavailable while it reboots. Works for any node returned by ‘nodes list’, including the bastion/gateway.ankra cluster aws preflight
Run the AWS create preflight: credential and region reachability, the network (a free CIDR and the zones for a created network; VPC and subnet membership and bastion subnet routing for an adopted one), instance-type and AMI availability, and what the server resolved - the network ownership (created or adopted), the availability zones the network will span, and the egress mode when--egress-mode is left unset.
Takes the same flags as ‘create’.
ankra cluster aws pricing
Show the on-demand prices a cluster in a region is estimated fromankra cluster aws regions
List AWS regions available to a credentialankra cluster aws start
Re-provision a stopped AWS cluster. Use--scope control_plane to bring up only the control plane.
ankra cluster aws stop
Stop an AWS cluster by terminating its EC2 instances while preserving its configuration so it can be re-provisioned later.ankra cluster aws subnets
List the subnets of a VPC with their availability zone, how their route table reaches the internet (egress: internet_gateway, nat_gateway, nat_instance, transit, none or unknown) and how many instances Ankra did not create already live in them. Nodes go in private subnets (egress via a NAT gateway, or via the bastion with--egress-mode bastion_nat, which is
refused when a node subnet carries foreign instances); the bastion needs a
public one (internet_gateway).
ankra cluster aws vpcs
List the VPCs of a region with their CIDR and DHCP domain name. The DHCP domain column is the domain the VPC’s DHCP option set hands to instances; “(none)” means the option set names no domain and ”?” means it could not be read, which is not the same thing.ankra cluster aws workers
Get current worker count for an AWS clusterankra cluster backups
Read the cluster’s backup posture: which stacks are protected, which hold data and are not, what each one can be restored from, and whether the backup components are installed on the cluster.ankra cluster backups status
Show what this cluster is backing up, one row per stack. The verdict has three values, not two: “unknown” is a stack Ankra could not assess - its inventory has not landed, or its backup settings could not be read - and it is deliberately not reported as unprotected. Examples:ankra cluster clear
Clear the active cluster selectionankra cluster clone
Clone stacks from an existing cluster ImportCluster YAML to a new cluster. The source can be either a local file path or a URL (http/https). Examples:ankra cluster cordon
Mark a node unschedulable so no new pods land on it. Pods already running stay where they are; ‘cluster drain’ moves them off. ‘cluster uncordon’ puts the node back into service. Example:ankra cluster custom-dns-zones
Declare, list, and withdraw the DNS zones a cluster serves with the organisation’s own external-dns webhook credential, alongside the generated domain Ankra serves itself. The external-dns Ankra manages publishes only under the cluster’s generated subdomain: its credential is scoped to that zone by the DNS provider, so ingress hostnames on your own zones are dropped silently. Declaring a zone here has Ankra render and reconcile a separate external-dns for it, using a DNS credential you supply (‘ankra org dns credentials’). Each controller is pinned to exactly its zone with its own record ownership, so it can never fight Ankra’s controller or another cluster’s. To serve a zone from every cluster in the organisation - including clusters created later - declare it once with ‘ankra org custom-dns-zones add’ instead. ‘list’ shows those inherited zones with source ‘organisation’; a zone declared here on the cluster itself takes precedence over the organisation’s on this cluster, which is how one cluster serves a zone with a different credential. Withdrawing a zone removes the controller Ankra rendered; the zone’s records are yours and are left untouched.ankra cluster custom-dns-zones add
Declare a zone the cluster also serves, with the DNS credential that can publish into it. Ankra renders an external-dns for the zone on the next reconciler pass, scoped to exactly that zone. Refused when the zone is not a domain name, when the organisation has no DNS credential of that name, or when the zone overlaps the generated domain Ankra already serves for this cluster - that would put a second controller on names Ankra’s own external-dns publishes.ankra cluster custom-dns-zones list
List the zones declared on a clusterankra cluster custom-dns-zones remove
Withdraw a declared zone. Ankra removes the controller it rendered on the next reconciler pass. The zone’s records are yours and are left untouched.ankra cluster debug
Debug pods are pods Ankra creates on your behalf, in any namespace of the active cluster, from an image chosen for its tools rather than for the workload. Point one at an existing pod with--from-pod and it impersonates
that pod: the same service account, node, volumes and volume mounts,
environment variables and envFrom sources, tolerations and security
context - under an image that actually has curl, dig, psql or strace in it.
The workload itself is never touched.
Labels are never copied, so a debug pod never sits behind the workload’s
Service. Every debug pod carries a lifetime the kubelet enforces on its own,
and every terminal session into one is recorded to the audit log.
ankra cluster debug create
Create a debug pod in a namespace of the active cluster and wait for it to start. With--from-pod the pod impersonates the named pod - its service
account, node, volumes and mounts, environment - so what the workload’s
container sees, the debug pod sees. Without --from-pod it is a plain pod of
the chosen image with no service-account token.
The command prints the portal link to the new pod’s terminal; every session
opened there is recorded to the audit log. Creating a debug pod needs the
kubernetes.write and kubernetes.exec permissions.
Examples:
ankra cluster debug delete
Delete a debug pod before its lifetime ends. Only a pod carrying the ankra.io/debug-pod label can be deleted this way; a workload pod answers not found.ankra cluster debug images
List the tag-pinned images the platform offers for debug pods. Any image reference is accepted by “debug create--image”; the catalogue is the set
that ships with tools and is known to pull.
ankra cluster debug list
List the debug pods on the active clusterankra cluster decrypt
Decrypt SOPS-encrypted values stored on a cluster or in a local cluster.yaml.ankra cluster decrypt addon
Decrypt a SOPS-encrypted addon’s Helm values and print the result to stdout. Two modes: Cluster mode (default): fetch the addon values from a live cluster, decrypt, and print to stdout. File mode (-f cluster.yaml): read the addon values file referenced from a local cluster.yaml, decrypt, and print to stdout. Examples:ankra cluster decrypt manifest
Decrypt a SOPS-encrypted manifest and print the result to stdout. Two modes: Cluster mode (default): fetch the manifest from a live cluster, decrypt it, and print to stdout. File mode (-f cluster.yaml): read the manifest file referenced from a local cluster.yaml, decrypt it, and print to stdout. Examples:ankra cluster delete
Delete one or more Kubernetes resources from the active cluster. The kind takes the kubectl spellings - pod, pods, po, deployment, deploy, statefulset, sts, configmap, cm, namespace, node, pvc, … - and a custom resource is reachable with--group and --api-version, exactly like
‘cluster get resources’ and ‘cluster describe’.
A pod owned by a controller (Deployment, StatefulSet, DaemonSet, Job) is
recreated by that controller, so deleting it is how you restart a single
replica; ‘cluster restart’ rolls a whole workload. The delete goes through
the cluster’s Ankra agent: no kubeconfig is needed and the same organisation
permissions as the portal apply.
Each object reports its own outcome. The command exits 0 when everything was
deleted, 3 when one of the objects did not exist, and 1 when the cluster
refused a delete.
Examples:
ankra cluster deprovision
Tear down a managed cluster: everything it runs on is released. Whether the cluster survives as a record depends on its kind, and the two outcomes are very different:- cloud clusters (hetzner, ovh, upcloud, digitalocean, scaleway, ankracloud, aws, proxmox, morpheus) go to the provider-specific endpoint, which DELETES the cluster. The record does not survive, “ankra cluster provision” cannot bring it back, and the cluster id, its stacks and anything referencing them are gone. Rebuilding means creating a new cluster;
- imported clusters keep their record, so “ankra cluster provision” can rebuild them from the stored stack definition later.
- all cloud resources are released (servers, networks, SSH keys);
- every stack resource on the cluster is uninstalled;
- on hetzner, ovh, upcloud, digitalocean, scaleway, ankracloud and aws the cluster’s
persistent volumes (the cloud volumes its CSI driver provisioned) are
deleted with it, and the data on them. The command names them first and
deletes them only when you accept that: answer the prompt on a terminal,
or pass
--accept-volume-data-loss(--yesdoes not imply it). A cluster whose retention_policy is retain (aws, scaleway, ankracloud) keeps its volumes, which keep billing in your cloud account.
ankra cluster describe
Show a single Kubernetes resource together with the events scoped to it. This answers the question a failing workload raises - why is it not ready? - in one call: the object’s conditions, a pod’s per-container state (probe failures, image-pull errors, OOMKills, exit codes), and the events whose involvedObject is this resource, rather than a namespace-wide event list you have to filter by eye. Kinds outside the built-in set need--group (and sometimes --api-version),
exactly like ‘cluster get resources’.
Examples:
ankra cluster digitalocean
Commands to create, deprovision, and scale DigitalOcean clusters.ankra cluster digitalocean bastion
Inspect, diagnose, and resize the cluster’s single bastion/gateway node. Find its node ID with ‘nodes list’.ankra cluster digitalocean bastion diagnose
Dispatch the provider’s read-only bastion diagnose job and wait for its report: sshd configuration, failed-login volume, disk, failed units, journal errors, listening ports, and pending security updates. Nothing on the host is changed. The platform waits up to two minutes for the job; a slower run hands back the operation id to poll with ‘cluster operations list’.ankra cluster digitalocean bastion resize
Resize the bastion/gateway node. The provider’s bastion/gateway update job powers it off, resizes it, and powers it back on, causing brief SSH/NAT downtime for the cluster.--wait covers the platform write only; the cloud resize runs as the operation
reported on success. Follow it with ‘ankra cluster operations list <operation_id>’.
ankra cluster digitalocean bastion status
Report the verdict the platform’s bastion health loop last recorded for the cluster’s bastion/gateway: whether it is reachable, which hop a failed probe stopped at, and when it was last checked. Nothing is probed by this command, so it answers even while the bastion is unreachable - use ‘bastion diagnose’ to SSH in and collect a fresh report.ankra cluster digitalocean control-plane
Inspect and change the control plane configuration. Only 1 or 3 controllers are allowed (etcd needs an odd number of voting members for quorum). The controller count can only be changed while the cluster is stopped, and applies the next time the cluster is started. The instance type can also be changed on a running cluster that has three controllers: they are then resized one at a time, keeping the Kubernetes API up. With a single controller it still needs a stopped cluster, because resizing the only controller takes the API down while it reboots. Run “control-plane get” to see which of the two is available right now.ankra cluster digitalocean control-plane get
Show the current control plane configurationankra cluster digitalocean control-plane set-count
Change the controller count (1 or 3)ankra cluster digitalocean control-plane set-instance-type
Change the instance type of every controller in a DigitalOcean cluster. The instance type is stored as given; it is not checked against DigitalOcean’s catalog. A name that does not exist is rejected by DigitalOcean itself, which on a stopped cluster is at the next start - after this command has already reported success. On a running cluster the rolling resize drains each controller before resizing it, honouring its pods’ PodDisruptionBudgets.--force-drain bypasses them for
that drain, so pods whose budget refuses eviction are evicted anyway. It
applies to this request only, and only a live rolling resize reads it: a
stopped cluster’s offline resize drains nothing and ignores it, and so does a
request the rolling resize refuses (fewer than three controllers) or has
nothing to do for (the controllers already run that type).
List the instance types that do exist with:
ankra cluster digitalocean create
Create a new DigitalOcean clusterankra cluster digitalocean k8s-version
Get current Kubernetes version for an DigitalOcean clusterankra cluster digitalocean node-group
List, add, scale, upgrade, and delete node groups.ankra cluster digitalocean nodes
Inspect every server Ankra manages for the cluster (control plane, workers, and bastion or gateway). Soft-deleted entries from a stopped cluster are included so the saved topology is visible before re-provisioning.ankra cluster digitalocean nodes cloud-init-log
Fetch ‘cloud-init status--long’ and the tail of
/var/log/cloud-init-output.log from the node over the platform’s bastion SSH
lane, as a tracked read-only operation. This is the debug surface for
node-group user-data: it shows whether the first-boot document ran and what
it printed, without needing the cluster’s SSH key. Repeated calls attach to
an in-flight fetch instead of dispatching duplicates. Find node ids with
‘nodes list’.
ankra cluster digitalocean nodes get
Show full spec and metadata for a single nodeankra cluster digitalocean nodes list
List all nodes for the clusterankra cluster digitalocean nodes restart
Schedule a native reboot (falling back to a power cycle) of the node as a tracked operation. The node must be in the ‘up’ state and have no restart already in flight. Workloads on the node are briefly unavailable while it reboots. Works for any node returned by ‘nodes list’, including the bastion/gateway.ankra cluster digitalocean regions
List the DigitalOcean regions the supplied credential can deploy in.ankra cluster digitalocean sizes
List DigitalOcean droplet sizes. Pass--region to filter by region availability.
ankra cluster digitalocean start
Start (re-provision) a stopped DigitalOcean cluster. Use--scope control_plane to bring up only the control plane.
ankra cluster digitalocean stop
Stop an DigitalOcean cluster’s compute while keeping its configuration so it can be started again later.ankra cluster digitalocean workers
Get current worker count for an DigitalOcean clusterankra cluster domain
Show the cluster’s generated public domain. The domain nests under the organisation’s Ankra-managed root - ankra.cc by default, or the organisation’s own domain when one is registered (portal: AI > Settings > Workspaces, field “Custom Ankra domain”; CLI: ‘ankra org domain’). The read also reports the cluster’s PUBLIC domain: the domain hostnames on the cluster are published under, and what ${{ ankra.cluster_domain }} resolves to in stacks and stack profiles. It is the organisation’s preview domain (‘ankra org ai-environment set--demo-base-domain’) whenever a custom DNS zone
declared for the organisation or the cluster (‘ankra org custom-dns-zones’,
‘ankra cluster custom-dns-zones’) covers it - the cluster’s own external-dns
then publishes every hostname under it - and the generated domain otherwise.
An organisation whose domain cannot be registered as the Ankra root (it lives
in its own DNS account) gets its own domain as the cluster domain this way.
The plain command is a read: it never creates a zone. A cluster that has no
domain reports state “none”, and ‘ankra org dns zones’ lists every cluster in
the organisation that does have one.
--enable queues the zone for a cluster that has none. It is idempotent: a
cluster that already has a zone reports its existing domain unchanged. A fresh
zone reads “pending” until it is published to the authoritative nameservers
and then turns “active”; external-dns is wired to it on the next
cloud-provider pass, after which any ingress hostname under the domain
resolves with TLS.
--remove hands the zone back for teardown: the removal step before an
organisation switches its Ankra root domain (the switch is refused while
cluster zones still live under the old root). The removal is then HELD -
nothing re-creates the zone, including the external-dns Ankra runs on the
cluster and the discovery that mints zones for clusters that lack one - until
you ask for it back. A read reports “opted out” for as long as the hold
stands.
--enable withdraws the hold and re-creates the zone under the organisation’s
current root. The cluster’s label is derived from its id, so the zone comes
back under exactly the name it had before, and the external-dns Ankra manages
for it keeps the same --txt-owner-id.
ankra cluster draft
Stage all changes in an ImportCluster YAML as drafts on the cluster without deploying anything. The local checks run first (the same ones as ‘ankra cluster apply--dry-run’), then each stack in the file is saved as a
resource draft you can review, edit, and deploy from the Ankra stack builder.
If the cluster does not exist yet it is imported first without its stacks,
since drafts can only be attached to an existing cluster; every stack in the
file is then staged as a draft. Stacks that already match the cluster’s
desired state are reported as “no changes” rather than creating an empty
draft.
ankra cluster drain
Cordon a node, then delete every pod scheduled on it so its controller reschedules the pod elsewhere. DaemonSet pods are left alone (they would come straight back on the same node) and so are the static pods the kubelet runs from disk. A pod without a controller is deleted like any other and is not recreated - the plan names every pod before anything happens, and--dry-run stops after printing it.
Unlike ‘kubectl drain’, the pods are deleted rather than evicted: the Ankra
agent has no eviction relay yet, so PodDisruptionBudgets are not consulted
and a budget at its limit does not hold the drain back. Check the budgets in
the namespaces you care about (‘cluster get resources PodDisruptionBudget
--group policy’) before draining a node that carries a quorum member.
The node stays cordoned afterwards; run ‘cluster uncordon’ to put it back
into service.
Examples:
ankra cluster encrypt
Encrypt sensitive values in manifest or addon configuration files using SOPS.ankra cluster encrypt addon
Encrypt one or more keys in an addon’s Helm values using SOPS.--key takes the YAML key name whose values should be encrypted. Repeat --key to
encrypt several keys in a single run; all keys are encrypted in one SOPS pass
and one write. SOPS matches key names anywhere in the document, not dotted
paths; a dotted --key is normalised to its last segment. A key whose own name
starts with a dot (such as “.dockerconfigjson”) is kept literally. After
encrypting, the CLI verifies every value is actually ENC[…] ciphertext and
fails if any is not.
--key glob:<pattern> encrypts every key whose name matches the pattern, now
and on every later platform re-encrypt - including keys added afterwards.
Only ”*” is a wildcard; everything else is literal. The entry is recorded in
encrypted_paths as written (“glob:*Password”). A pattern that matches no key
fails, the same way a misspelled exact key does. Requires cluster#1867 on the
platform.
Two modes:
Cluster mode (default): fetch the addon’s values from a live cluster,
encrypt the key together with every key the addon already declares in
encrypted_paths (a declared value can still be stored as plaintext until
the next GitOps push seals it), and push the result back via the
partial-stack PATCH endpoint. The owning stack is resolved automatically.
File mode (-f cluster.yaml): rewrite the local addon values file referenced
by the cluster.yaml in place, adding the key to encrypted_paths. Keys the
file already declares are sealed together with --key.
Examples:
ankra cluster encrypt manifest
Encrypt one or more keys in a manifest using SOPS.--key takes the YAML key name whose values should be encrypted (for a Secret’s
data.password, that is “password”). Repeat --key to encrypt several keys in a
single run; all keys are encrypted in one SOPS pass and one write. SOPS matches
key names anywhere in the document, not dotted paths; a dotted --key is
normalised to its last segment. A key whose own name starts with a dot (such as
“.dockerconfigjson” in a kubernetes.io/dockerconfigjson Secret) is kept
literally. After encrypting, the CLI verifies every value is actually ENC[…]
ciphertext and fails if any is not.
--key glob:<pattern> encrypts every key whose name matches the pattern, now
and on every later platform re-encrypt - including keys added afterwards.
Only "" is a wildcard (any run of characters); everything else is literal,
and a leading “data.” or “stringData.” is accepted and ignored, exactly as for
an exact key. The entry is recorded in encrypted_paths as written
(“glob:stringData.DB_”), which is the form the platform re-expands into the
SOPS encrypted_regex on every push. A pattern that matches no key fails, the
same way a misspelled exact key does. Requires cluster#1867 on the platform.
--all-data selects every key under data and stringData of a Kubernetes Secret
manifest instead of naming keys individually; keys whose values are already
encrypted are skipped. The manifest must be a Secret. --all-data and --key are
mutually exclusive.
Two modes:
Cluster mode (default): fetch the manifest from a live cluster, encrypt the
key, and push the result back via the partial-stack PATCH endpoint. The
owning stack is resolved automatically.
File mode (-f cluster.yaml): rewrite a local cluster.yaml’s referenced
from_file in place, adding the key to encrypted_paths in the file. Used by
GitOps workflows where the source of truth is on disk. Every key the file
already declares in encrypted_paths is sealed together with --key, so a
document decrypted with “ankra cluster decrypt” (which leaves the
declaration in place) is sealed whole again.
In cluster mode, --set applies value edits in-memory BEFORE encrypting, so the
new secret value and its encryption land in a single commit - the plaintext
value never reaches git history. This is the recommended way to set a new
secret value:
--set” followed by “encrypt manifest”, which
commits the plaintext value first).
In cluster mode every key the manifest already declares in encrypted_paths is
sealed together with --key. A value declared in the portal or through the API
is stored as plaintext until the next GitOps push seals it, and a document
that carries SOPS metadata with plaintext under a declared path is refused by
the platform, so sealing only the new key would be rejected.
Examples:
ankra cluster events
List Kubernetes events from the active cluster.--for scopes the listing to a single object’s involvedObject, which is what
turns “the pod is Pending” into “no node matches the nodeSelector”. This is
a server-side field selector, not a substring match on the event text, so
an object whose name is a prefix of another object’s name is not conflated
with it.
Examples:
ankra cluster exec
Run a single command in a container of the named pod, through the platform- no kubeconfig and no port-forward - and exit with the command’s own exit code, so a script or CI job can branch on it.
--stdin is given, no input; with --stdin your
input is forwarded and the command sees end-of-file when it ends.
Like “ankra cluster terminal”, every run is recorded by the platform and
linked from the cluster’s audit log as an open_pod_terminal event carrying
the command; “ankra org terminal-session” replays it. Needs kubernetes.exec
on the cluster, and a cluster agent recent enough to run one-off commands.
Exit codes: the command’s own exit code when it ran; otherwise the CLI’s
usual codes (6 for a refused credential, 7 for a missing kubernetes.exec,
1 when the command could not be started).
With -o json nothing is streamed; one document is printed when the command
ends: {“exit_code”, “stdout”, “stderr”, “stdout_truncated”,
“stderr_truncated”}, each stream capped at 8 MiB.
ankra cluster get
Get Kubernetes resources from the active cluster. Examples:ankra cluster get configmaps
List configmaps in the clusterankra cluster get cronjobs
List cronjobs in the clusterankra cluster get daemonsets
List daemonsets in the clusterankra cluster get deployments
List deployments in the clusterankra cluster get events
List events in the clusterankra cluster get ingresses
List ingresses in the clusterankra cluster get k8s-jobs
List Kubernetes jobs in the clusterankra cluster get namespaces
List namespaces in the clusterankra cluster get nodes
List nodes in the clusterankra cluster get pods
List pods or get a specific pod’s manifestankra cluster get resources
Fetch any Kubernetes resource type. Use for kinds not covered by dedicated commands. Kinds outside the core API group need--group (and sometimes --api-version).
Example:
ankra cluster get secrets
List Secrets, or read one Secret by name. The platform returns every Secret value as a sha256 digest (sha256: followed by 12 hex characters) unless you ask for the values. Keys, type and metadata are readable; the values are not. A digest still changes when its value does.--reveal prints the plaintext values of ONE named Secret. It needs the
Secret’s namespace (-n), it is refused on a listing (no name, -A or -l), and
it needs the kubernetes.secrets_reveal permission on the cluster, which the
operator, admin and owner roles carry. The platform records every reveal in
the organisation’s audit log. Values under data stay base64-encoded, as with
kubectl.
Exit codes with --reveal: 7 when your role lacks kubernetes.secrets_reveal,
3 when the Secret does not exist, 1 when the platform could not hand out live
values (for example the cluster is unreachable), 2 for a reveal on a listing.
Examples:
ankra cluster get services
List services in the clusterankra cluster get statefulsets
List statefulsets in the clusterankra cluster get storageclasses
List storage classes in the clusterankra cluster gitops
Commands for inspecting which GitOps repository a cluster syncs from.ankra cluster gitops status
Show the GitOps sync status of a cluster: the repository, branch, and credential it syncs from, the last synced commit, any pending commit or sync error, and any open merge conflicts pausing the sync. If no cluster name is provided, uses the currently selected cluster.ankra cluster helm
Commands to list, inspect, roll back, upgrade and uninstall Helm releases running in the cluster.ankra cluster helm get
Show one Helm release - the chart and revision it is on, when it was deployed, the values it was installed with and the chart’s notes. ‘-o values’ prints only the values the release was installed with, as YAML: edit that file and hand it back to ‘cluster helm upgrade--values’.
Examples:
ankra cluster helm history
List a Helm release’s revisions, newest first, with the chart and status of each - the revision numbers ‘cluster helm rollback--revision’ takes.
Example:
ankra cluster helm releases
List Helm releases in the clusterankra cluster helm rollback
Roll a Helm release back to one of its earlier revisions, as listed by ‘cluster helm history’. The rollback runs on the cluster’s Ankra agent and, by default, waits for the rolled-back resources to become ready before returning. A release that an Ankra addon manages is refused: change the addon’s values in the stack instead, so Git stays the source of truth. Examples:ankra cluster helm uninstall
Uninstall a Helm release from the clusterankra cluster helm upgrade
Upgrade a Helm release in place: the agent runs ‘helm upgrade’ with the chart reference and the values file you pass. The values file REPLACES the release’s values wholesale - start from ‘cluster helm get <release> -o values’ so nothing you did not mean to change resets to a chart default. Without--version the release stays on the chart version it already runs.
A release that an Ankra addon manages is refused: change the addon in the
stack instead, so Git stays the source of truth.
Examples:
ankra cluster hetzner
Commands to create, deprovision, and scale Hetzner clusters.ankra cluster hetzner bastion
Inspect, diagnose, and resize the cluster’s single bastion/gateway node. Find its node ID with ‘nodes list’.ankra cluster hetzner bastion diagnose
Dispatch the provider’s read-only bastion diagnose job and wait for its report: sshd configuration, failed-login volume, disk, failed units, journal errors, listening ports, and pending security updates. Nothing on the host is changed. The platform waits up to two minutes for the job; a slower run hands back the operation id to poll with ‘cluster operations list’.ankra cluster hetzner bastion resize
Resize the bastion/gateway node. The provider’s bastion/gateway update job powers it off, resizes it, and powers it back on, causing brief SSH/NAT downtime for the cluster.--wait covers the platform write only; the cloud resize runs as the operation
reported on success. Follow it with ‘ankra cluster operations list <operation_id>’.
ankra cluster hetzner bastion status
Report the verdict the platform’s bastion health loop last recorded for the cluster’s bastion/gateway: whether it is reachable, which hop a failed probe stopped at, and when it was last checked. Nothing is probed by this command, so it answers even while the bastion is unreachable - use ‘bastion diagnose’ to SSH in and collect a fresh report.ankra cluster hetzner control-plane
Inspect and change the control plane configuration. Only 1 or 3 controllers are allowed (etcd needs an odd number of voting members for quorum). The controller count can only be changed while the cluster is stopped, and applies the next time the cluster is started. The instance type can also be changed on a running cluster that has three controllers: they are then resized one at a time, keeping the Kubernetes API up. With a single controller it still needs a stopped cluster, because resizing the only controller takes the API down while it reboots. Run “control-plane get” to see which of the two is available right now.ankra cluster hetzner control-plane get
Show the current control plane configurationankra cluster hetzner control-plane set-count
Change the controller count (1 or 3)ankra cluster hetzner control-plane set-instance-type
Change the instance type of every controller in a Hetzner cluster. The instance type is stored as given; it is not checked against Hetzner’s catalog. A name that does not exist is rejected by Hetzner itself, which on a stopped cluster is at the next start - after this command has already reported success. On a running cluster the rolling resize drains each controller before resizing it, honouring its pods’ PodDisruptionBudgets.--force-drain bypasses them for
that drain, so pods whose budget refuses eviction are evicted anyway. It
applies to this request only, and only a live rolling resize reads it: a
stopped cluster’s offline resize drains nothing and ignores it, and so does a
request the rolling resize refuses (fewer than three controllers) or has
nothing to do for (the controllers already run that type).
List the instance types that do exist with:
ankra cluster hetzner create
Create a new Hetzner clusterankra cluster hetzner k8s-version
Get current Kubernetes version for a Hetzner clusterankra cluster hetzner locations
List the Hetzner Cloud locations the supplied credential can deploy in. Only these locations are valid for cluster creation.ankra cluster hetzner node-group
List, add, scale, upgrade, and delete node groups.ankra cluster hetzner nodes
Inspect every server Ankra manages for the cluster (control plane, workers, and bastion or gateway). Soft-deleted entries from a stopped cluster are included so the saved topology is visible before re-provisioning.ankra cluster hetzner nodes cloud-init-log
Fetch ‘cloud-init status--long’ and the tail of
/var/log/cloud-init-output.log from the node over the platform’s bastion SSH
lane, as a tracked read-only operation. This is the debug surface for
node-group user-data: it shows whether the first-boot document ran and what
it printed, without needing the cluster’s SSH key. Repeated calls attach to
an in-flight fetch instead of dispatching duplicates. Find node ids with
‘nodes list’.
ankra cluster hetzner nodes get
Show full spec and metadata for a single nodeankra cluster hetzner nodes list
List all nodes for the clusterankra cluster hetzner nodes restart
Schedule a native reboot (falling back to a power cycle) of the node as a tracked operation. The node must be in the ‘up’ state and have no restart already in flight. Workloads on the node are briefly unavailable while it reboots. Works for any node returned by ‘nodes list’, including the bastion/gateway.ankra cluster hetzner server-types
List Hetzner Cloud server types. Pass--location to see which types are currently available for provisioning there, and --available-only to hide the rest.
ankra cluster hetzner start
Start (re-provision) a stopped Hetzner cluster. Use--scope control_plane to bring up only the control plane.
ankra cluster hetzner stop
Stop a Hetzner cluster’s compute while keeping its configuration so it can be started again later.ankra cluster hetzner workers
Get current worker count for a Hetzner clusterankra cluster info
Show details of a specific cluster. If no name is provided, shows details for the currently selected cluster.ankra cluster k3s-versions
List the k3s versions the platform can provision or upgrade to. Use one of these values withankra cluster upgrade <cluster_id> <target_version> (the provider is detected automatically).
ankra cluster kube-token
Print a short-lived Kubernetes ExecCredential so kubectl can authenticate to the Ankra cluster gateway. This command is intended to be invoked by kubectl as a client-go credential plugin, for example in a kubeconfig:--org to the cluster’s organisation ID keeps the entry working when
your selected organisation differs from the cluster’s (‘ankra cluster
kubeconfig add’ writes it automatically). An entry written without --org still
works: a cluster ID the selected organisation does not have is looked up
across the organisations you belong to, and the token is minted against the
one that owns it. Your selected organisation is not changed.
It prints JSON to stdout and never prompts; run ‘ankra login’ first.
ankra cluster kubeadm-versions
List the upstream Kubernetes versions the platform can provision or upgrade kubeadm-distribution clusters to. Use one of these values with--kubernetes-version on ankra cluster <provider> create --distribution kubeadm, or with ankra cluster upgrade <cluster_id> <target_version>.
ankra cluster kubeconfig
Add, remove, and list the Ankra cluster contexts in your kubeconfig. By default ‘add’ writes an exec-based context that fetches a short-lived token on demand via ‘ankra cluster kube-token’, so credentials stay ephemeral and SSO-backed (run ‘ankra login’ once). Other clusters/users/contexts already in your kubeconfig are left untouched. These commands read and write a single file:--kubeconfig if given, otherwise
the first entry of $KUBECONFIG, otherwise ~/.kube/config.
Examples:
ankra cluster kubeconfig add
Add or update an Ankra context in your kubeconfigankra cluster kubeconfig list
List Ankra-managed contexts in your kubeconfigankra cluster kubeconfig remove
Remove Ankra contexts from your kubeconfigankra cluster list
List all clustersankra cluster logs
Stream log output from the active cluster. By default the stream stays open and prints new lines as they arrive, like kubectl logs -f. Pass--follow=false to print the current backlog and exit,
which is what a pipeline into grep or a script wants.
--previous reads the log of the container instance that terminated. For a
pod in CrashLoopBackOff that is the only log with the failure in it, and it
is the case where reaching for kubectl through a broad access grant used to
be the only option. A previous log is closed, so --previous always makes a
bounded read.
-l/--selector reads every pod matching a label selector instead of one pod
name, and --all-containers expands each pod to all of its containers (init
and ephemeral containers included). With more than one target each line is
prefixed with [pod] or [pod/container] so the interleaved output stays
attributable.
Examples:
ankra cluster managed
Create, delete, stop and start, scale node pools, and upgrade cloud-managed Kubernetes clusters on DOKS, UpCloud UKS, GKE, OVH MKS, AKS, EKS, Scaleway Kapsule, and Ankra Cloud Kubernetes.ankra cluster managed create
Create a managed Kubernetes clusterankra cluster managed delete
Delete a managed Kubernetes clusterankra cluster managed discover
List the managed Kubernetes clusters that already run in the provider account behind a credential, marking the ones already imported into Ankra.ankra cluster managed import
Adopt a managed Kubernetes cluster that already runs at the provider: Ankra fetches the kubeconfig through the provider API and installs the agent automatically, so there is nothing to run against the cluster.ankra cluster managed node-pool
Manage managed cluster node poolsankra cluster managed node-pool add
Add a node pool to a managed clusterankra cluster managed node-pool delete
Delete a managed cluster node poolankra cluster managed node-pool scale
Scale a managed cluster node poolankra cluster managed node-pool update
Update the node count or autoscaling settings of a managed cluster node pool. Pass at least one of--count, --autoscaling, --autoscaling-min, or
--autoscaling-max; unspecified settings are left unchanged.
Pass --externally-managed on its own to hand the pool’s node count to
something outside Ankra, such as a cluster autoscaler you run yourself. While
it is set, Ankra refuses to scale, update, replace or delete the pool;
--externally-managed=false hands it back.
ankra cluster managed start
Start a stopped managed Kubernetes cluster. Currently only AKS supports stopping and starting managed clusters.ankra cluster managed stop
Stop a managed Kubernetes cluster’s compute while keeping its configuration so it can be started again later. Currently only AKS supports stopping and starting managed clusters.ankra cluster managed upgrade
Upgrade a managed cluster Kubernetes versionankra cluster manifests
Commands to list, view, upgrade, and delete manifests.ankra cluster manifests create
Add a NEW manifest to an existing stack, without touching any other member. Unlike ‘ankra cluster apply’, which is declarative over the WHOLE cluster and prunes anything the file does not mention, this sends only the new manifest. Every other stack, addon and manifest is left exactly as it is. Examples:--from-file / --manifest - accept SOPS-encrypted content: when the file carries
a top-level sops: metadata mapping, the keys holding ENC[…] ciphertext are
detected and recorded as encrypted_paths automatically. Use --encrypted-path to
declare keys explicitly when auto-detection cannot see them.
To change a manifest that already exists, use ‘ankra cluster manifests upgrade’.
ankra cluster manifests delete
Disconnect a manifest from its stack. The manifest’s resources are removed from the cluster and dependent resources are reconnected to the manifest’s own parents. The owning stack is discovered automatically (manifest names are unique per cluster). Use--dry-run to preview the target without making changes.
ankra cluster manifests get
Print the current YAML content of a manifest. By default the decoded YAML is written to stdout, making it easy to pipe into a file or edit and re-apply with--from-file:
ankra cluster manifests list
List manifests for the active cluster; or show details for a single manifestankra cluster manifests upgrade
Upgrade a manifest by patching just the fields you supply. At least one mutating flag is required. Examples:--set/--set-string/--set-file MUTATE the existing manifest YAML and address
list items by a stable field (e.g. containers[name=app]) as well as by numeric
index (containers[0]). --from-file / --manifest - REPLACE the whole manifest
and are mutually exclusive with --set*.
--from-file / --manifest - accept SOPS-encrypted content: when the file
carries a top-level sops: metadata mapping, the keys holding ENC[…]
ciphertext are detected and recorded as encrypted_paths automatically (merged
with the manifest’s existing encrypted_paths). Use --encrypted-path to declare
keys explicitly when auto-detection cannot see them.
When no content or --set flag is supplied, the existing content is re-sent
unchanged (only namespace is updated). This is required because the backend’s
manifest validation rejects empty manifest_base64.
ankra cluster mesh
Manage Cilium ClusterMeshes: sets of Ankra clusters whose pods and services resolve each other. A cluster can join a mesh only if it was created on the platform’s WireGuard overlay with a unique network identity, soankra cluster mesh readiness is the place to start - it says which of your clusters can mesh, and why the others cannot.
ankra cluster mesh create
Create an empty cluster meshankra cluster mesh delete
Delete a cluster mesh. The mesh must be empty; remove its members first so their Cilium configuration is torn down rather than left pointing at a mesh that no longer exists.ankra cluster mesh join
Add a cluster to a mesh. The platform mints the mesh’s shared certificate authority on the first join, hands it to the joining cluster, and re-renders every member’s peer list. A cluster that cannot mesh is refused with the reason;ankra cluster mesh readiness reports the same checks up front.
ankra cluster mesh leave
Remove a cluster from a meshankra cluster mesh list
List the organisation’s cluster meshesankra cluster mesh make-ready
Turn an existing cluster mesh-capable, day-2: allocate its Cilium identity and overlay range, stamp the overlay onto its stored definitions, and set its resources converging so every node joins the platform WireGuard overlay. The node-IP switch restarts kubelets once; nothing is deleted or recreated. Two clusters prepared from the kubeadm default share one pod range and cannot mesh with each other. Moving a running cluster onto another pod range is disabled while it is redesigned - the platform refuses it, because a kube-controller-manager whose--cluster-cidr excludes a node’s range exits at start - so such a pair cannot mesh for now. --pod-cidr still accepts the kubeadm default 10.244.0.0/16, which puts a cluster an earlier move split back onto the range its nodes run. UpCloud clusters only.
Proxmox clusters need --site-public-ip: the address other sites dial this cluster’s site gateway on.
ankra cluster mesh readiness
Check whether the given clusters could form one mesh. Each cluster is reported ready or not, with the failing checks spelled out. A missing Cilium identity and a node network no other cluster can reach are fixed in place byankra cluster mesh make-ready; a pod range that overlaps another member’s is not, while moving a running cluster onto a fresh range is disabled. The cloud, the distribution and the container network are settled when the cluster is created, so a cluster failing those has to be rebuilt to mesh. ankra cluster mesh up runs the whole path for a set of clusters.
ankra cluster mesh show
Show one cluster mesh and its membersankra cluster mesh up
Bring a set of clusters into one mesh from wherever they are: read their readiness, run make-ready on every cluster that only lacks its network identity or the overlay, join every cluster that is ready, and keep going until each member reports ready or--wait runs out. The mesh is created when no mesh of that name exists.
Two clusters prepared from the kubeadm default share one pod range and cannot mesh with each other, and moving one onto a fresh range is disabled while it is redesigned, so up reports such a cluster blocked with the platform’s reason. --renumber-pods has no effect until that move returns.
--plan prints what a pass would do and changes nothing. Re-running is safe: members are skipped and a make-ready re-arms a cluster whose nodes did not converge.
ankra cluster metrics
Query the Prometheus metrics source configured for a cluster. The query is proxied through the Ankra agent to the in-cluster Prometheus endpoint configured in Cluster Settings > Metrics. Flagsankra cluster metrics query
Run an instant PromQL query against the cluster’s Prometheus source. Examples:ankra cluster metrics query-range
Run a range PromQL query against the cluster’s Prometheus source. Provide either--range (a duration relative to now) or both --start and --end
(Unix seconds). When --step is omitted a sensible step is chosen automatically.
Examples:
ankra cluster morpheus
Commands to create, stop, start, and inspect HPE Morpheus clusters.ankra cluster morpheus bastion
Inspect and diagnose the cluster’s single bastion/gateway node. Find its node ID with ‘nodes list’.ankra cluster morpheus bastion diagnose
Dispatch the provider’s read-only bastion diagnose job and wait for its report: sshd configuration, failed-login volume, disk, failed units, journal errors, listening ports, and pending security updates. Nothing on the host is changed. The platform waits up to two minutes for the job; a slower run hands back the operation id to poll with ‘cluster operations list’.ankra cluster morpheus bastion status
Report the verdict the platform’s bastion health loop last recorded for the cluster’s bastion/gateway: whether it is reachable, which hop a failed probe stopped at, and when it was last checked. Nothing is probed by this command, so it answers even while the bastion is unreachable - use ‘bastion diagnose’ to SSH in and collect a fresh report.ankra cluster morpheus clouds
List HPE Morpheus clouds available to a credentialankra cluster morpheus control-plane
Inspect and change the control plane configuration. Only 1 or 3 controllers are allowed (etcd needs an odd number of voting members for quorum). The controller count can only be changed while the cluster is stopped, and applies the next time the cluster is started. The instance type can also be changed on a running cluster that has three controllers: they are then resized one at a time, keeping the Kubernetes API up. With a single controller it still needs a stopped cluster, because resizing the only controller takes the API down while it reboots. Run “control-plane get” to see which of the two is available right now.ankra cluster morpheus control-plane get
Show the current control plane configurationankra cluster morpheus control-plane set-count
Change the controller count (1 or 3)ankra cluster morpheus control-plane set-instance-type
Change the instance type of every controller in a HPE Morpheus cluster. The instance type is stored as given; it is not checked against HPE Morpheus’s catalog. A name that does not exist is rejected by HPE Morpheus itself, which on a stopped cluster is at the next start - after this command has already reported success. On a running cluster the rolling resize drains each controller before resizing it, honouring its pods’ PodDisruptionBudgets.--force-drain bypasses them for
that drain, so pods whose budget refuses eviction are evicted anyway. It
applies to this request only, and only a live rolling resize reads it: a
stopped cluster’s offline resize drains nothing and ignores it, and so does a
request the rolling resize refuses (fewer than three controllers) or has
nothing to do for (the controllers already run that type).
List the instance types that do exist with:
ankra cluster morpheus create
Create a new HPE Morpheus clusterankra cluster morpheus groups
List HPE Morpheus groups available to a credentialankra cluster morpheus k8s-version
Get current Kubernetes version for an HPE Morpheus clusterankra cluster morpheus layouts
List HPE Morpheus instance-type layouts available to a credentialankra cluster morpheus networks
List HPE Morpheus networks available to a credentialankra cluster morpheus nodes
Inspect every server Ankra manages for the cluster (control plane, workers, and bastion or gateway). Soft-deleted entries from a stopped cluster are included so the saved topology is visible before re-provisioning.ankra cluster morpheus nodes get
Show full spec and metadata for a single nodeankra cluster morpheus nodes list
List all nodes for the clusterankra cluster morpheus plans
List HPE Morpheus service plans available to a credentialankra cluster morpheus start
Start (re-provision) a stopped HPE Morpheus cluster. Use--scope control_plane to bring up only the control plane.
ankra cluster morpheus stop
Stop an HPE Morpheus cluster’s instances while keeping its configuration so it can be started again later.ankra cluster morpheus workers
Get current worker count for an HPE Morpheus clusterankra cluster move
Move a cluster into another existing organisation. Only an administrator of BOTH the current organisation and the destination can move a cluster. The cluster keeps its id, agent, executions, resources, security findings, insights, DNS records and variables. Bindings that belong to the current organisation are detached and reported: access grants, kube tokens, notification routes and mutes, security report schedules, trusted AI actions and cluster-group memberships. Billing, audit and chat history stay with the current organisation. Only imported clusters can be moved for now: Ankra-provisioned and managed Kubernetes clusters use a provider credential that belongs to the current organisation, so the platform refuses to move them. The platform also refuses the move while operations are running on the cluster, while the cluster is a member of a cluster mesh, while it has DNS zones bound to the current organisation (a published cluster domain or custom DNS zones), for playground and sandbox clusters, and when the destination already has a cluster with the same name. The destination is resolved among your organisations by id, slug or name. If no cluster name is provided, the currently selected cluster is moved.ankra cluster node-group
List, add, scale, upgrade, and delete node groups on a cloud cluster. The cloud provider (Hetzner, OVH, UpCloud, DigitalOcean, Scaleway, Ankra Cloud, AWS, Proxmox VE, or HPE Morpheus) is detected automatically from the cluster.ankra cluster node-group add
Add a node groupankra cluster node-group autoscaling
Read or write the Cluster Autoscaler settings of a node group. When autoscaling is enabled, the Ankra-managed Cluster Autoscaler keeps the group’s node count within [min, max] based on pod demand. Manual scaling stays allowed but is clamped into the same bounds.ankra cluster node-group autoscaling get
Show autoscaling settings for a node groupankra cluster node-group autoscaling set
Enable autoscaling with--enabled --min <n> --max <n>, or disable it with
--enabled=false. min must be at least 1 (scale-to-zero is not supported);
enabling requires the cluster’s ankra-agent to be recent enough to serve
the autoscaler, and installs the Cluster Autoscaler on first enable.
ankra cluster node-group delete
Delete a node group and every node in it. Each node removed is drained first, honouring its pods’ PodDisruptionBudgets. A node whose drain is refused (a budget allows no eviction, or the node cannot be drained at all) is kept in service instead of removed, and a notice on the cluster says why. Give the blocking workloads eviction headroom (more replicas or a looser budget) and run the command again, or pass--force-drain to remove
the node anyway without honouring its PodDisruptionBudget. --force-drain
applies to this request only; use it only for a node you have decided to lose.
Examples:
ankra cluster node-group labels
Replace the labels on every node in the group. Pass--labels as a comma-separated list of key=value pairs, or --clear to remove all labels. The cloud provider is detected automatically from the cluster.
ankra cluster node-group list
List node groupsankra cluster node-group scale
Scale a node group up or down to <count> nodes. A scale-down picks the nodes to remove. Each node removed is drained first, honouring its pods’ PodDisruptionBudgets. A node whose drain is refused (a budget allows no eviction, or the node cannot be drained at all) is kept in service instead of removed, and a notice on the cluster says why. Give the blocking workloads eviction headroom (more replicas or a looser budget) and run the command again, or pass--force-drain to remove
the node anyway without honouring its PodDisruptionBudget. --force-drain
applies to this request only; use it only for a node you have decided to lose.
Examples:
ankra cluster node-group taints
Replace the taints on every node in the group. Pass--taints as a comma-separated list of key=value:Effect (value optional, effect defaults to NoSchedule), or --clear to remove all taints. The cloud provider is detected automatically from the cluster.
ankra cluster node-group upgrade
Change the instance type of every node in a node group. This cannot be reversed. The resize power-cycles each node, and each is drained first, honouring its pods’ PodDisruptionBudgets.--force-drain bypasses those budgets for that
drain, so a node is resized even if its pods’ disruption budget refuses the
eviction. It applies to this request only.
Examples:
ankra cluster operations
Commands to list, inspect, retry, and cancel executions and their steps.ankra cluster operations cancel
Cancel one or more running executionsankra cluster operations cancel-step
Cancel a specific step within an executionankra cluster operations list
List executions for the active cluster; optionally, provide an ID for detailsankra cluster operations retry
Retry a terminal execution (failed/cancelled/timeout)ankra cluster operations steps
List the steps of an execution with their status and error excerpt.--results additionally fetches each step’s job result - the structured
payload the scheduler recorded when the step finished (for example the
resources a teardown deleted, skipped, or failed to reclaim). Results are
printed under each step, and merged into the steps in -o json|yaml output.
ankra cluster ovh
Commands to create, deprovision, and scale OVH Cloud clusters.ankra cluster ovh access-info
Show the gateway (bastion) and control plane IPs plus ready-to-use SSH jump and Kubernetes API port-forward commands.ankra cluster ovh bastion
Inspect, diagnose, and resize the cluster’s single bastion/gateway node. Find its node ID with ‘nodes list’.ankra cluster ovh bastion diagnose
Dispatch the provider’s read-only bastion diagnose job and wait for its report: sshd configuration, failed-login volume, disk, failed units, journal errors, listening ports, and pending security updates. Nothing on the host is changed. The platform waits up to two minutes for the job; a slower run hands back the operation id to poll with ‘cluster operations list’.ankra cluster ovh bastion resize
Resize the bastion/gateway node. The provider’s bastion/gateway update job powers it off, resizes it, and powers it back on, causing brief SSH/NAT downtime for the cluster.--wait covers the platform write only; the cloud resize runs as the operation
reported on success. Follow it with ‘ankra cluster operations list <operation_id>’.
ankra cluster ovh bastion status
Report the verdict the platform’s bastion health loop last recorded for the cluster’s bastion/gateway: whether it is reachable, which hop a failed probe stopped at, and when it was last checked. Nothing is probed by this command, so it answers even while the bastion is unreachable - use ‘bastion diagnose’ to SSH in and collect a fresh report.ankra cluster ovh control-plane
Inspect and change the control plane configuration. Only 1 or 3 controllers are allowed (etcd needs an odd number of voting members for quorum). The controller count can only be changed while the cluster is stopped, and applies the next time the cluster is started. The instance type can also be changed on a running cluster that has three controllers: they are then resized one at a time, keeping the Kubernetes API up. With a single controller it still needs a stopped cluster, because resizing the only controller takes the API down while it reboots. Run “control-plane get” to see which of the two is available right now.ankra cluster ovh control-plane get
Show the current control plane configurationankra cluster ovh control-plane set-count
Change the controller count (1 or 3)ankra cluster ovh control-plane set-instance-type
Change the instance type of every controller in a OVH cluster. The instance type is stored as given; it is not checked against OVH’s catalog. A name that does not exist is rejected by OVH itself, which on a stopped cluster is at the next start - after this command has already reported success. On a running cluster the rolling resize drains each controller before resizing it, honouring its pods’ PodDisruptionBudgets.--force-drain bypasses them for
that drain, so pods whose budget refuses eviction are evicted anyway. It
applies to this request only, and only a live rolling resize reads it: a
stopped cluster’s offline resize drains nothing and ignores it, and so does a
request the rolling resize refuses (fewer than three controllers) or has
nothing to do for (the controllers already run that type).
ankra cluster ovh create
Create a new OVH clusterankra cluster ovh k8s-version
Get current Kubernetes version for an OVH clusterankra cluster ovh node-group
List, add, scale, upgrade, label, taint, and delete node groups.ankra cluster ovh nodes
Inspect every server Ankra manages for the cluster (control plane, workers, and bastion or gateway). Soft-deleted entries from a stopped cluster are included so the saved topology is visible before re-provisioning.ankra cluster ovh nodes cloud-init-log
Fetch ‘cloud-init status--long’ and the tail of
/var/log/cloud-init-output.log from the node over the platform’s bastion SSH
lane, as a tracked read-only operation. This is the debug surface for
node-group user-data: it shows whether the first-boot document ran and what
it printed, without needing the cluster’s SSH key. Repeated calls attach to
an in-flight fetch instead of dispatching duplicates. Find node ids with
‘nodes list’.
ankra cluster ovh nodes get
Show full spec and metadata for a single nodeankra cluster ovh nodes list
List all nodes for the clusterankra cluster ovh nodes restart
Schedule a native reboot (falling back to a power cycle) of the node as a tracked operation. The node must be in the ‘up’ state and have no restart already in flight. Workloads on the node are briefly unavailable while it reboots. Works for any node returned by ‘nodes list’, including the bastion/gateway.ankra cluster ovh regions
List the OVH Cloud regions the supplied credential’s project can deploy in. Only these regions are valid for cluster creation.ankra cluster ovh ssh-keys
Get and set the SSH key credentials authorised to access an OVH cluster’s nodes.ankra cluster ovh start
Start (re-provision) a stopped OVH cluster. Use--scope control_plane to bring up only the control plane.
ankra cluster ovh stop
Stop an OVH cluster’s compute while keeping its configuration so it can be started again later.ankra cluster ovh workers
Get current worker count for an OVH clusterankra cluster patch
Patch one or more live Kubernetes resources in the active cluster. This is ‘kubectl patch’: the document given with--patch (inline, JSON or
YAML) or --patch-file is sent to the API server as a patch of the chosen
--type - ‘strategic’ (the default, the kubectl default too), ‘merge’ (RFC
7386 JSON merge patch) or ‘json’ (RFC 6902 JSON patch, a list of operations).
A patch changes only the fields it names and does not go through
server-side apply, so it is the way to correct a field on an object another
manager owns - a value the API server defaulted on an older chart, a label a
release left behind - without taking that object over or deleting it.
The kind takes the kubectl spellings - pod, deployment, deploy, service, svc,
configmap, cm, node, … - and a custom resource is reachable with --group
and --api-version, exactly like ‘cluster get resources’ and ‘cluster delete’.
The patch goes through the cluster’s Ankra agent: no kubeconfig is needed and
the same organisation permissions as the portal apply.
Each object reports its own outcome. The command exits 0 when everything was
patched, 3 when one of the objects did not exist, and 1 when the cluster
refused a patch.
Examples:
ankra cluster playground
The playground is a real, writable Kubernetes environment Ankra provisions for you - a virtual cluster on Ankra’s own infrastructure, with the agent already installed. Every organisation may hold one; it expires after a period of inactivity.ankra cluster playground create
Create the organisation’s playground, optionally at a paid size fromankra cluster playground plans. Without --size the free trial is created. Provisioning runs in the background: poll ankra cluster playground status <cluster_id> until the phase reaches ready.
ankra cluster playground destroy
Tear the organisation’s playground down. Everything deployed in it, including its storage, is deleted and cannot be recovered, so the command asks first; pass--yes to skip the prompt in scripts. Teardown runs in the background: poll ankra cluster playground status <cluster_id> until the phase reaches removed.
This is also how a refused ankra org domain set is cleared. A playground publishes a wildcard DNS record in the organisation’s zone, and that record is reconciled rather than written once - deleting it with ankra org dns delete only lasts until the provisioner’s next pass. Destroying the environment is what removes it for good.
ankra cluster playground plans
List every playground size with its monthly price and whether the pool can place it right now. Order one withankra cluster playground create --size <id>.
ankra cluster playground resize
Change a paid playground to another paid size in place: only the namespace quota and the monthly price change (the month is billed pro-rata across the change), nothing you deployed is touched. The free trial cannot be resized - order a paid size instead.ankra cluster playground status
Show the provisioning phase of a playgroundankra cluster power-schedules
Manage the cluster’s power schedules: scheduled stop or start actions that fire once at a chosen time or repeatedly on a cron expression, so a development cluster can park itself outside working hours. Power schedules are available for self-managed Hetzner, OVHcloud, UpCloud, DigitalOcean, Scaleway, AWS (EC2), Proxmox VE, and HPE Morpheus clusters - the same clusters that support manual stop and start. A scheduled stop behaves like stopping the cluster yourself: on Hetzner, OVHcloud, UpCloud and DigitalOcean the cluster’s state is captured first (an encrypted etcd snapshot the next start restores) unless--preserve-state=false; elsewhere
the provider VMs are terminated and only the configuration is preserved.
--stop-mode scale_to_zero deletes only the worker servers instead, and creates
new ones at the next start: the control plane and etcd, cloud volumes and
addresses are kept (and keep billing), and data on the workers’ own disks is
lost at every stop. On a cluster whose volumes keep data there, the schedule
needs --accept-node-local-data-loss (or a yes at the prompt).
--stop-mode pause powers the servers off and keeps them.
--stop-mode pause keeps the cluster’s state but saves no compute cost on
Hetzner, DigitalOcean or UpCloud (Developer and General Purpose plans):
they bill a powered-off server at its full price. To save money there, use
scale_to_zero or delete_resources. On AWS and Scaleway a powered-off server
stops billing compute; its disks and IPs keep billing.
Examples:
ankra cluster power-schedules create
Create a scheduled stop or start on the active cluster. The schedule fires once at--at, or repeatedly per --cron evaluated in --timezone (UTC when
omitted). A cluster can hold up to 20 schedules.
ankra cluster power-schedules delete
Delete a power schedule: it stops firing immediately and disappears from the cluster’s schedule list. The cluster itself is not touched. To pause a schedule while keeping its configuration, use ‘ankra cluster power-schedules update <schedule_id> …--enabled=false’.
ankra cluster power-schedules list
List the active cluster’s power schedulesankra cluster power-schedules update
Replace a power schedule. This is a full replace, not a patch: pass the complete schedule as it should be afterwards ---action plus one of --at or
--cron (with --timezone for cron schedules), and --enabled=false to leave it
paused. A stop schedule’s --stop-mode and --preserve-state are the exception:
when omitted, the schedule’s current choices are carried over, so a change of
timing never silently turns a state-discarding stop into a preserving one.
Use ‘ankra cluster power-schedules list’ for the schedule ID and the current
values.
ankra cluster provision
Provision a managed cluster that is not running. This works for a cluster that was created but never built, and for an imported cluster that was deprovisioned. It cannot rebuild a deprovisioned cloud cluster (hetzner, ovh, upcloud, digitalocean, scaleway, ankracloud, aws, proxmox, morpheus): that deprovision deleted the record, so there is nothing left to provision - create a new cluster instead. Provisioning rebuilds the cluster’s infrastructure and then redeploys its stack resources from the cluster’s stored stack definition. Verify anything you patched in place afterwards - see “ankra cluster addons list <addon>” and “ankra cluster manifests list”. This is not a power-on. To resume a cluster you powered off, use the provider’s start command (for example “ankra hetzner cluster start”) or “ankra cluster power-schedules”. If no cluster name is provided, uses the currently selected cluster.ankra cluster proxmox
Commands to create, stop, start, and inspect Proxmox VE clusters.ankra cluster proxmox bastion
Inspect and diagnose the cluster’s single bastion/gateway node. Find its node ID with ‘nodes list’.ankra cluster proxmox bastion diagnose
Dispatch the provider’s read-only bastion diagnose job and wait for its report: sshd configuration, failed-login volume, disk, failed units, journal errors, listening ports, and pending security updates. Nothing on the host is changed. The platform waits up to two minutes for the job; a slower run hands back the operation id to poll with ‘cluster operations list’.ankra cluster proxmox bastion status
Report the verdict the platform’s bastion health loop last recorded for the cluster’s bastion/gateway: whether it is reachable, which hop a failed probe stopped at, and when it was last checked. Nothing is probed by this command, so it answers even while the bastion is unreachable - use ‘bastion diagnose’ to SSH in and collect a fresh report.ankra cluster proxmox bridges
List Proxmox VE network bridges on a host nodeankra cluster proxmox control-plane
Inspect and change the control plane configuration. Only 1 or 3 controllers are allowed (etcd needs an odd number of voting members for quorum). The controller count can only be changed while the cluster is stopped, and applies the next time the cluster is started. The instance type can also be changed on a running cluster that has three controllers: they are then resized one at a time, keeping the Kubernetes API up. With a single controller it still needs a stopped cluster, because resizing the only controller takes the API down while it reboots. Run “control-plane get” to see which of the two is available right now.ankra cluster proxmox control-plane get
Show the current control plane configurationankra cluster proxmox control-plane set-count
Change the controller count (1 or 3)ankra cluster proxmox control-plane set-instance-type
Change the instance type of every controller in a Proxmox VE cluster. The instance type is stored as given; it is not checked against Proxmox VE’s catalog. A name that does not exist is rejected by Proxmox VE itself, which on a stopped cluster is at the next start - after this command has already reported success. On a running cluster the rolling resize drains each controller before resizing it, honouring its pods’ PodDisruptionBudgets.--force-drain bypasses them for
that drain, so pods whose budget refuses eviction are evicted anyway. It
applies to this request only, and only a live rolling resize reads it: a
stopped cluster’s offline resize drains nothing and ignores it, and so does a
request the rolling resize refuses (fewer than three controllers) or has
nothing to do for (the controllers already run that type).
List the instance types that do exist with:
ankra cluster proxmox create
Create a new Proxmox VE clusterankra cluster proxmox hosts
List the Proxmox VE host nodes the supplied credential can deploy virtual machines on.ankra cluster proxmox k8s-version
Get current Kubernetes version for a Proxmox VE clusterankra cluster proxmox nodes
Inspect every server Ankra manages for the cluster (control plane, workers, and bastion or gateway). Soft-deleted entries from a stopped cluster are included so the saved topology is visible before re-provisioning.ankra cluster proxmox nodes get
Show full spec and metadata for a single nodeankra cluster proxmox nodes list
List all nodes for the clusterankra cluster proxmox nodes restart
Schedule a native reboot (falling back to a power cycle) of the node as a tracked operation. The node must be in the ‘up’ state and have no restart already in flight. Workloads on the node are briefly unavailable while it reboots. Works for any node returned by ‘nodes list’, including the bastion/gateway.ankra cluster proxmox sizes
List the instance-size presets (px-small, px-medium, …) accepted by the Proxmox VE instance-type flags.ankra cluster proxmox start
Start (re-provision) a stopped Proxmox VE cluster. Use--scope control_plane to bring up only the control plane.
ankra cluster proxmox stop
Stop a Proxmox VE cluster’s virtual machines while keeping its configuration so it can be started again later.ankra cluster proxmox storages
List Proxmox VE storages on a host nodeankra cluster proxmox templates
List Proxmox VE VM templates on a host nodeankra cluster proxmox workers
Get current worker count for a Proxmox VE clusterankra cluster reconcile
Trigger a reconciliation for a cluster to sync desired state with actual state. If no cluster name is provided, uses the currently selected cluster. If a cluster name is provided, reconciles that specific cluster.ankra cluster restart
Rolling-restart one or more workloads in the active cluster. This is ‘kubectl rollout restart’: the pod template gets a fresh kubectl.kubernetes.io/restartedAt annotation, so the controller replaces every pod under its own rollout strategy - no downtime for a Deployment with more than one replica, one pod at a time for a StatefulSet. Nothing else in the spec changes. The kind is deployment, statefulset or daemonset; the kubectl short and plural spellings work too. Examples:ankra cluster roll-to
Roll a cluster to a specific resource version. Uses the currently selected cluster unless--cluster is provided.
Example:
ankra cluster scale
Scale the number of default-pool worker nodes up or down for a cloud cluster. The cloud provider (Hetzner, OVH, UpCloud, DigitalOcean, Scaleway, Ankra Cloud, AWS, Proxmox VE, or HPE Morpheus) is detected automatically from the cluster, so you do not need to remember which provider it runs on. To scale a named node group instead, use ‘ankra cluster node-group scale’. A scale-down picks the workers to remove. Each node removed is drained first, honouring its pods’ PodDisruptionBudgets. A node whose drain is refused (a budget allows no eviction, or the node cannot be drained at all) is kept in service instead of removed, and a notice on the cluster says why. Give the blocking workloads eviction headroom (more replicas or a looser budget) and run the command again, or pass--force-drain to remove
the node anyway without honouring its PodDisruptionBudget. --force-drain
applies to this request only; use it only for a node you have decided to lose.
Examples:
ankra cluster scaleway
Manage the lifecycle of Scaleway clusters.ankra cluster scaleway bastion
Inspect the cluster’s single bastion/gateway node. Find its node ID with ‘nodes list’.ankra cluster scaleway bastion status
Report the verdict the platform’s bastion health loop last recorded for the cluster’s bastion/gateway: whether it is reachable, which hop a failed probe stopped at, and when it was last checked. Nothing is probed by this command, so it answers even while the bastion is unreachable. This provider has no bastion diagnose job lane, so the recorded verdict is all there is to read.ankra cluster scaleway control-plane
Inspect and change the control plane configuration. Only 1 or 3 controllers are allowed (etcd needs an odd number of voting members for quorum). The controller count can only be changed while the cluster is stopped, and applies the next time the cluster is started. The instance type can also be changed on a running cluster that has three controllers: they are then resized one at a time, keeping the Kubernetes API up. With a single controller it still needs a stopped cluster, because resizing the only controller takes the API down while it reboots. Run “control-plane get” to see which of the two is available right now.ankra cluster scaleway control-plane get
Show the current control plane configurationankra cluster scaleway control-plane set-count
Change the controller count (1 or 3)ankra cluster scaleway control-plane set-instance-type
Change the instance type of every controller in a Scaleway cluster. The instance type is stored as given; it is not checked against Scaleway’s catalog. A name that does not exist is rejected by Scaleway itself, which on a stopped cluster is at the next start - after this command has already reported success. On a running cluster the rolling resize drains each controller before resizing it, honouring its pods’ PodDisruptionBudgets.--force-drain bypasses them for
that drain, so pods whose budget refuses eviction are evicted anyway. It
applies to this request only, and only a live rolling resize reads it: a
stopped cluster’s offline resize drains nothing and ignores it, and so does a
request the rolling resize refuses (fewer than three controllers) or has
nothing to do for (the controllers already run that type).
List the instance types that do exist with:
ankra cluster scaleway create
Create an Ankra-managed K3s or kubeadm cluster on Scaleway Instances. Ankra owns the server graph, security group, Public Gateway v2, generated SSH key and (unless--private-network-id adopts an existing one) the Private
Network. Run ‘preflight’ first to check region, zone, CIDR and SKU
availability - it proves availability, not project hard quota.
Examples:
ankra cluster scaleway deprovision
Permanently delete a Scaleway cluster and the provider resources Ankra created for it. Volumes and load balancers follow the cluster’s retention_policy: ‘retain’ keeps them, ‘delete’ sweeps them. A ‘delete’ cluster’s persistent volumes are named first and deleted only when you accept that: answer the prompt on a terminal, or pass--accept-volume-data-loss (--yes does not imply it).
ankra cluster scaleway gateway-types
List Scaleway Public Gateway types for a zoneankra cluster scaleway instance-types
List Scaleway instance types (commercial types) for a zoneankra cluster scaleway k8s-version
Get current Kubernetes version for a Scaleway clusterankra cluster scaleway locations
List Scaleway regions and zones available to a credentialankra cluster scaleway networks
List Scaleway Private Networks a credential can adoptankra cluster scaleway nodes
Inspect every server Ankra manages for the cluster (control plane, workers, and bastion or gateway). Soft-deleted entries from a stopped cluster are included so the saved topology is visible before re-provisioning.ankra cluster scaleway nodes cloud-init-log
Fetch ‘cloud-init status--long’ and the tail of
/var/log/cloud-init-output.log from the node over the platform’s bastion SSH
lane, as a tracked read-only operation. This is the debug surface for
node-group user-data: it shows whether the first-boot document ran and what
it printed, without needing the cluster’s SSH key. Repeated calls attach to
an in-flight fetch instead of dispatching duplicates. Find node ids with
‘nodes list’.
ankra cluster scaleway nodes get
Show full spec and metadata for a single nodeankra cluster scaleway nodes list
List all nodes for the clusterankra cluster scaleway nodes restart
Schedule a native reboot (falling back to a power cycle) of the node as a tracked operation. The node must be in the ‘up’ state and have no restart already in flight. Workloads on the node are briefly unavailable while it reboots. Works for any node returned by ‘nodes list’, including the bastion/gateway.ankra cluster scaleway preflight
Run the Scaleway create preflight: region/zone reachability, CIDR overlap, gateway and instance-type availability. A quota warning means SKU stock was visible, not that project hard-quota headroom was proven. Takes the same flags as ‘create’.ankra cluster scaleway start
Re-provision a stopped Scaleway cluster. Use--scope control_plane to bring up only the control plane.
ankra cluster scaleway stop
Stop a Scaleway cluster by terminating its compute while preserving its configuration so it can be re-provisioned later.ankra cluster scaleway workers
Get current worker count for a Scaleway clusterankra cluster select
Select a cluster and save it as the active cluster for subsequent commands. If a cluster name is provided, it will be selected directly without prompting. If no name is provided, an interactive picker is shown. Examples:ankra cluster sops-config
Show the SOPS encryption configuration including the public key used for encrypting secrets.ankra cluster ssh-keys
Get, set, and re-sync the SSH key credentials authorised to access a cloud cluster’s nodes. The cloud provider (Hetzner, OVH, UpCloud, DigitalOcean, Scaleway, Ankra Cloud, AWS, Proxmox VE, or HPE Morpheus) is detected automatically from the cluster.ankra cluster ssh-keys get
Show SSH keys attached to a clusterankra cluster ssh-keys resync
Re-sync the cluster’s SSH key with the cloud provider. Use this to repair a stale provider-side SSH key reference (for example when the key was deleted and re-created in the provider console) that blocks new node creation, and to re-apply the authorised keys to running nodes.ankra cluster ssh-keys set
Replace the SSH key credentials attached to a cluster. Changes take effect on the next reconciliation and are applied to running nodes. Pass--clear to remove all user SSH keys (the Ankra-managed key always remains).
ankra cluster stacks
Commands to list, create, delete, rename, and view history of stacks.ankra cluster stacks clone
Clone a stack from the current cluster to a target cluster. The cloned stack is created as a draft on the target so it can be reviewed before it is deployed. Encrypted values are stripped during cloning and must be reconfigured on the target. With--with-data the clone also carries the stack’s data: a restore point is
taken on the source and restored onto the target by a run the command names.
The data moves after the clone, not during it, so the copy is a draft until
the restore has landed - a with-data clone never deploys at clone time, and
--deploy plans the deploy step rather than running it.
Data flags need --with-data beside them. Databases travel by default and
volumes only where named with --include-pvc namespace/name; --exclude-databases
needs --confirm-exclude-databases. Naming any selection flag REPLACES the
stack’s stored backup selection for this clone rather than narrowing it, so
name the volumes to keep alongside --exclude-databases; leave every selection
flag off and the stored selection decides.
The vault resolves in order: --vault, the stack’s own backup policy, then the
organisation’s single ready vault. With --from latest the restore point is
read from the vault that holds it, so --vault is not accepted there.
Carrying volume data keeps the stack, Helm release and namespace names, so the
platform refuses --name for a clone whose plan holds volumes (a database-only
clone may still be renamed), and a target that already has a stack of this
name is refused rather than suffixed around.
Examples:
ankra cluster stacks data
The stack’s data inventory: standalone persistent volume claims and database custom resources with their claims folded in, each with the engine that would capture it and the consistency that engine can promise.ankra cluster stacks data list
List what a stack holds that a backup would have to carry. Each asset says which engine would capture it and what consistency that engine can promise: an engine either produces a consistent artifact or it declares itself crash-consistent, and there is no third answer. The live read of the database operators can come back unavailable - no relay, or an offline agent - in which case the command says so rather than presenting a partial inventory as the whole truth. Example:ankra cluster stacks delete
Delete a stackankra cluster stacks deploy-draft
Deploy a draft stack - the state a clone, a stack-profile instantiation or ‘ankra cluster draft’ leaves behind - on the active cluster. The draft’s contents are deployed exactly as they are stored. Review them first with ‘ankra cluster stacks list <stack name>’, and edit them in the stack builder if the clone warned that something has to change before it can come up.ankra cluster stacks history
Show history of changes for a stackankra cluster stacks list
List stacks for the active cluster; or show details for a single stackankra cluster stacks protect
Turn on protection for a stack. Protection is a property of the stack, not a separate object: the command writes a backup block onto the stack’s definition, and the platform converges on it by installing the backup data plane on the cluster. Until that plane exists the command reports the backup stack as “installing” rather than claiming the stack is protected.--vault is required; a protected stack with nowhere to write to is not
protected. --schedule takes hourly, daily, weekly, or a five-field cron
expression. --retention takes the buckets to keep, as key=value pairs.
Examples:
ankra cluster stacks rename
Rename a stackankra cluster stacks restore-points
A restore point is an immutable copy of a stack’s data in a backup vault, self-describing enough to be read without the cluster it came from. Backing up creates one; restoring applies one.ankra cluster stacks restore-points create
Take a restore point of a stack now. The capture is dispatched by the platform, so the command answers with the restore point in ‘creating’ and the run that will seal it. With--wait it
follows that run to completion and prints the sealed restore point.
The vault is resolved in order: --vault, then the stack’s own backup policy,
then the organisation’s single ready vault. With more than one ready vault and
nothing naming which, the platform refuses rather than choosing for you.
Examples:
ankra cluster stacks restore-points delete
Delete a restore point. The row goes either way, so a restore point whose cluster was destroyed is never undeletable; the objects in the bucket are swept by an execution on the source cluster, and when no sweep could be dispatched the command says why the objects were left behind rather than understating the storage bill. A restore point a backup, restore or clone is currently using is refused, and so is one that is still being taken. The id may be a prefix of the one the listing printed, at least 8 characters long (the uuid’s first group), checked for ambiguity against every restore point the stack has; a shorter prefix is refused because a delete cannot be undone, and the full id is always accepted.ankra cluster stacks restore-points get
Describe one restore point: the manifest it carries, every asset in it, everything it does not carry, and the run that produced it. The id may be an unambiguous prefix of the one the listing printed; it is checked for ambiguity against every restore point the stack has, not just the newest page, and a prefix two of them share is refused with both named.ankra cluster stacks restore-points list
List the restore points taken of a stack, newest first. The listing carries what each restore point does NOT contain as well as what it does: a backup listing that showed sizes and hid omissions would be exactly the silence this is here to remove. Examples:ankra cluster stacks restore-points restore
Restore a restore point over the stack it was taken from. This destroys before it replaces. Typing the stack’s own name is what gates it - the sequence the platform will follow is printed from its answer, once the restore has been accepted and before any of its steps run:- Scale down the workloads that own the data.
- Remove the volumes the restore point replaces.
- Restore the restore point’s assets onto the cluster.
- Scale the workloads back up over the restored data.
--yes skips it for
scripts. A restore point carrying a CloudNativePG or Percona database is
refused with the platform’s own reason - the ordinary restore path would
report success over unchanged data, which is worse than refusing.
A stack whose data has changed since the restore point was taken is refused
unless --force. An inventory whose live database scan did not run counts as
drift, because “we could not read it” is not “it is unchanged”.
The id may be a prefix of the one the listing printed, at least 8 characters
long (the uuid’s first group), checked for ambiguity against every restore
point the stack has; a shorter prefix is refused because the stack’s volumes
are removed before anything is written back, and the full id is always
accepted.
ankra cluster stacks unprotect
Turn off protection for a stack. Every restore point already taken is kept and stays restorable: removing protection is a decision about the future, not about the past. The scheduled backups and the rendered object stores disappear on the next render. Confirmation is typing the stack’s own name, not y/N;--yes skips it.
ankra cluster stacks variables
Manage variables on a specific stack. Stack variables are the most specific scope and shadow cluster and organisation variables of the same name when this stack’s manifests/addons are rendered.ankra cluster stacks variables delete
Delete a variable from a stackankra cluster stacks variables get
Get a single stack variableankra cluster stacks variables list
List variables on a stackankra cluster stacks variables set
Create or update a stack variable. The value can be read from stdin by passing ”-”.ankra cluster terminal
Open an interactive shell in a container of the named pod, through the platform - no kubeconfig and no port-forward. The local terminal is put in raw mode, so every keystroke (Ctrl-C included) reaches the remote shell; leave with exit or Ctrl-D. Window resizes follow the local terminal. Every session is recorded by the platform and linked from the cluster’s audit log as an open_pod_terminal event; “ankra org terminal-session” replays it. Needs kubernetes.exec on the cluster. With one container the shell opens there; a pod with several needs--container. Input that is not a terminal (a pipe) is forwarded as typed
and should end with exit, since the remote shell cannot see the pipe close.
To run one command non-interactively and get its exit code, use
“ankra cluster exec <pod> -n <namespace> — <command> [args…]” instead;
--shell names a shell binary and cannot carry arguments.
ankra cluster top
Show live resource usage measured by metrics-server. This is the “which container just got OOMKilled” view. It reads the aggregated metrics API directly, so it works on clusters where Prometheus was never installed. For trends over time use ‘ankra cluster metrics’, which queries Prometheus.ankra cluster top nodes
Show live CPU and memory usage per node, measured by metrics-server. Percentages are computed against each node’s allocatable capacity. If the node list cannot be read the percentage columns are omitted rather than guessed. Examples:ankra cluster top pods
Show live CPU and memory usage per pod, measured by metrics-server. Without -n or--all-namespaces this reads every namespace, unlike kubectl
top, which defaults to the current one.
Examples:
ankra cluster uncordon
Clear the unschedulable mark ‘cluster cordon’ or ‘cluster drain’ set, so the scheduler can place pods on the node again. Example:ankra cluster upcloud
Commands to create, deprovision, and scale UpCloud clusters.ankra cluster upcloud bastion
Inspect, diagnose, and resize the cluster’s single bastion/gateway node. Find its node ID with ‘nodes list’.ankra cluster upcloud bastion diagnose
Dispatch the provider’s read-only bastion diagnose job and wait for its report: sshd configuration, failed-login volume, disk, failed units, journal errors, listening ports, and pending security updates. Nothing on the host is changed. The platform waits up to two minutes for the job; a slower run hands back the operation id to poll with ‘cluster operations list’.ankra cluster upcloud bastion resize
Resize the bastion/gateway node. The provider’s bastion/gateway update job powers it off, resizes it, and powers it back on, causing brief SSH/NAT downtime for the cluster.--wait covers the platform write only; the cloud resize runs as the operation
reported on success. Follow it with ‘ankra cluster operations list <operation_id>’.
ankra cluster upcloud bastion status
Report the verdict the platform’s bastion health loop last recorded for the cluster’s bastion/gateway: whether it is reachable, which hop a failed probe stopped at, and when it was last checked. Nothing is probed by this command, so it answers even while the bastion is unreachable - use ‘bastion diagnose’ to SSH in and collect a fresh report.ankra cluster upcloud control-plane
Inspect and change the control plane configuration. Only 1 or 3 controllers are allowed (etcd needs an odd number of voting members for quorum). The controller count can only be changed while the cluster is stopped, and applies the next time the cluster is started. The instance type can also be changed on a running cluster that has three controllers: they are then resized one at a time, keeping the Kubernetes API up. With a single controller it still needs a stopped cluster, because resizing the only controller takes the API down while it reboots. Run “control-plane get” to see which of the two is available right now.ankra cluster upcloud control-plane get
Show the current control plane configurationankra cluster upcloud control-plane set-count
Change the controller count (1 or 3)ankra cluster upcloud control-plane set-instance-type
Change the instance type of every controller in a UpCloud cluster. The instance type is stored as given; it is not checked against UpCloud’s catalog. A name that does not exist is rejected by UpCloud itself, which on a stopped cluster is at the next start - after this command has already reported success. On a running cluster the rolling resize drains each controller before resizing it, honouring its pods’ PodDisruptionBudgets.--force-drain bypasses them for
that drain, so pods whose budget refuses eviction are evicted anyway. It
applies to this request only, and only a live rolling resize reads it: a
stopped cluster’s offline resize drains nothing and ignores it, and so does a
request the rolling resize refuses (fewer than three controllers) or has
nothing to do for (the controllers already run that type).
ankra cluster upcloud create
Create a new UpCloud clusterankra cluster upcloud k8s-version
Get current Kubernetes version for an UpCloud clusterankra cluster upcloud node-group
List, add, scale, upgrade, and delete node groups.ankra cluster upcloud nodes
Inspect every server Ankra manages for the cluster (control plane, workers, and bastion or gateway). Soft-deleted entries from a stopped cluster are included so the saved topology is visible before re-provisioning.ankra cluster upcloud nodes cloud-init-log
Fetch ‘cloud-init status--long’ and the tail of
/var/log/cloud-init-output.log from the node over the platform’s bastion SSH
lane, as a tracked read-only operation. This is the debug surface for
node-group user-data: it shows whether the first-boot document ran and what
it printed, without needing the cluster’s SSH key. Repeated calls attach to
an in-flight fetch instead of dispatching duplicates. Find node ids with
‘nodes list’.
ankra cluster upcloud nodes get
Show full spec and metadata for a single nodeankra cluster upcloud nodes list
List all nodes for the clusterankra cluster upcloud nodes restart
Schedule a native reboot (falling back to a power cycle) of the node as a tracked operation. The node must be in the ‘up’ state and have no restart already in flight. Workloads on the node are briefly unavailable while it reboots. Works for any node returned by ‘nodes list’, including the bastion/gateway.ankra cluster upcloud start
Start (re-provision) a stopped UpCloud cluster. Use--scope control_plane to bring up only the control plane.
ankra cluster upcloud stop
Stop an UpCloud cluster’s compute while keeping its configuration so it can be started again later.--force also deletes the cluster’s load balancers. The CSI storage volumes are kept, forced or not, and keep billing while the cluster is stopped; deprovision the cluster to delete them.
ankra cluster upcloud workers
Get current worker count for an UpCloud clusterankra cluster upcloud zones
Extend the zone pool of an UpCloud cluster created with--network-mode wireguard_mesh
(or with --zones). Pass the full desired pool, primary zone first: zones can only be
added, never removed, and the pool must keep at least 3 zones with 3 control planes.
Every new zone gets its own private network and NAT gateway; node groups added or
scaled afterwards spread across the grown pool, and the cloud-provider stack
republishes with load balancers and volumes scoped to the primary zone.
ankra cluster upgrade
Upgrade the Kubernetes version on all nodes in a cloud cluster. The cloud provider (Hetzner, OVH, UpCloud, DigitalOcean, Scaleway, Ankra Cloud, AWS, Proxmox VE, or HPE Morpheus) is detected automatically from the cluster, so you do not need to remember which provider it runs on. Both kubeadm and k3s clusters are supported; list the available target versions with ‘ankra cluster kubeadm-versions’ or ‘ankra cluster k3s-versions’. Nodes upgrade one at a time (control plane first, then workers): each node is cordoned, drained respecting PodDisruptionBudgets, upgraded, and gated on being Ready at the target version before the rollout moves on. An etcd snapshot is taken before the control plane upgrade. A drain blocked by a PodDisruptionBudget aborts the rollout; pass--force to proceed anyway.
Downgrades and skipping minor versions are not supported.
Examples:
ankra cluster validate
Validate an ImportCluster YAML file. The local structural, dependency, and YAML checks run first (the same ones as ‘ankra cluster apply--dry-run’),
then the file is sent to the Ankra API for server-side validation that the
offline checks cannot perform:
- chart existence in the Helm registries connected to your organisation
- plaintext Kubernetes Secret / unencrypted addon value detection
- parent references resolved against a cluster’s existing resources
--cluster <name|id> to validate the spec against an
existing cluster’s deployed resources, and --strict-secrets to treat
plaintext secrets as errors instead of warnings.
ankra cluster variables
Manage cluster-scoped variables that are available to every stack on the cluster as template substitutions in manifests and addon values. Cluster variables shadow organisation variables of the same name on this cluster.--cluster is omitted, the active selection is used.