Kubernetes auf Hetzner als vollständige Anwendungsplattform aufbauen? WZ-IT plant und betreibt Cluster auf Hetzner Cloud, Dedicated Servern oder Proxmox - inklusive Netzwerk, GitOps, Monitoring, Backup und privatem Zugriff. Kubernetes auf Hetzner ansehen
Kubernetes lässt sich auf Hetzner in drei grundlegenden Modellen betreiben: auf Cloud-VMs, direkt auf Dedicated Servern oder innerhalb einer Proxmox-Umgebung. Die Modelle unterscheiden sich weniger bei Kubernetes selbst als bei Provisionierung, Ausfallgrenzen, Storage, Load Balancing und der Verantwortung für den Cluster-Lifecycle.
Hetzner stellt dafür Infrastruktur und offizielle Kubernetes-Integrationen bereit. Die Plattform wird jedoch selbst oder durch einen Betriebspartner aufgebaut. Wer nach "Managed Kubernetes auf Hetzner" sucht, sollte deshalb zuerst klären, ob nur eine verwaltete Control Plane oder ein vollständiger Betrieb einschließlich GitOps, Monitoring, Backups und Workloads gemeint ist.
Inhaltsverzeichnis
- Drei Betriebsmodelle im Vergleich
- Kubernetes auf Hetzner Cloud
- Kubernetes auf Dedicated Servern
- Kubernetes auf Proxmox bei Hetzner
- Netzwerk und sichere Zugänge
- Load Balancer und Ingress
- Storage, Datenbanken und Backups
- GitOps, Updates und Observability
- Welche Architektur passt?
Drei Betriebsmodelle im Vergleich
| Modell | Eigenschaften | Typische Eignung | Zusätzliche Verantwortung |
|---|---|---|---|
| Hetzner Cloud | API-gesteuerte VMs, Networks, Load Balancer und Volumes | Dynamische Node-Pools, standardisierte Plattformen, schneller Aufbau | Control Plane, Nodes, CNI, GitOps, Policies und Workloads |
| Dedicated Server | Feste physische Leistung, lokale NVMe, keine Hypervisor-Schicht | Dauerhafte Grundlast, datenintensive Workloads, planbarer Ressourcenbedarf | Provisionierung, Hardwaretausch, Load Balancing und Storage-Architektur |
| Proxmox auf Dedicated Servern | Kubernetes-Nodes als VMs auf einer Virtualisierungsschicht | Gemischte VM- und Container-Landschaften, Trennung mehrerer Umgebungen | Proxmox- und Kubernetes-Lifecycle sowie deren gemeinsame Kapazitätsplanung |
Ein viertes Modell kombiniert Cloud-VMs und Bare Metal. Der Cluster API Provider Hetzner kann beide Ressourcentypen deklarativ verwalten. Diese Flexibilität erhöht allerdings auch die Zahl der Komponenten, die aktualisiert, überwacht und im Fehlerfall verstanden werden müssen.
Kubernetes auf Hetzner Cloud
Bei einer Cloud-Architektur laufen Control Plane und Worker auf Hetzner-Cloud-Servern. Der offizielle Hetzner Cloud Controller Manager verbindet Kubernetes mit den Hetzner Cloud- und Robot-APIs. Der CSI-Treiber stellt Hetzner Cloud Volumes über Kubernetes StorageClasses bereit.
Eine vollständige Plattform benötigt darüber hinaus mindestens:
- ein CNI wie Cilium oder Calico,
- einen Ingress Controller oder die Kubernetes Gateway API,
- DNS- und Zertifikatsautomatisierung,
- eine Container Registry,
- GitOps mit Argo CD oder Flux,
- Metriken, Logs und Alerting,
- Backup und getestete Wiederherstellung,
- eine dokumentierte Upgrade-Strategie.
Cloud-VMs vereinfachen das automatisierte Erstellen und Ersetzen von Nodes. Eine vollständige Application Platform ergänzt den Cluster um GitOps, Ingress, Zertifikate, Observability, Backup, Security Policies und geregelte Upgrade-Prozesse.
Kubernetes auf Dedicated Servern
Dedicated Server geben Kubernetes direkten Zugriff auf CPU, RAM und lokale NVMe-Laufwerke. Das kann für konstante Grundlast, Build-Workloads, Datenverarbeitung oder zustandsbehaftete Dienste wirtschaftlich und technisch passend sein.
Die Gegenleistung ist ein größerer eigener Verantwortungsbereich. Das offizielle Hetzner-Community-Tutorial zu Kubernetes auf Bare Metal weist ausdrücklich darauf hin, dass Load Balancing, Fehlertoleranz, Netzwerksicherheit, Hardening und CSI-Storage zusätzlich konfiguriert werden müssen.
Für einen produktiven Aufbau sind insbesondere zu klären:
- Wie werden Server reproduzierbar installiert und ersetzt?
- Wo laufen die Control-Plane-Knoten und ihr API-Endpunkt?
- Wie werden Hardware- und Rechenzentrumsausfälle abgegrenzt?
- Welche Daten liegen lokal, repliziert oder auf externem Storage?
- Wie lange dauert die Wiederherstellung eines Nodes oder einer ganzen Region?
Cluster API kann den Maschinen-Lifecycle automatisieren. Es ersetzt trotzdem keine Kapazitäts-, Storage- und Recovery-Architektur.
Kubernetes auf Proxmox bei Hetzner
Proxmox ist keine Voraussetzung für Kubernetes. Die Kombination ist dann sinnvoll, wenn eine Hetzner-Dedicated-Infrastruktur neben Kubernetes auch klassische VMs, Appliances, Datenbankserver oder getrennte Kundenumgebungen aufnehmen soll.
Kubernetes-Nodes werden dabei als VMs bereitgestellt. Das schafft klar definierte virtuelle Ressourcen und erleichtert das standardisierte Provisionieren von Control Plane und Workern. Gleichzeitig entstehen zwei Betriebsplattformen:
- Proxmox verantwortet Compute, virtuelle Netzwerke, Storage und VM-Verfügbarkeit.
- Kubernetes verantwortet Scheduling, Service-Netzwerk, Deployments und Workload-Zustand.
Backups auf VM-Ebene und Kubernetes-Backups erfüllen unterschiedliche Aufgaben. Ein VM-Snapshot ersetzt weder konsistente Datenbank-Backups noch die Sicherung von Kubernetes-Ressourcen und Persistent Volumes. Die Schichten müssen gemeinsam getestet werden. Details beschreibt der Artikel Kubernetes auf Proxmox.
Netzwerk und sichere Zugänge
Produktionscluster sollten Management-, Node- und Workload-Verkehr nicht ungeplant über öffentliche Netze führen. Eine typische Architektur trennt:
- privaten Verkehr zwischen den Nodes,
- den Kubernetes-API-Zugang für Administratoren und Automation,
- öffentliche Anwendungseinstiege,
- private interne Anwendungen und Verwaltungsdienste,
- ausgehenden Verkehr und gegebenenfalls feste Egress-Adressen.
Die Kubernetes-API, Argo CD, Grafana oder interne Services können über NetBird als privaten Zugriffspfad erreichbar sein. Öffentliche Anwendungen erhalten dagegen kontrollierte Ingress- oder Gateway-Endpunkte. So wird nicht jeder Betriebsdienst nur deshalb öffentlich, weil das Team remote arbeitet.
Load Balancer und Ingress
Auf Hetzner Cloud kann der Cloud Controller Manager Kubernetes-Services vom Typ LoadBalancer mit Hetzner Cloud Load Balancern verbinden. Dahinter übernimmt ein Ingress Controller oder Gateway die Verteilung auf Anwendungen.
Auf Bare Metal ist dieser Pfad nicht automatisch vorhanden. Je nach Architektur kommen externe Load Balancer, HAProxy, kube-vip oder MetalLB infrage. Die Auswahl hängt davon ab, ob öffentliche IPs, BGP, Layer-2-Erreichbarkeit oder ein vorgeschaltetes Netzwerk verfügbar sind. Bereits bei der Planung muss feststehen, wie ein Load-Balancer-Ausfall behandelt und wie TLS terminiert wird.
Storage, Datenbanken und Backups
Für Cloud-Nodes stellt der Hetzner CSI-Treiber persistente Volumes bereit. Für Bare Metal oder Proxmox sind lokale Volumes, Ceph, Longhorn, Rook, NFS oder externe Storage-Systeme mögliche Bausteine. Keiner davon ist pauschal die richtige Wahl.
Die Entscheidung folgt dem Datenmodell:
- Darf ein Volume an einen anderen Node verschoben werden?
- Welche Latenz und IOPS benötigt die Anwendung?
- Repliziert die Datenbank selbst oder soll die Storage-Schicht replizieren?
- Welche Recovery Point und Recovery Time Objectives gelten?
- Wohin werden Backups kopiert, wenn der Cluster oder Standort ausfällt?
Ein Kubernetes-Backup umfasst mindestens Cluster-Ressourcen, Persistent-Volume-Daten und anwendungskonsistente Datenbank-Backups. Restore-Tests gehören zum Betriebsplan, nicht nur zum Einführungsprojekt.
GitOps, Updates und Observability
Kubernetes-Versionen und Plattformkomponenten haben eigene Release-Zyklen. Deshalb wird der gewünschte Zustand versioniert und automatisiert ausgerollt. Ein typischer Betriebsstack enthält:
- Terraform oder OpenTofu für Hetzner-Ressourcen,
- Cluster API, Ansible oder Talos für den Node- und Cluster-Lifecycle,
- Argo CD oder Flux für Plattform und Anwendungen,
- Prometheus und Grafana für Metriken,
- Loki oder einen vergleichbaren Stack für Logs,
- Alertmanager und definierte Reaktionswege,
- Velero und anwendungsspezifische Backup-Werkzeuge.
Entscheidend ist nicht die Länge der Werkzeugliste, sondern ein dokumentiertes Ownership-Modell: Wer aktualisiert Kubernetes, wer prüft Backups, wer reagiert auf Alarme und wer verantwortet die Anwendung?
Welche Architektur passt?
| Ausgangslage | Naheliegender Startpunkt |
|---|---|
| Neue Plattform mit dynamischen Workern | Hetzner Cloud mit API-gesteuertem Provisioning |
| Konstante, rechenintensive Grundlast | Dedicated Worker mit automatisiertem Lifecycle |
| Bestehender Proxmox-Cluster und gemischte Workloads | Kubernetes-Nodes als standardisierte VMs |
| Mehrere Anwendungen, aber kaum internes Plattformteam | Betreuter Cluster mit klar abgegrenztem Leistungsumfang |
| Eine kleine Anwendung auf einem Server | Zuerst Docker Compose oder Coolify mit Kubernetes vergleichen |
WZ-IT verbindet bei Bedarf Hetzner-Infrastruktur, Kubernetes-Plattform, NetBird-Zugriff, GitOps und Managed Operations in einem Verantwortungsmodell. Die Architekturentscheidung wird aus Workloads, Ausfallzielen, Daten, Team und Budget abgeleitet.
