Kubernetes läuft auf Hetzner Cloud zuverlässig, aber du betreibst es selbst: Hetzner bietet (Stand 18.10.2026) keinen eigenen Managed-Kubernetes-Dienst an. Hetzner liefert die Bausteine, also Cloud-Server, private Netze, Load Balancer, Volumes und Object Storage, dazu einen offiziellen Cloud Controller Manager und einen CSI-Treiber für Kubernetes. Den Cluster selbst setzt du mit einer Distribution wie k3s auf, oder du beauftragst einen Dienstleister, der ihn auf Hetzner für dich betreibt.
Ich betreibe meine eigenen Dienste, darunter diese Website, auf einem k3s-Cluster bei Hetzner Cloud. In diesem Beitrag zeige ich, wie dieser Cluster aufgebaut ist und warum: drei Standorte, keine öffentlichen IP-Adressen an den Nodes, alles als Code. Alle meine Beiträge zum Betrieb von Kubernetes findest du gesammelt auf der Seite Kubernetes.
Bietet Hetzner Managed Kubernetes an?
Nein, nicht als eigenes Produkt. Auf hetzner.com findest du Cloud-Server, Load Balancer, Volumes, Object Storage und private Netze, aber keinen Kubernetes-Dienst, bei dem Hetzner die Control Plane für dich betreibt. Kubernetes taucht auf den Produktseiten als Anwendungsfall auf: Private Netze nennt Hetzner ausdrücklich für den „Betrieb eines Kubernetes-Clusters“, und auf die Frage, ob sich die Load Balancer in Kubernetes einbinden lassen, verweist Hetzner auf seinen offiziellen Cloud Controller Manager auf GitHub.
Wenn du nach „Hetzner Managed Kubernetes“ suchst, landest du deshalb bei zwei Arten von Treffern. Die einen sind Anleitungen und Werkzeuge, mit denen du den Cluster selbst aufbaust. Die anderen sind Dienstleister, die einen Cluster auf Hetzner-Infrastruktur für dich aufsetzen und betreiben. Das ist ein Angebot dieser Firmen, nicht von Hetzner, und du schließt den Vertrag mit ihnen.
Für die Entscheidung heißt das: Auf Hetzner bekommst du günstige, europäische Infrastruktur und volle Kontrolle über Kubernetes, trägst aber Upgrades, Sicherheit und Fehlersuche in der Control Plane selbst. Wie sich das gegen Managed Kubernetes und das eigene Rechenzentrum abgrenzt, ordne ich in Kubernetes on-premise oder Cloud? ein.
Mein Cluster im Überblick
Mein Cluster ist kein Bastelaufbau, sondern die Umgebung, auf der meine Website und meine eigenen Dienste laufen. Die Bausteine:
Im Rest des Beitrags gehe ich die Entscheidungen dahinter durch.
Hochverfügbar über drei Standorte
Die drei Control-Plane-Nodes stehen in Falkenstein, Nürnberg und Helsinki, je einer pro Standort. Die drei Nodes für die Anwendungen laufen in Falkenstein (zwei) und Nürnberg (einer). Der Grund für drei Control-Plane-Nodes: Die Steuerungsebene braucht eine Mehrheit, um Änderungen am Cluster-Zustand zu beschließen. Die k3s-Dokumentation formuliert das für eingebettetes etcd so: Ein hochverfügbarer Cluster muss aus einer ungeraden Zahl von Servern bestehen, damit etcd sein Quorum hält, und das Quorum liegt bei (n/2)+1. Bei drei Servern darf also einer ausfallen, ohne dass der Cluster handlungsunfähig wird. Ein vierter Server würde daran nichts verbessern.
Die Verteilung über drei Rechenzentren hat einen Preis, den die etcd-Dokumentation offen benennt: Jede Abstimmung muss über Standortgrenzen hinweg, das kostet Latenz, und die Daten werden zwischen allen Standorten repliziert. Für meinen Betrieb überwiegt der Vorteil, dass der Ausfall eines ganzen Standorts die Steuerung des Clusters nicht mitreißt. Fällt Falkenstein aus, fehlen allerdings zwei der drei Anwendungs-Nodes; der Cluster bleibt steuerbar, hat aber deutlich weniger Kapazität. Wenn du alle drei Server in dasselbe Rechenzentrum stellst, bist du gegen den Ausfall eines Servers geschützt, aber nicht gegen den Ausfall des Gebäudes.
Ob die Verteilung wirklich so aussieht, wie du sie geplant hast, siehst du an den Labels, die der Cloud Controller Manager an die Nodes schreibt:
kubectl get nodes -L topology.kubernetes.io/region,topology.kubernetes.io/zone
kubectl get nodes -o custom-columns=NAME:.metadata.name,ARCH:.status.nodeInfo.architecture
Der erste Befehl zeigt Region und Zone je Node, der zweite die Prozessorarchitektur. Laut Changelog des Cloud Controller Manager werden die Zonen-Labels in der nächsten Hauptversion nicht mehr automatisch gesetzt; prüfe die Projektseite, bevor du dich darauf verlässt. Bei mir steht dort überall arm64, und das hat eine Folge, die ich weiter unten erkläre.
Netz ohne öffentliche IP-Adressen
Keiner meiner Nodes hat eine öffentliche IPv4- oder IPv6-Adresse. Die Server sprechen nur über ein privates Hetzner-Netz miteinander, der Verkehr im Cluster-Netz ist zusätzlich mit WireGuard verschlüsselt. Für Administration komme ich über einen einzelnen Bastion-Host hinein, und ausgehender Verkehr, etwa zum Ziehen von Container-Images, läuft über ein NAT-Gateway, das sich bei Bedarf ebenfalls hochverfügbar aufbauen lässt.
Der Vorteil: Ein Node ist aus dem Internet schlicht nicht erreichbar, auch nicht, wenn ein Dienst versehentlich auf einem offenen Port lauscht. Die Angriffsfläche reduziert sich auf zwei Punkte, den Bastion-Host und den Load Balancer.
Von außen kommen Anfragen über einen Hetzner Load Balancer vom Typ LB11 herein, der sie an Traefik weiterreicht, den Ingress Controller, den k3s mitliefert. Zwischen beiden ist Proxy-Protocol aktiviert. Ohne diese Einstellung sähe Traefik als Absender jeder Anfrage nur den Load Balancer, mit ihr kommt die echte Client-IP an, was für Logs, Ratenbegrenzung und Fehlersuche wichtig ist. Wie Ingress und Ingress Controller zusammenspielen, erkläre ich in Kubernetes Ingress und Ingress Controller.
Betriebssystem und Updates
Auf den Nodes läuft openSUSE MicroOS, ein unveränderliches Betriebssystem mit automatischen Updates. Unveränderlich heißt: Das Grundsystem wird nicht Paket für Paket verändert, sondern als Ganzes aktualisiert, und ein fehlerhaftes Update lässt sich zurückrollen. Die Server-Images baue ich mit Packer als eigene Snapshots, sodass jeder neue Node vom selben Stand startet.
Automatische Updates brauchen gelegentlich einen Neustart. Damit nicht alle Nodes gleichzeitig neu starten, sorgt kured dafür, dass immer nur ein Node nach dem anderen geleert und neu gestartet wird. So bleibt die Mehrheit der Control Plane erhalten, und die Anwendungen ziehen vorher auf andere Nodes um.
Speicher, Datenbanken und Zertifikate
Persistente Volumes kommen über den CSI-Treiber von Hetzner, der Hetzner-Volumes als Speicher in Kubernetes einbindet. Datenbanken betreibe ich mit dem Operator CloudNativePG, der PostgreSQL-Cluster samt Replikation im Cluster verwaltet. Zertifikate für HTTPS holt und erneuert cert-manager. Wie du Volumes und den Cluster-Zustand sicherst, beschreibe ich in Kubernetes Backup: etcd und Volumes sichern.
Alles als Code: Terraform, SOPS und GitOps
Die gesamte Infrastruktur entsteht aus einem Terraform-Repository mit einem einzigen terraform apply: Netz, Server, Load Balancer, NAT-Gateway und Bastion-Host. Der Terraform-State liegt nicht auf meinem Rechner, sondern remote in Hetzner Object Storage, damit er nicht verloren geht und nicht zwei Stände auseinanderlaufen.
Secrets liegen verschlüsselt im selben Repository, mit SOPS und age. So steht jede Konfiguration nachvollziehbar in Git, ohne dass ein Passwort im Klartext darin auftaucht.
Die Anwendungen rollt ArgoCD aus. Es zieht die Helm-Values aus dem Repository und gleicht den Cluster laufend damit ab. Ein Release dieser Website besteht deshalb aus zwei Schritten: ein neues Container-Image bauen und den Image-Tag in den Helm-Values erhöhen. Den Rest erledigt ArgoCD. Wie das im Detail funktioniert, steht in GitOps mit ArgoCD: Deployments aus Git.
Beobachten und absichern
Für Metriken und Alarme nutze ich Prometheus, Grafana und Alertmanager, für Logs OpenSearch mit Fluent Bit als Sammler. Auf der Sicherheitsseite überwacht Falco das Verhalten der Container zur Laufzeit, Gatekeeper setzt Regeln durch, bevor ein Objekt im Cluster landet, und der Trivy Operator prüft laufende Images auf bekannte Schwachstellen. Das ist mehr, als ein kleiner Cluster zwingend braucht, aber es ist die Ausstattung, die ich auch für produktive Umgebungen von Unternehmen für angemessen halte. Wie du anfängst, ohne alles auf einmal einzuführen, zeige ich in Kubernetes Monitoring mit Prometheus.
Worauf du auf Hetzner achten musst
Der Cloud Controller Manager muss aktuell bleiben. Hetzner hat das Feld server.datacenter zum 01.07.2026 aus der API-Antwort entfernt. Laut Projektseite stürzen Versionen des Cloud Controller Manager bis einschließlich v1.30.0 seitdem ab; nötig ist mindestens v1.30.1. Aktuell ist v1.39.0 (06.10.2026). Das ist ein gutes Beispiel dafür, warum Selbstbetrieb Pflege bedeutet: Der Cluster läuft, bis sich unter ihm etwas ändert.
ARM-Server brauchen ARM-Images. Die CAX-Server von Hetzner haben Ampere-Prozessoren mit ARM-Architektur. Jedes Container-Image, das du dort startest, muss für arm64 gebaut sein. Die meisten verbreiteten Images gibt es für beide Architekturen, bei eigenen Images musst du das in der Build-Pipeline selbst einrichten.
Upgrades liegen bei dir. k3s folgt den Kubernetes-Versionen, aktuell ist v1.37.1+k3s1 vom 30.09.2026. Jede Kubernetes-Version bekommt laut Projekt nur etwa ein Jahr lang Patches, deshalb gehört ein regelmäßiger Upgrade-Termin in den Betriebsplan, nicht in die Liste für „wenn mal Zeit ist“.
Du musst nicht bei null anfangen. Für den Einstieg gibt es Community-Projekte, die genau diesen Weg vorbereiten, etwa kube-hetzner (Terraform, k3s, unveränderliche openSUSE-Nodes) oder hetzner-k3s (ein Kommandozeilenwerkzeug, das einen k3s-Cluster anlegt). Prüfe vor dem Einsatz, wie aktiv das Projekt gepflegt wird und ob du verstehst, was es für dich anlegt. Ein Cluster, den du nicht erklären kannst, wird dich bei der ersten Störung überraschen.
Wann du dir Hilfe holst
Ein eigener Cluster auf Hetzner ist gut machbar, wenn in deinem Team jemand Kubernetes wirklich versteht und Zeit für den Betrieb hat. Hilfe lohnt sich vor allem an drei Stellen: bevor du den Cluster aufbaust, weil Entscheidungen zu Netz, Standorten und Werkzeugen später teuer zu ändern sind; wenn ein bestehender Cluster läuft, aber niemand sicher sagen kann, ob er einen Ausfall übersteht; und wenn das Wissen an einer einzigen Person hängt.
Genau dafür biete ich Beratung, Cluster-Reviews, Betrieb sowie Schulungen und Workshops für Teams an. Was ich mache und für wen, steht auf meiner Seite Kubernetes-Experte: Beratung und Betrieb.
Häufige Fragen
Bietet Hetzner Managed Kubernetes an?
Nein, Hetzner hat (Stand 18.10.2026) keinen eigenen Managed-Kubernetes-Dienst. Hetzner liefert Server, Netze, Load Balancer, Volumes und Object Storage sowie einen offiziellen Cloud Controller Manager und CSI-Treiber. Den Cluster betreibst du selbst oder über einen Dienstleister.
Ist k3s für Produktion geeignet?
Ja, k3s ist laut Projekt eine vollständig konforme Kubernetes-Distribution für den Produktionseinsatz, nur schlanker verpackt. Ich betreibe darauf meine eigenen produktiven Dienste. Entscheidend ist nicht die Distribution, sondern der Aufbau drumherum: mehrere Control-Plane-Nodes, Backups, Monitoring und regelmäßige Upgrades.
Warum ARM-Server statt x86?
Ich nutze die ARM-Server vom Typ CAX21 mit 4 vCPUs (Ampere) und 8 GB Arbeitsspeicher. Für meine Dienste reicht die Leistung, und die Images, die ich brauche, gibt es für ARM. Wenn deine Anwendung nur als x86-Image existiert, nimmst du x86-Server; Kubernetes kann beide Architekturen auch in einem Cluster mischen.
Was kostet ein Kubernetes-Cluster auf Hetzner?
Das hängt von Zahl und Typ der Server, Load Balancer, Volumes, Object Storage und Traffic ab. Preise ändern sich, deshalb nenne ich hier keine Zahlen; rechne mit der aktuellen Preisliste auf hetzner.com. Der größere Posten ist meistens die Arbeitszeit für den Betrieb, wie ich in Kubernetes Kosten: was ein Cluster kostet zeige.
Brauche ich wirklich drei Standorte?
Nicht zwingend. Drei Server an einem Standort schützen dich gegen den Ausfall eines Servers. Wenn deine Anwendung auch den Ausfall eines Rechenzentrums überstehen soll, verteilst du die Control Plane auf drei Standorte und nimmst die höhere Latenz zwischen ihnen in Kauf.
Wie du weitermachst
Wenn du noch abwägst, ob Selbstbetrieb überhaupt zu dir passt, beginne mit Kubernetes on-premise oder Cloud? und Kubernetes im Mittelstand: Betriebsmodell. Wenn du loslegen willst, plane früh die Sicherung mit Kubernetes Backup: etcd und Volumes sichern und das Ausrollen mit GitOps mit ArgoCD: Deployments aus Git.
Mein Rat: Fang klein an, aber von Anfang an als Code. Ein Cluster, den du mit einem Befehl neu bauen kannst, nimmt dir die Angst vor jedem Upgrade.
Die Grundlagen von Architektur, Objekten und Betrieb erkläre ich ausführlich in meinem Kubernetes-Praxisbuch bei Rheinwerk. Die offizielle Anbindung an Hetzner findest du im Cloud Controller Manager von Hetzner auf GitHub, die Distribution im k3s-Projekt.
