Neuigkeiten von trion.
Immer gut informiert.

Talos Kubernetes auf Hetzner Cloud einfach einrichten

Kubernetes

Talos Linux ist ein auf Kubernetes optimiertes Linux, dass auf die absolut wesentlichen Elemente reduziert ist. Auf typische Elemente einer Linux Distribution, wie z.B. ein Paketmanager wird dabei verzichtet. Selbst SSH ist nicht verfügbar: Sämtliche Interaktionen mit dem System werden über eine Talos System API ermöglicht.
Damit ist Talos Linux als minimales Linux aus der Perspektive der Systemsicherheit sehr attraktiv.

Die Installation erfolgt durch Images, so ähnlich, wie bei Mobiltelefonen. Ein Update besteht aus dem Download eines neuen Image und anschließendem Neustart. Als offizielle Boot Medien stehen ISO, USB-Stick und PXE zur Verfügung.
In diesem Beitrag geht es um ein etwas ungewöhnliches Installationsverfahren, das prinzipiell mit beliebigen bestehenden Linux Umgebungen kombinierbar sein sollte.
Als Beispielumgebung wird dazu die Hetzner Cloud verwendet.

Hetzner hat sich einen Namen gemacht, indem preiswerte Infrastruktur mit typischerweise recht niedrigem Abstraktionsgrad angeboten wird. Früher waren dies primär physische Server, später kam auch die Hetzner Cloud hinzu, bei der virtuelle Maschinen mit stundengenauer Abrechnung und monatlichem Maximalpreis gemietet werden können.

Server können dabei via API oder über die Weboberfläche der Hetzner Cloud erstellt werden. Bei der Bestellung kann für den Zugriff bereits ein SSH Key angegeben werden, alternativ sendet Hetzner die Zugangsdaten per E-Mail zu. Erfolgt der Login per Passwort, so muss dies beim ersten Login geändert werden.

E-Mail mit Zugangsdaten
E-Mail mit Zugangsdaten für Hetzner Cloud Server

Auf der Maschine eingeloggt muss nun die Installation von Talos noch erfolgen.

boot-to-talos

