Kubernetes auf Hetzner aufbauen oder übernehmen lassen? WZ-IT wählt den Bereitstellungsweg passend zu Team und Workloads, baut den Cluster auf Hetzner Cloud oder Dedicated Servern und betreibt ihn auf Wunsch. Kubernetes auf Hetzner ansehen
Die Provisionierung eines Kubernetes-Clusters auf Hetzner läuft über vier dokumentierte Wege: das Terraform-/OpenTofu-Modul kube-hetzner, das CLI hetzner-k3s, Talos Linux (mit talosctl oder dem Community-Modul hcloud-talos) und für dedizierte Server den Cluster API Provider Hetzner. Dieser Vergleich stützt sich ausschließlich auf Repositories, Releases, Lizenzdateien und Dokumentation der Projekte, abgerufen am 28.10.2026. Stand Oktober 2026. Einordnungen, die kein Beleg sind, stehen als solche da.
Inhaltsverzeichnis
- Was alle Wege gemeinsam haben
- Projektstatus im Vergleich
- Betrieb: Upgrades, Rollback und Backup
- Plattformen: ARM64 und dedizierte Server
- Die Wege im Einzelnen
- Welcher Weg zu welchem Team passt
- Stand und Methodik
- Unser Vorgehen bei WZ-IT
- Weiterführende Guides
Was alle Wege gemeinsam haben
Alle Wege verbinden Kubernetes über dieselben zwei Hetzner-Komponenten mit der Plattform. Der Cloud Controller Manager (CCM, Apache-2.0, v1.39.2 vom 22.10.2026) bindet die Hetzner-Cloud- und die Robot-API an und legt Load Balancer für Services vom Typ LoadBalancer an. Der CSI-Treiber (MIT, v2.24.1 vom 22.10.2026) stellt Cloud Volumes als ReadWriteOnce-Volumes bereit. Beide Projekte bauen Images für amd64 und arm64 (CCM, CSI). Der Cluster API Provider Hetzner kann beide Komponenten ebenfalls einsetzen; für Bare Metal empfiehlt seine Dokumentation derzeit statt des Hetzner-CCM den CCM-Fork von Syself, bis ein Upstream-Release die Korrektur zum Robot-Namensabgleich enthält. Drei Eigenschaften gelten unabhängig vom Werkzeug:
- Storage auf Robot-Servern: Der CSI-Treiber funktioniert dort nicht. Dedizierte Worker brauchen eigenes Storage, zum Beispiel Longhorn oder Rook-Ceph (Vergleich). Der CCM unterstützt für Robot-Server keine Routen; das CNI übernimmt die Pod-Netze.
- Kubernetes-Versionen: Der CCM unterstützt laut Versionsrichtlinie die jeweils drei neuesten Kubernetes-Versionen. Für Kubernetes 1.34 bis 1.37 gilt die neueste CCM-Version, für 1.33 die Version v1.37.0.
- Add-on-Versionen: Welche Version im Cluster läuft, legt das Werkzeug fest. kube-hetzner v3.2.1 hinterlegt CCM 1.33.0 und CSI 2.21.2 als Standard (Quelltext, abgerufen am 28.10.2026). Die Konfigurationsreferenz von hetzner-k3s nennt dieselben Versionen als Manifest-URL. Ältere Versionen können Funktionen verlieren: CCM bis v1.30.0 setzt bei neu initialisierten Nodes seit dem 01.07.2026 keine Zone- und Region-Labels mehr (Hinweis im README).
Projektstatus im Vergleich
| kube-hetzner | hetzner-k3s | Talos Linux | |
|---|---|---|---|
| Art | Terraform-/OpenTofu-Modul | CLI mit YAML-Datei | Betriebssystem mit talosctl; auf Hetzner per CLI oder Community-Modul hcloud-talos |
| Lizenz | MIT | MIT | MPL-2.0; hcloud-talos: MIT |
| Aktueller Release | v3.2.1 (09.09.2026) | v2.7.0 (25.10.2026) | v1.14.5 (26.10.2026); hcloud-talos v4.1.4 (26.10.2026) |
| Jüngere Releases | v3.0.0 (06.07.), v3.1.0 (08.08.), v3.2.0 (31.08.2026) | v2.5.0 (07.05.), v2.6.0 (24.06.2026) | v1.14.0 (03.09.), v1.14.2 (29.09.2026) |
| Pflege | Open-Source-Projekt, nicht mit Hetzner verbunden | laut README von einem Entwickler gepflegt | Sidero Labs, optional kommerzieller Support; Hetzner ist Plattform der Stufe 3 |
| Distribution | k3s oder RKE2 | k3s | Upstream-Kubernetes (1.33 bis 1.37 mit Talos 1.14) |
| Node-Betriebssystem | openSUSE Leap Micro (MicroOS für Bestandscluster) | Ubuntu 24.04, andere Images per ID | Talos Linux ohne SSH und Shell |
| Voraussetzungen | OpenTofu oder Terraform, Packer, kubectl, hcloud | das CLI, Hetzner-Token, SSH-Schlüssel | talosctl, Image, Endpunkt für die Kubernetes-API (zum Beispiel Load Balancer) |
Quellen: kube-hetzner README und Releases, hetzner-k3s Releases, Talos Releases und Support Matrix, hcloud-talos README.
Betrieb: Upgrades, Rollback und Backup
| kube-hetzner | hetzner-k3s | Talos Linux | |
|---|---|---|---|
| Kubernetes-Upgrade | system-upgrade-controller, automatisch oder per Node-Label | hetzner-k3s upgrade, danach Jobs prüfen und create erneut ausführen (Doku) |
talosctl upgrade-k8s, vorab mit --dry-run (Doku) |
| Betriebssystem-Update | transaktional, Neustarts über Kured | Drain, Update, Neustart; Kured optional | talosctl upgrade mit neuem Image |
| Rollback des Betriebssystems | BTRFS-Rollback des transaktionalen Systems | in der Doku nicht beschrieben | A/B-Image, Rückfall bei Boot-Fehler, manuell mit talosctl rollback (Doku) |
| Änderungen am Cluster | tofu plan und apply; Major-Sprung mit Migrationsanleitung |
YAML ändern, create erneut ausführen |
Maschinenkonfiguration anwenden oder patchen |
| etcd-Backup | S3-Snapshots über etcd_s3_backup (Doku) |
Snapshot-Zeitplan, optional S3 | talosctl etcd snapshot, Zeitplan selbst einrichten (Doku) |
| Zustand | Terraform-/OpenTofu-State | YAML-Datei, laut Doku kein Terraform-State | Maschinenkonfiguration und Secrets; bei hcloud-talos im State |
Zwei Details aus der Dokumentation beeinflussen den Alltag. Bei hetzner-k3s ist der Befehl create nach einem Upgrade ausdrücklich nötig, damit neue Nodes direkt mit der neuen k3s-Version entstehen. Bei Talos 1.14 wird das Installer-Image nicht mehr unter ghcr.io/siderolabs/installer veröffentlicht, sondern über die Image Factory als factory.talos.dev/metal-installer/<schematic-id>:<version> ausgeliefert; Upgrade-Skripte mit dem alten Pfad müssen angepasst werden.
Plattformen: ARM64 und dedizierte Server
| kube-hetzner | hetzner-k3s | Talos Linux | |
|---|---|---|---|
| ARM64 (CAX) | x86 und ARM mischbar (Support Matrix) | ARM-Pools über Image-ID | amd64 und arm64; Image je Architektur |
| Dedizierte Server | Robot-Server als zusätzliche Agents über vSwitch (Doku), Einstufung „Advanced/special-case" (Support Matrix) | externe Worker-Pools mit provider: robot, seit v2.6.0; privates Netz seit v2.7.0; Debian oder Ubuntu (Doku) |
Plattform „Metal" (Stufe 1) per ISO oder PXE; die Hetzner-Anleitung beschreibt nur die Cloud |
| Control Plane | Hetzner Cloud | Hetzner Cloud | Cloud oder Metal |
| CCM und CSI | im Modul, feste Standardversionen | im Tool, per manifest_url änderbar |
selbst installieren |
Bei Talos auf Hetzner Cloud liefert Hetzner seit dem 23.04.2025 ein öffentliches ISO, dessen Aktualisierung nach Best Effort erfolgt. Eigene Images entstehen im Rescue-Modus, mit Packer oder mit hcloud-upload-image. Das Community-Modul hcloud-talos weist darauf hin, dass einzelne Hetzner-ISOs im metal-Modus statt hcloud gestartet sind, was falsche Provider-IDs und fehlerhafte CCM-Routen erzeugt (Issue 417); es empfiehlt eigene Snapshots.
Für reine Bare-Metal-Cluster ist der Cluster API Provider Hetzner (CAPH, Apache-2.0, v1.1.10 vom 22.10.2026) der vierte Weg. Er verwaltet Cloud und Bare Metal, setzt einen Management-Cluster voraus und basiert auf kubeadm; die Node-Images brauchen Container-Runtime, kubelet und kubeadm. Das Projekt wird von Syself und der Community gepflegt, nicht von Hetzner. Die mitgelieferten Bare-Metal-Flavors sind laut Dokumentation nur für Demonstrationen gedacht und nicht für den Produktivbetrieb. Das Tutorial in der Hetzner Community (Autor: Syself) empfiehlt für Produktion eine eigene Konfiguration mit Load Balancing, Fehlertoleranz, Netzwerksicherheit und Hardening.
Die Wege im Einzelnen
kube-hetzner beschreibt den Cluster als Modul im Infrastruktur-Code: Control-Plane- und Agent-Pools, privates Netz, Firewall, Load Balancer und Add-ons. Das Modul läuft mit OpenTofu und Terraform; wie sich beide unterscheiden, behandelt der Leitfaden Terraform zu OpenTofu migrieren. Zu beachten sind State und Modulversionen: Der Wechsel von v2 auf v3 hat eine eigene Anleitung, die vor dem Apply jeden geplanten Destroy oder Replace prüfen lässt. Die Support-Matrix führt k3s auf Leap Micro als stabilen Standard und RKE2 als unterstützte Variante.
hetzner-k3s legt Server, Firewall und privates Netz an, installiert k3s und richtet CCM, CSI, System Upgrade Controller und Cluster Autoscaler ein. Alles steht in einer YAML-Datei. Zwischen v2.6.0 (24.06.2026) und v2.7.0 (25.10.2026) liegen vier Monate, und die Pflege liegt laut README bei einem Entwickler. Wer Cluster mit dem CLI betreibt, sollte diese Abhängigkeit in der Bewertung berücksichtigen.
Talos entfernt SSH und Shell; jede Änderung läuft über die API. Auf Hetzner Cloud setzt das Team Image, API-Endpunkt (Load Balancer), CCM und CSI selbst auf, oder nutzt das Community-Modul hcloud-talos, das Netzwerk, Cilium, CCM und Talos-CCM bereitstellt. Das Modul benennt Grenzen: Änderungen an user_data und Image werden auf bestehenden Nodes nicht angewendet, Kubernetes-Upgrades laufen über talosctl upgrade-k8s, und die unterstützten Talos-Versionen sind an Kubernetes-Bereiche gebunden (Talos 1.14.3 und neuer mit Kubernetes 1.32 bis 1.37). Zu Talos selbst siehe Was ist Talos Linux? und den Vergleich k3s vs. RKE2 vs. Talos; die Automatisierung mit OpenTofu auf Proxmox zeigt Talos auf Proxmox mit OpenTofu.
Welcher Weg zu welchem Team passt
Die folgende Tabelle ist eine Einordnung von WZ-IT. Die Spalte „Beleg" nennt die Dokumentationsgrundlage.
| Ausgangslage | Naheliegender Weg | Beleg |
|---|---|---|
| IaC-Routine mit Terraform oder OpenTofu, mehrere Umgebungen aus Code | kube-hetzner | Modul im State, Kured und System Upgrade Controller, OS-Rollback |
| Ein bis wenige Cluster, kein IaC-Stack, Ubuntu erwünscht | hetzner-k3s | eine YAML-Datei, kein Terraform-State; kein OS-Rollback beschrieben |
| Kein SSH auf Nodes, API-gesteuerte Konfiguration, A/B-Rollback | Talos | Hetzner Stufe 3, CCM und CSI selbst installieren, talosctl-Routine nötig |
| Dedizierte Server als Worker neben Cloud-Control-Plane | hetzner-k3s oder kube-hetzner | Robot-Pools bzw. vSwitch-Anleitung; CSI funktioniert dort nicht |
| Cluster aus dedizierten Servern, deklarative Verwaltung | Cluster API Provider Hetzner | Management-Cluster nötig, Flavors nur Demo |
| Kleines Team ohne Betriebskapazität für Upgrades und Backups | Betrieb durch Dritte | bei allen Wegen bleiben Restore-Tests, Monitoring und Add-on-Pflege beim Betreiber |
Vor der Entscheidung sind sechs Fragen zu klären:
- Wer führt das nächste Kubernetes-Upgrade aus, und mit welchem Befehl?
- Wer aktualisiert CCM und CSI, und wann?
- Wo liegt der etcd-Snapshot, und wann wurde er zuletzt zurückgespielt? (Backup und Restore)
- Sind Control Planes auf mehrere Standorte verteilt?
- Welche Quellen dürfen auf Kubernetes-API, SSH oder Talos-API zugreifen?
- Brauchen Worker dedizierte Server, und welches Storage trägt dort die Volumes?
Stand und Methodik
Die Tabellen geben den Stand vom 28.10.2026 wieder. Release-Daten stammen aus den GitHub-Releases der Projekte, Lizenzen aus den LICENSE-Dateien, Funktionen aus README und Dokumentation im jeweiligen Repository. Gemessen wurde nichts: keine Geschwindigkeit, keine Kosten, keine Stabilität. Wo die Dokumentation einen Punkt nicht beschreibt, steht „nicht beschrieben", nicht „nicht möglich". Die Tabelle zur Teamgröße ist eine Bewertung. Versionsnummern und Einstufungen ändern sich; der Artikel nennt für jede Zahl die Quelle.
Quellen, abgerufen am 28.10.2026:
- kube-hetzner: README, Support Matrix, Upgrades, Robot-Anleitung, locals.tf v3.2.1
- hetzner-k3s: README, Doku zu Cluster, Wartung, externen Nodes
- Talos Linux: Releases; Doku zu Hetzner, Upgrades, Support Matrix
- hcloud-talos und Cluster API Provider Hetzner: README und Dokumentation
- Hetzner Cloud Controller Manager und CSI-Treiber: README, Versionsrichtlinie, Robot-Hinweise
Unser Vorgehen bei WZ-IT
Wir klären zuerst Workloads, Ausfallziele, Team und vorhandene Infrastruktur-Pipeline, dann den Weg. Aufgebaut wird der Cluster auf Ihren Hetzner-Ressourcen: Cloud, Dedicated oder beides, mit privatem Zugang zur API, GitOps und getesteten Backups. Der Betrieb eines bestehenden oder neuen Clusters ist als Managed Kubernetes ab 590 € je Cluster und Monat netto inklusive 3 Worker-Nodes buchbar (Stand Oktober 2026), jeder weitere Worker-Node kostet 129,90 €. Monitoring erfolgt 24/7, die Reaktion auf P1-Incidents erfolgt entsprechend Service Level. Ein bereits laufender Cluster lässt sich vor der Übernahme mit dem Cluster-Audit prüfen; das Vorgehen beschreibt die Audit-Checkliste. Die Übersicht zu Architektur, Netzwerk und Storage auf Hetzner steht in Kubernetes auf Hetzner.
Weiterführende Guides
- Kubernetes auf Hetzner - Cloud, Bare Metal oder Proxmox, Netzwerk, Load Balancer und Storage
- k3s vs. RKE2 vs. Talos - Distributionen im Vergleich
- Was ist Talos Linux? - Betriebsmodell ohne SSH
- Terraform zu OpenTofu migrieren - Migrationsleitfaden für den Infrastruktur-Code
- Kubernetes-Backup und Restore - die vier Ebenen
- MetalLB vs. kube-vip - Load Balancing auf Bare Metal
Cluster auf Hetzner aufbauen oder den Betrieb übernehmen lassen? WZ-IT plant Cloud-, Dedicated- und Hybrid-Cluster und betreibt sie nach Service Level. Kubernetes auf Hetzner · Managed Kubernetes
