Skip to main content
Your cluster is running and now it needs to change: more workers, a bigger instance type, a new Kubernetes version, a pause overnight, or a clean teardown. This page covers those tasks for every cluster Ankra builds on your own account - the Ankra Managed clusters in the create dialog, on Hetzner, OVHcloud, UpCloud, DigitalOcean, Scaleway, AWS EC2, Ankra Cloud, Proxmox VE and HPE Morpheus. Where a provider behaves differently, the table in each section says so, and the provider’s own guide carries the details.
Clusters whose control plane your cloud runs (EKS, GKE, AKS, DOKS, UKS, OVHcloud MKS, Kapsule) are Cloud Managed; their node pools, upgrades and deletion are on Managed Kubernetes.

Before you start

  • The cluster shows Online and no operation is running on it. Day-2 changes are queued one at a time; follow them under Operations or with ankra cluster operations list.
  • In the dashboard, most controls live under Nodes in the cluster sidebar (tabs Node groups, Control plane, Bastion & VMs) and under Settings → General. Nodes describes every control on those tabs.
  • On the CLI, most commands find the provider from the cluster, so they are the same everywhere. The rest take the provider name: hetzner, ovh, upcloud, digitalocean, scaleway, aws, proxmox, morpheus or ankracloud. The Ankra Cloud commands need CLI v0.21.0 or later; ankra cluster ankracloud lists them.
  • Every command has an API equivalent under /api/v1/clusters/{provider}/{cluster_id}/... - see the API reference. Writes answer 202 Accepted and run in the background; pass --wait on the CLI to block until one finishes.

Node groups

A node group is a set of workers with one instance type, a count, and optional labels and taints. Each group scales, changes type and carries its labels independently. A group holds 0 to 100 nodes; scaling a group to 0 keeps its definition and removes its servers. In the dashboard: open Nodes → Node groups. Each card has the group’s controls, Add node group opens the size picker with live prices, and Max out sizes a group to what your cloud account still has room for. On the CLI:
  • Instance type changes go one way. A group moves to an equal or larger type only; to get smaller nodes, add a new group with the smaller type and delete the old one. How the change is applied depends on the provider - most power each node off, resize it and power it on again, while AWS replaces each node - so check the provider guide before you resize a group that runs stateful workloads.
  • Labels and taints apply to every node in the group. --clear removes them all; a taint without an effect gets NoSchedule.
  • Removing nodes drains them first. A scale-down, a group delete and a replacement drain each node, honouring PodDisruptionBudgets. A scale-down picks the nodes it removes itself; remove-node retires one chosen worker instead, named by its server id, server name, Kubernetes node name or providerID, and prints the operation that drains it and deletes its server. A node whose drain is refused is kept in service, and --force-drain removes it anyway. The last node of a group is not removed that way (scale the group to 0 or delete it), and a stopped cluster’s nodes are not removed.
  • Deleting a group removes all its servers. Workloads on them are evicted.
  • Zones. On OVHcloud 3-AZ regions (--availability-zone), UpCloud zone pools (--zone) and multi-zone AWS clusters, a group can be pinned to one zone - do that for groups that run zonal storage.
  • Autoscaling and first-boot scripts. Set a group’s autoscaling range with ankra cluster node-group autoscaling set - see Cluster Autoscaling. OVHcloud groups can carry a cloud-init document - see Node Group Cloud-init User Data.
  • A stopped cluster. Adding or changing a node group on a stopped cluster brings its infrastructure back first, so the cluster comes online. Use Start cluster when you want the full saved topology back.

Legacy worker scaling

Clusters also keep a single default worker pool that predates node groups. ankra cluster scale <cluster> <count> sets its size, and ankra cluster <provider> workers <cluster> shows it. Prefer node groups for anything new.

Control plane

In the dashboard: Nodes → Control plane shows the controller count and instance type, and says for each change whether it runs live or offline, or why it is refused right now.
  • Growing the count is live. Going from 1 to 3 controllers (3 to 5 on Proxmox VE) provisions the new controllers and joins them to the running cluster.
  • Reducing the count is offline. Stop the cluster (its state is kept and restored on start), apply the change, then start it.
  • The instance type changes in one of three ways, described below. control-plane get and the Control plane tab say which one applies to your cluster right now.
  • A cluster spread across several zones or hosts keeps at least three controllers.