Das Projekt boot-to-talos[https://github.com/cozystack/boot-to-talos] hat es sich zur Aufgabe gemacht, bestehende Linux-Installationen unkompliziert in eine Talos Linux-Installation zu überführen. Das besondere daran: Dies erolgt vollständig aus dem Userspace heraus und ohne zusätzliche Abhängigkeiten. Dadurch können auch Systeme oder virtuelle Maschinen, auf denen bereits eine beliebige Linux-Distribution läuft, mit minimalem Aufwand auf Talos migriert werden, ohne auf PXE-Boot, Installationsmedien oder Out-of-Band-Management angewiesen zu sein. Das Werkzeug unterstützt sowohl einen direkten Start des Talos-Installers/Maintenance Mode mittels kexec als auch eine direkte vollständige Installation auf den Ziel-Datenträger

Die Installation erfolgt dabei durch ein kleines Shellscript:

Der Standard-Netzwerkadapter wird automatisch anhand der Informationen aus Netlink und /proc/net/route ermittelt. In manchen Umgebungen kann diese automatische Erkennung jedoch schief gehen und den falschen Netzwerkadapter auswählen. In diesem Fall kann mit der Option -override-interface explizit angegeben werden, welcher Netzwerkadapter für die Generierung der Kernel-Parameter verwendet werden soll.

boot-to-talos läuft in der bestehenden Linux-Umgebung, in der die Netzwerkkarte als eth0 erscheint. Talos vergibt nach der Installation jedoch eigene, vorhersagbare, Interface-Namen, sodass ein fest eingetragenes interface: eth0 nach dem Neustart nicht mehr passt.
Der Patch wählt die Schnittstelle deshalb nicht über den Namen, sondern über einen deviceSelector anhand der MAC-Adresse (hardwareAddr). Die MAC-Adresse bleibt beim Wechsel von Linux zu Talos gleich, sodass die Konfiguration unabhängig vom später vergebenen Namen greift.

Wer auf Nummer sicher gehen will, und dabei auch direkt den Hostnamen in Talos übernehmen möchte, kann sich auch einen Patch zur von Talos generierten Konfiguration erzeugen lassen.

#!/bin/bash
set -euo pipefail
PATCH_FILE="${1:-$(hostname).patch.yaml}"
IFACE=$(ip -4 route show default | awk '{print $5}')
MAC=$(cat "/sys/class/net/$IFACE/address")
HOSTNAME=$(hostname)
CIDR=$(ip -4 addr show "$IFACE" | awk '/inet / {print $2}' | head -1)
IP=${CIDR%/*}
PREFIX=${CIDR#*/}
GATEWAY=$(ip route | awk '/default/ {print $3}')
DNS_SERVERS=$(awk '/^nameserver/ {print $2}' /etc/resolv.conf)
DISK=$(lsblk -ndo NAME,TYPE | awk '$2=="disk"{print "/dev/"$1; exit}')

cat > "$PATCH_FILE" <<EOF
machine:
  network:
    interfaces:
      #- interface: ${IFACE}
      - deviceSelector:
          hardwareAddr: "${MAC}"
        dhcp: false
        addresses:
          - ${IP}/${PREFIX}
        routes:
          - network: ${GATEWAY}/32   # Hostroute zum Gateway (scope link), Hetzner-spezifisch
          - network: 0.0.0.0/0
            gateway: ${GATEWAY}
    nameservers:
    - 9.9.9.9
    - 8.8.8.8
  install:
    disk: ${DISK}
---
apiVersion: v1alpha1
kind: HostnameConfig
hostname: ${HOSTNAME}
EOF

cat "$PATCH_FILE"

Hetzner weist dem Server eine /32-Adresse zu, das Standard-Gateway 172.31.1.1 liegt damit außerhalb des eigenen Subnetzes. Damit das Gateway trotzdem erreichbar ist, ergänzt das Script eine Hostroute auf 172.31.1.1/32, die als "scope link" direkt über die Schnittstelle aufgelöst wird. Erst darüber greift die anschließende Default-Route über dieses Gateway.

Nun kann es fast direkt losgehen.

Install vs. boot

Bei boot-to-talos gilt es zwischen zwei Varianten zu unterscheiden: Dem boot und dem install Modus.

Bei boot wird mittels kexec auf den von boot-to-talos extrahierten Kernel (vmlinuz) und die Ramdisk (initramfs) direkt aus dem angegebenen Talos-Installer-Image umgeschaltet. Der Server wird dabei nicht neu gestartet, sondern das Linux "schaltet um". Der Server läuft danach in einer temporären Talos-Umgebung im RAM (Maintenance-Modus), ohne dass die Festplatte des Servers permanent mit Talos überschrieben wird. Erst wenn anschließend via talosctl apply-config die Konfiguration an den Server gesendet wird, installiert sich Talos dauerhaft auf die Festplatte.

Im install Modus bereitet das Tool eine temporäre Umgebung im RAM vor, lädt das Talos-Installer-Image und führt es innerhalb eines chroot aus. Es partitioniert und formatiert die Festplatte (z.B. /dev/sda oder /dev/vda) direkt im laufenden Betrieb neu und schreibt das fertige Talos-Festplattenimage (inklusive GRUB-Bootloader) blockweise direkt auf das primäre Speichermedium.
Sobald das Image erfolgreich gestreamt wurde, erzwingt das Tool über einen Kernel-Trigger (echo b > /proc/sysrq-trigger) einen sofortigen, harten Neustart des Servers. Der Server fährt danach direkt von der frisch beschriebenen Festplatte in Talos Linux hoch.

Für welchen Modus man sich entscheidet hängt davon ab, ob kexec überhaupt unterstützt wird. Ist Secureboot aktiv, wird das zum Beispiel nicht funktionieren. Im Gegensatz zum Install Modus ist ein Test nicht destruktiv und es kann testweise ein Talos im Maintenance Modus gestartet werden.

Installation von Talos auf Hetzner Cloud

Zur Installation fragt boot-to-talos neben der Methode auch ab, welches Image genutzt werden soll. Als Vorbelegung nutzt boot-to-talos das cozystack Image, es kann jedoch auch ein ganz normales Talos Upstream Image genutzt werden.

Die Installation wird durch /usr/local/bin/boot-to-talos angestartet,

Installationsschritte boot-to-talos auf Hetzner Cloud
root@ubuntu-4gb-hel1-1:~# /usr/local/bin/boot-to-talos
Mode:
  1. boot – extract the kernel and initrd from the Talos installer and boot them directly using the kexec mechanism.
  2. install – prepare the environment, run the Talos installer, and then overwrite the system disk with the installed image.
Mode [1]:
Talos installer image [ghcr.io/cozystack/cozystack/talos:v1.11.6]: ghcr.io/siderolabs/installer:v1.13.5
Add networking configuration? [yes]:

Detected interface: eth0 (enx920008cfdab4)
Network device for IP [enx920008cfdab4]:
IP address [65.21.152.105]:
Netmask [255.255.255.255]:
Gateway (or 'none') [172.31.1.1]:
Hostname [ubuntu-4gb-hel1-1]:
Configure serial console? (or 'no') [ttyS0]:

Boot Summary:
  Image: ghcr.io/siderolabs/installer:v1.13.5
  Extra kernel args: ip=65.21.152.105::172.31.1.1:255.255.255.255:ubuntu-4gb-hel1-1:enx920008cfdab4:none console=ttyS0

Continue with boot? [yes]:

2026/07/04 14:46:48 boot mode: extracting kernel and initramfs from image
2026/07/04 14:46:55 loading kernel with kexec
2026/07/04 14:46:55 using KexecFileLoad
2026/07/04 14:46:55 cmdline: talos.platform=metal console=tty0 init_on_alloc=1 slab_nomerge pti=on consoleblank=0 nvme_core.io_timeout=4294967295 printk.devkmsg=on selinux=1 module.sig_enforce=1 proc_mem.force_override=never ip=65.21.152.105::172.31.1.1:255.255.255.255:ubuntu-4gb-hel1-1:enx920008cfdab4:none console=ttyS0
2026/07/04 14:46:56 kexec loaded successfully, rebooting...

Nach einigen Momenten ist die SSH Verbindung nicht mehr nutzbar:
Jetzt ist Talos aktiv.

Da Talos kein SSH anbietet, kann ab jetzt lediglich über die Talos API oder einer Remote-Console auf die Maschine zugegriffen werden. Hetzner bietet dafür integriert in der Weboberfläche eine Option, um eine grafische Konsole zu erhalten.

Weboberfläche der Hetzner Cloud
Zugriff auf die Weboberfläche der Hetzner Cloud

Talos startet die 'dashboard' Oberfläche als Text-UI. Damit lassen sich alle wesentlichen Informationen zum Zustand der Maschine, Talos und Kubernetes einsehen.

Remote Console
Web basierte Console eines Hetzner Cloud Servers

Bisher ist die Node jedoch lediglich im "Maintenance" Modus: Es gibt noch keine Konfiguration, diese muss erzeugt werden und zu der Maschine gesandt werden.

Erzeugung der Talos Konfiguration und Maschinenkonfiguration
$ export TALOSCONFIG=$PWD/talosconfig
$ export IP=65.21.152.105
$ talosctl gen secrets
$ talosctl gen config --with-secrets=secrets.yaml hetzner https://$IP:6443
generating PKI and tokens
Created controlplane.yaml
Created worker.yaml
Created talosconfig

Die so erzeugte Konfiguration kann nun zur Maschine geschickt werden. Da noch gar keine Konfiguration auf der Maschine ist, akzeptiert diese unauthentifizerte Requests. All zu lange sollte damit also nicht gewartet werden, wenn es um im Internet erreichbare Nodes geht.

Aktivierung der Talos Maschinenkonfiguration
$ talosctl apply-config --insecure \
  -n $IP \
  --file controlplane.yaml \
  --config-patch @patch.yaml
Applied configuration without a reboot

Talos installiert sich nun auf der Node. Dabei wird ein Betriebssystem-Image heruntergeladen, die Festplatte partitioniert und das Image auf die Bootpartition installiert. Anschließend startet der Rechner neu.

Währenddessen kann die Konfiguration des Talos CLI angepasst werden, so dass ein Default Endpoint und eine Default Node verwendet wird. Damit müssen nicht bei jedem Aufruf die --endpoint (oder -e) und --nodes (oder -n) Parameter mit angegeben werden.

Vorbelegung von Nodes und Endpoint in der Talos Konfiguration
$ talosctl config endpoints $IP
$ talosctl config nodes $IP

Da noch kein etcd Cluster existiert, muss dieser auf einer, und wirklich nur einer, Node initialisiert werden.

Initialisierung des etcd Clusters
$ talosctl bootstrap -e $IP -n $IP

Nach einer Weil sind etcd, der Kubernetes API Server und die weiteren essentiellen Komponenten verfügbar. Der Kubernetes Cluster ist einsatzbereit!
Um auf den Kubernetes API Server zugreifen zu können, wird noch eine entsprechende Konfiguration für kubectl benötigt. Diese wird wiederumg mit talosctl generiert.
Anschließend können die Nodes im Cluster abgefragt werden. Falls dort noch NotReady steht, gilt es einen Moment zu warten, bis diese vollständig, inkl. Overlay-Network, bereitsteht.

Erzeugung von kubeconfig und Abfrage des Node Status im Hetzner Kubernetes Cluster
$ export KUBECONFIG=$PWD/kubeconfig
$ talosctl -n $IP kubeconfig
$ kubectl get nodes
NAME                STATUS     ROLES           AGE   VERSION
ubuntu-4gb-hel1-1   NotReady   control-plane   16s   v1.36.2
$ kubectl get nodes
NAME                STATUS   ROLES           AGE   VERSION
ubuntu-4gb-hel1-1   Ready    control-plane   51s   v1.36.2

Nun soll auch etwas Workload auf dem Cluster gestartet werden. Talos, bzw. Kubernetes, deaktiviert die Platzierung regulärer Pods auf Nodes der Control-Plane, um unerwünschte Wechselwirkungen zu vermeiden.
Da wir jedoch lediglich eine Node haben, wird dieser Schutz deaktiviert.

Entfernung des Control-Plane-Taint
$ kubectl taint nodes ubuntu-4gb-hel1-1 node-role.kubernetes.io/control-plane-

Nun kann ein Test-Pod gestartet werden, um zu valideren, dass alles funktioniert. Darauf kann mittels kubectl port-forward auch zugegriffen werden, um den Test zu komplettieren.

Testworkload und Zugriff durch kubectl port-forward und curl
$ kubectl run echo --image ghcr.io/trion-development/echoserver:1 --port 3000
$ kubectl get pods
NAME   READY   STATUS    RESTARTS   AGE
echo   1/1     Running   0          3m53s
$ kubectl port-forward echo 3000:3000 &
$ curl localhost:3000
(server v1)
headers
===============

host: localhost:3000
user-agent: curl/8.20.0
accept: */*


body
===============



===============
end.

Fazit

Es ist mit boot-to-talos sehr einfach, einen Kubernetes Cluster auf beliebiger Infrastruktur einzurichten. Talos ist ein sehr auf Sicherheit und Robustheit optimiertes Linux samt hoch aktueller Kubernetes Distribution. Wer bisher dachte, dass Talos nicht passt, weil komplizierte Installationsverfahren notwendig sind, oder der jeweilige Anbieter Talos nicht unterstützt, der sollte boot-to-talos unbedingt eine Chance geben.




Zu den Themen Kubernetes, Docker und Cloudarchitektur bieten wir sowohl Beratung, Entwicklungsunterstützung als auch passende Schulungen an:

Auch für Ihren individuellen Bedarf können wir Workshops und Schulungen anbieten. Sprechen Sie uns gerne an.

Feedback oder Fragen zu einem Artikel - per E-Mail an [email protected] oder über das Kontaktformular. Wir freuen uns auf eine Kontaktaufnahme!

Suche

Los geht's!

Bitte teilen Sie uns mit, wie wir Sie am besten erreichen können.