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, while keeping the managed Kubernetes experience.

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 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 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.
• Metal servers: select the servers to attach from the list loaded from that integration; you no longer type IPs by hand. Search by name, IP, server number, product, or datacenter and click a server to attach it (or Add all to attach every server shown). Each row shows a status: Ready servers are installed and attachable, while In process servers are still being set up in Robot. Attached servers appear as cards above the list, each with a Detach control, so you can adjust the selection before saving.

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. For a single Metal server pool the VLAN ID and vSwitch private subnet are assigned automatically, so you don’t need to configure networking by hand.

A second Metal server pool needs distinct networking

The auto-assigned defaults (VLAN 4000 and the same vSwitch /24) are identical for every Metal server pool, so a second pool left on the defaults is rejected. Give each additional pool an explicit, distinct VLAN ID (4000–4091) and a non-overlapping /24 vSwitch subnet.

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. Runs installimage to install a clean Debian 13 (trixie) system. Disks are detected automatically, and multiple disks are mirrored with software RAID 1. 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 attaching or detaching servers in the list is safe.

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, 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 the disk, so bring fresh servers.
• 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.