Skip to main content
The Nodes section answers “what machines is this cluster made of, and what can I do to each of them?” - the infrastructure view. Kubernetes → Nodes stays the view of the node objects Kubernetes keeps; the two link to each other.

​
Accessing the section

Open a cluster and click Nodes in the sidebar, directly above Kubernetes. The section has up to four tabs, depending on what Ankra manages for the cluster: Node management used to live under Settings → Nodes; that tab is gone and its address now opens the Node groups tab, so older links keep working.

​
Overview

​
Stat tiles

Machines counts every server Ankra runs for the cluster by role - control plane, workers, bastion. Kubernetes ready is ready over total nodes as the kubelets report them, with the cordoned count beside it. vCPU and Memory sum node capacity; GPUs counts what device plugins advertise. Run rate is the projected monthly cost from the cluster’s cost read, with how many nodes it covers. A figure the platform cannot read says so - No nodes reporting, Not priced - rather than showing zero. A cluster whose agent is offline is not an empty cluster.

​
The Machines table

One row per machine, joining what the cloud provider knows about the VM with what Kubernetes knows about the node. The join is by name (Ankra names the VM and the kubelet the same), with the private address as the fallback.
  • Machine - name and role.
  • Group - the node group the machine scales in.
  • Instance - the instance type, with vCPU, memory, disk and list price from the provider’s live catalog, and a GPU chip when the node carries GPU feature-discovery labels (1 × NVIDIA H100 80GB HBM3).
  • Kubernetes - Ready, Cordoned or Not ready from the node object, with the kubelet version. A VM without a node object reads Not joined (a worker that has not registered yet) or Not a node (the bastion). Neither is rendered as a failure: a machine Kubernetes has never seen is not a machine Kubernetes reports as broken.
  • VM - the provider’s state and power state.
  • Location and Addresses - private and public.
The ⋯ menu on a row holds what applies to that machine:
  • Cordon / Uncordon and Drain - on any machine with a node object. Drain cordons the node and evicts its pods, with progress shown until it completes; pods without a controller are not recreated.
  • Restart VM - reboots the server at the provider (an operation you can follow under Operations). Workloads on the node are briefly unavailable.
  • Resize bastion - on the bastion row.
  • Open in Kubernetes - the node’s page under Kubernetes → Nodes, with capacity, conditions, pods, GPU telemetry and the manifest.
  • Machine details - the provider record, resource definition and reconciler data.
On an imported cluster the table shows the Kubernetes side only - Ankra does not provision those machines - and cordon, uncordon and drain still apply.

​
Node groups

Each card is one node group: instance type, count, autoscaling bounds, labels and taints, with the same controls the settings tab offered - scale, switch autoscaling on or off and set its range, move to an equal-or-larger instance type, edit labels and taints, delete the group. Add node group opens the size picker with live availability and prices.

​
Max out

Under each group that is not autoscaled, Max out sizes the group to the most your cloud account still has room for. Ankra reads the account’s quota through the cluster’s credential and takes the tightest of three bounds:
  • remaining servers in the account,
  • remaining vCPUs divided by the instance type’s vCPUs,
  • remaining memory divided by the instance type’s memory,
capped at the 100-node group limit. The control names the bound and the added cost at list price before you confirm, and the scale itself is an operation you can follow. The answer has three states and all three are shown: a known maximum, at max when the quota is spent, and unavailable when the provider does not expose its limits or the instance type’s specs are not known - it never offers 100 on a guess. For an autoscaled group the autoscaler owns the count; raise its maximum on the card instead. The same report is available on the API as GET /org/clusters/{provider}/{cluster_id}/quotas (and under /api/v1), alongside the credential-scoped GET /org/credentials/{provider}/{credential_id}/quotas.

​
Control plane

The controller count (1 or 3 - etcd needs an odd number of voting members) and the controllers’ instance type, each with what a change involves for the running cluster (offline or rolling) or why it is refused right now.

​
Bastion & VMs

The bastion is the one machine with a public address: every SSH hop into the cluster and the private network’s egress go through it. The tab shows its name, instance type, addresses, location, VM state, and the health verdict the scheduler last recorded, with:
  • Diagnose over SSH - runs the bastion diagnosis and shows the report inline.
  • Restart VM and Resize - the same controls as the machines table.

​
Standalone VMs

A standalone VM is a machine on the cluster’s network that is not a Kubernetes node - a database host, a build box, a jump host of your own. Ankra provisions it the way it provisions the bastion: on the cluster’s private network, with the cluster’s SSH keys, and it is reachable the moment it is reported up. It is never joined to Kubernetes, never made a gateway, and - unlike the nodes and the bastion - it keeps running when the cluster is stopped, because it carries your own state. Add VM takes a name (lowercase letters, digits and hyphens), a size from the provider’s live catalog with its price, a location (the bastion’s unless you change it), and whether the machine gets a public address. Without one it is private-network only: reach it over the bastion, exactly like a node (ssh -J with the material under Settings → Access). With one it has its own address and key-only SSH. The provider-side server is named <cluster>-vm-<name>. Each VM row shows its size, addresses and state, and its menu offers Restart VM, Resize (powered off, moved to the new size, started again - the disk is kept) and Remove (deletes the server and its disk; there is no undo). The machines table on the overview lists VMs too, with the role VM and the Kubernetes column reading Not a node. Standalone VMs are available on Hetzner clusters first. On other providers the tab says so rather than offering a control that does nothing. On the API: GET/POST /org/clusters/{provider}/{cluster_id}/vms, DELETE .../vms/{vm_id}, PUT .../vms/{vm_id}/instance-type, and the same under /api/v1 with ?wait=false for asynchronous writes.

​
Playground size

On a playground the overview carries the Playground size card. A paid playground picks a new size from the list; the card names the direction and the monthly difference before anything changes - Upgrade to Medium: +€15.30/mo - and the button reads Upgrade or Downgrade. The resize changes the namespace quota and the price, billed pro-rata across the change, and touches nothing you deployed. The free trial has one fixed size; its card offers Upgrade to a paid size, which orders a second, paid playground at the size you pick.

​
CLI

ankra cluster get nodes lists the Kubernetes nodes and ankra cluster describe node <name> describes one. Node groups, the control plane and the bastion are managed from the section or the API.