Change the control plane instance type

How Ankra changes the instance type depends on how many controllers the cluster has and whether it is running: A running cluster with one controller on any other provider cannot change its instance type live. Either grow it to three controllers first and then resize it with no downtime, or stop it and change the type offline.

What the API downtime means

While the only controller reboots, the Kubernetes API is not available:
  • Pods that are already running on the workers keep running.
  • kubectl, deployments, Stack and add-on changes, controllers and operators, and the Ankra agent pause until the API is back. Anything that needs the API, such as scaling a Deployment or rescheduling a pod, waits until then.
  • Before it changes the server, Ankra takes an etcd snapshot on the node and drains it. Hetzner changes the server type and keeps its disk and IP address, so the node comes back as the same machine with the same cluster state. Ankra then waits for the node to be Ready again. When the new type has a larger disk, the disk grows with it, and Hetzner cannot shrink it again, so the controller cannot move back to a type with a smaller disk.
In a test on 2026-10-28, a Hetzner cluster resized from cpx22 to cpx32 finished the whole step in about two and a half minutes, and the workloads on the workers were not restarted. Plan for a few minutes of API downtime. To avoid any downtime, grow the cluster to three controllers first. Ankra does not start the resize while another change is running on the cluster, for example a scheduled Cluster State Snapshot. Start it again when that change has finished.

Resize the only controller

In the dashboard: open Nodes → Control plane and pick the new type. The tab says the Kubernetes API will be unavailable for a few minutes. Resize with API downtime in the review dialog accepts the downtime and starts the resize. On the CLI: control-plane get shows the change as Change type: yes - live with a few minutes of API downtime (single controller). set-instance-type refuses the change unless you pass --accept-api-downtime:
From the AI or MCP: the change_control_plane tool takes accept_api_downtime. The AI tells you about the downtime and sets it only after you have accepted it. On the API: send accept_api_downtime: true with the new type. Without it, the request is refused with 409 Conflict and a message that describes the downtime.
Sending the type the controller already has changes nothing and needs no acceptance.

Restart a node

Restart one node - a control plane, a worker or the bastion - without waiting for a reconciliation. The restart is a tracked operation, and workloads on the node are briefly unavailable while it reboots. In the dashboard: open Nodes, find the machine in the Machines table and choose Restart VM from its ⋯ menu. On the CLI: find the node ID, restart it, and follow the operation:
The node must be up with no restart already in flight. If a node never joined, ankra cluster <provider> nodes cloud-init-log <cluster> <node-id> shows its cloud-init status and the end of its log, read over the bastion (not on Proxmox VE or HPE Morpheus). You can also ask Ankra’s AI, for example “restart worker-2 on my-cluster”.

Bastion

The bastion is the machine Ankra and you reach the cluster through: every SSH hop into the private network goes via it. On most providers it carries no workload traffic, so workloads keep running while it is down, but Ankra cannot provision, scale, upgrade or reconcile the cluster until it is back. In the dashboard: Nodes → Bastion & VMs shows its state and the last health verdict, with Diagnose over SSH, Restart VM and Resize. The ⋯ menu on the bastion row in the Machines table also has Resize bastion.
A resize powers the bastion off, changes its type and powers it on again, so SSH access is interrupted briefly. Where the bastion is also the NAT for the nodes (AWS bastion_nat egress), node egress stops until it is back.

SSH access and keys

Settings → Access shows copy-paste SSH commands through the bastion for the cluster’s own addresses, and the SSH key credentials attached to the cluster. To change the keys:
The new keys are written to every node on the next reconciliation; resync forces it. The key Ankra itself uses is never removed. For everyday kubectl you need no SSH at all - see Accessing Clusters with kubectl.

Patch the operating system

Operating system security updates that restart networking are installed one host at a time by rolling OS patching, with a per-cluster maintenance window. See OS Security Patching.

Upgrade Kubernetes

