Wozu überhaupt Kubernetes? Wer es nutzt und wofür
Kubernetes ist eine Open-Source-Plattform, die das Deployment, die Skalierung und den Betrieb containerisierter Anwendungen automatisiert – ursprünglich bei Google entwickelt, 2014 veröffentlicht und heute der De-facto-Standard für Container-Orchestrierung. Der Kernnutzen lässt sich auf drei Punkte verdichten:
- Automatische Skalierung: Bei Lastspitzen fährt der Cluster automatisch zusätzliche Instanzen hoch – und danach wieder herunter. Selbst datenintensive Organisationen wie das CERN nutzen Kubernetes, um Systeme bei plötzlichen Nachfragespitzen schnell zu skalieren.
- Self-Healing: Fällt ein Container oder sogar ein ganzer Node aus, startet Kubernetes die betroffenen Workloads automatisch neu bzw. verschiebt sie auf andere Nodes. Die Anwendung bleibt verfügbar, ohne dass jemand nachts aufstehen muss.
- Einheitlicher Betrieb: Ob Microservices-Architektur, klassische Webanwendung oder CI/CD-Pipeline – alles wird über dieselben deklarativen Konfigurationen beschrieben und läuft konsistent, unabhängig von der darunterliegenden Infrastruktur.
Typische Anwender sind entsprechend vielfältig: Teams, die eine SaaS-Anwendung oder Microservices betreiben und mit schwankender Last umgehen müssen; DevOps-Teams, die ihre Deployments automatisieren wollen; und Organisationen, die viele Anwendungen einheitlich auf gemeinsamer Infrastruktur konsolidieren. Dass die Spannbreite auch auf der Hetzner Cloud groß ist, zeigt schon ein Blick ins Ökosystem: Das populärste Community-Projekt zum Thema ist mit 5,7k Stars ausgerechnet der Guide „Kubernetes clusters for the hobbyist" – während Werkzeuge wie hetzner-k3s explizit „production-ready" Cluster versprechen. Vom Wochenendprojekt bis zum Produktivsystem ist alles vertreten.
Wer für kleine, statische Setups eine einzelne VM mit Docker Compose betreibt, braucht Kubernetes nicht zwingend. Spannend wird es, sobald Verfügbarkeit, Skalierung und Automatisierung zum Thema werden – und genau dann stellt sich die Frage: Wie baut man das auf der Hetzner Cloud richtig auf?
Kubernetes auf der Hetzner Cloud: Selbst betreiben, ohne alles selbst zu entwickeln
Wer Kubernetes auf der Hetzner Cloud betreibt, trifft eine bewusste Entscheidung: volle Kontrolle über den eigenen Cluster statt eines Managed-Angebots. Was auf den ersten Blick nach viel Handarbeit klingt, ist in der Praxis ein gut ausgebautes Ökosystem. Unter dem GitHub-Topic „hetzner-cloud" finden sich derzeit 383 öffentliche Repositories – und die beliebtesten davon sind fast durchweg Kubernetes-Werkzeuge. Allein terraform-hcloud-kube-hetzner (3,9k Stars) und hetzner-k3s (3,7k Stars) kommen zusammen auf über 7.500 Stars.
Das Fundament dafür liefern die offiziellen, quelloffenen Integrationen von Hetzner selbst: der Cloud Controller Manager, der CSI-Treiber, der Terraform-Provider und die hcloud-CLI. Sie sorgen dafür, dass sich Kubernetes-Ressourcen wie Nodes, Services und Volumes direkt in Hetzner-Cloud-Ressourcen übersetzen. Schauen wir uns die Bausteine der Reihe nach an.
Der Cloud Controller Manager: Die Brücke zur API
Der hcloud-cloud-controller-manager (HCCM) ist das Bindeglied zwischen einem Kubernetes-Cluster und den Hetzner Cloud- und Robot-APIs. Er implementiert die Schnittstellen, die Kubernetes im Upstream-Paket k8s.io/cloud-provider definiert – der Mechanismus, über den jeder Cloud-Anbieter seine eigene Logik in einen gemeinsamen Satz von Controllern einklinkt. Im HCCM übernehmen vier dieser Controller die Arbeit:
- Node Controller: Initialisiert jeden Kubernetes-Node und versieht ihn mit Metadaten wie dem Instanztyp und der Provider-ID. Diese ID ist die Server-ID aus der Hetzner Cloud bzw. dem Robot, mit dem Präfix
hcloud://oderhrobot://– die unveränderliche Verbindung zwischen Kubernetes-Node und Server.
- Node Lifecycle Controller: Beobachtet Nodes, die nicht mehr „ready" sind, prüft, ob der zugehörige Server noch existiert oder heruntergefahren wurde, und räumt Node-Objekte auf, deren Server es nicht mehr gibt.
- Routes Controller: Legt für jeden Node eine Route im Private Network an, die dessen Pod-CIDR auf seine private IP abbildet. Traffic zu Pods auf einem Node wird so direkt über das Private Network geroutet – ohne den Overhead eines Overlay-Netzwerks wie VXLAN.
- Service Controller: Erstellt und konfiguriert für jeden Kubernetes-Service vom Typ
LoadBalancerautomatisch einen Hetzner Cloud Load Balancer.
Wie aktiv an diesem Baustein gearbeitet wird, zeigt die jüngste Optimierungsrunde: Ein gemeinsamer Cache für die Node-Controller und eine ereignisgesteuerte statt zeitgesteuerte Routen-Abstimmung reduzieren die API-Requests gegen die Hetzner Cloud API um rund 76 % beim Hochskalieren und um 94 % im Ruhezustand. Die Änderung am Routes Controller wurde dabei nicht nur im HCCM umgesetzt, sondern als KEP-5237 direkt in Kubernetes selbst eingebracht – ein Beispiel dafür, wie die Arbeit an der Hetzner-Integration ins Upstream-Projekt zurückfließt. Alle Details dazu stehen im Blogartikel „How we reduced API requests in the Hetzner Cloud Controller Manager"; ab HCCM v1.33 sind sämtliche Verbesserungen enthalten.
Der CSI-Treiber: Persistenter Speicher für Stateful Workloads
Datenbanken, Message Queues, Monitoring – kaum ein produktiver Cluster kommt ohne persistenten Speicher aus. Der offizielle CSI-Treiber ist ein Container-Storage-Interface-Treiber für die Hetzner Cloud und ermöglicht ReadWriteOnce-Volumes in Kubernetes und anderen Container-Orchestratoren.
Für Anwender ist der Umgang damit reines Standard-Kubernetes: Du erstellst einen PersistentVolumeClaim mit der StorageClass hcloud-volumes und weist ihn einem Pod zu. Im Hintergrund wird daraufhin automatisch ein PersistentVolume über den CSI-Treiber bereitgestellt. Der Treiber erstellt dafür ein Hetzner Cloud Volume, hängt es an den passenden Node an und stellt es dem Pod als Speicher zur Verfügung.
apiVersion: v1kind: PersistentVolumeClaimmetadata:name: csi-pvcspec:accessModes:- ReadWriteOnceresources:requests:storage: 10GistorageClassName: hcloud-volumes
Netzwerk und Load Balancing: Der Weg des Traffics
Zwei weitere Hetzner-Cloud-Produkte vervollständigen das Bild:
Private Networks ermöglichen es, Cluster-Nodes über ein privates Netzwerk miteinander zu verbinden. Wie das Pod-Netzwerk innerhalb des Clusters aufgebaut wird, hängt von der gewählten Netzwerklösung ab. Eine Möglichkeit ist der Routes Controller des HCCM: Er legt Routen an, die die Pod-Netzwerke der einzelnen Nodes über deren private IP-Adressen erreichbar machen.
Load Balancer bilden den Eingang von außen. Der Service Controller des HCCM verwaltet sie automatisch: Ein Service vom Typ LoadBalancer im Cluster genügt, und der passende Hetzner Cloud Load Balancer wird erstellt und konfiguriert. In typischen Setups nimmt er den Traffic aus dem Internet entgegen und leitet ihn über das Private Network an einen Ingress Controller wie Traefik auf den Worker Nodes weiter.
Das Community-Ökosystem: Vier Wege zum Cluster
Auf diesen offiziellen Bausteinen setzt ein bemerkenswert aktives Community-Ökosystem auf. Diese Projekte stechen heraus:
terraform-hcloud-kube-hetzner (3,9k Stars) verspricht „optimiertes und wartungsfreies Kubernetes auf Hetzner Cloud mit einem Befehl" und setzt auf Terraform in Kombination mit k3s, der schlanken Kubernetes-Distribution.
hetzner-k3s (3,7k Stars) verfolgt ein ähnliches Ziel als eigenständige CLI: Nach eigener Beschreibung der einfachste und schnellste Weg zu produktionsreifen Kubernetes-Clustern auf Hetzner Cloud, ebenfalls auf k3s-Basis.
Talos-basierte Setups gehen einen anderen Weg beim Betriebssystem: Talos ist ein minimales, API-gesteuertes OS, das ausschließlich für Kubernetes gebaut ist. Neben dem Terraform-Modul terraform-hcloud-talos (349 Stars) existiert mit dem hcloud-k8s-Kubernetes-Modul ein Weg, der im offiziellen Community-Tutorial für private Cluster zum Einsatz kommt.
cluster-api-provider-hetzner (1,1k Stars) ermöglicht es, Kubernetes-Cluster auf der Hetzner Cloud und Bare Metal Servern deklarativ zu erstellen und zu verwalten. Das Projekt basiert auf Kubernetes Cluster API und richtet sich vor allem an erfahrene Anwender, die ihre Cluster automatisiert betreiben möchten.
Dazu kommen die offiziellen Hetzner-Integrationen, die in fast allen diesen Setups im Hintergrund zum Einsatz kommen: der Terraform-Provider (728 Stars), die hcloud-CLI (1,8k Stars) – und natürlich HCCM und CSI-Treiber selbst. Eine Übersicht über weitere Kubernetes-Projekte auf der Hetzner Cloud findest du in der Kubernetes-Kategorie unserer awesome-hcloud Liste.
Eine Referenzarchitektur für den Produktivbetrieb
Wie sieht ein produktionsreifer Cluster konkret aus? Das Community-Tutorial „Private Kubernetes cluster via Terraform and Talos" zeigt eine Architektur, die alle Bausteine zusammenführt:
- Drei Control-Plane-Nodes für eine hochverfügbare Steuerungsebene (etcd, kube-apiserver, kube-scheduler)
- Worker Nodes ohne öffentliche IPs, verteilt über Placement Groups, damit die VMs auf unterschiedlicher physischer Hardware laufen
- Ein Private Network (z. B. 10.21.0.0/16) als Rückgrat des Clusters
- Eine Egress-VM als NAT-Gateway, über die die privaten Nodes das Internet erreichen – und über die per SSH auch kubectl und talosctl laufen
- Ein Hetzner Load Balancer, verwaltet von Kubernetes, als Eingangspunkt für ingress-nginx
- Longhorn für verteilten persistenten Speicher, cert-manager für TLS-Zertifikate
- Cluster Autoscaler, der bei Bedarf zusätzliche Worker Nodes provisioniert
Für die automatische Skalierung auf der Hetzner Cloud gibt es einen offiziellen Cloud Provider für den Kubernetes Cluster Autoscaler. Er ermöglicht es, bei Bedarf automatisch zusätzliche Cloud Server als Worker Nodes bereitzustellen. Werden diese nicht mehr benötigt, kann der Autoscaler sie wieder entfernen. So passt sich die Infrastruktur dem Ressourcenbedarf deiner Anwendungen an.
Wer noch weiter Richtung Hochverfügbarkeit gehen will, verteilt Worker Nodes und Load Balancer über mehrere Standorte und ergänzt redundante Egress-VMs. Das Tutorial beschreibt beide Ausbaustufen Schritt für Schritt.
Welcher Weg passt zu welchem Projekt?
Die Wahl des richtigen Ansatzes hängt weniger von der Clustergröße ab als von den eigenen Anforderungen:
- Schnell zum lauffähigen Cluster: Wer mit minimalem Aufwand starten will, greift zu hetzner-k3s oder terraform-hcloud-kube-hetzner. Beide liefern in kurzer Zeit einen Cluster inklusive der offiziellen Integrationen.
- Infrastructure as Code mit maximaler Härtung: Talos-basierte Terraform-Setups spielen ihre Stärken aus, wenn ein unveränderliches, rein API-gesteuertes Betriebssystem und ein vollständig privater Cluster gewünscht sind – wie in der Referenzarchitektur oben.
- Volle Kontrolle über jede Komponente: Wer seinen Cluster von Hand oder mit eigenen Automatisierungen aufbaut, installiert HCCM und CSI-Treiber direkt und entscheidet selbst über jedes Detail – von der Netzwerktopologie bis zur Storage-Strategie.
- Deklarative Cluster-Verwaltung: Wer Kubernetes-Cluster automatisiert erstellen, verwalten und aktualisieren möchte, findet mit dem Cluster API Provider Hetzner eine Kubernetes-native Lösung für Cloud und Bare Metal.
Alle vier Wege haben das gleiche Fundament: Cloud Controller Manager, CSI-Treiber, Private Networks und Load Balancer. Wer versteht, wie diese Bausteine zusammenspielen, kann jedes der Werkzeuge bewusst einsetzen – und im Fehlerfall gezielt debuggen.
Fazit
Kubernetes auf der Hetzner Cloud ist ein Zusammenspiel aus offiziellen Open-Source-Integrationen und einem lebendigen Community-Ökosystem. Der HCCM übersetzt Kubernetes-Konzepte in Cloud-Ressourcen, der CSI-Treiber liefert persistenten Speicher, Private Networks und Load Balancer bilden das Netzwerk-Fundament – und Projekte wie kube-hetzner, hetzner-k3s oder die Talos-Module machen daraus in kurzer Zeit einen produktionsreifen Cluster. Wer tiefer einsteigen will, findet auf GitHub alle Projekte im Quelltext und in der Hetzner Community über 350 Tutorials – vom ersten Cluster bis zur hochverfügbaren Multi-Location-Architektur.
