Hetzner Metal Server Pools

Edka lets you attach your own Hetzner dedicated servers to a cluster as extra worker pools, alongside cloud workers. This is ideal when you need more raw CPU, RAM, or disk than cloud instances offer. Edka provisions and operates metal nodes the same way it does cloud nodes.

The Kubernetes control plane always runs on Hetzner Cloud. Metal servers join as worker nodes, connected to the cluster’s private network through a Hetzner vSwitch.

Start minimal, add metal later

Provision a normal cloud cluster first (a cloud control plane plus at least one cloud worker pool) and let it come up healthy, then add your Metal server pools to it. Don’t include Metal server pools in the initial cluster definition.

This keeps cluster creation fast and reliable, lets the private network and control plane settle before any server is reinstalled, and isolates the disk wiping Metal server provisioning into a separate, retriable step: if a Metal server reinstall fails, your cluster stays healthy and you simply retry the pool instead of failing the whole cluster create.

How it works

When you add a Metal server pool, Edka:

1. Creates or reuses an existent Robot vSwitch and attaches your dedicated servers to it.
2. Couples that vSwitch to the cluster’s Cloud Network and exposes routes, so Cloud and Metal server nodes share one private network.
3. Reinstalls a clean OS on each server (see below), then installs the K3s agent and joins the node over its private vSwitch IP.

You own the servers. Edka never orders or deletes hardware. Removing a Metal server node drains and removes the Kubernetes node, then best-effort detaches the server from the vSwitch and clears its Robot firewall. This removes the server’s entire Robot firewall configuration, not only the rules Edka added. The server and the vSwitch are left intact.

Before you start

You will need:

• A Hetzner Robot account with web service credentials enabled (Robot → Settings → Web service and app settings). This is a separate credential from your Hetzner Cloud API token.
• One or more vSwitch-capable dedicated servers that you have already ordered in your Robot account. They must be online and reachable over SSH (port 22) when you add the pool; Edka verifies connectivity before accepting it.
• A cluster whose control plane is in the EU-Central network zone (Nuremberg nbg1, Falkenstein fsn1, or Helsinki hel1), where Hetzner vSwitch is available, and that was created with a private network. This is required and enforced: adding a Metal server pool to a cluster without a private network is rejected.

Existing cluster network subnet limitation

Some older private-network clusters were created with a Hetzner Cloud subnet that uses the entire private range, for example a full /16. Those clusters cannot attach Metal server pools because Hetzner requires the vSwitch subnet to be a separate, non-overlapping /24 on the same Cloud Network.

If Edka reports that the Metal vSwitch subnet overlaps an existing cloud subnet, create a new private-network cluster for Metal servers. New clusters reserve address space for future vSwitch subnets by using a smaller Cloud subnet inside the private network range.

The server’s disk is wiped

On first provision, Edka reinstalls the operating system on each Metal server so the cluster SSH key is installed automatically and every node starts from a known, clean state. All existing data on every drive of the server is erased. Only add servers that are empty or that you are ready to wipe.

1. Add Robot credentials

1. In the Edka dashboard, go to Settings → Integrations and add a Hetzner Robot integration.
2. Enter your Robot web service username and password.
3. Edka validates the credentials against the Robot API and stores them encrypted (in Vault). This saved integration is required to add Metal server pools: you select it when configuring the pool, and you cannot attach metal servers without one.

2. Add a Metal server node pool

From Cluster Settings → Node Pools, click Add Node Pool and set Provider to Hetzner Dedicated. Then configure:

• Pool name: used in scheduling and cluster events.

• Robot integration: the integration you created above. Edka uses it to load the dedicated servers in that Robot account.

• Servers: a table of every server the integration lists, with its IP, model and site. Check a server to attach it, or click Add all. Servers that are still In process in Robot can’t be checked yet, and servers another pool holds are listed under Show unavailable servers with the pool that holds them. Above eight servers, a search narrows the table by name, IP, server number, model or site.

• Disk: Standard, or Encrypted local storage for volumes of the local-path-encrypted storage class.

• Layout: Mirrored keeps the system on two drives, so a server keeps running when one drive fails. Separate puts it on one drive. See Disk layout.

The preview beside the form shows the pool as you set it up: its servers, what each drive will hold, and that applying reinstalls the servers.

Disk and Layout are fixed once the pool exists.

Edka resolves each server’s public IP and Robot server number from your inventory when you select it. The pool’s node count is the set of servers you attach; there is no separate count to set. The VLAN ID and vSwitch private subnet are assigned automatically when you add the cluster’s first Metal server pool, so you don’t need to configure networking by hand.

Metal server pools share one vSwitch per cluster

Hetzner couples one vSwitch to a Cloud Network, so every Metal server pool in a cluster uses the same vSwitch, VLAN ID, and /24 subnet, and all Metal server pools of a cluster must use Robot integrations of the same Robot account. A pool groups and labels servers; it is not a separate network.