In the dashboard: Settings → General shows the current Kubernetes version. Pick a target and click Upgrade. The same card has Auto upgrade patch versions, which moves the cluster to the newest patch of its current minor version on its own; minor versions are never upgraded automatically. On the CLI:
  • Nodes upgrade one at a time, control plane first, then workers. Each node is cordoned, drained honouring PodDisruptionBudgets, upgraded, and must be Ready at the target version before the next one starts.
  • An etcd snapshot is taken before the control plane upgrade. With external etcd, the dedicated etcd members are upgraded first, one at a time, each saving a snapshot.
  • A drain blocked by a PodDisruptionBudget stops the rollout; --force proceeds anyway.
  • One minor version at a time (1.33 to 1.34, not 1.33 to 1.35), and no downgrades.
Restore points, the pre-upgrade checklist and what to do when a hop stops are in Upgrade Kubernetes on a Cluster.

Stop and start

Stopping releases the cluster’s compute and keeps its configuration, stacks and credentials in Ankra, which is how you park a cluster you do not need right now. Starting re-provisions it and reconciles it back to running. What a stop does to the servers depends on the provider: Stop cluster explains the snapshot, the pause mode and the restore in full. In the dashboard: Settings → General → Danger Zone → Stop cluster, or Stop cluster / Start cluster in the cluster’s ⋯ menu. They also run on a timetable with Power Schedules.
A start restores the newest snapshot captured after the cluster’s last start by itself. When there is none but older snapshots exist, the start is refused and the refusal names the newest; ankra cluster state-snapshots latest shows it, and --restore-snapshot-id <id> restores it. On AWS EC2, Scaleway and Ankra Cloud, whose stop keeps the servers, a start restores nothing by itself; when the control-plane machines are lost, add --restore-over-kept-etcd to the named restore. Restore a named snapshot has the detail.
  • A stop never deletes the volumes your workloads provisioned through the CSI driver, forced or not; they keep billing while the cluster is stopped. --force also deletes the cluster’s load balancers, and never captures a snapshot.
  • Stop and start run in the background. A start is refused with 409 while a stop or terminate is still running.
  • While the cluster is stopped, ankra cluster <provider> nodes list still shows the saved machines that the next start re-provisions.

Terminate a cluster

Terminating deletes the cluster’s servers and the network Ankra created, then removes the cluster from Ankra. It cannot be undone. In the dashboard: Settings → General → Danger Zone → Terminate. The dialog lists the persistent volumes the teardown deletes, and the button stays disabled until you accept that.
  • Volumes are deleted only once you accept it. --yes skips the teardown confirmation but never the volume one. The API lists the volumes with GET .../deprovision-volumes and needs ?accept_volume_data_loss=true on the DELETE; without it the answer is 409 naming them.
  • --force deletes leftover load balancers and tolerates infrastructure that no longer answers. It never stands in for accepting the volume loss. On Proxmox VE it finishes the teardown when the host or jumphost is unreachable, leaving the VMs behind.
  • A stopped cluster can be terminated too: the volumes recorded at stop time are still known and named.
Persistent volumes covers every case, including volumes Ankra cannot prove belong to the cluster.

Choices fixed at create time

A few choices cannot be changed on a running cluster. They are made in the create wizard (the Kubernetes step) or in the create request, and they shape the upgrade and networking tasks above.
  • Distribution. kubeadm (the default everywhere: wizard, CLI and API) is upstream Kubernetes with containerd; its versions are plain tags such as v1.33.2. k3s is a single-binary distribution; its versions look like v1.33.2+k3s1.
  • CNI (cni). kubeadm clusters always run Cilium. k3s clusters choose flannel (the default), calico or cilium; AWS defaults to Cilium for both distributions. The CNI cannot be changed later.
  • CNI features (cni_features). Cilium offers kube_proxy_replacement, hubble and wireguard_encryption; Calico offers ebpf_dataplane; flannel takes none. On k3s, kube_proxy_replacement and ebpf_dataplane need a single control plane.
  • etcd topology (kubeadm only). stacked (the default) runs etcd on the control plane nodes. external runs it on 3 or 5 dedicated machines (etcd_node_count), sized by a provider-specific field:

Next steps

  • Nodes - every control on the Nodes tabs, including standalone VMs.
  • Gateway API - serve Gateway and HTTPRoute resources from the networking stack’s Traefik, chosen when you create the cluster.
  • Cluster Autoscaling - let pod demand size your node groups.
  • Power Schedules - stop and start on a timetable.