Pools of Existing Hetzner Cloud Servers
A pool of existing servers is a worker pool made of Hetzner Cloud servers that are already in the cluster’s Hetzner project. Use it for servers you want to keep rather than replace, for example servers bought at a price that ends when the server is deleted.
Edka never deletes these servers. Removing a server from the pool, removing the pool, or deleting the cluster releases the server: it leaves the cluster and keeps running in your project, powered off.
Before you start
Section titled “Before you start”- The cluster exists. Pools of existing servers are added to a running cluster from its node pool settings, not when you create the cluster.
- The cluster has a private network. Adding the pool to a cluster without one is refused.
- The servers are in the cluster’s Hetzner project, the project of the cluster’s API token, and in the network zone of its control plane.
- They share one server type. Put servers of another type in a pool of their own.
- Nothing is attached to them. Detach their volumes, remove them as Load Balancer targets, and turn off their protection. Hetzner turns delete and rebuild protection on and off together, and a protected server cannot be wiped. Edka turns protection back on after the wipe.
- No other cluster claims them. A server with a
clusterlabel of another cluster may still be a node of that cluster. Once you know it is free, remove the label in the Hetzner Console.
Add the pool
Section titled “Add the pool”- Open the cluster, go to Settings → Node Pools and click Add Node Pool.
- Set the source to Existing servers.
- Pick the servers. The list shows every server in the cluster’s Hetzner project. A server that cannot join is greyed out with the reason, for example when it belongs to another cluster or another pool, has volumes attached, or has another server type than the servers you already picked.
- Name the pool and set its labels and taints like any other pool.
- Click Update Node Pools.
The pool’s size is the set of servers you pick. Pools of existing servers do not autoscale.
What happens when a server joins
Section titled “What happens when a server joins”For each server, Edka:
- Names it. Renames the server after its place in the pool.
- Moves it. Moves it to the cluster’s private network, and on clusters with a NAT gateway, deletes its public IPs.
- Wipes it. Reinstalls it with the cluster image. Only the cluster’s SSH key can log in afterwards.
- Protects it. Turns on delete and rebuild protection.
- Joins it. Joins it to the cluster as a worker. The node appears as
Readyand is scheduled like any other worker.
From then on it is a cluster node like the others: it gets Kubernetes upgrades, it can use Hetzner volumes, and Load Balancers send traffic to it.
Remove servers
Section titled “Remove servers”- Remove a server: unselect it in the pool and apply.
- Remove the pool: remove the pool and apply.
- Delete the cluster: releases every server of its pools of existing servers.
In each case Edka drains the node, removes it from Kubernetes and the cluster’s private network, and powers the server off. The server stays in your Hetzner project with delete protection on, so it keeps its price. On a cluster with a NAT gateway it has no public IP left; assign a new primary IP in the Hetzner Console before you use it again.
To move a server to another pool, remove it from its pool, apply, then add it to the other pool.
Billing
Section titled “Billing”These servers stay on your Hetzner bill at the price you bought them at, which Hetzner’s price list does not show. To count them in the pool’s and the cluster’s monthly price, enter that price on the pool’s page under Price: the amount per server per month, excluding VAT, as it appears on your Hetzner invoice. Until you do, Edka leaves these servers out of both.
Related
Section titled “Related”- Update a Cluster: managing node pools.
- Metal (Dedicated) Node Pools: Hetzner dedicated servers as worker pools.
- NAT Gateway: private-only workers.