A server belongs to one pool at a time. Servers already attached to a pool are listed but cannot be selected. To move a server, detach it from its pool, apply the change, then attach it to the other pool.

Click Update Node Pools. Edka verifies SSH reachability to each server, configures the vSwitch, and then provisions the nodes.

What happens during provisioning

For each Metal server node, Edka:

1. Registers the cluster SSH key in Robot and boots the server into rescue mode (via the Robot API + a hardware reset).
2. Lists the server’s drives, checks that they fit the pool’s disk layout, wipes every drive, and runs installimage to install a clean Debian 13 (trixie) system on the system drives. The cluster SSH key is baked into the installed system, so there is no manual authorized_keys step.
3. Boots the freshly installed OS, brings up the vSwitch VLAN interface, and joins the node to the cluster over its private IP.
4. Installs the K3s agent. The node appears as Ready and is scheduled like any other worker.

Reinstalling a server takes roughly 10–20 minutes (OS install plus two reboots). Provisioning is idempotent: a node that has already been installed is never re-wiped on later updates. Identity is keyed on each server’s public IP, so reordering servers in the list is safe. A server that was removed from a pool and attached again, to another pool or at a new position, is reinstalled like a new server, because its previous installation is still bound to the old node identity.

Disk layout

Disk and Layout decide what each drive of a server holds:

Layout	Disk	Drives
Mirrored	Standard	The system on two drives with software RAID 1.
Mirrored	Encrypted local storage	The system and an encrypted partition after it, both mirrored. Root sets the root size.
Separate	Standard	The system on one drive. The other drives stay empty for your own use.
Separate	Encrypted local storage	The system on one drive, and the next drive encrypted whole.

A mirrored server keeps running when one drive fails. The system goes on solid-state drives before spinning ones, the smallest first. With Separate and encrypted local storage, Edka encrypts the next drive in the same order, so a server with two NVMe drives keeps the system on nvme0n1 and encrypts nvme1n1. Every drive that holds neither the system nor encrypted storage is wiped and left with no partition or file system, so nothing of an earlier install comes back.

Edka checks the drives in the rescue system before it writes anything. A server that cannot take the layout, such as a one-drive server in a mirrored pool or a one-drive server that should encrypt a second drive, fails there with its list of drives and keeps its data. Detach it, or create a pool with a layout that fits it.

Pools created before the layout choice existed mirror the system on servers with two drives or more, and use the one drive otherwise.

The node’s Disk tab in Explorer shows the drives of a Metal server node, what each one holds, its RAID arrays and each drive’s health. Edka installs smartmontools on Metal server nodes to read it.

Scaling and removal

• Add capacity: attach more servers to the pool, or add another Metal server pool.
• Remove a node or pool: Edka drains and removes the Kubernetes node, then best-effort detaches the server from the vSwitch and clears its Robot firewall. This removes the server’s entire Robot firewall configuration, not only the rules Edka added, and also runs when you delete the whole cluster. The physical server keeps running in your Robot account and can be reused, and the vSwitch is preserved; Edka never deletes hardware. Cleanup is best-effort: if a detach or firewall-clear fails, Edka logs a warning and continues.
• Autoscaling is not available for Metal server pools; the pool size is the set of servers you attach.

Load balancers

Hetzner Cloud load balancers, created by a Service of type LoadBalancer, the Gateway API, or an ingress controller, attach to the cluster’s private network and load-balance across all of your worker nodes, Cloud and Metal servers alike. The cloud controller manager registers cloud nodes as Cloud-server targets and Metal server nodes as private-IP targets in the vSwitch subnet. Both show up as healthy targets in the Hetzner Console (cloud nodes grouped under Cloud Server and Metal server nodes under Dedicated Server, by their private vSwitch IP), so workloads scheduled on either kind of node are reachable through the load balancer with no special configuration.

Manual steps that remain

A few things stay outside Edka because they involve hardware or your Robot account:

• Buying / cancelling the dedicated servers themselves.
• Enabling the Robot web service user and password.
• Ensuring each server is online and reachable on port 22 before you add it, and that its main NIC supports the vSwitch.
• You don’t need to hand-manage the Robot switch-port firewall for vSwitch traffic. Edka applies one automatically on provision (allowing the cluster private subnet and the vSwitch subnet, SSH, ICMP, and established-connection replies) and clears it when the node or cluster is removed.

Limitations (current)

• Metal servers are workers only; the control plane stays on Hetzner Cloud.
• The first provision OS reinstall wipes every drive, so bring fresh servers.
• Disk and Layout are fixed when the pool is created. Servers of one pool should have the same drives.
• A cluster must be in a vSwitch-capable location and created with a private network. This is enforced: adding a Metal server pool to a cluster without a private network is rejected.
• Existing clusters whose Hetzner Cloud subnet spans the full private range, such as a /16, cannot attach Metal pools because the required vSwitch /24 would overlap it. Create a new private-network cluster before adding Metal servers.

Related

• Updating a Cluster — managing node pools.
• Kubernetes on Hetzner Cloud — Hetzner credentials and resources.